Habits of top engineers

https://engineercodex.substack.com/p/7-simple-habits-of-the-top-1-of-engineers

by myshpa • 3 years ago

59 59 3 years ago

engineercodex.substack.com

amelius• 3 years ago

Misses the most important one: making sure your office has a door.

smitty1e• 3 years ago

The best engineers I know complete projects fast… by coding slow.

Via an Army friend: "Slow is smooth, and smooth is quick."

Waterluvian• 3 years ago

My #1 issue as an engineer is running out of steam. By the end of a feature development I really struggle to force myself to end it properly. To not rush the testing. To update all the documentation. To fix the discovered quirks “properly.”

I think it may be related to ADHD because I’m getting paid the same and there’s no rush to move onto something else. The work environment is quite good.

My current coping mechanism is to work on two (but never more) projects concurrently and swap between them every few days.

jddj• 3 years ago

No ADHD here but all of that is perfectly relatable.

The last 10% of polishing is hard, and the 10% after that is even harder.

Working on multiple projects helps me too.

ricardbejarano2• 3 years ago

I have found success in using your "coping mechanism". I usually alternate between 2 projects that need my "engineering cycles" and then have N that need my "management cycles", which I don't find as exhausting and don't drain "steam" as quickly.

In bodybuilding, this is called "periodization", I'd say that's a pretty accurate term to describe this.

anonyfox• 3 years ago

this sounds interesting to try for me. Software engineering alone wears off for me after a while on a project to the point I simply cannot type a single line for it if forced. Managament is where I am really good at coming up with ideas/plans/strategies but the day-to-day following-up (including staying calm and friendly in the face of very slow employees sometimes) also is soul crushing and depressing after a while. My sweet spot somehow is in the middle an hopping between projects, mentoring engineers and also doing my own projects on the side or even spearheading initiatives... sometimes.

What cycle times/scheduling works best for you? how do you deal with the dread of picking up a topic again after letting it go mentally?

rendall• 3 years ago

If you can, implement code reviews in your integration pipeline. Someone pointing out my lazy shortcuts keeps me honest.

andenacitelli• 3 years ago

Have ADHD and this matches up perfectly with my experience. Finishing feature work off (especially things with a long timeline) is difficult and I tend to also cope that way, working on multiple things at once because it’s difficult to tunnel on any one thing.

BerislavLopac• 3 years ago

to end it properly. To not rush the testing. To update all the documentation

A trick I've learned is, when possible, to start with tests and documentation.

oaiey• 3 years ago

With communication comes knowledge. And with knowledge comes clarity. And with clarity comes fast written, good code.

There is only one way to become a senior role in computer science: be good in communication with humans.

revskill• 3 years ago

If there's one word that i could teach my self 10 years ago, it's "iteration".

Miracle doesn't exist overnight. You build a miracle by small steps in small iteration.

That's how you build software the right way.

SanderNL• 3 years ago

Write aesthetic, simple code

This is incredibly “draw the rest of the owl”. If it was easy to do that we would all do that.

Step one to become a good developer: be a skilled developer.

Thanks for that. Also, overlapping skill is less useful than you make it out to be. They also all have arms and eyes. That’s not what sets them apart. Engineers of some standing all follow these very basic guidelines. That does not an 1% engineer make. In fact, there is no definition of this fabled one percent engineer. At least not in this article so I cannot be sure what this is about.

The fact this article starts out with referencing big companies and leading positions - AKA status and power - also signals that these people he regards so highly are at least also talented politicians and/or entrepreneurs.

bryancoxwell• 3 years ago

This is incredibly "draw the rest of the owl".

The post isn’t meant to be a tutorial on becoming a top engineer though.

jabradoodle• 3 years ago

Kind of besides the point, "be good at X" is a trait; not a habit.

perihelions• 3 years ago

For people not familiar with the metaphor, this is the context:

