Hacker News Reader

Comment by Jimmy | Hacker News Reader

Meh. If your code works, then it's good.

Of course I don't literally mean that; you can write code in a way that makes it easier to debug, extend, etc. But too many developers get wrapped up in engineering the perfect system and forget that they're supposed to be, you know, writing a program. I think this is why a lot of hobbyist projects run out of steam.

View on HN

It's funny but it's true. There's tons of production code out there making MILLIONS OF DOLLARS for it's company, that 1. compiles with 10,000 warnings, 2. has no unit tests, 3. has global variables and gotos all over the place, and 4. exhibits buffer overruns, undefined behavior, and thread-un-safety. In the commercial SW world, you almost never get time to polish the stone. You race to your deadline, release, and then race on to the next mess.

When I was a young engineer I used to think, "One day, ONE DAY, the company will go down in flames for all this bad software practice, and then I can stand triumphantly among the ashes gloating over how I was SO RIGHT to worry about compiler warnings!"

It never happens.

One of the quotes from a senior engineer that has stuck with me over the years:

> "Working is the lowest bar of quality."

If you replace "bar" with "rung" I think you may evaluate that a bit differently. According to Kent Beck, "Make it work, make it right, make it fast."

Something that's reached for the most proper implementation, the fastest execution, and the most compatibility with something else is still useless if it produces the wrong results quickly and prettily.

Going through this with my side project (a game of sorts, C++ and DirectX) but it's more of the opposite issue. I needed to implement a very simple GUI and didn't want to dig into any libraries, so I created a sort of minimalist mouse event flow with GUI objects. It was designed just well enough that it wouldn't be full of bugs.

But as I've been adding all the features I originally intended I'm finding it's a bit of a slog. Every new feature I add is pretty well compartmentalized but it all still smells a little + sometimes requires some refactoring to fix unintended side effects. I'm only working on it a few hours a week (as opposed to 16+ last month), partially because it's just not fun writing code that I'm not proud of, but also because new code requires more and more caution as the system grows.

Do you ever reconsider your no-libraries stance? There have been times where I didn't use a library but eventually learned that the library exists for good reasons. Some time is wasted, but on the other hand, I have a deeper understanding.

I use libraries all the time. However, all the C++ DirectX GUI libraries seemed way too heavy for what I was trying to do. Part of the fun of hobby projects is creating your own little development style, and digging through old docs on opinionated frameworks to reconcile those choices doesn't make for a very fun hobby project :(

Now that I think of it, the GUI itself was simple enough to do, but the mouse clicks in the 3D scene + various methods of selection were the biggest pain. The GUI just had to show things related to those selections.

I'm going through similar stuff at the moment; fluffing up my opengl application with an actual interface that is forgiving and functional is proving slightly less trivial than I thought - but fun. And oh so nice compared to native Windows.

I like to think of the original code as the first approximation to correct. You can always get closer to correct, but if you ever actually reach it, the universe will hit a breakpoint, and the daemons will halt their processes, grab you, and drag you and your code-that-mankind-was-not-meant-to-know off to coder heaven.

Coder heaven is nice. It has free juice, catered lunches, and foos-pong tables. Individual offices, with plenty of collaboration-friendly huddle rooms. You're only on call 1 eon out of every 4. Unfortunately, the universe is one giant CRUD app.

Probably better off not writing perfect code.

> I think this is why a lot of hobbyist projects run out of steam.

Thank you! I asked that for myself and tried to create (really) good code. Result: Hobby project felt more like work, than actual work did. Now I realized why.

Exactly. Perfect is the enemy of good enough. Granted, you still do have to cross the good enough threshold. I think this is the harder question to answer: Is this code a good balance of correctness and maintainability without being perfect?

At the end of the day, you are either adding value for the company and team or you are not.

Reply on news.ycombinator.com