13 ms·

On Good Software Engineers

130 points by BerislavLopac 2y ago

andrewstuart 2y ago
The more a company attempts to define what a "good software engineer" is, the worse their hiring practices will become as they come to believe they can identify and select for "good software engineers". As the author says after articulating a long list of traits of a first class developer; "I strongly believe all that I’ve mentioned is a basic expectation from any engineer." Folks, apply for jobs where the employer is pragmatic about hiring and gets people employed and gets on with the job.
- Joel_Mckay 2y ago
  Process people can't resist trying to optimize things they superficially comprehend. When business ops tries to define how engineers with decades of experience should solve problems, it is usually a conversation with a firm heading for failure. Smart people usually just quickly leave a doomed project... =3
  - earthnail 2y ago
    > Process people can't resist trying to optimize things they superficially comprehend. Wow, I don't think I ever heard it summarised so well. I cannot agree more with this statement.
  - opentokix 2y ago
    This is so profound, I need a t-shirt "Process people can't resist trying to optimize things they superficially comprehend."
- p0nce 2y ago
  You don't see blogs about all the desirable properties of a software company with 10/10 in every direction.
indulona 2y ago
What differentiates a good programmer from a bad one? The good programmer will navigate the unknown on his own while the bad programmer will struggle. That's about it. It does not matter what level of proficiency the programmer is at right now. It is a state of mind. The core of a personality. This translates to the whole career. Can you figure things out on your own or do you need someone to guide you, is what makes the ultimate difference.
- cloogshicer 2y ago
  I think you're on to something but I wouldn't call it a personality trait. It's something that can be learned, but it takes a ridiculous amount of time. I've been teaching programming to complete beginners now for a few years and there is always a point in time during their education where this clicks: they go from asking about everything to realizing that there are often no easy answers and start doing their own research and problem solving.
  - robocat 2y ago
    > there is always a point in time during their education where this clicks Always? Or are you showing a selection bias? I call it "hitting your head against a brick wall". The tenacity to keep fighting until you win. Doesn't always work (can end up wasting time) but it is surprisingly effective against seemingly intratible problems. "Grit" is the marketing word. Workarounds is another form. I'm interested in how it can be taught. I force myself because I admire a certain level of "OCD" behaviours and try to emulate those I admire.
    - cloogshicer 2y ago
      No, unfortunately not always. Some people drop out before they learn it. I think it's best learnt through encouragement and support. If I have one takeaway for the last 5+ years of teaching, it's that most barriers to learning are emotional, not intellectual.
- intromert 2y ago
  This is spot on—a simple and precise explanation. As a programmer myself, I’ve seen developers dive into a 15-year-old codebase, independently work through it, and only ask questions once they’ve exhausted all other options.
xnorswap 2y ago
I don't like this re-framing of "the 10x engineer" to be someone who writes 10 times as much low-quality code. It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.
- dailykoder 2y ago
  This. My understanding of 10x engineers was, even if a bit tongue-in-cheek, always positive. They are the smart guys and girls that know what they are talking and think ahead a few miles. It sure can be overwhelming when you hear them talk, but if you let it sink it in, it makes sense. But we as a society should not pretend that this is what you have to be. There are just some smart people in the world, but they are rare. You don't need to be one to be a good person.
- marcusbuffett 2y ago
  Yeah I'm also sick of seeing articles cite this mythical trade-off, where any increase in programming output must be correlated with being a bad team member, churning out bad code, and generally being a pain to work with. Anyone that's worked with engineers can tell you that there are simply some people getting more done than others, in the same amount of time. Are there people producing bad code? Yes. But I don't think output is inversely correlated with code quality. In fact the people I've worked with that have the most output, also had some of the highest quality code. I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers. He probably exists somewhere, but not with the sort of prevalence that justifies every programming productivity article ripping on his archetype.
  - earnesti 2y ago
    If a system is impossible to maintain, that system is nothing of value, and therefore doesn't fit to any sensible definition of 10x. I have always assumed that the 10x means value creation, not some kind of "lines of code" output or other nonsense. And for sure there are 10x programmers, maybe even 100x. I have been mostly working at startups and you see these early stage decisions and designs that create huge costs when the company starts to scale, similarly you have some decisions that might save huge amount of costs during the company life time, or allow better revenue generation etc.
larsonnn 2y ago
> Good engineers know how to influence others and the organization to deliver a solution as a team. This is a Problem, assuming someone is good at talking is also a good engineer. > Good engineers constantly work on reducing complexity in the codebase to consistently provide high quality. Complexity for the manager? Who is deciding how complex a system is. This could also be a skill issue with the „team“ by taking skilled engineers and mix them with not so skilled ones. Overall the article is written for managers which try to add a image of an engineer which is like a manager. Influence people and give up on complex stuff.
- devjab 2y ago
  I know a lot of engineers follow various principles like SOLID, DRY, Clean Architecture and so on, but as far as complexity goes it’s really rather straight forward. You never add abstractions until you can’t avoid them. We’ve had 20 years of these principles (and what other nonsense OOP had brought with it) now, and despite the fact that many of them were written by people who haven’t worked in software engineering since a decade before Python was made they still remain popular and largely unaltered. Which is silly considering our industry has never been more of a mess, with so many teams building complexity to “future proof” things that they will never need, to the point where some teams actively hinder the business. Complexity is fairly straight forward in my opinion. You build after the YAGNI principles and you include things from SOLID, DRY, CLEAN, whatever when it makes sense to do so. If you happen to enter a team that has dug themselves into a pit of unnecessary complexity you need to work on reducing it. This is takes a good engineer, because the fundamental reason to do this or that comes down to engineering. People who follow dogmas are not good engineers. You will even see the authors of some of these principles like Uncle Bob tell you that people who over complicate their code bases misunderstand his principles. Convenient when your career is selling consultant, but also very true.
  - imiric 2y ago
    > Complexity is fairly straight forward in my opinion. That's a bold take. The difficult thing with complexity is that it's an abstract and, sometimes, subjective concept. (Not speaking of measurable complexity like cyclomatic or algorithmic.) It may involve abstractions, yes, but those are usually introduced with the argument that they—ironically enough—_simplify_ some interface or process. It's difficult to argue against that since we deal with abstractions on a daily basis which _do_ make our lives easier, from the hardware layer and up. So then the task of removing abstractions becomes an uphill battle to convince the rest of the team that this is indeed a good idea. This is a sociocultural and political problem, not strictly related to engineering. So I don't see the task of resolving complexity as being this straightforward. The best approach I've found of dealing with this is to focus on things we can measure instead. Use linters to warn you about cyclomatic complexity, function length, dead code, single interface implementations, and any other quantifiable metric that contributes to increasing complexity. Even this is often difficult to align on within teams, but with it in place at least there's an objective metric that can guide the team in the right direction.
