5 ms·
Habits of top engineers
- dave333 3y agoRegex 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 :-)
- tamimio 3y agoYou 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.
- amelius 3y agoMisses the most important one: making sure your office has a door.
- smitty1e 3y ago> The best engineers I know complete projects fast… by coding slow. Via an Army friend: "Slow is smooth, and smooth is quick."
- revskill 3y agoIf 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.
- Waterluvian 3y agoMy #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 3y agoNo 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.
- ricardbejarano 3y agoI 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 3y agothis 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?
- ricardbejarano 3y agoTo be honest I go by feel. I usually can't spend more than 3 full focus days on something without getting burns.
- rendall 3y agoIf you can, implement code reviews in your integration pipeline. Someone pointing out my lazy shortcuts keeps me honest.
- andenacitelli 3y ago
- oaiey 3y agoWith 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.
- SanderNL 3y 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 3y 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 3y agoKind of besides the point, "be good at X" is a trait; not a habit.
- perihelions 3y agoFor people not familiar with the metaphor, this is the context: https://i.imgur.com/rCr9A.png https://i.imgur.com/rCr9A.png ("How to draw an owl")
- dkarl 3y agoTo 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 3y agoDoes name dropping FAANG in the first sentence still have the same impact it did ten years ago?
- tamimio 3y agoJust write “ex-“ before FAANG in your resume and boom, you are automatically successful and a 100x outperformer fella!
- deleted 3y ago[deleted]
- samjohnation111 3y ago[dead]
- wolframhempel 3y agoA 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 3y agoAnd especially especially for security. Slow down and make sure the feature is secure as possible.
- xyzzy_plugh 3y 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 3y agoAgreed. 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 3y agoDepends 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.
- lr4444lr 3y agoEveryone thinks their own #%$@ doesn't stink. "Aesthetically pleasing" code often looks different to me than other people.
- timrobinson333 3y agoI 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.
- timrobinson333 3y agoI 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 3y agothis 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.
- iraqmtpizza 3y agofixing 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
- mcluck 3y agoAutoformatting 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
- iraqmtpizza 3y agoIf 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?
- mcluck 3y agoI 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
- iraqmtpizza 3y agoYou 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.
- sergiosgc 3y agoThe 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.
- tamimio 3y agoThank 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 3y agoKeep a notebook. Most things you struggle with, you already solved once and forgot. I use org-mode. YMMV.
- jckahn 3y agoI meet this need with comments and code search tools.
- bpicolo 3y agoFor 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 3y agoI’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 3y agoWhy are there 2 entries in the top 5 of HN of this regurgitated blog?
- engineercodex 3y agoSorry you didn’t like it dude. If you have any constructive feedback, that’d be more helpful.
- PUSH_AX 3y 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 3y agoThe 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 3y agoThese points are certainly not specific to top %, maybe top 20%.
- artyom 3y agoTop 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"?
- corethree 3y agoIn 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.
- corethree 3y agoHabits of top engineers? Highly disagree. Style and ultra neatness are not central to achieving higher ranking in software engineering.
- ryanar 3y agoThis 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.