Programmer vs Software Engineer: Defining the True Professional
Shouldn't we put an end to the so-called self-taught programmers phenomenon or at least draw a visible line between what is called a programmer and what is called a software engineer? Self taught...
Shouldn't we put an end to the so-called self-taught programmers phenomenon or at least draw a visible line between what is called a programmer and what is called a software engineer?
Self taught developers can be software engineers. Almost all software engineers are self taught, in fact. It just so happens that some of them also earned a degree somewhere along the way.
For the most part you aren't taught how to program, or how to design software architecture. You learn it or you don't. Classes just point you in the right direction and tell you what you need to learn.
Yes, there are some things you can be taught. And there are many more things you can learn by working in industry. But most of the skills come from observing how things have been done by others and building up your own mental model and software development patterns.
On the other hand, in my opinion, not all people who call themselves programmers are software engineers, degree or otherwise.
Heck, many don't even really qualify as programmers 1. And yet they somehow get jobs and copy-paste their way through getting things “done” — as in, it sort of works so ship it! — creating disasters along the way.
We do seem to have a problem in this industry in that a significant fraction—maybe more than half?—of the “experts” don't actually have the core skills required to program. Those folks can potentially contribute alongside software engineers, but they are being asked to do the job of a software engineer without the skill to do it well.
And as such we have an embarrassingly pathetic record of high profile project failures that's unequaled in pretty much any other industry. Certainly any other branch of engineering.
A software engineer should be able to deterministically create software that works. It shouldn't be a compete guess. It shouldn't be so insecure that the first 14-year-old techie who tries to finds glaring vulnerabilities. It should be robust enough that it can hold up to expected load, or at least be able to be quickly modified to handle expected load.
Yes, as in every other engineering discipline, it should also be expected to go over budget. I understand the average for construction projects is about 30% over budget, though I've certainly heard of worse examples, especially when they involve building roads.
A huge difference in software is that we often don't really know what we're building when we first estimate the project, and after it's partway built based on the original customer requirements they realize there are serious problems that need to be addressed and require major changes.
But the rest? A software engineer should be able to get things right, or close to right, the first time. Major exception: Developing genuinely new tech is R&D, and no one can accurately predict how long R&D will take, in any industry. That's kind of the point.