Habits of top engineers | Hacker News Reader

Habits of top engineers

engineercodex.substack.com

59 pointsmyshpa59 comments

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

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

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

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.

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.

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.

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"

Until you meet the 1% engineer who does have children, and you feel wildly inadequate lol.

In all seriousness though, I agree. Maybe I’m just sad that I’m getting older (39) and don’t have the time or energy to toss away an entire weekend on some new tech, meanwhile watching all the young kids have all the fun. I miss it a bit.

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.

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

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.

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.

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.

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?

To be honest I go by feel. I usually can't spend more than 3 full focus days on something without getting burns.

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

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.

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

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

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

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

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

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

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

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.

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.

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.

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.

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

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

If anything, each chunk of code having its own distinctive structure would make the code easier to visualize. If all the code looks the same then you have no landmarks. Do you not visualize code?

I do visualize it but the logic is the landmarks. It's like living on a grid system such as in Utah or New York but you still know where Times Square is and how Broadway connects everything

You cannot know the logic prior to reading and understanding the code unless you recognize the code immediately on sight. That is my point. If I see a nested ternary expression with beautiful indentation, I know I've scrolled too far when I'm looking for a certain method.

Method names are not logic. You really don't use distinctive method names or formatting to orient yourself and your colleagues? That sounds awful.

I misunderstood what you meant then. Obviously I use descriptive names and different styles of elements inherently have different shapes to them but I don't choose to add extra lines or change spacing just to make something look distinct. As I scroll through I see blocks, names, fors, lambdas, these form the shapes of different bits of code. The baseline formatting of each of these elements is uniform though

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.

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

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.

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

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

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

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

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

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.

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.

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.

> 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

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.

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"?

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.

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

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.

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

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.

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

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.

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

Habits of top engineers? Highly disagree.

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

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

I meet this need with comments and code search tools.

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

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

Sorry you didn’t like it dude.

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

Reply on news.ycombinator.com