On Good Software Engineers
candost.blog
candost.blog
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 ;)
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.
It's tragedy of commons. To stop this we need software engineers to own their own code legally.
This is also a reason lots of decent open source code comes out of the media industry. As much as we despise the media for its effect on society, journalists are much better than software developers in enforcing their worldview on others.
That was realistic or if someone feels like cynical take on the friendly advice from article.
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.
Im still studying CS so I'm probably way off base,but it seems far more realistic, and usefull.
(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.
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.
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.
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.
Is this what people think of when they think of an old codebase? Must be nice :')
15 years of active feature development on the other hand will likely be a major slog for any developer, regardless of experience. There's a lot that can happen in 15 years even if there were only 1-3 developers if they everyone takes the easy path since they know where all the gotchas are. It's only when new devs are added that the curtain comes down and the lazy abstractions (or lack thereof) are exposed.
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.
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.
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.
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.
Whilst I accept that bad abstractions can really hold a codebase back, good abstractions and layering are what make code clean, understandable, and maintainable. I don't think we should throw the baby out with the bathwater.
What's important is having good designers who understand the domain and are able to judiciously select the "right abstractions" to apply at the "right time". Often this will mean people who have worked in a domain and made or experienced the consequences of mistakes previously.
Bad or inexperienced developers will write bad code. Good, experienced devs will do a little better. Don't let inexperienced devs design abstractions that you'll be stuck with for a while.
What would be a case where you would _have_ to add an abstraction? I'd say you probably never have to, but things will get start getting complex.
Basically things which will never change, and when they do, you really don’t want them to change in a million things.
Otherwise I’d probably never add abstractions. Sometimes it makes sense to build a service which owns a domain on a business which is then consumed by others, but you have to make sure the consumption can be stopped when that domain is no longer relevant without it causing issues.
I’m not sure what my personal stance is on frontend components. Probably as low reuse as possible.
Disturbing fact: sometimes you get best ideas out of boredom:)
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.
I don't think of morals when I read "effective engineer" personally
Star Wars Death Star stuff maybe, or a perhaps a global system to direct people's attention to ads? ;)
> what they want isn’t necessarily what they need
and i agree with effective. it’s less of a loaded term but i feel it’s also a more accurate description of what we try to strive for as engineers.
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.
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.
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.
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".
How does the real world works? What are the hard parts? What’s wrong with using other people’s software?
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.
I am honestly disappointed to see this level of discourse on HN.
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.
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.
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.
What about: "Setting expectations for managers is tricky for all software engineers." ?
-> 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)
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.
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.
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
Wow, I don't think I ever heard it summarised so well. I cannot agree more with this statement.
"Process people can't resist trying to optimize things they superficially comprehend."
Also: Please don't post shallow dismissals, especially of other people's work.
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.
> 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.
In my experience where I've worn both IC and TL/manager hats -even just going from "adequate" to "OK" team/engineering/product manager leads to impact/output that's bigger than having the best (so that mythical 10x) engineer.
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.
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.
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.
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.
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.
I've seen this plenty of times.
Recently I was trying to explain the pros and cons of micro-services, and more importantly, microrepos, with regards to automated testing. The lead engineer that said he'd quit if I colocated the tests with the app.
Same place, they replaced all deploy system with argo, but every environment is pinned against main, which means you can no longer test a change without it going to all environments at the same time.
In both cases, the engineers are actually much higher skilled than average and churn out / lead change, but they'd rather be chasing a fad and just don't care if their changes shit on other parts of the SDLC.
Personally I have had clashes during my career with people who obsess about unit testing way too much in places where it just doesn't add any value (in fact destroys it by requiring lots of work and additional mainteinance). Value in the end is quite a subjective thing so it doesn't make sense to argue that much about it.
It's really pointless to quantify the productivity of a developer via numbers. It's a conjunction of knowledge, intelligence and ability to express this as code.
In many cases I've observed 10x engineers are those that can simplify and automate the processes and programs to need minimal human input.
In some cases it's more about deleting code than producing it.
But nowadays "10x" just goes into the same pile I throw "agile" and other meaningless terms.
Part of it is problem selection, part of it is hard work, some fraction appears to be genius. But it is obvious and observable, I've seen average developers at work and they just won't achieve the results the top performers get even if given 10x as much time.
The denial by some of the existence of 10x engineers is one of the ongoing baffling mysteries to me.
Why only 10x? And why not try to make your 1x into 2x?
It's like if sports fans spent all their time talking about a potential player who could deliver exactly 10 times more goals than everyone else. Why is this a topic that needs to be brought up so often? Why have we 'software engineer'-ised the idea that some people are much more important for productivity?
The "myth" is that there was a formal study done and these performers were identified. The reality is that the study was looking at the difference best and worst performers, not best vs average, which is an important clarification.
This has since evolved to a further myth that 10x programmers exist, but are somehow always harmful and should be avoided. There are plenty of articles examining "The 10x programmer myth" which, with no more evidence than the original assertion, put forward that 10x programmers should be avoided.
And here in this article, it gets re-written again, that they aren't even 10x as productive, and just produce ten times as much in terms of LOC but it's all terrible code!
That is an important, often misunderstood, clarification, but I think it’s also subtly incorrect.
It’s 10x higher than some minimally competent level, not 10x higher than the worst in the field.
I think the original studies (certainly later follow-up studies did this) excluded results from participants who did not complete the assignment at all. That makes some sense from a data analysis convenience standpoint, but truncating the left tail and then saying some are 10x better than the absolute worst (that you truncated in the previous step) isn’t fully representative of what we see in the field.
Except that particular 1968 paper, which is held up and treated as gospel, because it helps to confirm rather than challenges their personal experience.
If we are going to demand better, we should do so consistently. Reproducing that result with more rigour would be a useful start.
One is "it's not 10x, but is maybe 4 or 5x"; the other is "if differences exist at all, it's definitely less than 2x".
I get/have sympathy and agreement for the first type on a technically-precise level, but it also doesn't really change any of my behavior as a technologist or people/org leader.
The second type of skepticism I just don't understand at all from people who have worked more than a couple years in industry.
This is a myth, the worst performers didn't complete the task or delivered a faulty solution, those were removed from the study so you didn't see the worst.
Best to worst would be much much larger than 10x, however finding anything larger than 10x would take a very long time as it means waiting around for the slowest to finish.
Edit: And if you add back all of those worst performers, best vs average would also shift significantly towars 10x.
Basically it's in the 30's in Russia, where a coal miner, Alexei Stakhanov, had a mythic productivity and inspired people to reach that said mythic productivity, as an example. While Stakhanov really existed, it's not factually established that he managed to produce what is claimed.
Same goes for 10x developpers. Is there at least a name for some of them and a concrete example of what they managed to produce ?
That is, I believe, a fairly good explanation.
There were several studies, and it’s about being 10× as productive as the worst not the average.
https://www.construx.com/blog/the-origins-of-10x-how-valid-i...
It wouldn't take them 10 times as long as Linus to make Linux or git, social context and all. It just wouldn't happen.
So what's the useful takeaway from this topic we spend so much energy on? 'Hire people who are good'?
You have people gaining billions of experience points or tens of thousands of boss kills in the same amount of calendar days the average player accomplishes tens of millions or hundreds of boss kills.
I don’t see why this couldn’t be the case for software engineering. I have a wife and kids and spend 10 to 15 hours doing sports a week. I’m maybe more efficient than average since my career has gone well, but there are people who are way more efficient and way smarter than me. Couple that with them being able to spend twice or more the number of hours, and you might arrive at similar 10-100x productivity numbers that you see on the game RuneScape.