Habits of great software engineers(vadimkravcenko.com)
vadimkravcenko.com
Habits of great software engineers
https://vadimkravcenko.com/shorts/habits-of-great-software-engineers/
65 comments
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.
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.
At the end of the day these are wars of opinion until someone checks back wether these gold platings actually make a difference
You want an obsessive non-perfectionist? You find it necessary to say that it's rare to find near-perfect employees? Managers, man.
You want an obsessive non-perfectionist.
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 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.
This feels like something straight out of a management book.
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.
Agreed. Palaver with no actionable advice.
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.
>Joy of tinkering - build projects, try out frameworks, build stuff on the side. Keeps the spark alive.
>Tech detox — Recharging away from your monitor makes you a better programmer.
Aren't these the opposite of each other? Do build stuff on your own time, but don't spend your own time on the computer?
>Tech detox — Recharging away from your monitor makes you a better programmer.
Aren't these the opposite of each other? Do build stuff on your own time, but don't spend your own time on the computer?
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.
Nope,
Go above and beyond, but still close tickets = work 60 hrs/week
Do a tech detox = you better not have family to visit, because every vacation has to be about recovery from work.
Do side projects = what are kids ?
All of these these posts are written with a massive dose of cognitive dissonance.
Make US top 1 percentile wages, but live with the emotional security of a daily wage earner. Amazing !
Go above and beyond, but still close tickets = work 60 hrs/week
Do a tech detox = you better not have family to visit, because every vacation has to be about recovery from work.
Do side projects = what are kids ?
All of these these posts are written with a massive dose of cognitive dissonance.
Make US top 1 percentile wages, but live with the emotional security of a daily wage earner. Amazing !
You can do the one after the other. When on vacation, no tech. When at home, one weekend a month (or some afternoons), do some tinkering and learning
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.
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.
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.
[deleted]
I mean obviously you can do both, why be so obtuse?
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.
There's something deeply depressing about a modern software developer role consisting of 20% coding.
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.
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.
And mostly on how many reports you have.
I agree.
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.
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.
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.
20%! Where is this magical place you work?
I think I write perhaps a couple of lines a week and that's usually patching something in an emergency after other people have failed.
Advice: never get too senior.
I think I write perhaps a couple of lines a week and that's usually patching something in an emergency after other people have failed.
Advice: never get too senior.
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 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...
Ada Lovelace is a hero for having the sense to die before computers were powerful enough to run her programs.
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.
This was my life, until I moved from SF to Japan. Now my life is 90% coding and I’m 350% happier.
How many hours a day though?
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.
Coverage for preexisting conditions.
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.
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).
A big piece is communication.
- 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.
- 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.
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.
No one says it but everyone knows it should have been a boat.
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.
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.
[deleted]
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.
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.
First habit: stop calling them engineers.
I have just a few simple rules.
Be:
- World class at what you do
- Humble
- Helpful
- Someone with a reputation for solving problems, not causing more
Be:
- World class at what you do
- Humble
- Helpful
- Someone with a reputation for solving problems, not causing more
Not sure you can consider yourself to be world class and also be humble. Humble is a state of mind, not a behaviour.
Perhaps aiming to be world class.
Perhaps aiming to be world class.
[deleted]
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”
> Not sure you can consider yourself to be world class and also be humble.
A good example of such a union is Newton’s letter to Hooke (1675). Most folks will recognize the “standing on the shoulders of giants” quote.
A good example of such a union is Newton’s letter to Hooke (1675). Most folks will recognize the “standing on the shoulders of giants” quote.
> Most folks will recognize the “standing on the shoulders of giants” quote.
Context is everything. Newton said that to Robert Hooke, a short man with a hunchback!
Context is everything. Newton said that to Robert Hooke, a short man with a hunchback!
better way is to be humbled.
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.
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.
Slightly snarky, but another great habit is brevity in communication :)
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.
People overcomplicate everything!
People overcomplicate everything!
[deleted]
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).