https://i.imgur.com/rCr9A.png ("How to draw an owl")

dkarl• 3 years ago

To get better at writing code, stick to this rule: Never submit a first draft. Always make your code better before you submit it.

If you can see the difference between ugly, complex code and aesthetic, simple code, and you're willing to spend extra time to go over your code and make it better, you'll develop the skills to write it better in the first place.

This won't teach you taste (years of maintenance and exposure to other people's code will do that) but it will teach you the skill of living up to a style.

tjpnz• 3 years ago

Does name dropping FAANG in the first sentence still have the same impact it did ten years ago?

tamimio3• 3 years ago

Just write “ex-“ before FAANG in your resume and boom, you are automatically successful and a 100x outperformer fella!

wolframhempel• 3 years ago

A personal habit that I found really helpful early on was to always force myself to do things "the proper way". Here's what I mean by that:

- Are you bad at regular expressions, but feel you could get away by just processing text with some loops and split statements? Don't. Use RegExes - every single time until you are good at it.

- You don't really understand database joins and normalization, but you feel you could just make two queries and merge things in your backend code? Nope - go learn joins properly.

- You're overwhelmed by large CSS stylesheets and are tempted to write some inline style or important! statement? Nope - read up on CSS taxonomies and structures...

etc...

quickthrower2• 3 years ago

And especially especially for security. Slow down and make sure the feature is secure as possible.

xyzzy_plugh• 3 years ago

Are you bad at regular expressions, but feel you could get away by just processing text with some loops and split statements? Don't. Use RegExes - every single time until you are good at it.

I'm quite proficient with regular expressions but rarely reach for them outside of throwaway scripts. I'd much rather use some loops and split statements, frankly.

jweatherby• 3 years ago

Agreed. Early on, I would enjoy solving a problem with regex, but really, that's a code smell and a red flag beyond basic validation.

znpy• 3 years ago

Depends on the case, however...

A few times i've seen a number of lines of code that was easily replaced with a single line of regexp matching and value extraction via named capture groups. The amount of code that comes out of "some loops and split statements" quickly turns into spaghetti code, especially when you need to extract values and/or reference what would be other capture groups.

In my experience, as long as you provide (at least) one sample of the expected input, a regexp is essentially self-documenting.

danielvaughn2• 3 years ago

100%. I started my career like this - I call it The Hard Way.

But then once I worked in a few startups, I realized the point was to just ship as fast as possible. I lost the Hard Way mindset and settled into a life of wide, shallow knowledge. As a result I now feel like a glorified plumber, not at all what I set out to be. So I’m trying to figure out how to get back to that state, but it’s difficult to slow down once you’ve gotten used to moving fast.

comprev• 3 years ago

Unfortunately what you describe is the norm. We're paid to solve business problems and time (therefore, money) is a limiting factor.

For many people the only time they can "practise" RegEx (etc.) is outside of office hours.

There is probably significant overlap in a Venn diagram of "1% engineer" and "20-40 year old single person with no children or social life"

lr4444lr2• 3 years ago

My unsolicited advice: stick with a company you like for a while. You will earn the right to work on hard problems that resist simple solutions and mere "plumbing". And those problems will come up sooner or later. Keep an eye out for them.

hardware2win• 3 years ago

- Are you bad at regular expressions, but feel you could get away by just processing text with some loops and split statements? Don't. Use RegExes - every single time until you are good at it.

Ehh, i disagree about regex

Regex is great tool with shitty API, at least when used in code, not in config files

When things arent trivial I suggest writing parser, so your loops and splits instead of ugly monsters

lr4444lr2• 3 years ago

Everyone thinks their own #%$@ doesn't stink. "Aesthetically pleasing" code often looks different to me than other people.

timrobinson3332• 3 years ago

I have to say that's not been my experience. I find most people will have a similar opinion of what's clean code and if I point out something that's messy they'll usually respond with reasons why it's messy rather than denying it.