Daub 2y ago
> Good engineers understand the stakeholders’ needs… In my experience, this can take two very different forms: 1. Being observant of a stakeholder’s stated needs. 2. Being confident enough to tell a stakeholder what their needs should be. On a pedantic note, I would prefer the term ‘effective’ engineer to ‘good’ engineer. The later sounds like a judgment on their moral character.
- justinclift 2y ago
  Heh Heh Heh. Queue the post about highly effective evil engineers then? Star Wars Death Star stuff maybe, or a perhaps a global system to direct people's attention to ads? ;)
- andrewstuart 2y ago
  Good engineers are pedantic about terminology such as effective versus good.
  - jhot 2y ago
    I'm hoping this is sarcasm. The people I've worked with who are highly pedantic wreck team dynamics and rarely deliver anything of value.
- switch007 2y ago
  Edit: oops read too quickly. Disregard: I don't think of morals when I read "effective engineer" personally
  - lazyasciiart 2y ago
    “The latter” means “the second of the two options I just mentioned”, so in this case he is saying that ‘good’ engineer feels like a moral judgment.
    - switch007 2y ago
      I read too quickly. Thanks
000ooo000 2y ago
Another day, another listicle about senior/staff/principal developer labelling disguised as a blog. Only insecure devs care about this crap. Devs who know their shit aren't coming up with definitions distinguishing themselves from devs who don't. They have better things to do (e.g. actual work).
- arp242 2y ago
  Or, you know, people interested in building a team of Good Software Engineers are interested in thinking about this sort of thing. Also: Please don't post shallow dismissals, especially of other people's work. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - ownagefool 2y ago
    Depends. At least some of these lists will be created to define the scope of the good engineer so it applies to them, or habits they like, but there's nothing that actually clarifies the benefit here. Is there a measurable increase in revenue, feature releases, uptime? I've worked as a contractor for a decade. I'm brought in to deliver specific outcomes by specific timelines. There are polarizing views on what I do. Some will view me as the 10x engineer; others a bit of a cowboy. However, there's no lack of "good engineers" that aren't able to deliver working software in a timely manner, which is why I'm even at those orgs in the first place.
    - arp242 2y ago
      You can disagree with any of this list, of course, but that's not what the previous poster was doing: it's just a shallow dismissal, and a claim that it was written for what are essentially bad faith reasons. That's quite a different thing than "I disagree with this because X" (which is what you're doing).
  - tgv 2y ago
    Then look at articles that are a bit better than this one, which manages to come up with the blandest of ... definitions? > A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again. What a vacuous statement. The phrase "as a manager or peer" is so 2014 "user story". And it doesn't get more linkedin than "to progress a project." The whole sentence just says "A good engineer is someone who will do his/her job." It's meaningless drivel.
opentokix 2y ago
I have read many of this types of blog posts about 10x, good engineers and such. The only thing I have learned during my close to 30 years of professional experience is how incredible rare they are. The really good engineers in IT. They are so rare so MOST people will never work with even one. That is how rare they are. And a "Blogger, Writer, Philospher" - have probably never worked with one, and never will. Because they are in a whole different sphere of engineering. The number of systems is increasing explonentially - the number of truely good engineer is pretty much a constant number.
- hu3 2y ago
  I have a hot take about this: neurotypicals can't achieve this level of proficiency because the type of mind required is just too exquisite. It requires a large bandwidth between parts of the brain that aren't usually that well connected. And it also requires some parts of the brain to not function very well, like ones that break/filter/censor out ideas and impulsiveness. Looking at you prefrontal cortex. That would explain why they are so rare. I might have worked with one. They are just beyond human in terms of hyperfocus, pattern matching and technical memory. It's a humbling experience.
sidcool 2y ago
I like the post, but it's a bit idealistic. It's like a laundry list of all the perfect attributes of almost any profession. It's like reading a religious text.
- sk11001 2y ago
  I don't agree that it's idealistic because it's only directional - it tells you what to move towards, it doesn't give you any idealistic target or criteria for any of the things it lists. Which seems like a good thing.
- brianmcc 2y ago
  Yeah like current sibling reply here, it's OK to be idealistic: "here's what I think perfect looks like", and accept that sure not everybody meets that definition. Doesn't mean it's a bad aspiration though. I mostly agree with the article, FWIW. Including having worked with various "talented but difficult" people before. One of the more under-appreciated aspects of management is having direct reports you can delegate stuff to and (a) they just deal with it, and (b) you need little or no supervision and there's no drama. Managers are humans: making their lives a little better by being Mr/Mrs/Ms Reliably Gets Things Done will in any sane org yield dividends. Of course not all orgs are sane, and not all managers are Good Managers, but that's a different conversation.
