Comment by scriptkiddy | Hacker News Reader

Comment by scriptkiddy | Hacker News Reader

I don't know if I can call myself a senior. (none of the companies I've worked for have used senior/junior in their job titles), but one of the most important pieces of information I've picked up is this:

The Simplest way is usually the right way.

What I mean is that fancy algorithms, sweeping design patterns, and "clever" pieces of code are generally not the best approach to 99% of coding specific problems.

Example: Nested for-loops. Generally a bad choice. When encountering a nested for-loop, one may be tempted to try and refactor it into some sort of recursive and highly-performant function with O(n) complexity, etc. You go through all that work and then realize that the most iterations that for loop will ever see is ~10. You just wasted a ton of time writing code that is more complex, harder to debug, and generally more opaque.

In my experience, I've seen this a lot in the context of premature optimization. I've also been the perpetrator many times as well.

Premature optimization comes in many forms, and at least these three cases are doing more harm than good:

1: "It's good practice"

For example: Wrapping every function implementation in a memoize function may seem like a good idea (= it prevents doing unnecessary work-heavy stuff), but it actually makes code both harder to read (more boilerplate to skip when reading) and most cases slower (= even when a function is executed only once, you're doing extra checks and function call).

2. "We're gonna need this soon"

For example: many times I've implemented an abstraction that makes sense for sharing code with a feature that I know we'll be implementing soon, only to find out priorities have changed and that other feature never gets implemented. What's left is an unnecessary abstraction that only makes the code harder to read and maintain.

3: Optimising for speed/lines of code

Unless you're building a game engine, it rarely makes bang for the buck to optimise for speed until you have identified an actual bottleneck in performance.

Same for one-liners. It may be cool that you know how to write 10-line function as one-liner nested ternary, but your "clever" code is probably less readable and harder to maintain.

Properly choosing an algorithm or data structure is first knowing the nature of your data.

Sidenote: I believe in general a Senior developer is 8-10 years with a general expectation that you will mentor junior developers.

YMMV depending upon region and company.

Reply on news.ycombinator.com