Habits of great software engineers

https://vadimkravcenko.com/shorts/habits-of-great-software-engineers/

by bndr • 3 years ago

51 61 3 years ago

tr888• 3 years ago

There's something deeply depressing about a modern software developer role consisting of 20% coding.

sverhagen• 3 years ago

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.

Apocryphon2• 3 years ago

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.

65103• 3 years ago

Coverage for preexisting conditions.

glutamate• 3 years ago

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.

65103• 3 years ago

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...

bluGill• 3 years ago

Ada Lovelace is a hero for having the sense to die before computers were powerful enough to run her programs.

rafamvc• 3 years ago

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.

jamil72• 3 years ago

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.

ido2• 3 years ago

And mostly on how many reports you have.

davedx2• 3 years ago

Yup. 20+ years experience and I spend the majority of my time coding. The solution is easy IMO: work for startups not politics riddled corporations

baz00• 3 years ago

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.

rkangel• 3 years ago

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.

bcherny• 3 years ago

This was my life, until I moved from SF to Japan. Now my life is 90% coding and I’m 350% happier.

Apocryphon2• 3 years ago

How many hours a day though?

yodsanklai• 3 years ago

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.

realharo2• 3 years ago

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?

rolisz• 3 years ago

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

monsieurbanana• 3 years ago

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.

manyxcxi• 3 years ago

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.

screye• 3 years ago

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 !

lloydatkinson• 3 years ago

I mean obviously you can do both, why be so obtuse?

realharo2• 3 years ago

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.

baal80spam• 3 years ago

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

beardyw• 3 years ago

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.

f1shy• 3 years ago

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”

joshxyz• 3 years ago

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.

mathgeek• 3 years ago

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.

lordnacho• 3 years ago

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.

JackMorgan• 3 years ago

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.

65103• 3 years ago

No one says it but everyone knows it should have been a boat.

davedx2• 3 years ago

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!

onion2k4• 3 years ago

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).

nindalf• 3 years ago

This feels like something straight out of a management book.

keithalewis2• 3 years ago

Agreed. Palaver with no actionable advice.

vermooten• 3 years ago

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.

onion2k4• 3 years ago

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.

ponector2• 3 years ago

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.

mnsc• 3 years ago

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.

szundi• 3 years ago

At the end of the day these are wars of opinion until someone checks back wether these gold platings actually make a difference

dwb4• 3 years ago

You want an obsessive non-perfectionist? You find it necessary to say that it's rare to find near-perfect employees? Managers, man.

onion2k4• 3 years ago

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.

bloqs• 3 years ago

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.

rco8786• 3 years ago

Slightly snarky, but another great habit is brevity in communication :)

braza• 3 years ago

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.

sys_647382• 3 years ago

First habit: stop calling them engineers.

dwb4• 3 years ago

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).

Habits of great software engineers

Related Stories