sergiosgc• 3 years ago

The article misses the most important "habit": be an engineer, not a coder. The best engineers I know design the right solution in the first few iterations. They do this because they invest time in understanding the problem. This is a social skill, not a technical one.

You don't have to code fast if you don't need to write a solution for the problem ten different times.

tamimio3• 3 years ago

Thank you! A lot of misconceptions about “coder” and an engineer, engineering is a philosophy and a discipline of converting and applying theoretical knowledge into real-life applications after all design considerations, mixing that with coding is like mixing a philosopher with a writer, a doctor with a nurse, etc., and this is not to play down programming, but both concepts should not be mixed.

nonrandomstring• 3 years ago

Keep a notebook. Most things you struggle with, you already solved once and forgot. I use org-mode. YMMV.

jckahn• 3 years ago

I meet this need with comments and code search tools.

timrobinson3332• 3 years ago

I find that almost all coders can recognise clean code but many fail to produce it.

I think partly it's down to the "if it ain't broke don't fix it" mentality - once it's working there's a temptation to leave it as is and move on to the next task, especially if you're under time pressure.

In fact the time just after you've got it working is the time you have maximum knowledge about the code and the problem it solves, so that's the best time to refactor. Even something as simple as renaming variables and functions to be consistent and reflect what they actually do (rather than what you thought they would do when to started) can make a huge difference.

paulhodge• 3 years ago

this advice isn't all that useful.

On that first one: "Every outperformer I knew had the style guide internalized"

No thanks.. It's the year 2023, just install an autofixing linter which fixes the code for you, and then worry about other things.

iraqmtpizza3• 3 years ago

fixing whitespace is something to do while thinking about the code. unless you can't do two things at once in which case it's a problem. either way, autoformatting doesn't magically make you engineer faster unless your company enforces a style in a really fascist and pedantic way

mcluck3• 3 years ago

Autoformatting makes me faster because I don't have to think about it at all. All of the code in the codebase looks pretty similar and it opens up a sliver more mental RAM

heisenbit• 3 years ago

Exactly, I’m all for readable code but this style guide stuff is cargo culting. The guides are the culmination of wisdom of past decades where IT became dominated by a few language stacks. Innovation happened elsewhere as computers got faster, bigger and use cases grew but did not transform. This changed and use cases and targeted platforms are different now calling for new stacks with new conventions. A typical developer is exposed to myriad languages and tools. Documenting small details in proper format never was enough but these days it has become ever more important to focus on communicating context and motivation.

lubutu• 3 years ago

That works for new code, but I'm much less keen when maintaining legacy code. Sure, you could reformat every file and then proceed to work on them, but then you've had a serious impact on the version history, worsening tools like git blame and often making it harder to understand how a particular piece of code evolved. It's even worse if one reformats and then makes a code change in the same commit...

BytesAndGears• 3 years ago

That’s not the only thing that maintaining consistent style involves. For example, we have an auto linter at my job, but there have been a few (bad) engineers whose code I can recognize even after it’s all auto-formatted.

Plus, when you’ve spent enough time with the code in varied environments, you start to internalize what it should look like. Seeing something that doesn’t match the style guide will stand out as looking funny.

I don’t think they were suggesting that you need to memorize every minute detail of your prettier config to be a good engineer. Rather, a good engineer has focused on writing clean-looking code so intensely for so long, to know it automatically.

bpicolo• 3 years ago

For the top 1%, I suspect one of the biggest differentiators is "write a lot of code". On and off the clock. Working hard / practicing a discipline goes a very long way

cebert• 3 years ago

I’ll admit that sometimes I could structure my code to be more clear. Lately, I’ve been running some new methods I’ve created thru GPT4. I know the method works and does its job, but I want to see how GPT4 iterates on it. While I don’t always use its suggestions, it has made me better consider how I can restructure my code. I can see this as a great way for developers to improve their code quality.

