Hacker News Reader

Comment by ThePhysicist | Hacker News Reader

I think it's normal. Some systems I've built were quite sticky in the sense that they started as prototypes to be scrapped once we figure out the "real" system architecture, and 8 years later they're still in use and integrated into dozens of business processes, so hard to replace.

In general, looking back at old code I wrote it seems my solutions were better when I was more naive / less experienced, as I would often go for the immediately obvious and simple solution (which is the right one in 90 % of cases). Working many years in software development and reading HN seems to have made me more insecure regarding software, as I tend to over-engineer systems and constantly doubt / second-guess my technical decisions. So one thing I'm actively trying to do is to go back to using simpler approaches again, and caring less about perfect code.

View on HN

I've taken the opposite lesson to you, I now keep everything super simple and am quite conservative on adopting new concepts.

It's because I've so often seen the cycle here of "X is brilliant" and then 2 years later "how we switched off X and saved millions of manhours!".

Sounds like you took the same lesson

Only reading the first paragraph is pretty simple though.

So, the same lesson

Definitely my experience as well. My dark horse is trying to optimize for speed when i don't need it, and not doing it when i do.

When i was more naive, i'd just stick with the first solution that worked. Now, i find that i'm always worried that someone is going to try to input a 30000-line csv in my tool and that i must use the slightly faster way because it's the right thing to do.

One of my tools to prevent this has been the non-accepted answers from stackoverflow. I find that they are generally of similar quality to the accepted answer, but that because they are less tailored to the (necessarly) different problem, they fit less and have a lesser chance of being accepted despite being more useful to more people.

> as I tend to over-engineer systems and constantly doubt / second-guess my technical decisions

I find this as well. I also think that there is a sub-conscious fear as you become more senior that you need to justify that with more elaborate/complex solutions. In my experience there are also a lot of people in software who never come out of the other side of that view and constantly equate "complex" with "good". Being in an environment with lots of people like this makes it hard sometimes. Ultimately you need to trust yourself and do what you think best. If it goes wrong, at least you know you did it for the right reasons.

Anyone with young children may be familiar with Peppa Pig, an animated British show. Daddy Pig is an expert when it comes to concrete. A far off land sends for him to inspect their concrete, and he travels by overnight train. In the dining car, his breakfast is catered to better than royalty. When he gets there, he taps a block of concrete with his pen, declares it good, and the king and everyone rejoices.

In many ways, that's what it's actually like when you've punched through and become a true expert in your field. Important problems are solved with an overnight sleep, a cup of coffee, and a few careful taps. By the time you get there you're insane, but at least you're offered both coffee and orange juice if you ask.

I don't know what this means about my personal (in-)ability but I've been developing for years (15+) and I feel like all of the other developers I have to deal with are constantly turning to weird, convoluted solutions to problems. I have also never been able to get past the first step in the google interview process so I have this deep, frustrated insecurity. And people constantly like to point out how simple my stuff is in a tone that suggests that is a bad thing.

My hatred of the complex solutions is so deep that I just suffer through all of the commentary silently.

You probably need to study the Complex, get to know it really well, almost, but not entirely, embrace it, and only then ditch it in favor of Simple.

I mean, it could just be that your simple solutions have been missing something, maybe something crucial, or you lacked the understanding of the mindset of people loving their complex stuff, which presented a communication barrier.

Simple is good, you have nothing to fear (as long as it's not naive/laggy).

I started doing the same thing out of impatience.

Recent example: I have a side project with Typescript on the backend and frontend which also uses an Audio Worklet, so it loads a JS file at runtime to be run in a separate process, isolated from anything else.

I also have a class which I need to use in all three mentioned pieces.

Three years ago I would spend hours trying to figure out how to make this work with the build system so as to not have duplicated code and maybe eventually arrive at a mostly working solution before the e.g. frontend framework maintainers update their build system version which may or may not break something.

This time I just copied the damn file everywhere - the Audio Worklet got the compiled JS output pasted at the start. It's a class, it works and I have maybe one idea what changes I could make there in the future at which point I'm just going to copy everything again.

I think most of us go through that journey.

Can be hard to decouple overengineered messes from Good Software: an idiot admires complexity, et cetera.

Relevant xkcd: https://xkcd.com/2730/

Plot twist: biological evolution works like that too.

Reply on news.ycombinator.com