8 ms·

It’s interesting there are so many different answers given to this question whenever it is asked. If we asked, “What makes a good surgeon?” or as pointed out in

It’s interesting there are so many different answers given to this question whenever it is asked. If we asked, “What makes a good surgeon?” or as pointed out in another comment, “What makes for a great basketball player?” it seems that there would be less debate. It seems to me that this debate is related to another question, “Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?” If you could build a skyscraper according to rules limited only by our imagination, then perhaps we’d see a lot more of them collapsing. And given that frequency of failure, we’d see a lot more debate about what makes for excellence in skyscraper-building. Maybe a better question to ask is, “What makes for a poor software engineer?” That question seems a lot easier to answer. A poor engineer takes a long time to write unreadable, unmaintainable, buggy code that only partially solves problems that no one has. Ironically, such code often goes unnoticed by its very nature: it takes a lengthy period of time to even come into existence, when it does exist it is so buggy that its failure seems related to bugs rather than that it solves no problems, and the unreadable nature of the code is mistakenly attributed to essential complexity rather than incidental. And that last point is where I think we get closest to an answer: Good engineers reduce complexity. Bad engineers magnify complexity. Tolstoy wrote, “All Happy families resemble one another, but each unhappy family is unhappy in its own way.” It seems to me that the same could be said of software engineers.

Ygor 6y ago
"Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?" I think this is a great question to use as a thought exercise. We don't see the designs that fail, as they don't pass the review? Using the analogy of software engineering being the design stage (vs build/construction stage), this would be a closer comparison. How many skyscraper designs fail before they end up being "uptaken". Also, just because buildings don't collapse and fail catastrophically, I assume there are many flaws in the design that get "worked around" during construction. Many flaws (bugs) do likely end up "in production", but they are more of a technical debt type of issue that will be a burden for building maintenance and/or future tenants.
- PretzelFisch 6y ago
  watch engineering disasters or extreme engineering and you will find a discipline that has failed and learned from mistakes for hundreds of years.
- dekhn 6y ago
  https://en.wikipedia.org/wiki/Citigroup_Center#Engineering_crisis_of_1978 https://en.wikipedia.org/wiki/Citigroup_Center#Engineering_c...
watwut 6y ago
> "Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?" The massive amount of regulation surrounding skyscrapers building. Including legal responsibility.
- mgkimsal 6y ago
  Yep. In our cowering space, a fire marshal comes by to make inspections. If we're not up to snuff, we'll get closed down. I can not imagine too many software projects where people will submit to random audits and accept total shutdown if they don't meet specific criteria.
  - mgkimsal 6y ago
    coworking space...
- deleted 6y ago
  [deleted]
austincheney 6y ago
So many of the thought exercises present in your comment are missing rather obvious validations. Why do we not ask this of other professions? Because other professions have metrics and regulatory bodies. Why are no skyscrapers falling? Because they are well regulated and required a huge infusion of cash to build. A software company with such a large cash infusion is also likely to not fail. Software engineers are best analyzed on a bell curve and once identified according to such plotting relative to other developers the criteria becomes clear. The problem, for many people, is that selective bias prevents people from seeing the objective distinctions. If not for those blinders the question of what makes an excellent software engineer is largely self answered.
- Ologn 6y ago
  > Software engineers are best analyzed on a bell curve and once identified according to such plotting relative to other developers the criteria becomes clear Absolutely. Four out of six software engineers are average and interchangeable - they get tickets of average complexity done, and make mistakes, some of which are caught by other average programmers in code reviews. One out of six engineers is junior, or is effectively junior, and is a drag on teams until they get up to speed. They can only do simple tickets, every pull request must be carefully monitored etc. One of six engineers is one standard deviation above the rest. If a new system or module or library is to be built, the team defers to them for architecture. They notice subtle problems others miss. They are up to date on the stack and know what features and problems are coming down the road. They tend to do the needed work outside of what the standard ticket requires. One feature I have noticed about engineers one or more deviations above the mean is their focus, when needed, on the build system. They work to make a simple, working, fast as possible build. If the build is breaking, or gets too complex, they will address the problem in the build system and then get back to work.
- sombremesa 6y ago
  > Software engineers are best analyzed on a bell curve and once identified according to such plotting relative to other developers the criteria becomes clear. So how are you plotting this bell curve without having criteria to begin with? Sounds like you already decided what you were looking for.

Ygor 6y ago

"Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?" I think this is a great question to use as a thought exercise. We don't see the designs that fail, as they don't pass the review? Using the analogy of software engineering being the design stage (vs build/construction stage), this would be a closer comparison. How many skyscraper designs fail before they end up being "uptaken". Also, just because buildings don't collapse and fail catastrophically, I assume there are many flaws in the design that get "worked around" during construction. Many flaws (bugs) do likely end up "in production", but they are more of a technical debt type of issue that will be a burden for building maintenance and/or future tenants.

PretzelFisch 6y ago
watch engineering disasters or extreme engineering and you will find a discipline that has failed and learned from mistakes for hundreds of years.
dekhn 6y ago
https://en.wikipedia.org/wiki/Citigroup_Center#Engineering_crisis_of_1978 https://en.wikipedia.org/wiki/Citigroup_Center#Engineering_c...

watwut 6y ago

> "Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?" The massive amount of regulation surrounding skyscrapers building. Including legal responsibility.

mgkimsal 6y ago
Yep. In our cowering space, a fire marshal comes by to make inspections. If we're not up to snuff, we'll get closed down. I can not imagine too many software projects where people will submit to random audits and accept total shutdown if they don't meet specific criteria.
- mgkimsal 6y ago
  coworking space...
deleted 6y ago
[deleted]

austincheney 6y ago

So many of the thought exercises present in your comment are missing rather obvious validations. Why do we not ask this of other professions? Because other professions have metrics and regulatory bodies. Why are no skyscrapers falling? Because they are well regulated and required a huge infusion of cash to build. A software company with such a large cash infusion is also likely to not fail. Software engineers are best analyzed on a bell curve and once identified according to such plotting relative to other developers the criteria becomes clear. The problem, for many people, is that selective bias prevents people from seeing the objective distinctions. If not for those blinders the question of what makes an excellent software engineer is largely self answered.

Ologn 6y ago
> Software engineers are best analyzed on a bell curve and once identified according to such plotting relative to other developers the criteria becomes clear Absolutely. Four out of six software engineers are average and interchangeable - they get tickets of average complexity done, and make mistakes, some of which are caught by other average programmers in code reviews. One out of six engineers is junior, or is effectively junior, and is a drag on teams until they get up to speed. They can only do simple tickets, every pull request must be carefully monitored etc. One of six engineers is one standard deviation above the rest. If a new system or module or library is to be built, the team defers to them for architecture. They notice subtle problems others miss. They are up to date on the stack and know what features and problems are coming down the road. They tend to do the needed work outside of what the standard ticket requires. One feature I have noticed about engineers one or more deviations above the mean is their focus, when needed, on the build system. They work to make a simple, working, fast as possible build. If the build is breaking, or gets too complex, they will address the problem in the build system and then get back to work.
sombremesa 6y ago
> Software engineers are best analyzed on a bell curve and once identified according to such plotting relative to other developers the criteria becomes clear. So how are you plotting this bell curve without having criteria to begin with? Sounds like you already decided what you were looking for.