wiz21c 2y ago
FTA: "Setting expectations for software engineers is tricky for all managers." What about: "Setting expectations for managers is tricky for all software engineers." ?
fullstackwife 2y ago
This is fine if you see programmer as a sort of large factory blue collar worker, but not all programmers see themselves in such position of a perfect cog in your "org". Disturbing fact: sometimes you get best ideas out of boredom:)
punduk 2y ago
I don't think good engineering is a soup of confusion like the one in this article. simple is beautiful. And I think good engineering is associated with simplicity.
yosefk 2y ago
Very inspiring! I'm off to "embed quality elements into my deliverables to increase consistency and velocity." Apart from the tone, I agree that it's awesome when an engineer understands your fucked up process and manages to be productive despite it ("goes beyond the processes to independently drive work"), but as a manager you can't count on most people being like that and so you should work very hard to make your process work for people who do not think very much about what could go wrong when acting fairly naively according to this process. It says in the end that these are basic expectations from any engineer or even any employee. Well, maybe, but most people don't meet these expectations, and it's a basic expectation from a manager to be able to work with actually available people and not only imaginary ones.
_s_a_m_ 2y ago
This post is sooo symptomatic of people who have too much time and don't seem to be educated beyond their field. Overthinking something that maybe not that complicated after all. The egos of software people is just bigger than it should be. Also mythical thinking like "10x bla bla" is symptomatic.
- MortyWaves 2y ago
  Your comment is basically a personal attack of the character of the author. Totally unnecessary. Additionally, I completely disagree with your assessment. It's clear the author has spent a lot of time thinking about this and you framing it as "over thinking" and "not educated beyond their field" and "big ego" is downright mean spirited, wrong, and reductivism.
  - _s_a_m_ 2y ago
    Of course it is a personal attack on the character of the person. That is the only thing guard-railing spreading nonsense. Software people need to work on their character.
    - Gigablah 2y ago
      > That is the only thing guard-railing spreading nonsense. I am honestly disappointed to see this level of discourse on HN.
      - MortyWaves 2y ago
        Seems like the sort of thing dang et al. would normally remove.
ozim 2y ago
You take proactive approach, listen to people, work on reducing complexity. Then you wake up one day being steamrolled by business change where other senior dev with some business analyst hijacks process does some awful crap "because business needs this ASAP" and leaves you maintaining/fixing up pile of crap. Guess who is blamed later on for the system is not up to standard like having security hole or totally not logical flow in places where "business need" was implemented. Keep in mind after 6 months no one will remember they did that business change everyone will remember that you are maintaining the system because you try to keep it decent so it is your fault ;)
- karmakurtisaani 2y ago
  They might not blame you for it, but you're definitely in every meeting with eyes on you to fix it. Blaming the predecessor at this point is not only futile, but makes you look bad as well.
  - woleium 2y ago
    Amazon’s “away team” method is supposed to account for this. The sponsoring business unit is (supposed to be) accountable for upkeep.
    - azemetre 2y ago
      What happens if the entire team gets churned in 4 years? Or is 4 years the lifespan of a single BU nowadays? I don't see a way to mitigate this unless you care about these things from the onset, but I suppose if you're a monopoly you can just do anything you want because you have no competition.
- moffkalast 2y ago
  Ah yes, nothing quite like trashing half the codebase because "a customer needs this next week" and then having to maintain that shit for years.
- awesomegoat_com 2y ago
  I have seen this so many times. You almost made me weep. It's tragedy of commons. To stop this we need software engineers to own their own code legally.
braza 2y ago
The article is good, but I think it communicates with a narrower audience than it intended to in terms of demographics, especially the ones who do not work in nice tech companies. For instance that passage: > I first found definitions of 10x engineers, superstars, or rockstar developers, which aren’t definitions of good engineers in any way. Someone may produce a lot of work but it’s often at the cost of team spirit and results in low-quality code. Ultimately, the team is demoralized and the organization bears the cost of substandard code. I used to work in a tech company (bytes), and now I am working in an old money/traditional company (atoms) that uses technology marginally to stay ahead. My team's (a couple of dozens) median age is 53, and I do not see how this relates to them or even to myself. I definitely would like to hear more from "Working Bee Engineer", "Dark Matter Engineer", "How I survived 25 layoffs Engineer", "How I kept my sanity working with internal clients Engineer", "I managed to raise kids being in Tech as Engineer", "The bodybuilder/triathlete/sports(wo)man Engineer" and so on. I'm not being cynical, but I miss the old days of actionable and down-to-earth blogposts that anyone could relate to.
jimberlage 2y ago
It’s useful to have a vision like this. Not because everyone will hit all these criteria. (If you do, I’d love to steal your hiring process.) I find it useful because coaching people to be better is easier with an ideal like this to point to, that is complete. Lots of managers struggle to put into words why they don’t see an employee as they see themselves. If you have a genuine difference of opinion, you can relate back to something like this. Say your employee does a lot of tickets, and sees themselves as a hyper productive engine on a team. You as a manager see them picking up low-impact tickets and not finishing any features the business asked for end-to-end. The employee wants their productivity to be recognized. You want your employee to be more focused on a single business outcome rather than seeing a high number of tickets in the done column. Some people (especially neurodivergent people) really “get it” when they have a pre-read they can think on and apply to their situation. A blog post like this is nice because you can have the employee read a bullet and then talk about how it applies to their situation in a 1:1.
louwrentius 2y ago
Maybe it's hard to accept that often, code quality or technical prowess are not that important. What is really important is understanding the actual process that is being supported by the thing you're building. It's so obvious but building something technically sound that doesn't address the actual organisational need is a 100% waste of time and has a huge opportunity cost. And the reality seems to be that the business and IT don't know the right answer upfront, so it's - cliché alert - a journey between professionals helping each other understand how a proces should operate. This has NOTHING to do with technology or technical implementations. At this level, tech is just an abstraction, a black box that does magic.
nicolay1 2y ago
Good engineers want to create the best product possible, and are demanding from the product team. They want clarity and visibility on user insight in order to be able to do the right tradeoffs to maximize customer satisfaction. -> I think that as engineers, we also have the responsibility to create the best product (interested to have your feedback, I want to create a meetup talk on this subject)
spacemanspiffii 2y ago
A developer that ticks all these boxes is certainly a Good Software Engineer, but the reverse relation doesn't necessarily hold. There are many that have made very valuable contributions while not even working on a team, or perhaps even being an asshole to everyone around them, ignoring stakeholders, everything. Or just something less extreme, such as maybe they didn't at all times know their organization that well. That is fine, if it works at their time and place. To call those "Bad Software Engineers" is unhelpful.
kozikow 2y ago
Story of two engineers in a team I worked with. P is what most people would consider 10x engineer (but not this article). Can get anything done few times quicker than anyone else. It's like 10 junior engineers stacked in one person. But it often would be unmaintainable mess. M is a lot like article describes. Understands what needs to be done and creates good technical designs. Often unf*s mess created by P. Delivers business value. Do not write a lot of code. It's funny that depending on whom you ask, M or P would be the 10x engineer and other would be the bad engineer. Real 10x engineer can wear the M or P hat depending on circumstances.
- Wheatman 2y ago
  I wonder if it woudl be better to think of it as the the 10X team, rather than a single 10x developer. Im still studying CS so I'm probably way off base,but it seems far more realistic, and usefull.
  - wrs 2y ago
    There are definitely 10X teams in that sense. Two problems: (1) Very few corporate compensation programs are team-oriented; managers are structurally forced to reward/punish individuals, not teams. In many cases there is even some sort of forced distribution that requires the manager to punish someone on the team regardless of performance. This makes it counterproductive to attempt to construct a uniformly high-quality team in the first place. (2) The organizational friction encountered by a 10X team is the same as for a 10X developer, only much larger in scope, thus more expensive and visible. A 10X developer might want to write a bunch of unit tests; a 10X team might want to swap out the entire CI/CD system and reorganize their relationship with product management.
