Just let me give my 2ct: as somebody that did search for hiring EEs and mechanical engineers, I really searched hard for the ones that DID soldered, pulled wires and welded, even for management positions. They use to manage much better, had better communication with the team, had better feeling for quality, could look much further in the furure and had much more authority, were way more respected by the team.
That being said, another 2ct:
> A software Engineer needs to have all phases of the SDLC in mind, and be thinking about and planning all of them. Code is a tiny piece of the puzzle.
I would not AT ALL call it tiny. Yes, is one part of MANY. But is your final delivery. Would be like Toyota saying: “hey they don’t really have to understand what makes a good car, the cars we sell is a tiny portion in the whole development cycle”. SW engineers do need to tell apart good from bad code, as much as good from bad tests and good from bad requirements. After all, if I somehow manage to deliver good SW (working and documented) I don’t gove a crap how the requirements and teat work or don’t in the company.
I remember a professor who used to say “If the requirements, design, test plan and acceptance criteria are done to a high enough standard, the code can be written by a monkey.”
Which is exactly what we’re seeing now with LLMs writing code.
Interestingly you’ll see the same building a mega bridge or skyscraper. As long as the plan has been done well, it can be assembled by relatively very unskilled labor.
Note the test plan and acceptance criteria could be one and the same, depending.
> If the requirements, design, test plan and acceptance criteria are done to a high enough standard, the code can be written by a monkey.
Nice sentence. But it has 2 problems:
1) Define "high enough" - There is where good requirements start, make it measurable! (How much is going to cost?)
2) Related to "you’ll see the same building a mega bridge or skyscraper". I've seen enough cases where "unskilled labor" messed up building something. You will reply "that is why I said 'Acceptance Criteria'!". My take is: you are making it far more complicated than it should, taking totally unnecessary risks, and it will be invariably more expensive in the long run.
I mean, I've seen enough examples of cases where the acceptance criteria was not properly checked, because also the ones doing the test were "unskilled" and had received a "perfect plan". (Just look at any infrastructure disaster we have every year)
And even in the best case: you discover the poured cement does not meet the specifications. What now? Blow the thing and start over? Better to have skilled labor.
Again, my 2ct. experience: hire experienced people, who actually have done the work all the way down to the lowest level.
"If you think knowledge is expensive, try with ignorance"
That being said, another 2ct:
> A software Engineer needs to have all phases of the SDLC in mind, and be thinking about and planning all of them. Code is a tiny piece of the puzzle.
I would not AT ALL call it tiny. Yes, is one part of MANY. But is your final delivery. Would be like Toyota saying: “hey they don’t really have to understand what makes a good car, the cars we sell is a tiny portion in the whole development cycle”. SW engineers do need to tell apart good from bad code, as much as good from bad tests and good from bad requirements. After all, if I somehow manage to deliver good SW (working and documented) I don’t gove a crap how the requirements and teat work or don’t in the company.
Which is exactly what we’re seeing now with LLMs writing code.
Interestingly you’ll see the same building a mega bridge or skyscraper. As long as the plan has been done well, it can be assembled by relatively very unskilled labor.
Note the test plan and acceptance criteria could be one and the same, depending.
That "if" is doing an unrealistic amount of lifting, here, in practice, and that's probably why human coders have had a better run than monkeys.
Nice sentence. But it has 2 problems:
1) Define "high enough" - There is where good requirements start, make it measurable! (How much is going to cost?)
2) Related to "you’ll see the same building a mega bridge or skyscraper". I've seen enough cases where "unskilled labor" messed up building something. You will reply "that is why I said 'Acceptance Criteria'!". My take is: you are making it far more complicated than it should, taking totally unnecessary risks, and it will be invariably more expensive in the long run.
I mean, I've seen enough examples of cases where the acceptance criteria was not properly checked, because also the ones doing the test were "unskilled" and had received a "perfect plan". (Just look at any infrastructure disaster we have every year)
And even in the best case: you discover the poured cement does not meet the specifications. What now? Blow the thing and start over? Better to have skilled labor.
Again, my 2ct. experience: hire experienced people, who actually have done the work all the way down to the lowest level.
"If you think knowledge is expensive, try with ignorance"