alecco• 3 years ago

Why are there 2 entries in the top 5 of HN of this regurgitated blog?

engineercodex• 3 years ago

Sorry you didn’t like it dude.

If you have any constructive feedback, that’d be more helpful.

PUSH_AX• 3 years ago

Write aesthetic, simple code

Where do idioms fit into this? An example might be golang, ‘c’ could be a perfectly fine idiomatic variable name in go if it’s used very soon after initialisation.

Don’t follow rules blindly

I think this section could be improved by changing it to talk about being pragmatic vs dogmatic

vbezhenar• 3 years ago

The habit that I've found useful for myself is: learn everything from the bottom (reasonable bottom).

For example recently I had to learn MCU development. I bought some STM32 devboard, I learned ARM assembly, I learned how to use ld, as, gdb, st-util, st-flash. I wrote led blink with assembly and I can understand every single line in every file that compiles into final firmware, I can understand every byte in the firmware, I know where to find every ARM instruction. I'm not going to use assembly language other than reading some disassembly dumps, however I find it a necessary part. I'm not going to hardcode GPIO register addresses after those learning projects, I'll use CMSIS, however I need to understand the overall structure of manuals, so I did it with bare assembly and then bare C.

I know that some folks are fine with firing up STM cube IDE, autogenerating some template code and fill in missing parts, not even caring much about registers. That might be my way in the future, however I still think that it's incredibly important to have solid foundations and build knowledge upon this foundation, rather than some weak "magic".

The_Colonel• 3 years ago

These points are certainly not specific to top %, maybe top 20%.

artyom• 3 years ago

Top engineers? Sounds like a bunch of regular good practices that I'd expect by default from a senior engineer.

Maybe the term senior engineer has been overused and now we need a new term for "pretty experienced at the job"?

corethree2• 3 years ago

In my experience the smarter engineers write code that's a bit sloppier. It's the stupider engineers that tend to be more into style.

Smarter engineers see the world through a different lens. They don't need ultra clear code because they are too smart and as a result their coding style reflects that. Things that are obviously easy to read to them actually aren't easy to read in general but they don't know that because they're too smart.

The stupidest engineer often attacks pointless stylistic choices. First off style in general is more important to them because they aren't as smart... But additionally they can't differentiate between pointless stylistic conventions and ones that arent. For example, I've seen this:

   // More comments 
   // Comment
   //This is a comment

Get corrected in a review to this:

   // More comments 
   // Comment
   // This is a comment

Which is fine, but.

Stupider engineers tend to follow certain common human ocd conventions. The corrected code does not practically improve the code at all even from a readability standpoint... it's just jarring to the ocd tendencies of the stupider engineers who cant tell the difference between his own ocd instincts and actual practicality of readable code.

Auto formatters help alleviate these things a bit, but not always.

I admit I'm more on the stupider side in terms of engineering.

corethree2• 3 years ago

Habits of top engineers? Highly disagree.

Style and ultra neatness are not central to achieving higher ranking in software engineering.

ryanar• 3 years ago

This is filled with common sense (follow a style guide) and subjectively wrong advice (clear naming). In Go, it is expected to keep locally used variable names short to improve comprehension and the more global the variable the more explicit it becomes. For example, a for loop using the variable i instead of writing out “index”. Writing out the word arguably makes the code harder to comprehend because there is more noise around unimportant details like the name of the index variable in the loop.

I am surprised this got upvoted.

dave333• 3 years ago

Regex vs loops and splits sounds like a classic case for a divide and conquer pattern. Use simple maybe trivial regexes for everything you can, but split the entire whole into simple bits using loops and splits. But there's no way I'm top 1% - maybe top 20% in my prime on a good day :-)

tamimio3• 3 years ago

You should’ve wrote “software” engineering since those only apply to when you program a software, not to mention calling anyone who type a code an engineer is another debatable topic.

Habits of top engineers

Related Stories