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.
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.
>- 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.
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
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.
[+] [-] wolframhempel|2 years ago|reply
- 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...
[+] [-] xyzzy_plugh|2 years ago|reply
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.
[+] [-] danielvaughn|2 years ago|reply
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.
[+] [-] hardware2win|2 years ago|reply
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
[+] [-] quickthrower2|2 years ago|reply
[+] [-] Waterluvian|2 years ago|reply
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.
[+] [-] ricardbejarano|2 years ago|reply
In bodybuilding, this is called "periodization", I'd say that's a pretty accurate term to describe this.
[+] [-] jddj|2 years ago|reply
The last 10% of polishing is hard, and the 10% after that is even harder.
Working on multiple projects helps me too.
[+] [-] andenacitelli|2 years ago|reply
[+] [-] BerislavLopac|2 years ago|reply
A trick I've learned is, when possible, to start with tests and documentation.
[+] [-] rendall|2 years ago|reply
[+] [-] SanderNL|2 years ago|reply
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|2 years ago|reply
The post isn’t meant to be a tutorial on becoming a top engineer though.
[+] [-] dkarl|2 years ago|reply
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.
[+] [-] perihelions|2 years ago|reply
https://i.imgur.com/rCr9A.png ("How to draw an owl")
[+] [-] sergiosgc|2 years ago|reply
You don't have to code fast if you don't need to write a solution for the problem ten different times.
[+] [-] tamimio|2 years ago|reply
[+] [-] paulhodge|2 years ago|reply
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.
[+] [-] BytesAndGears|2 years ago|reply
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.
[+] [-] heisenbit|2 years ago|reply
[+] [-] lubutu|2 years ago|reply
[+] [-] iraqmtpizza|2 years ago|reply
[+] [-] vbezhenar|2 years ago|reply
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".
[+] [-] tjpnz|2 years ago|reply
[+] [-] tamimio|2 years ago|reply
[+] [-] smitty1e|2 years ago|reply
Via an Army friend: "Slow is smooth, and smooth is quick."
[+] [-] revskill|2 years ago|reply
Miracle doesn't exist overnight. You build a miracle by small steps in small iteration.
That's how you build software the right way.
[+] [-] ryanar|2 years ago|reply
I am surprised this got upvoted.
[+] [-] corethree|2 years ago|reply
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:
Get corrected in a review to this: 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.
[+] [-] PUSH_AX|2 years ago|reply
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
[+] [-] timrobinson333|2 years ago|reply
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.
[+] [-] artyom|2 years ago|reply
Maybe the term senior engineer has been overused and now we need a new term for "pretty experienced at the job"?
[+] [-] oaiey|2 years ago|reply
There is only one way to become a senior role in computer science: be good in communication with humans.
[+] [-] amelius|2 years ago|reply
[+] [-] cebert|2 years ago|reply
[+] [-] lr4444lr|2 years ago|reply
[+] [-] timrobinson333|2 years ago|reply
[+] [-] dave333|2 years ago|reply
[+] [-] tamimio|2 years ago|reply