- eXpl0it3r 2y ago
  I much rather have no 10x engineer on my team, but instead engineers who do just a bit more than the bare minimum. For example, who don't just test their single use case, but check if it breaks anything around it. Or who invest just a tiny bit more time to actually write down what their bug analysis has yielded. Or who update the documentation after an interface change. Or who write solution designs to think about the approach, before hacking some ugly mess. Or who check with the PO or user if the chosen approach/design is what they expected. Or who ... In my experience having devs who do more than the bare minimum is way more productive for most day-to-day business. Maybe there's room for a powerhouse in cases, where you have to drastically restructure a code base and quickly create some PoC.
revskill 2y ago
Good leetcoder is good engineerer
kl5ag 2y ago
"A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again." Not again. The real world does not work like that. The author has the luxury to have team meetings, onboarding, agile and all of that nonsense because the hard parts of open source have already been written by 10x engineers. What the author is working on is presumably some kind of devops that uses other people's software. Perhaps OSS was a mistake. It enables all sorts of pundits and is now repackaged by "AI".
- allgreed 2y ago
  Would you be so kind as to elaborate? I definitely see you’re onto something. How does the real world works? What are the hard parts? What’s wrong with using other people’s software?
  - azemetre 2y ago
    I took their comment to mean that these people are standing on the massive mountains of progress that have been made, but not acknowledging that a lot of wasted effort was lost learning these things. It's easy to only talk about what should be done with perfection in mind, it's another to talk about what can realistically be done. It's no different in regards for anything else the humane race has done, we know the solutions to be done in regards to climate change, inequality; it's another to convince society to then go and try to solve these things with the solutions we thought of.
bjornsing 2y ago
All posts on this topic should start with a brief description of the problem domain, because all sensible conclusions depend on it. There are problem domains where you just have to be insanely smart to be able to contribute, and there are others (as I get the feeling is the case here) where you just need to be reasonably socially competent and dependable. A “good engineer” in one domain can be terrible in another.
Glitter7030 2y ago
This post makes me a bit angry. In a nutshell it’s promoting engineers doing more project management. I think an engineer at any level should not be managing (“driving”) projects, and you should not expect that, unless you are able to pay “the engineer” both a manager’s and an engineer’s compensation. I like the idealistic view on proactivity, but I think idealising this soup of responsibilities should not be promoted. I want a good engineer and I want a good manager as well in a team.
hintymad 2y ago
> We can’t expect a junior engineer to drive a big project; their scope will be limited I find it a dilemma when it comes to driving "big project", especially in a large company. The engineers who drive such projects often behave more like product managers. They sketch out key product features, work with teams to get roadmaps out, and convince the leadership and teams to get the right resources. In addition, they will also draw a few boxes to have a so-called "architecture diagram", and hand out the actual design and implementation to lower-level engineers. I don't deny the importance of such work, and I do recognize that junior engineers likely won't have the clout or the knowledge to push such project forward. On the other hand, I find the value of such high-level engineers diminish fast in the industry, especially when they want to switch jobs, for the will have lost the ability to get down to specifics to solve tough technical problems. Case in point, I have seen most of the so-called "uber TL" fail interviews because all they could do was drawing a bunch of boxes and talking about strategies or requirements. They may tell you that a recommender pipeline will have retrieval, ranking, and reranking, and even throw around a few model names. But when you ask them any specifics about the landscape, the model architecture, the selection of specific technologies (especially how the selected tech works), they would get stuck. And they certainly can't implement any of the said components. Note this is not a criticism but a lament. I certainly face the same dilemma, and frequently question how I can continue to be more valuable as I grow in my career, especially given that that I don't plan to say within the same company forever and I don't want to be a professional box drawer for life. The only path I can think of now is to become someone like a great CS professor: the professor does not necessarily write all the papers, but she is invaluable to her students by unblocking them when needed, by understanding new paper better than anyone, by pointing out a direction that is not so obvious to the students, and etc. That is, to be someone like Wernher von Braun or Kelly Johnson. Someone who can code out a system like ClickHouse or at least pin down exactly which data structures to use, instead of telling his team vague ideas like let's use SIMD to speed up the query. Someone who can write a working TLA+ spec to show the flaw in a design by his team instead of telling his team that they can use TLA+ to find intricate bugs. To be honest, I don't know how to become like that while keeping getting promoted to a higher-level IC, but I don't see other ways.

