What Makes a Great Software Engineer (Dissertation) (2016) [pdf](faculty.washington.edu)
faculty.washington.edu
What Makes a Great Software Engineer (Dissertation) (2016) [pdf]
https://faculty.washington.edu/ajko/dissertations/Li2016Dissertation.pdf
54 comments
Here are some slides summarizing the shorter paper this is based on:
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.
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.
Thats a very handy link, thanks.
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?
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?
check "recommended readings" on the right:
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.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.
Thank you very much, I'll check that out
also check this about building/growing S3 at Amazon - quite some socio-technical points:
https://www.allthingsdistributed.com/2023/07/building-and-op...
https://www.allthingsdistributed.com/2023/07/building-and-op...
We certainly know what makes bad developers:
* 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.
* 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.
* decision anxiety - agree
* 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
* 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
Not always insisting upon measuring is not the same thing as an inability to measure when it would actually help.
People tend to preference their bias because they cannot execute more objectively and then frame that against a collection of logical fallacies and other nonsense as justifications and equivocations.
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.
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.
>who said this is something that is necessary at all stages?
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.
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.
Decision anxiety, measuring things, and a preference toward bias are basically all you need to skewer anyone who has a different opinion than you. If they want more data they are anxious if you want more data they rush to an opinion.. Then they are either wasting your time with measurements when the project is done or not taking improvement seriously.
Nonsense. Just be honest that you have either evidence or a hypothesis. If you are in charge make an arbitrary decision or defer to the person that is in charge. Everything else is posturing by people that cannot perform, typically due to an irrational fear or some face saving silliness.
There's certainly many dimensions along these lines that if you don't think about them in relation to the type of software development you are doing, and what you have done, you will take a long time to improve.. But this being the model for all software development (such that all others are bad) strikes me as a missing chapter from printf.
https://ferd.ca/the-little-printf.html
https://ferd.ca/the-little-printf.html
Sure there are always edge cases and unknowns. Additionally we each have a limited capacity for condition variability. All of that can be qualified away by people who have prior experience. By prior experience I don't mean ample work history (vague), but people who have participated in a given scenario in the past (highly specific).
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.
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.
[deleted]
That was a good read. I appreciate you sharing!
It's interesting how your list contains points that are almost duplicates of each other:
- 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
- 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
> * preference towards bias
I do prefer those things I'm biased towards.
I do prefer those things I'm biased towards.
Also I've never known anyone who has no bias. Even if such people existed, it's not a given that they would make the best decisions. I would imagine the best decisions are made by those who have a good set of preferences and opinions based on experience.
I also like the things you're biased towards. :)
Bad management can easily incentivize all of those things, with the possible exception of neglecting assertion criteria.
All those are traits of subservient people that non-technical managers like
> What makes a great sw engineer?
> ...
> Abstract:... we interviewed Microsoft software experts...
That's a meme right there!
That's a meme right there!
[deleted]
I jumped straight the the Personality section and sure got a nice dopamine hit reading the list of attributes of what makes a great engineer.
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.
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.
"At a high level, our informants described great software engineers as people who are passionate about their jobs."
Curious to know this group's thoughts: Do you believe that passion is NECESSARY to be a "great" software engineer?
Curious to know this group's thoughts: Do you believe that passion is NECESSARY to be a "great" software engineer?
To some degree.
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".
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".
Yes. Earlier in careers, passion can lead to more time and energy towards growth, which is a strong contributor to becoming a great engineer.
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.
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.
I doubt passion is needed to execute at a "great" level once the skills are built to do so, but I think it's pretty likely that passion play an important role at building the capability
In my experience with the people that I have worked with over many years, the best software engineers were always that ones that had a personal interest in software and programming and not just "assembly-line programmers". So I do think that passion plays a large role in the difference between adequate/good and "great".
yes for sure. you can't be good at something you don't give a shit about and only there for money.
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 .
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 .
I loved the "3.3.1 Personality" section, with 18 attributes.
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.
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.
What do you guys think of the UW information school, where this thesis is from?
Are/were you a prof at UW?
I was 6 years ago but in math.
Did you make SageMath? I used it a bunch in college. It was/is such a cool tool. There was a LaTeX plugin or something and I used it to grade students papers. It's also how I learned about hardware and software precision. Along with a whole bunch of other stuff.
Also very much thought it was cool to know someone can nerd out on math and skateboard.
Also very much thought it was cool to know someone can nerd out on math and skateboard.
It doesn't seem to have much of a connection to the well-known UWCSE.
Are you asking for bias?
There was also a very interesting and popular HN post a few days ago from the ischool about how to better incorporate AI in teaching.
Curiosity & daily Attempts to Invent something.
> We interview 59 expert Microsoft software engineers to inductively understand what software engineering expertise entailed. We survey 1,926 more expert Microsoft software engineers to understand the relative importance of the 45 attributes of expertise derived from interviews, as well as to understand the influence of context on rating
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.
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.
cindylmcindy(1)
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.