Scott Adams has a way of thinking about this that he casts as "Systems vs Goals", where he advocates developing a talent stack of skills that work well together towards unspecified, undefined future goals. He says his talent stack is comedian+cartoonist, he's not amazing at either individual skill but he's one of the best at the combination which allowed him to create Dilbert.
I got value from this way of thinking but I also think specific goals are necessary (e.g. as a startup founder targeting a specific market, product or vision) and that there are some domains that demand you to be the best in a single talent vertical due to a winner take all tendency (e.g. athelete, musician, professional gambler - although in any of these we can still distinguish systems & talent stacks from goals).
Skills one might think have nothing in common can have surprising intersections.
For example, my training as a mechanical engineer and 3 years spent working on a gearbox design for the 757 have had a significant positive effect on my programming and the design of the D language.
Can you please comment on the advantages and the effect on your programming?
Do you think these advantages are common among those who have (mech/electrical/chem/etc.) engineering education and training who move into software development?
1. Code that looks right should be right, code that looks wrong should be wrong. (I know this sounds trite, but there are many examples.)
2. When a program self-detects a fault in its logic, it must stop immediately, as it no longer will be in a known state. (It's still common practice to imagine one can recover from an assertion failure. I've spent many, many hours trying to convince other programmers of this.)
3. Better education will not prevent programming bugs. Better process and mechanical checking will. (This notion has been gaining a lot of momentum.)
> Do you think these advantages are common among those who have (mech/electrical/chem/etc.) engineering education and training who move into software development?
Heck, they haven't even trickled into the nuclear power industry (Fukushima), the oil business (Deepwater Horizon), or the automobile industry (Toyota surging problem). Those disasters taught lessons learned by the aviation industry decades earlier.
Perhaps I should amend my earlier statement that it's experience in the aviation business that I've taken over to software. My engineering training was mostly about math, not cutting metal and the nut behind the wheel.
I appreciate the principles, thank you for sharing them.
I started my career in automotive manufacturing before becoming a business analyst on a team developing in-house business automation tools. The program I studied did cover an engineering design process. We were taught to quantify design requirements (subject to a static load of this much, must be within these dimensions, and so on) and use a combination of calculations, simulations, and prototypes to check we are meeting those design specifications.
I am assuming that you would have done something similar in aerospace. If so, have you carried over any of that into software development? Do you have any guidance or D design documents you can point to? The D specification is the final product, but I’m trying to gain a better understanding of how one gets to that final specification.
You're right, we did this a lot at Boeing. I am very proud of the fact that none of my designs needed to be modified once the metal was cut, and it all passed test and certification without any problems.
Software development, on the other hand, lends itself very well to iterative development. You don't have problems like sinking a new forging die costing half a million bucks, so work really diligently to not need to scrap a die. Keep making mistakes like that, and Boeing will move you to a position where you get to design ash trays.
3. Better education will not prevent programming bugs. Better process and mechanical checking will.
I don't know if this is what you meant by mechanical checking, but I highly rate two things to reduce bugs:
(1) Checking that the output of the entire system is 100% (and I meant 100% literally in every sense of the word) accurate, not just that the smaller unit tests pass or that the output "looks right".
(2) Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.
As a dev with a data science background, I'm always impressed how many bugs pure devs are able to smuggle in whenever the task involves any kind of data, despite extensive unit testing. I check out their code, run it once, and immediately see the output is wrong and then they have to go back and debug. If we just check our output that wouldn't be the case!
int[10] a;
a[10] = 3; // Error, array index out of bounds
The idea is to allow powerful metal code, while providing constructs that make errors much less likely. For example,
if (a < b < c)
is allowed by C, but few C programmers can tell you what it means, and the appearance of it in code is almost always a bug. Instead of educating programmers with "don't do that", D makes it illegal. (If you really want it, you'd have to write it as: `(a < b) < c`. But notice you have to make an effort to write code that way, it is highly unlikely to be accidentally written.)
> Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.
I find it useful to go back through the logic a couple months later. I usually find a lot to improve :-)
I think Adam's approach is mostly lacking deliberation, it's only after the fact that the synergy is realized but it's hard to intentionally engineer it.
I can definitely see the validity in the other school of thought though; i.e. that we should deliberately seek out synergistic talent verticals. I know this is Conor Mcgregor's approach, he's very much systems over goals (in Adam's vein, and explicitly so) but is deliberate about the specific talent stack he's working towards. Ironically it is all done towards a specific goal (to be the best fighter) although the path towards that goal is underspecified.
Here's a very common talent stack here on HN that works pretty well: math + CS + data science + one domain (e.g. finance or biology).
I got value from this way of thinking but I also think specific goals are necessary (e.g. as a startup founder targeting a specific market, product or vision) and that there are some domains that demand you to be the best in a single talent vertical due to a winner take all tendency (e.g. athelete, musician, professional gambler - although in any of these we can still distinguish systems & talent stacks from goals).