My biggest flaw as a programmer, is without a doubt, that when faced with a complicated problem, that usually involves making a lot of ugly hacks. Or when facing a solution that makes no sense, usually because it is a hack for a complicated problem.

I shut down.

It's as if there's some ethical reason (more likely immature reason) as to why I do not want to proceed. I am too focused on being upset over why this is a problem in the first place.

Usually it is related to me not being able to fix the originating problem (usually UX design or some programmers idea of a "clean" solution).

I've sometimes spent hours just staring at the problem and ruminating over why it shouldn't have had to be a problem in the first place.

Does anyone else react like this? I would prefer to just be able to not give a damn and dig in so I can finish whatever I'm doing.

  • 2
    maybe you're not a programmer really

    but it's ok
  • 3
    When I see a poorly written program, I rant and groan or mumble how to revamp it were it mine. In the end I trudge along to finish because fixing one means I get to fix others after. It feels more rewarding to fix the issues that anything else will just be a distraction so I don't dwell thinking about them too much.
  • 4
    The fun thing about being a programmer for me is solving those real disgusting problems that shouldn't have being problems in the first place. Maybe 5 years ago I would brood and rant over it, now I just make a coffee, put on Frank ocean (yes I do code to sad music) and get shit done. It is the only way to grow as a dev. Shutting down does not solve the problem. You wake up tomorrow and u are still faced with the problem u refused to attack.
  • 2
    It's good to think about why things are problems and how you could have solved them if you had implemented it from the start, because that will make you a better programmer. However, sometimes it's not that simple - you might think something makes no sense and shouldn't have been a problem to begin with, but maybe it was a workaround for something else that was outside the implementer's control. These things have a way of cascading like that. So it's good to think about it, but then it's important to move beyond that and think of solutions. Even if they are hacky, you can still make them as robust and clean as possible.
  • 2
    If the code is too ugly to reason about, you have to refactor it iteratively until you can reason about it enough to be able to detect the real problem and cut the solution into manageable pieces.
Add Comment