5 ms·

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

by Jimmy 10y ago

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.

h3ctic 10y ago
> 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.
snarf21 10y ago
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.
vkjv 10y ago
One of the quotes from a senior engineer that has stuck with me over the years: > "Working is the lowest bar of quality."
- cestith 10y ago
  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.
and0 10y ago
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.
- criddell 10y ago
  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.
  - and0 10y ago
    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.
    - laythea 10y ago
      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.
logfromblammo 10y ago
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.
ryandrake 10y ago
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.

by Jimmy 10y ago

h3ctic 10y ago

> 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.

snarf21 10y ago

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.

vkjv 10y ago

One of the quotes from a senior engineer that has stuck with me over the years: > "Working is the lowest bar of quality."

cestith 10y ago
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.

and0 10y ago

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.

criddell 10y ago
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.
- and0 10y ago
  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.
  - laythea 10y ago
    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.

logfromblammo 10y ago

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.

ryandrake 10y ago

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.