Often I hear developers trying to find an excuse for their bad code. Most of the time it end up as: lack of time, bad management, a colleague who left the company, etc.
What's the reason you heard the most?
I used to train myself to avoid excuses and take responsibility. But I also can’t resist sometimes to blame external factors 😢
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (9)
Same excuse as when I eat badly:
"sometimes you just need to do something dirty."
Corollary: I also try and do this in a safe space (mkdir /tmp/yegods; cd !$; vi erk.c; ...), usually to prove something stupid to myself, then nuke the evidence (shred -uz *; cd ..; rm -rf yegods), before I'm tempted to commit anything.
Coda: sometimes I fail at not committing my crimes and they get shipped (hello single file, ~4000 C/LoC PKCS#11 API to emulate our HSM devices for testing.., also a single file ~3000 C#/LoC WPF->GTK# wrapper, to make a colleagues windows app run on mono - I am ashamed but slightly pleased)
I wouldn’t say it’s an excuse, but the startup way of life makes you code fast under a stressful environment when you don’t want to miss some opportunities. I think you learn to live with that over time and your code gets better even in those moments.
Without thinking about the idea of "good" code.
I generally write things I don't like when under a time crunch or do not have clear direction/understanding on what I'm even trying to do.
I also think it's okay to write bad code if you have to get things done. Sometimes you just need to solve the problem in front of you and that doesn't require "good" code.
The hard part is convincing other developers that right now is not the time to be building the maintainable solution. Sometimes you just gotta ship.
For me it's all my own fault or lack of resources in other departments. For instance if I work on legacy code that is real janky I have two options: add more jank, or rewrite it to follow at least some general good practices. All changes like that require something like 4-8 jira tickets, many hours of approval meetings, and time in the QA department. So most of the time I pick more jank xD. If the code is somewhat self contained I can get away with rewriting it to modern standards. New code I am much more strict with code quality.
And everyone has their own opinions on "good" code but I can say there are a few well accepted things. Code with tests > code without. Separation of concerns > one giant function. Variables that describe purpose > x, b, g.
My excuses are to have to release 3 hotfixes/day in production sometimes ! Usually some sprints after (if task effort allow to do that, obv) we get back to refactor and eventually totally change bad code we previously written.
First I guess we'd have to define bad code.
Is it code that is longer than it should be?
Code that is not as performant?
Not DRY?
My 'bad' code is usually not DRY or not as performant as it could be, but when there's a time constraint for first release, I usually code with this motto in mind:
Make it work, make it fast, make it pretty.
So the first version might not be as good, but it should always work and pass tests.
After, when time permits, I make it faster and last but not least, pretty, so when anyone else has to work on it, they don't want to pry their eyes out! 😄
When certain situations invariably lead to bad code writing, it doesn't pay to just ask the developers their excuses, because that only tries to (mis)treat the symptom rather than addressing the root cause(s).
Most of the time it's just tight deadlines.
Most of the times to add wierd hacks to fix an issue with an external library that does not behave well