What Makes a Great Software Engineer (Dissertation) (2016) [pdf]
faculty.washington.edu
faculty.washington.edu
My view of GSEs:
- Wiliness to test hypotheses, listen to others, seeks input and feedback, and maintain metrics to decide if various methods are or aren't working.
- Minimal ego.
- Curiosity about things at lower levels.
- Mastery of first principles and able to create data structures and algorithms optimized for specific, difficult problems.
- Ability to debug up and down the stack quickly.
- Concern for stability and usability by consumers of products and services maintained and delivered.
- Ability to teach and mentor.
- Ethical integrity refusing to compromise or exploit users for short-term business gain.
https://web.archive.org/web/20170809055122id_/https://learni...
tl;dr They did a qualitative survey of what other people think makes a great software engineer at Microsoft.
Their take aways:
- The ability to learn is more important than any individual technical skill
- Making good decisions is rarely discussed in the software engineering literature, but it is critical to being a great software engineer
- Software engineering is a sociotechnical undertaking
- Delivering the code is often insufficient; complex contextual technical considerations abound.
The whole 'sociotechnical' part is gaping black hole for most new devs I meet, because it's not taught, and I don't know that schools know how to teach it.
Anyone have any internal processes (or resources) for helping newbs understand that side of the job?
https://www.svilendobrev.com/rabota/
starting from Organisational patterns, down. Skip anything there about design/ architecture/ math.
But: have in mind Conway's law - software-produced <=> organisation's-culture. So you can't dismiss entirely either of the two extremes of the socio-techical (human-machine) systems.
IMO, Winnie the Pooh has much more sociotechnical hints than CS university course.
https://www.allthingsdistributed.com/2023/07/building-and-op...
* decision anxiety
* fear of writing original ideas, both natural language and code
* the inability to measure things
* preference towards bias
* cognitive conservatism
* inability to form assertion criteria
Real engineers proceed on the basis of evidence and in the absence of evidence make arbitrary original decisions as necessary to gather evidence.
* fear of writing original ideas, both natural language and code - agree
* the inability to measure things - who said this is something that is necessary at all stages? sometimes you just need it done. when you have 1000 people teams selling to enterprises, sure. If it is you and your buddies, no need to measure, necessarily.
* preference towards bias - Why? If it works, a good engineer won't go to the newest tech/framework. They will stay with their biased favorite.
* cognitive conservatism - Disagree. See previous comment
* inability to form assertion criteria - Not exactly sure what you mean, but if you mean to reason about code and state at various points, then I agree
The inability to measure things results in a lot of really bad output often in preference for emotional comfort. This and cognitive conservatism are the most clearly identifiable criteria of poor cognitive performance by people who are in over their heads. I saw this at every employer when I wrote JavaScript for a living.
The inability to form assertion criteria means a person has absolutely no idea how to qualify a decision logically.
In most of these people tend to do Y at much greater cost because they cannot do X. The most common answer to this is anxiety and then people twist themselves into knots to somehow qualify that anxiety in a way that makes sense to themselves.
understanding when you don't need to measure is important too. If you are just making a small 2d app as a hobby with no more than maybe 100 draw calls on hardware that exceeds that of a potato: I probably won't waste much time with optimization schemes and just crank something out.
But that same app may want to be kept as small as it feels so I would focus more on any assets being compressed.
> inability to form assertion criteria - Not exactly sure what you mean
I took it as testing. Unable to understand what you're trying to solve, frequency of usage for such functions/modules, the amount of reach your code will have (only used once in a small module? Code code that he core multiple layers up will rely on?) and not considering potential edge cases. More or less similar to what you said.
I do prefer those things I'm biased towards.
- fear of original ideas = cognitive conservatism = preference towards bias
And kind of opposites:
- decision anxiety = results from, or brings about, too much measuring
So, I guess those can be digested to say that engineers are:
- Innovative - Make informed decisions
The problem space there comes from only two considerations. The first of which is a team where nobody has the required prior experience. In that case confidence drops in proportion to the increase of uncertainty, but that does not necessarily result in an increase of anxiety. Some people and/or work cultures are much better positioned than others to confront stress directly without distressing towards anxiety.
The second consideration is the collision between prior experience and evidence. In this case both the evidence and the prior experience must be considered and an alternate conclusion must be reached. That alternate conclusion is the definition of truth according to John Stuart Mills.
That's a meme right there!
It is a hard truth though that a lot of those personality traits lead to behaviours that are not aligned with small to medium enterprise (SME) needs, particularly ones that hire engineers and yet are not, at their core (in their couer) tech companies.
The big, great tech companies have their business units ride on the coat tails of great engineers and the engineers thrive in a stable maximum.
Great product companies can have great engineers fulfilling product needs, but the long term trend, without constant and frankly impossible levels org vigilance, will be for their engineering culture to devolve into mediocrity. SME product companies don’t stand a chance.
Curious to know this group's thoughts: Do you believe that passion is NECESSARY to be a "great" software engineer?
Or, perhaps, consider it in reverse. If you don't have passion, if you don't care about the software, if it's just a 9-to-5 job to you, how likely are you to do great work?
I don't think you have to have an obsessive, does-nothing-but-code-and-sleep kind of passion to be great, or at least moderately great. But you have to care about your craft, about the quality of the code you produce, or you won't produce anything approaching "great".
Also being a "great software engineer" doesn't get you money more than being "good at people" so ppl who are great are doing it for love .
For more experienced engineers, I think about it as skill vs motivation. In theory one doesn't need motivation to do great work. In practice, I haven't seen great work from folks with high skill but low motivation.
You could take any five of those attributes, any five sections, cut and paste them into a blog, and it would be a nice but middling post. Five good things to be reminded of. Nice quotes.
Probably a good post for applying to lots of other jobs besides software engineering.
But a comprehensive list of 18 distinct attributes becomes more. The extremely tight intersection you get from all 18 personality constraints creates the clearest picture of a "great software engineer" that I have found yet.
Comprehensive coverage adds depth and clarity all its own. Bravo.
Also very much thought it was cool to know someone can nerd out on math and skateboard.
I'm sorry... but only interviewing engineers from one company makes this a complete joke. I stopped reading after I saw that.
I don't understand how anybody could take any conclusions here seriously when they're obviously so fundamentally biased.