9 ms·
I'm partial to the O-ring explanation. Software engineering is uniquely multiplicative because it's possible for a software engineer to create software that doe
by kenhwang 9y ago
I'm partial to the O-ring explanation. Software engineering is uniquely multiplicative because it's possible for a software engineer to create software that does software engineering.
Chemical/electrical/mechanical engineers can't use their field to automate their field. Doctors and lawyers are almost exclusively service jobs, unlike the manufacturing nature of engineering.
Automation is a force multiplier, and software engineering benefits from being able to create automation, apply automation to others, as well as being able to apply automation to itself.
- litzer 9y ago> Software engineering is uniquely multiplicative because it's possible for a software engineer to create software that does software engineering. I think you misunderstood the O-ring explanation by citing that idea as an example. It doesn't mean building AI. It applies to any of those fields you mentioned. Good people in field X work together with other good people in field X in top firms -> multiplicative productivity.
- Kiro 9y agoWho said anything about AI?
- litzer 9y agoMost people would consider software that "does software engineering" AI.
- Swizec 9y agoA compiler is software that does software engineering. Saves a lot of time and effort. Package managers, that used to be hard to do by hand. Bundlers and linkers, that stuff used to need skilled engineers. Many other examples
- gaius 9y agoChemical/electrical/mechanical engineers can't use their field to automate their field. A mechanical engineer designing a new manufacturing technique or robot is most certainly using their field to automate their field. Most of computing exists because electronic engineers used their field to automate their field. Software is not unique in this respect.
- Arwill 9y agoEvery field is working to automate their field with the help of software. For which you need software developers. The article raises the question of why people are hired as software developers even if they don't have such a degree. Its because companies see it as an automation problem and not as a software engineering problem. That is also why quality or experience of the developer is irrelevant most of the time, there is no one else to judge it, so if its working then its working.
- gaius 9y agoEvery field is working to automate their field with the help of software. For which you need software developers. Right, but let's be clear about our terminology here. Automation in mechanical/manufacturing isn't being done by CS grads with skills in RoR employed as software developers. It's being done by MechEng graduates armed with FORTRAN compilers who write a lot of code but don't consider themselves to be developers at all.
- kenhwang 9y agoA rose by any other name would smell as sweet. How different is a MechEng writing FORTRAN for mechanical engineering from a MechEng writing RoR for trendy widget bean button SV startup? I'd argue they're both programming, which is sufficient to reap some of the benefits of automation. Software engineering can be described as applying engineering to programming. Any company that benefits from programming would also benefit from the increases in efficiency, reliability, performance, etc. software engineering would bring to programming.
- xevb3k 9y agoThis feels like it could quickly descend in to self congratulation. So to cast this in a different light perhaps another way to think about this is that programming is just becoming a basic skill, like reading, writing, basic mathematics required for all disciplines. Most dedicated software engineers exist because this new basic skill hasn’t yet gained widespread adoption as a basic skill in other disciplines. But with time it will, and the number of dedicated software engineers required will decline.
- Supernaut 9y agoIt takes a child several years in full-time education to learn how to fluently read and write. Basic mathematics takes even longer. Similarly, a typical person will become a skilled and highly productive software engineer only through spending several years working full-time at the profession, ideally with the assistance of one or more mentors. Having only a basic grasp of the concepts behind programming does not enable anyone to achieve anything particularly useful, and someone working in a different profession will not have the time or energy to acquire the skills needed to roll their own applications, unless they're an unusually dedicated hobbyist.
- watwut 9y ago> Similarly, a typical person will become a skilled and highly productive software engineer only through spending several years working full-time at the profession, ideally with the assistance of one or more mentors. Having only a basic grasp of the concepts behind programming does not enable anyone to achieve anything particularly useful [...] You can create basic good looking iOS or web or android app without all those years and be extremely useful. Many jobs and positions don't require years of study with mentors. Many self taught programmers started like that. You can do basic data analytics and write selects without years or study too. There is huge amount of positions that don't require years of study.
- Supernaut 9y ago> You can create basic good looking iOS or web or android app without all those years and be extremely useful. We obviously have differing definitions of the word 'useful'.
- olavk 9y agoYeah, but the questions is if creating tools (software that does software engineering) is so complex that only a few developers can do it well? Otherwise this tool creation would still be subject to market prices just as regular development.
- usrusr 9y agoYou are looking at differences between developers, but try pretending for a while that they are all the same, moderately qualified to adapt to any environment. I'm pretty sure that you would still see roughly the same distribution, since all environments are not created equal, and neither are the different positions inside those environments. The stagnant bog of billing hours to captive (e.g. internal) customers for example does not lend itself very well to a toolmaking microsingularity. Bimodality of pay is at least as much about the task as it about the one one executing. There is of course still a lot of correlation between ability and high value positions, but that's a natural consequence of matchmaking: both high value positions and high value developers get disproportional choice relative to their lesser peers.
- SomewhatLikely 9y agoI am too, and it seems testable, at least for large companies. Are the salaries bimodal within companies or not? If not, then the hypothesis would seem to hold water.