> Software engineering is more that knowing the API for product A or B.
You're confusing software engineering for computer science.
Software engineering on average is indeed knowing the APIs of a few frameworks or products well.
You're confusing software engineering for computer science.
Software engineering on average is indeed knowing the APIs of a few frameworks or products well.
One of those habits could be how to generally solve a problem, versus how to just duct-tape together a solution. If we don't understand something from first principles, we don't really understand it in my opinion.
I'm lucky to mostly work with people who're both good at their craft, as well as good at "getting the job done". For me personally it would be frustrating to be subjected to massive tech-debt generation and sub-optimal solutions just because the team is unwilling to step outside a walled garden.
How many modern developers have written a single line of assembly yet alone written production assembly code? How many have even written C or used any other language that doesn’t have garbage collection.
Everyone who started working on a technology before abstractions make it more accessible think that you really need to understand deeper to be effective.
I had to get out of that mode of thinking myself as I’ve been in the software field either as a hobbyist or professionally for 35 years and I did start off writing assembly as a hobbyist (and some as a professional) and spent a decade writing C.
But then, I also see the same attitude from old school infrastructure guys now that I live part of my life on that side of the world when they say I really need to understand the “fundamentals” of IT and I can’t possibly be effective as a consultant if my only experience standing up infrastructure is writing a yaml file.
At the end of the day not everyone needs to understand the fundamentals to get their work done and create business value no more than your software as a service CRUD developer needs to know how to reverse a binary tree on the whiteboard.
If you're building a dog house or even a shed, that'll be plenty. But I've seen developers try to take a knowledge of framework alone and attempt to build large-scale, business-critical applications, and they tend to come crashing down around their heads.
Part of my role at my last two companies was to know what to outsource and what to build internally and when to outsource the grunt work - ie decide what “the undifferentiated heavy lifting” was.
There are many different ways that people master a profession, and sure, in the best of all possible worlds people would learn under the guidance of expert mentors who supply "guard-rails" for the work of people they mentor.
In reality, however, that's not always possible. Many of us don't have the benefit of a safety net or benevolent deity, we just wing it, fail, learn, and try again. It's not always pretty, but it works, eventually. Someone who is a Dunning-Kruger poster-boy one year may very well become your MVP a couple years later.
If people don't push the limits of their capabilities (which often means failure), they'll not be able to grow.
I actually would have said that is the main thing that distinguishes a "programmer" from both a "computer scientist" and a "software engineer". Programmers are the tradespeople who know the APIs. Computer scientists know the science of the algorithms. Engineers know the design principles and systematic methodologies to apply them in practice successfully (independent of specific APIs). Of course, all this is blurred in practice.