130 points by BerislavLopac 2y ago

The more a company attempts to define what a "good software engineer" is, the worse their hiring practices will become as they come to believe they can identify and select for "good software engineers". As the author says after articulating a long list of traits of a first class developer; "I strongly believe all that I’ve mentioned is a basic expectation from any engineer." Folks, apply for jobs where the employer is pragmatic about hiring and gets people employed and gets on with the job.

Joel_Mckay 2y ago
Process people can't resist trying to optimize things they superficially comprehend. When business ops tries to define how engineers with decades of experience should solve problems, it is usually a conversation with a firm heading for failure. Smart people usually just quickly leave a doomed project... =3
- earthnail 2y ago
  > Process people can't resist trying to optimize things they superficially comprehend. Wow, I don't think I ever heard it summarised so well. I cannot agree more with this statement.
- opentokix 2y ago
  This is so profound, I need a t-shirt "Process people can't resist trying to optimize things they superficially comprehend."
p0nce 2y ago
You don't see blogs about all the desirable properties of a software company with 10/10 in every direction.

indulona 2y ago

What differentiates a good programmer from a bad one? The good programmer will navigate the unknown on his own while the bad programmer will struggle. That's about it. It does not matter what level of proficiency the programmer is at right now. It is a state of mind. The core of a personality. This translates to the whole career. Can you figure things out on your own or do you need someone to guide you, is what makes the ultimate difference.

cloogshicer 2y ago
I think you're on to something but I wouldn't call it a personality trait. It's something that can be learned, but it takes a ridiculous amount of time. I've been teaching programming to complete beginners now for a few years and there is always a point in time during their education where this clicks: they go from asking about everything to realizing that there are often no easy answers and start doing their own research and problem solving.
- robocat 2y ago
  > there is always a point in time during their education where this clicks Always? Or are you showing a selection bias? I call it "hitting your head against a brick wall". The tenacity to keep fighting until you win. Doesn't always work (can end up wasting time) but it is surprisingly effective against seemingly intratible problems. "Grit" is the marketing word. Workarounds is another form. I'm interested in how it can be taught. I force myself because I admire a certain level of "OCD" behaviours and try to emulate those I admire.
  - cloogshicer 2y ago
    No, unfortunately not always. Some people drop out before they learn it. I think it's best learnt through encouragement and support. If I have one takeaway for the last 5+ years of teaching, it's that most barriers to learning are emotional, not intellectual.
intromert 2y ago
This is spot on—a simple and precise explanation. As a programmer myself, I’ve seen developers dive into a 15-year-old codebase, independently work through it, and only ask questions once they’ve exhausted all other options.

xnorswap 2y ago

I don't like this re-framing of "the 10x engineer" to be someone who writes 10 times as much low-quality code. It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.

dailykoder 2y ago
This. My understanding of 10x engineers was, even if a bit tongue-in-cheek, always positive. They are the smart guys and girls that know what they are talking and think ahead a few miles. It sure can be overwhelming when you hear them talk, but if you let it sink it in, it makes sense. But we as a society should not pretend that this is what you have to be. There are just some smart people in the world, but they are rare. You don't need to be one to be a good person.
marcusbuffett 2y ago
Yeah I'm also sick of seeing articles cite this mythical trade-off, where any increase in programming output must be correlated with being a bad team member, churning out bad code, and generally being a pain to work with. Anyone that's worked with engineers can tell you that there are simply some people getting more done than others, in the same amount of time. Are there people producing bad code? Yes. But I don't think output is inversely correlated with code quality. In fact the people I've worked with that have the most output, also had some of the highest quality code. I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers. He probably exists somewhere, but not with the sort of prevalence that justifies every programming productivity article ripping on his archetype.
- earnesti 2y ago
  If a system is impossible to maintain, that system is nothing of value, and therefore doesn't fit to any sensible definition of 10x. I have always assumed that the 10x means value creation, not some kind of "lines of code" output or other nonsense. And for sure there are 10x programmers, maybe even 100x. I have been mostly working at startups and you see these early stage decisions and designs that create huge costs when the company starts to scale, similarly you have some decisions that might save huge amount of costs during the company life time, or allow better revenue generation etc.

larsonnn 2y ago

> Good engineers know how to influence others and the organization to deliver a solution as a team. This is a Problem, assuming someone is good at talking is also a good engineer. > Good engineers constantly work on reducing complexity in the codebase to consistently provide high quality. Complexity for the manager? Who is deciding how complex a system is. This could also be a skill issue with the „team“ by taking skilled engineers and mix them with not so skilled ones. Overall the article is written for managers which try to add a image of an engineer which is like a manager. Influence people and give up on complex stuff.

devjab 2y ago
I know a lot of engineers follow various principles like SOLID, DRY, Clean Architecture and so on, but as far as complexity goes it’s really rather straight forward. You never add abstractions until you can’t avoid them. We’ve had 20 years of these principles (and what other nonsense OOP had brought with it) now, and despite the fact that many of them were written by people who haven’t worked in software engineering since a decade before Python was made they still remain popular and largely unaltered. Which is silly considering our industry has never been more of a mess, with so many teams building complexity to “future proof” things that they will never need, to the point where some teams actively hinder the business. Complexity is fairly straight forward in my opinion. You build after the YAGNI principles and you include things from SOLID, DRY, CLEAN, whatever when it makes sense to do so. If you happen to enter a team that has dug themselves into a pit of unnecessary complexity you need to work on reducing it. This is takes a good engineer, because the fundamental reason to do this or that comes down to engineering. People who follow dogmas are not good engineers. You will even see the authors of some of these principles like Uncle Bob tell you that people who over complicate their code bases misunderstand his principles. Convenient when your career is selling consultant, but also very true.
- imiric 2y ago
  > Complexity is fairly straight forward in my opinion. That's a bold take. The difficult thing with complexity is that it's an abstract and, sometimes, subjective concept. (Not speaking of measurable complexity like cyclomatic or algorithmic.) It may involve abstractions, yes, but those are usually introduced with the argument that they—ironically enough—_simplify_ some interface or process. It's difficult to argue against that since we deal with abstractions on a daily basis which _do_ make our lives easier, from the hardware layer and up. So then the task of removing abstractions becomes an uphill battle to convince the rest of the team that this is indeed a good idea. This is a sociocultural and political problem, not strictly related to engineering. So I don't see the task of resolving complexity as being this straightforward. The best approach I've found of dealing with this is to focus on things we can measure instead. Use linters to warn you about cyclomatic complexity, function length, dead code, single interface implementations, and any other quantifiable metric that contributes to increasing complexity. Even this is often difficult to align on within teams, but with it in place at least there's an objective metric that can guide the team in the right direction.

