6 ms·
Habits of great software engineers
- tr888 3y agoThere's something deeply depressing about a modern software developer role consisting of 20% coding.
- sverhagen 3y agoIt 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.
- Apocryphon 3y agoMaybe, 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.
- 6510 3y agoCoverage for preexisting conditions.
- glutamate 3y agoIf 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.
- 6510 3y agoA 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 3y agoAda Lovelace is a hero for having the sense to die before computers were powerful enough to run her programs.
- rafamvc 3y agoIf 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.
- jamil7 3y agoI 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.
- ido 3y agoAnd mostly on how many reports you have.
- zmgsabst 3y agoI 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.
- ido 3y agoI 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).
- zmgsabst 3y agoMy 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.
- davedx 3y ago
- baz00 3y ago20%! 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 3y agoNot 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 3y agoThis was my life, until I moved from SF to Japan. Now my life is 90% coding and I’m 350% happier.
- Apocryphon 3y agoHow many hours a day though?
- yodsanklai 3y agoYes, 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.
- realharo 3y 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 3y agoYou 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 3y agoI'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.
- jamil7 3y agoYeah, 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.
- quickthrower2 3y agoA 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.
- baal80spam 3y agoI 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 3y agoNot 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 3y agoIs 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”
- deleted 3y ago[deleted]
- joshxyz 3y agobetter 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 3y 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.
- drewcoo 3y ago> 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!
- deleted 3y ago[deleted]
- lordnacho 3y agoA 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 3y agoSoftware 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.
- 6510 3y agoNo one says it but everyone knows it should have been a boat.
- davedx 3y agoGet 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!
- onion2k 3y agoFor 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 3y agoThis feels like something straight out of a management book.
- keithalewis 3y agoAgreed. Palaver with no actionable advice.
- onion2k 3y agoYou'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.
- keithalewis 3y agoHere 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.
- bloqs 3y agoThis 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 3y agoSlightly snarky, but another great habit is brevity in communication :)
- braza 3y agoWhenever 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.
- deleted 3y ago[deleted]
- sys_64738 3y agoFirst habit: stop calling them engineers.
- dwb 3y agoIs 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).