Hacker News Reader

Comment by jaydeegee | Hacker News Reader

I had a colleague who was old school and loved optimising, everything he reviewed come back with tiny changes that would save fractions of a ms. His nemesis was a guy who was arguably the best coder I have ever worked with. Things come to a head in one meeting and old school said if we did things his way our code would run quicker and the response was legendary 'If we coded like you it'd run quicker because most of the functionality would be still in the backlog.' I still think about that when it comes to optimisation.

View on HN

The problem with optimisation is that you first need to decide what you’re trying to optimise for. Latency? Throughput? Overhead? Correctness? Time to market? Ease of ramping up new hires?

'Optimising' for simplicity would often be a good idea, though.

Optimising for speed of execution only matters some times.

Optimising for simplicity first is almost always the right thing to do. Even if it turns out to be too slow you then have a reference implementation to confirm correctness against.

In my experience it's rare to correctly identify the bottleneck in code while writing it.

Oh, I had situations in mind where I can quickly write a simple version.

But sometimes when I really torture my brain I can spend a few days of doing mathematical proofs etc to come up with a even simpler solution.

That extra effort is only sometimes necessary. (But can be lots of fun to develop.)

> In my experience it's rare to correctly identify the bottleneck in code while writing it.

Why? It is so easy, just think of the work being done and pick the big parts, those are the bottlenecks.

Only reason I can see anyone fail at that is that they don't know how long things take in their programming language, but that takes very little time to learn, and once learned you will know the bottlenecks before writing.

In so many cases the bottleneck is using bad data structures everywhere, that often gets you 100x runtime and doesn't show up in a profiler because it is spread out all over the codebase, that is the real bottleneck that never gets fixed and is why programs are slow today. To fix that you have to learn to know the bottlenecks as you write the program and not rely on a profiler. Profilers helps you find how long things take, they are really bad at helping you understand how to make the program fast.

Depends on your definition of simplicity.

Some view simplicity more as minimizing lines of code, e.g., less moving parts.

I view simplicity more as increasing lines of code, the goal being to make the code very verbose. Sometimes this means more moving parts, but smaller "movement" at each step.

There are other views of simplicity as well.

The steps in this witty quote helps puts things in perspective as what anyone should do first when in doubt: "Make it work, make it correct, make it fast".

And the 'fast' can be optional.

But sometimes you already have something that works, is correct and fast, but you still want to simplify: for example, when understanding _why_ that code is correct is too annoyingly complicated to explain and understand.

It breaks the flow of the quote, but it really should be 'make it fast enough'

With AMD having 128 core CPUs with a 192 core coming soon... Depending on what you're doing, and how you're doing, there's a LOT of raw horsepower you can throw at a problem. For example, a classic RDBMS (PostgreSQL, MS-SQL, etc) over more complex No/New SQL solutions.

I deeply hate this modern attitude.

It’s factually correct due to hardware and compilers (néé transpilers) offering so much headroom, but part of me cries when you compare modern hardware utilization compared to how optimized-to-the-gills late generation PS2 games were.

I would argue that the fast part isn't optional for web apps (where "transpiling"), but it can be in many other instances.

I write a lot of data-pipeline code in Python that mostly runs once a day. Does it matter if it takes an hour to run instead of five minutes? Not really, as long as it's ready to go for the next run.

Reminds me of a mantra I picked up from somewhere on the internet:

1. Make it work

2. Make it right

3. Make it fast

Once you realize this, you are actually invincible as a SWE.

The greatest trick Matt Godbolt ever pulled was putting gcc -E on a website. Probably produced more value worldwide than the whole rest of his career.

That's just a rude thing to say. If you all coded like him you wouldn't be having the discussion.

The issue is when you have people who do not code with efficiency in mind, and someone who does think about those things reviews the code.

Most efficiency gains are probably marginal and not that impactful. So you're probably OK ignoring it. And it's true that bringing such things up during code review and then going back and changing it will take more time.

But if people wrote the code with efficiency in mind to begin with they likely wouldn't be spending much more (if any) time while writing the code. Just have to use their brains a lil.

This is it. People could write the code with a lean footprint the first time around.

And then you get an in-memory SQL database that is used for cached settings with a text-based SQL query to retrieve every configuration setting (thousands of times during a login) and have a login that takes many seconds to run.

Literal example... replaced with a lock-free hashmap, and reduced the blink of an eye in terms of time.

I don't see the problem here: the original dev delivers quickly, the next dev gets to solve an interesting problems and gets to show off how much time they saved.

They could have used any hashmap or dictionary in the first place... The DB solution was far more complicated.

Delivering the over-complicated feature and improving the performance of the over-complicated feature both seem to get more praise than shipping the simple version to begin with.

Who cares? Do you do your job for head pats or to actually get shit done?

To make a living. Being acknowledged is good to keep at it, or so I heard.

Reply on news.ycombinator.com