Daub 2y ago

> Good engineers understand the stakeholders’ needs… In my experience, this can take two very different forms: 1. Being observant of a stakeholder’s stated needs. 2. Being confident enough to tell a stakeholder what their needs should be. On a pedantic note, I would prefer the term ‘effective’ engineer to ‘good’ engineer. The later sounds like a judgment on their moral character.

justinclift 2y ago
Heh Heh Heh. Queue the post about highly effective evil engineers then? Star Wars Death Star stuff maybe, or a perhaps a global system to direct people's attention to ads? ;)
andrewstuart 2y ago
Good engineers are pedantic about terminology such as effective versus good.
- jhot 2y ago
  I'm hoping this is sarcasm. The people I've worked with who are highly pedantic wreck team dynamics and rarely deliver anything of value.
switch007 2y ago
Edit: oops read too quickly. Disregard: I don't think of morals when I read "effective engineer" personally
- lazyasciiart 2y ago
  “The latter” means “the second of the two options I just mentioned”, so in this case he is saying that ‘good’ engineer feels like a moral judgment.
  - switch007 2y ago
    I read too quickly. Thanks

000ooo000 2y ago

Another day, another listicle about senior/staff/principal developer labelling disguised as a blog. Only insecure devs care about this crap. Devs who know their shit aren't coming up with definitions distinguishing themselves from devs who don't. They have better things to do (e.g. actual work).

arp242 2y ago
Or, you know, people interested in building a team of Good Software Engineers are interested in thinking about this sort of thing. Also: Please don't post shallow dismissals, especially of other people's work. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- ownagefool 2y ago
  Depends. At least some of these lists will be created to define the scope of the good engineer so it applies to them, or habits they like, but there's nothing that actually clarifies the benefit here. Is there a measurable increase in revenue, feature releases, uptime? I've worked as a contractor for a decade. I'm brought in to deliver specific outcomes by specific timelines. There are polarizing views on what I do. Some will view me as the 10x engineer; others a bit of a cowboy. However, there's no lack of "good engineers" that aren't able to deliver working software in a timely manner, which is why I'm even at those orgs in the first place.
  - arp242 2y ago
    You can disagree with any of this list, of course, but that's not what the previous poster was doing: it's just a shallow dismissal, and a claim that it was written for what are essentially bad faith reasons. That's quite a different thing than "I disagree with this because X" (which is what you're doing).
- tgv 2y ago
  Then look at articles that are a bit better than this one, which manages to come up with the blandest of ... definitions? > A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again. What a vacuous statement. The phrase "as a manager or peer" is so 2014 "user story". And it doesn't get more linkedin than "to progress a project." The whole sentence just says "A good engineer is someone who will do his/her job." It's meaningless drivel.

opentokix 2y ago

I have read many of this types of blog posts about 10x, good engineers and such. The only thing I have learned during my close to 30 years of professional experience is how incredible rare they are. The really good engineers in IT. They are so rare so MOST people will never work with even one. That is how rare they are. And a "Blogger, Writer, Philospher" - have probably never worked with one, and never will. Because they are in a whole different sphere of engineering. The number of systems is increasing explonentially - the number of truely good engineer is pretty much a constant number.

hu3 2y ago
I have a hot take about this: neurotypicals can't achieve this level of proficiency because the type of mind required is just too exquisite. It requires a large bandwidth between parts of the brain that aren't usually that well connected. And it also requires some parts of the brain to not function very well, like ones that break/filter/censor out ideas and impulsiveness. Looking at you prefrontal cortex. That would explain why they are so rare. I might have worked with one. They are just beyond human in terms of hyperfocus, pattern matching and technical memory. It's a humbling experience.

sidcool 2y ago

I like the post, but it's a bit idealistic. It's like a laundry list of all the perfect attributes of almost any profession. It's like reading a religious text.

sk11001 2y ago
I don't agree that it's idealistic because it's only directional - it tells you what to move towards, it doesn't give you any idealistic target or criteria for any of the things it lists. Which seems like a good thing.
brianmcc 2y ago
Yeah like current sibling reply here, it's OK to be idealistic: "here's what I think perfect looks like", and accept that sure not everybody meets that definition. Doesn't mean it's a bad aspiration though. I mostly agree with the article, FWIW. Including having worked with various "talented but difficult" people before. One of the more under-appreciated aspects of management is having direct reports you can delegate stuff to and (a) they just deal with it, and (b) you need little or no supervision and there's no drama. Managers are humans: making their lives a little better by being Mr/Mrs/Ms Reliably Gets Things Done will in any sane org yield dividends. Of course not all orgs are sane, and not all managers are Good Managers, but that's a different conversation.

wiz21c 2y ago

FTA: "Setting expectations for software engineers is tricky for all managers." What about: "Setting expectations for managers is tricky for all software engineers." ?

fullstackwife 2y ago

This is fine if you see programmer as a sort of large factory blue collar worker, but not all programmers see themselves in such position of a perfect cog in your "org". Disturbing fact: sometimes you get best ideas out of boredom:)

punduk 2y ago

