For me (as an engineering manager these days) the most important quality I look for in a developer is a people-focused approach to work. No matter what you work on you should always be thinking "How is this making the end user's life better?" even if your code is miles from anything thr user sees. That manifests in traits like a focus on being error free, fast, usable, accessible, ethical, and 'kind'.
Good developers don't stop at making the happy path work. They obsess over making their code fail elegantly. They make systems that are strongly robust. They think about the failure states deeply. Slightly antagonistcally, they're also able to prioritize moving forwards when something is good enough rather than trying to make something perfect.
In my career I've only met and worked with a handful of really good devs. I've worked with loads of people who are great at one or two aspects of the job, but you rarely find the complete package. I think the best devs have a key skill of understanding how to make good tradeoffs and maintain a balance of what's needed versus what's interesting. I know I don't have that skill (yet).
But are you encouraging your developers to implement such approach?
Everywhere I've worked, managers are pushing devs to close tickets, implement features as fast as possible. Usually they are fine with implementation of happy path only, leaving tons of technical debt to the far future.
If someone puts an extra effort to have perfect system - that means they will look less productive than their peers.
Extra effort for getting to "perfect" I would argue mostly is gold plating, which not only is less productive than those good-enough-peers. But sometimes counter productive where every hypothetical edge case have been solved with extremely complicated/complex (unmaintainable) code. I'm currently replacing such "perfect" code with a, hopefully, simpler mess that still get the customer's work done.
I want user-focused pragmatists who aim high while understanding they don't have the resources available for perfection.
I was a dev for 25 years before moving into management. That's pretty much my approach, although I think I fell a bit short in many ways. Now my job is to try to lead other devs to do better than me. I'm trying to be the manager I wish I'd had. I don't think that's unreasonable.
I've been a developer for 14 years. Maybe I've been incredibly lucky, or the companies I've worked for have had watertight hiring processes, or something, but I can't think of a time where someone didn't care about the things you list unless there was some massive pressure for them to cut corners. (Okay, maybe one contractor, a long time ago, but they were very obviously sub-standard.) I can't think of anyone who had any significant tendencies to perfectionism. Quality, maybe, but not perfectionism. And so when I come across statements like yours, I have to wonder, what standard are you pushing for? How much are you truly considering the highly-connected, messy context of these individual qualities? I'm so tired of these big-talking over-generalities where the onus is always on the individual.
Managers are looking for people who will do more for the same money as others.
If employees are just doing the job to get a paycheck - they are labeled as quit quitters.
Your first sentence is certainly an eternal truth; I feel like there's quite a gap between those who consistently work more than their worth and those who only do what is strictly necessary. I'm somewhere in the middle – there's little chance of me doing what I'm not paid for, but at the same time I do very much care about what I produce, and the experience of the people I work with, and whoever ends up using what I make, and the wider effect on the world. I would put the vast majority of developers I've met in the same bracket – so companies should really want to keep us happy.
It's mostly experience with a big handful of Will Larson's 'An Elegant Puzzle' and Camille Fournier's 'The Manager's Path' to inform missing bits. So yeah, maybe.
Management-speak or not, it's correct. Software development is much more social than it was when I started. Pairing and mobbing get better results faster.
You're right that this isn't actionable advice. That's because this is me talking about the sorts of behaviors I look for, not the skills and actions that are derived from those behaviors. How a dev becomes someone who cares about the things that make software better is totally up to the individual.
Here is some actionable advice: give your existing employees an opportunity to become the sort of developer you wish you had. Convince your bosses to allocate time during working hours to allow them to learn new things and write experimental code. As they grow into the employees you wish you had, give them more responsibility for their deliverables. That is how you encourage them care and how you scale as a boss.
I do both. I’ve got lots of not computer hobbies (and kids) and I have tinker projects. I usually use early morning a couple days a week for tinker time as I’m an early riser.
I'm general I feel icky about people telling employees how they should spend their free time.
I'm keeping an open mind, that's my initial reaction but if what follows is interesting then it has value nonetheless. In this case it's just 2 generalities that don't really help anyone, akin to me saying that to live a better life you should have a good work-life balance.
Everybody knows that, I'm not bringing anything that they can reflect about or act upon.
Yeah, I’m also quite conflicted on this. I don’t like the way the industry expects this to some extent. At the same time most of my learning comes from tinkering outside of work and some larger initiatives have started from me hacking around on parts of a work codebase or open source dependency on the weekend or after work.
A neat trick would be for a company to say “you work 40 hours but 5 of those can be anytime you want 24/7 - and you can tinker. That would be a perk. some people can just do the normal 5 days but others might do stuff at the weekend because it is when they want to do it. I believe tinkering is essential for productivity not Jirafying evey minute of paid time. Software is non-linear. A tinker could lead to an entire team-quarter of work saved.
The Ayns will say do those 5 in addition you lazy bastard to which I say OK then I will do them for my own IP/ideas.
Advice on being a better professional from a colleague and an employer dictating my free time usage are entirely different things. This thread is very clearly about the former.
With a full-time job, your time will be quite limited. If you want to learn/read (on more than 1 subject), build something with what you've learned, and still have enough time for other things, chores, not to mention fun, you will eventually find you have to give something up, or do it in a very limited fashion.
If 80% is spent in progress meetings, scrum point estimation, and other acts of performative taylorism, yes.
If 80% is spent understanding reading about the domain in which you are working, talking to your users and domain experts, documenting your work, and mentoring juniors or being mentored by seniors, there should be nothing depressing about that.
I probably spend around 80% of my time coding in a senior role with around 12 years experience. I think it depends highly on where and what you work on.
If you have 8-10 engineers you’re supervising and are the person interfacing with management, I don’t think it’s unreasonable to spend half your time coordinating, teaching, and planning.
So scale down the expected SDE 1 quotas (~50% coding), and you get around 25-30% coding time.
I think a lot of people confuse being an experienced career engineer with being a technical lead; that’s the real jump from SDE 2 to SDE 3.
I think I'd get a lot less than 25-30% coding time while managing 8-10 people (and also depending on what you're doing while "supervising", if there's a dedicated project/product manager in addition to you, how senior are the other engineers, etc)! In fact at that point I think I'd be managing too many people ("ideally" 1 lead/manager isn't managing more than 5 ICs).
My experience of Big Co is that you have both a manager (HR and business sense) and a supervising/lead engineer (SDE 3) for a product.
I don’t think I explained that well — but a 3:3:1 to 5:5:1 SDE 1:2:3 mix is fairly standard across industry. (Again, with an SDM doing the managing.)
I used the word “supervising” because I wanted to distinguish that technical leadership from managing, but didn’t explain enough. Sorry for the confusion.
If you considering code reading part of coding, coding 20% of the time is certainly not enough.
The article is meant for a neurotypical ideal average employee.
There are many effective programmers that have different workflows.
A trait of a good manager is allow different people to be effective in the collaboration of writing software together.
The article paints an unreal rosy picture where "everything runs smoothly and has forward momentum".
Working with a live system is messy. There is always compromise because there is never enough time to keep everything smooth.
It is very common to be stuck at some problem. That moment you let a problem clunk around your brain and you randomly think of a solution in the shower or at the grocery store is way too common.
And honestly fun.
A great software developer doesn't have a computer. He lives alone in a cabin in the woods. He knows it is better that way as it minimizes harm to others and allows him to skip all of the meetings forever, until the end of time...
It depends heavily on the company and the team you're on. If you are a more seasoned professional, you probably get the luxury of filtering on this criterion. And a lot of people also really enjoy the other eighty percent.
Not all engineering is coding. If I'm debugging a couple of hard to find problems this week I won't write lots of code but I'll certainly be doing valuable engineering.
Maybe, but you also have to consider how much preexisting code has been prewritten in frameworks and libraries. Consider how much of “coding” is spent integrating that code instead of typing out new lines of code.
Yes, pretty sad. Even worse, these 20% coding can be fixing bugs in different projects your team work on, and on which you have only a basic understanding.
The percentage of coding on a project that I get to design is even lower.
Is it common in other professions for senior colleagues to opine so lengthily, definitively and frequently about not only every little detail about others' work practices, but their non-work life too? There's no end of blog posts like this where someone who's been around a bit (and sometimes not even that!) lays down the law about what's good and what isn't. And unless it's done with a lot of humility and nuance, my reaction is likely to be very negative, even if they're right (and/or I agree with them).
- What are we making? Why does it work on a domain level?
- Feedback. This thing I've built, does it do what it needs to do? No? What needs to change? Two-way conversation.
Finally, I would say that while writing code is important, it's also important to be able to read code, and to remove code. It's as important to be able to read what others have written as to be able to compose your own, or surgically remove pieces.
Software engineering on a live product feels like adding features to an aircraft in mid-flight. Imagine how much communication that would take to have a half dozen engineers crawling over the wings, swapping out engines, adjusting the fuel mixture, maybe even entirely changing the power supply. Especially when we assign totally different features to each engineer with the expectation that they are all worked on simultaneously.
One engineer has been asked by a naive product owner to remove the wings "for aesthetics". A junior engineer thinks we should be wind powered or something. A senior engineer has gone rogue and is trying to replace all the aluminum with titanium.
This aircraft doesn't even have landing gear, it'll never come down other than to crash. Meanwhile we crawl all over it, needing constant communication to keep from making a fatal change. Also the average tenure of an engineer on this aircraft is two years, just enough time to get the hang of it before jumping to the next aircraft.
It's amazing we even spend 20% of the time coding.
This is why I'm a big fan of pairing and mobbing. Fewer streams of work paradoxically allows for faster feature development because of reduced communication and training costs.
This is why I have my engineering teams only given X/2 streams of work where X was the number of engineers. I want more people thinking about finishing fewer tasks. Which means on average they spend about 28 hours a week writing code, far more than the industry average of 8 hours. This also reduces rework.
Whenever I read an article that praises a software engineer as "great," I always wonder what that actually means.
Is it the ability to solve problems using code?
Is it performing maintenance?
Is it the capability to navigate a socio-technological environment to build something?
Or is it a mastery of technical fundamentals?
In most other professions, "greatness" is often tied to the actual outcome of their work. A salesperson can say, "I sold XYZ units this month," a plumber can say, "I fixed XYZ bathrooms this month," and a soccer player can say, "I made XYZ goals or defended XYZ balls against the goal." However, when it comes to software, some people forget the importance of outcomes, or worse, claim some exceptionalism in this field.
I'm not trying to be cynical here, but for me, it's quite challenging to establish if someone is great or not if we detach outcomes from the evaluation, regardless of the concept of "greatness" in this piece.
At least for me, greatness has a large share of context, opportunity and concrete outcomes.
This is one of those posts where someone in a profession mistakes their professional experience for the understanding of how people work. Although not explicit, there is perhaps an implication that one should TRY to have these things to be brilliant.
Many of these habits are a byproduct of personality traits, which are largely plastic. Tinkering and lots of projects indicates high levels of Openness(HEXACO- openness to experience). Low Neuroticism can play a large part in the point about environmental fragility.
Great software engineers can (from MY experience and largely the collective commentary of hacker news) have a variety of dispositions.
Is a stete of mind, and can be seen completely different from the outside. Whenever I knew something, I always assumed all know that, because if I know that…
The problem is, I came across always as rude. I had to adjust my “humble being”
we can be world class, and at the same time have the appreciation on how other people excel at their craft. especially the fact that we are standing at the shoulders of giants.
Get shit done in a maintainable way, communicate communicate communicate. That’s it for me. You don’t need that extra crap about tinkering or tech detoxing etc etc.
Good developers don't stop at making the happy path work. They obsess over making their code fail elegantly. They make systems that are strongly robust. They think about the failure states deeply. Slightly antagonistcally, they're also able to prioritize moving forwards when something is good enough rather than trying to make something perfect.
In my career I've only met and worked with a handful of really good devs. I've worked with loads of people who are great at one or two aspects of the job, but you rarely find the complete package. I think the best devs have a key skill of understanding how to make good tradeoffs and maintain a balance of what's needed versus what's interesting. I know I don't have that skill (yet).