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?
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.
* 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
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.
>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.
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.
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.
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 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.
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.
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
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".
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".
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.
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.
> 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.
The people you described in your comment - if they found your description on-the-nose and were offended - would they not be the type to try to solve their problem by attacking the messenger?
Your comment read to me like an attempt to energize and motivate. It didn't seem to have "substance". How does your comment help me improve my understanding of what compromises a good engineer? Instead it seems to suggest I shut down my mind, stop doing the work, and feel like I've already won before I've even started. Yet, improving as an engineer has come with a lot of work, challenging myself to get more specific, be concrete and appropriately detailed, as well as thinking through "but really... How would that work throughout the complete causal chain with no shortcuts?".
I won't claim there aren't downsides but there is a utility to the expectation.
Hopefully you find ways it can help you grow.
Any leetcoders I have hired have turned out to be one trick ponies and actually aren't very creative or think from first principles. I have been in the industry for 21 years now and I know my opinion is shared by many others.
I also ponder what it means that u can graduate with a cs degree that essentially leet code companies don't trust, hence they test you. What does this say about the university system? I could see asking ppl from "lower tier" unis to take a test but applying leet code across thr board surely has to weed out really good candidates who are generally fast learners and are smart.
I'm just a bystander so I can't say why people are down-voting.. and considering they're unlikely to return and read your follow-up question, let alone respond, I think we can safely assume we won't know.
But since you're asking, and it seems with more sincerity than your initial comment, I can offer my view.
First, though, I need to point out something about HN karma that's a bit different than reddit or elsewhere. I include this because it was a shock to me at first, and your account is new enough you may not have gotten used to it yet, either. And it's that nobody cares about how much karma anyone has. It's used as a basic filter for allowing downvotes and it's visible in someone's profile, but what I mean is that there isn't a lot of farming going on. At least, in general. Partly because it's so much work with little pay-off, I think. You can't get easy karma from a quick laugh or posting something controversial. You can't even be sure that a news item you post will get enough attention to try and get easy comment points from. The kinds of comments that would get easy karma on Reddit are more likely to get downvoted here, and maybe it's reactionary but I am pretty sure it's not personal. I like how you can't downvote any responding comments, even if you can downvote. Anyway, it's not a perfect system but I can say I stopped going to reddit when I came to appreciate the better parts of HN commentary.
One of the things that can trigger a lot of downvotes is criticism without substance. Even if it's a valid commentary on the society or politics involved. And, if it's a little off topic, that can trigger some downvotes too. It takes a real gem of a comment and good timing to get more than a few upvotes, and you never really know how many upvotes someone else's comment got unless they tell you. tbh some of my comments that I put a decent amount of time and thought into never got an upvote, but I'm rarely surprised at getting too many upvotes for a comment.
The audience here tends to favor original thought, and are easily dismissive of comments that are overly dismissive of the news post it is commenting on.
Tying this all back to the fine article, which I'll admit to not having read, but whose topic I can claim some of my own opinions on, because I've been fortunate enough to work with a range of talent there. I think one of the hallmarks of a great engineer is to have partitioned off the creation from the creator enough that they never take personal offense to any criticism of their design or their plan. Assuming mutual respect and fair communication (both which also are requirements, IMO). There's also all the actual technical bits but I think it's fair to say that a lot of what makes a great anything involves a mastery over communication and enough confidence in themselves not to take things personally.
And, maybe, you know, that also connects with your original comment. But I don't know if that has anything to do with your intention when posting it.
Fair enough. And, certainly, my growth would have been impeded had I never heard any negative feedback.
To be clear, some of my commentary was in response to a sibling comment of yours where you seemed to take the downvotes personally. I can't speak for all the cases, obviously, but my observation of HN is that the downvotes are usually a signal of "this comment doesn't apply to the topic or follow-up debate" and less so a signal of "bad idea" or "bad author.". Disagreement with an idea usually results in a thoughtful comment response, not a downvote.
I think the karma threshold for downvoting rights is useful here in that it gives everyone enough exposure to the guidelines before taking action on their own personal ranking objectives (and the HN guidelines are worth reading if you haven't yet -- https://news.ycombinator.com/newsguidelines.html). My best guess is that your downvoters considered your comment a dismissal of TFA, without any explanation for your flippancy.
I may have read to the bottom of too many HN posts but,, fortunately, no one is keeping score and they really don't get that long or too toxic. (thanks largely to the efforts of dang and the rest of the mods, I'm sure)
It comes off a bit verbose and hand-wavy.
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.
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.
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?
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.
Thank you very much, I'll check that out
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 - 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.
>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.
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
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.
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
> * preference towards bias
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
[dead]
> What makes a great sw engineer? > ... > Abstract:... we interviewed Microsoft software experts...
That's a meme right there!
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.
"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?
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.
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
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".
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 .
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.
What do you guys think of the UW information school, where this thesis is from?
It doesn't seem to have much of a connection to the well-known UWCSE.
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.
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.
[dead]
[flagged]
My comment above is currently sitting at -4, so I guess this means I should do as others before me have done.
"Why the down votes?"
The people you described in your comment - if they found your description on-the-nose and were offended - would they not be the type to try to solve their problem by attacking the messenger?
No, they're the type to attack Cindy.
LLT, dis u?
Short version: HN is not Reddit
Welcome to HN.
Your comment read to me like an attempt to energize and motivate. It didn't seem to have "substance". How does your comment help me improve my understanding of what compromises a good engineer? Instead it seems to suggest I shut down my mind, stop doing the work, and feel like I've already won before I've even started. Yet, improving as an engineer has come with a lot of work, challenging myself to get more specific, be concrete and appropriately detailed, as well as thinking through "but really... How would that work throughout the complete causal chain with no shortcuts?".
I won't claim there aren't downsides but there is a utility to the expectation. Hopefully you find ways it can help you grow.
What did you write? I can't see it anymore.
Any leetcoders I have hired have turned out to be one trick ponies and actually aren't very creative or think from first principles. I have been in the industry for 21 years now and I know my opinion is shared by many others.
I also ponder what it means that u can graduate with a cs degree that essentially leet code companies don't trust, hence they test you. What does this say about the university system? I could see asking ppl from "lower tier" unis to take a test but applying leet code across thr board surely has to weed out really good candidates who are generally fast learners and are smart.
I'm just a bystander so I can't say why people are down-voting.. and considering they're unlikely to return and read your follow-up question, let alone respond, I think we can safely assume we won't know.
But since you're asking, and it seems with more sincerity than your initial comment, I can offer my view.
First, though, I need to point out something about HN karma that's a bit different than reddit or elsewhere. I include this because it was a shock to me at first, and your account is new enough you may not have gotten used to it yet, either. And it's that nobody cares about how much karma anyone has. It's used as a basic filter for allowing downvotes and it's visible in someone's profile, but what I mean is that there isn't a lot of farming going on. At least, in general. Partly because it's so much work with little pay-off, I think. You can't get easy karma from a quick laugh or posting something controversial. You can't even be sure that a news item you post will get enough attention to try and get easy comment points from. The kinds of comments that would get easy karma on Reddit are more likely to get downvoted here, and maybe it's reactionary but I am pretty sure it's not personal. I like how you can't downvote any responding comments, even if you can downvote. Anyway, it's not a perfect system but I can say I stopped going to reddit when I came to appreciate the better parts of HN commentary.
One of the things that can trigger a lot of downvotes is criticism without substance. Even if it's a valid commentary on the society or politics involved. And, if it's a little off topic, that can trigger some downvotes too. It takes a real gem of a comment and good timing to get more than a few upvotes, and you never really know how many upvotes someone else's comment got unless they tell you. tbh some of my comments that I put a decent amount of time and thought into never got an upvote, but I'm rarely surprised at getting too many upvotes for a comment.
The audience here tends to favor original thought, and are easily dismissive of comments that are overly dismissive of the news post it is commenting on.
Tying this all back to the fine article, which I'll admit to not having read, but whose topic I can claim some of my own opinions on, because I've been fortunate enough to work with a range of talent there. I think one of the hallmarks of a great engineer is to have partitioned off the creation from the creator enough that they never take personal offense to any criticism of their design or their plan. Assuming mutual respect and fair communication (both which also are requirements, IMO). There's also all the actual technical bits but I think it's fair to say that a lot of what makes a great anything involves a mastery over communication and enough confidence in themselves not to take things personally.
And, maybe, you know, that also connects with your original comment. But I don't know if that has anything to do with your intention when posting it.
I wasn't asking out of anger like others would.
I like negative feedback.
I'm surprised you wrote all this. You, too, should like negative feedback. How else are you going to get gritty and competitive?
Fair enough. And, certainly, my growth would have been impeded had I never heard any negative feedback.
To be clear, some of my commentary was in response to a sibling comment of yours where you seemed to take the downvotes personally. I can't speak for all the cases, obviously, but my observation of HN is that the downvotes are usually a signal of "this comment doesn't apply to the topic or follow-up debate" and less so a signal of "bad idea" or "bad author.". Disagreement with an idea usually results in a thoughtful comment response, not a downvote.
I think the karma threshold for downvoting rights is useful here in that it gives everyone enough exposure to the guidelines before taking action on their own personal ranking objectives (and the HN guidelines are worth reading if you haven't yet -- https://news.ycombinator.com/newsguidelines.html). My best guess is that your downvoters considered your comment a dismissal of TFA, without any explanation for your flippancy.
I may have read to the bottom of too many HN posts but,, fortunately, no one is keeping score and they really don't get that long or too toxic. (thanks largely to the efforts of dang and the rest of the mods, I'm sure)