I don't think good engineering is a soup of confusion like the one in this article. simple is beautiful. And I think good engineering is associated with simplicity.

yosefk 2y ago

Very inspiring! I'm off to "embed quality elements into my deliverables to increase consistency and velocity." Apart from the tone, I agree that it's awesome when an engineer understands your fucked up process and manages to be productive despite it ("goes beyond the processes to independently drive work"), but as a manager you can't count on most people being like that and so you should work very hard to make your process work for people who do not think very much about what could go wrong when acting fairly naively according to this process. It says in the end that these are basic expectations from any engineer or even any employee. Well, maybe, but most people don't meet these expectations, and it's a basic expectation from a manager to be able to work with actually available people and not only imaginary ones.

_s_a_m_ 2y ago

This post is sooo symptomatic of people who have too much time and don't seem to be educated beyond their field. Overthinking something that maybe not that complicated after all. The egos of software people is just bigger than it should be. Also mythical thinking like "10x bla bla" is symptomatic.

MortyWaves 2y ago
Your comment is basically a personal attack of the character of the author. Totally unnecessary. Additionally, I completely disagree with your assessment. It's clear the author has spent a lot of time thinking about this and you framing it as "over thinking" and "not educated beyond their field" and "big ego" is downright mean spirited, wrong, and reductivism.
- _s_a_m_ 2y ago
  Of course it is a personal attack on the character of the person. That is the only thing guard-railing spreading nonsense. Software people need to work on their character.
  - Gigablah 2y ago
    > That is the only thing guard-railing spreading nonsense. I am honestly disappointed to see this level of discourse on HN.
    - MortyWaves 2y ago
      Seems like the sort of thing dang et al. would normally remove.

ozim 2y ago

You take proactive approach, listen to people, work on reducing complexity. Then you wake up one day being steamrolled by business change where other senior dev with some business analyst hijacks process does some awful crap "because business needs this ASAP" and leaves you maintaining/fixing up pile of crap. Guess who is blamed later on for the system is not up to standard like having security hole or totally not logical flow in places where "business need" was implemented. Keep in mind after 6 months no one will remember they did that business change everyone will remember that you are maintaining the system because you try to keep it decent so it is your fault ;)

karmakurtisaani 2y ago
They might not blame you for it, but you're definitely in every meeting with eyes on you to fix it. Blaming the predecessor at this point is not only futile, but makes you look bad as well.
- woleium 2y ago
  Amazon’s “away team” method is supposed to account for this. The sponsoring business unit is (supposed to be) accountable for upkeep.
  - azemetre 2y ago
    What happens if the entire team gets churned in 4 years? Or is 4 years the lifespan of a single BU nowadays? I don't see a way to mitigate this unless you care about these things from the onset, but I suppose if you're a monopoly you can just do anything you want because you have no competition.
moffkalast 2y ago
Ah yes, nothing quite like trashing half the codebase because "a customer needs this next week" and then having to maintain that shit for years.
awesomegoat_com 2y ago
I have seen this so many times. You almost made me weep. It's tragedy of commons. To stop this we need software engineers to own their own code legally.

braza 2y ago

The article is good, but I think it communicates with a narrower audience than it intended to in terms of demographics, especially the ones who do not work in nice tech companies. For instance that passage: > I first found definitions of 10x engineers, superstars, or rockstar developers, which aren’t definitions of good engineers in any way. Someone may produce a lot of work but it’s often at the cost of team spirit and results in low-quality code. Ultimately, the team is demoralized and the organization bears the cost of substandard code. I used to work in a tech company (bytes), and now I am working in an old money/traditional company (atoms) that uses technology marginally to stay ahead. My team's (a couple of dozens) median age is 53, and I do not see how this relates to them or even to myself. I definitely would like to hear more from "Working Bee Engineer", "Dark Matter Engineer", "How I survived 25 layoffs Engineer", "How I kept my sanity working with internal clients Engineer", "I managed to raise kids being in Tech as Engineer", "The bodybuilder/triathlete/sports(wo)man Engineer" and so on. I'm not being cynical, but I miss the old days of actionable and down-to-earth blogposts that anyone could relate to.

jimberlage 2y ago

It’s useful to have a vision like this. Not because everyone will hit all these criteria. (If you do, I’d love to steal your hiring process.) I find it useful because coaching people to be better is easier with an ideal like this to point to, that is complete. Lots of managers struggle to put into words why they don’t see an employee as they see themselves. If you have a genuine difference of opinion, you can relate back to something like this. Say your employee does a lot of tickets, and sees themselves as a hyper productive engine on a team. You as a manager see them picking up low-impact tickets and not finishing any features the business asked for end-to-end. The employee wants their productivity to be recognized. You want your employee to be more focused on a single business outcome rather than seeing a high number of tickets in the done column. Some people (especially neurodivergent people) really “get it” when they have a pre-read they can think on and apply to their situation. A blog post like this is nice because you can have the employee read a bullet and then talk about how it applies to their situation in a 1:1.

louwrentius 2y ago

Maybe it's hard to accept that often, code quality or technical prowess are not that important. What is really important is understanding the actual process that is being supported by the thing you're building. It's so obvious but building something technically sound that doesn't address the actual organisational need is a 100% waste of time and has a huge opportunity cost. And the reality seems to be that the business and IT don't know the right answer upfront, so it's - cliché alert - a journey between professionals helping each other understand how a proces should operate. This has NOTHING to do with technology or technical implementations. At this level, tech is just an abstraction, a black box that does magic.

nicolay1 2y ago

Good engineers want to create the best product possible, and are demanding from the product team. They want clarity and visibility on user insight in order to be able to do the right tradeoffs to maximize customer satisfaction. -> I think that as engineers, we also have the responsibility to create the best product (interested to have your feedback, I want to create a meetup talk on this subject)

spacemanspiffii 2y ago

