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