A developer that ticks all these boxes is certainly a Good Software Engineer, but the reverse relation doesn't necessarily hold. There are many that have made very valuable contributions while not even working on a team, or perhaps even being an asshole to everyone around them, ignoring stakeholders, everything. Or just something less extreme, such as maybe they didn't at all times know their organization that well. That is fine, if it works at their time and place. To call those "Bad Software Engineers" is unhelpful.

kozikow 2y ago

Story of two engineers in a team I worked with. P is what most people would consider 10x engineer (but not this article). Can get anything done few times quicker than anyone else. It's like 10 junior engineers stacked in one person. But it often would be unmaintainable mess. M is a lot like article describes. Understands what needs to be done and creates good technical designs. Often unf*s mess created by P. Delivers business value. Do not write a lot of code. It's funny that depending on whom you ask, M or P would be the 10x engineer and other would be the bad engineer. Real 10x engineer can wear the M or P hat depending on circumstances.

Wheatman 2y ago
I wonder if it woudl be better to think of it as the the 10X team, rather than a single 10x developer. Im still studying CS so I'm probably way off base,but it seems far more realistic, and usefull.
- wrs 2y ago
  There are definitely 10X teams in that sense. Two problems: (1) Very few corporate compensation programs are team-oriented; managers are structurally forced to reward/punish individuals, not teams. In many cases there is even some sort of forced distribution that requires the manager to punish someone on the team regardless of performance. This makes it counterproductive to attempt to construct a uniformly high-quality team in the first place. (2) The organizational friction encountered by a 10X team is the same as for a 10X developer, only much larger in scope, thus more expensive and visible. A 10X developer might want to write a bunch of unit tests; a 10X team might want to swap out the entire CI/CD system and reorganize their relationship with product management.
eXpl0it3r 2y ago
I much rather have no 10x engineer on my team, but instead engineers who do just a bit more than the bare minimum. For example, who don't just test their single use case, but check if it breaks anything around it. Or who invest just a tiny bit more time to actually write down what their bug analysis has yielded. Or who update the documentation after an interface change. Or who write solution designs to think about the approach, before hacking some ugly mess. Or who check with the PO or user if the chosen approach/design is what they expected. Or who ... In my experience having devs who do more than the bare minimum is way more productive for most day-to-day business. Maybe there's room for a powerhouse in cases, where you have to drastically restructure a code base and quickly create some PoC.

revskill 2y ago

Good leetcoder is good engineerer

kl5ag 2y ago

"A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again." Not again. The real world does not work like that. The author has the luxury to have team meetings, onboarding, agile and all of that nonsense because the hard parts of open source have already been written by 10x engineers. What the author is working on is presumably some kind of devops that uses other people's software. Perhaps OSS was a mistake. It enables all sorts of pundits and is now repackaged by "AI".

allgreed 2y ago
Would you be so kind as to elaborate? I definitely see you’re onto something. How does the real world works? What are the hard parts? What’s wrong with using other people’s software?
- azemetre 2y ago
  I took their comment to mean that these people are standing on the massive mountains of progress that have been made, but not acknowledging that a lot of wasted effort was lost learning these things. It's easy to only talk about what should be done with perfection in mind, it's another to talk about what can realistically be done. It's no different in regards for anything else the humane race has done, we know the solutions to be done in regards to climate change, inequality; it's another to convince society to then go and try to solve these things with the solutions we thought of.

bjornsing 2y ago

All posts on this topic should start with a brief description of the problem domain, because all sensible conclusions depend on it. There are problem domains where you just have to be insanely smart to be able to contribute, and there are others (as I get the feeling is the case here) where you just need to be reasonably socially competent and dependable. A “good engineer” in one domain can be terrible in another.

Glitter7030 2y ago

This post makes me a bit angry. In a nutshell it’s promoting engineers doing more project management. I think an engineer at any level should not be managing (“driving”) projects, and you should not expect that, unless you are able to pay “the engineer” both a manager’s and an engineer’s compensation. I like the idealistic view on proactivity, but I think idealising this soup of responsibilities should not be promoted. I want a good engineer and I want a good manager as well in a team.

hintymad 2y ago

> We can’t expect a junior engineer to drive a big project; their scope will be limited I find it a dilemma when it comes to driving "big project", especially in a large company. The engineers who drive such projects often behave more like product managers. They sketch out key product features, work with teams to get roadmaps out, and convince the leadership and teams to get the right resources. In addition, they will also draw a few boxes to have a so-called "architecture diagram", and hand out the actual design and implementation to lower-level engineers. I don't deny the importance of such work, and I do recognize that junior engineers likely won't have the clout or the knowledge to push such project forward. On the other hand, I find the value of such high-level engineers diminish fast in the industry, especially when they want to switch jobs, for the will have lost the ability to get down to specifics to solve tough technical problems. Case in point, I have seen most of the so-called "uber TL" fail interviews because all they could do was drawing a bunch of boxes and talking about strategies or requirements. They may tell you that a recommender pipeline will have retrieval, ranking, and reranking, and even throw around a few model names. But when you ask them any specifics about the landscape, the model architecture, the selection of specific technologies (especially how the selected tech works), they would get stuck. And they certainly can't implement any of the said components. Note this is not a criticism but a lament. I certainly face the same dilemma, and frequently question how I can continue to be more valuable as I grow in my career, especially given that that I don't plan to say within the same company forever and I don't want to be a professional box drawer for life. The only path I can think of now is to become someone like a great CS professor: the professor does not necessarily write all the papers, but she is invaluable to her students by unblocking them when needed, by understanding new paper better than anyone, by pointing out a direction that is not so obvious to the students, and etc. That is, to be someone like Wernher von Braun or Kelly Johnson. Someone who can code out a system like ClickHouse or at least pin down exactly which data structures to use, instead of telling his team vague ideas like let's use SIMD to speed up the query. Someone who can write a working TLA+ spec to show the flaw in a design by his team instead of telling his team that they can use TLA+ to find intricate bugs. To be honest, I don't know how to become like that while keeping getting promoted to a higher-level IC, but I don't see other ways.