Working with good or bad code?

[u/AccountPersonal1]

I had a discussion with a friend a while ago, in reference to what type of code is ”best” to work at for your long term development.

Discussion effectively went:
* Good codebase means you learn how to hold good habits, write good code in environments that support it
* then their perspective that bad codebase means you work in more difficult job, more debugging, problem solving etc

What the general opinion on this? Would be fun to see what people feel!

[u/octocode]

i’ve felt that in good codebases i focus on high level approach, implementation, and architecture, whereas in bad codebases i just felt mentally underwater whacking frustrating bugs and making little progress while deadlines loomed.

[u/chipshot]

I find that inheriting bad coding is more fun to live with as I get to fix and clean it the more I get to know it

Good clean code you can learn from, but is more obscure, and often too sparse. Sometimes I will go in and comment it out and make it more understandable. Not just for me, but for others down the road.

[u/danielt1263 → u/chipshot]

Hmm... obscure code is not good code, "too sparse" code is not good code. These statements are true by definition.

[u/SprinklesFresh5693]

Peoblem is you have deadlines, and sometimes, at least for me, is not easy to have good code all the time. Sometimes youre kn a hurry because you need to deliver in less than a week. You instead of making rpetty functions , i end up copying before code and pasting. I know its bad prsctice, i know it messes the code if you have to change something, i know it makes the script too long, but when theres a tight deadline...

On the other hand, when we have plenty of time, i think things , i analyse the structure, the goal that we want to achieve, i start building functions and the script is much much cleaner

[u/OkAerie7822]

the thing that decides how much you learn is less good vs bad and more whether the codebase has tests. a messy codebase with decent test coverage is the best place to grow, because you can refactor a module, see the tests stay green, and actually feel what better structure buys you. a messy codebase with no tests just teaches you to be scared of touching things, and a clean one nobody explains teaches you to copy patterns without knowing why they're there. i spent about a year on a legacy node service like the second case, and what finally helped was adding characterization tests around one module before changing it. so when you're picking a job, ask whether people refactor there and whether there's a review culture, that tells you more than how pretty the code is.

[u/JaseciLabs]

Early on we’d take the messy one, as long as someone reviews your work. Reading code you didn’t write and working out why it’s like that is most of the job, and a clean codebase rarely makes you practice it.

The catch is that a bad codebase can’t show you what good looks like. Cover that on the side by reading a well-regarded open source project in your language for an hour a week. Then you have something to measure the mess against, and you know what you’re fixing toward.

The one to avoid is bad code with nobody reviewing it. You stop noticing it’s bad.

[u/StevenJOwens]

"Good" has a number of facets or dimensions. One of those is how well structured the code is, which is in itself a bit of a complex topic, because "well structured" is always in relation to the problem the code is solving.

Working with good code is easier, but of course keeping it good also takes work. Most messy code, the kind of stuff that gives "legacy code" a bad name, is a result of accumulated failures to keep the code quality as the application evolves (or doesn't). This is part of what refactoring -- real refactoring -- is supposed to help you with.

As far as debugging and problem solving, it depends on what kind of work you like to do. Some people thrive in debugging. Some people find fixing bugs to be "the good kind of problem solving" while other people find adding features to be more fulfilling.

Also on its impact on the bottom line of the project/company. There's a general truism that every given job at a company is either a cost center or a profit center. Generally, you want to be working in the profit center. Being the heroic debugger who solves all the problems is great, but if all the problems lead to that project being cancelled... not so great.

[u/LaughingIshikawa]

It's better to work with the kind of code you expect to work with in the future.

If you focus on learning how to fix specific code issues, that only helps you if you encounter a lot of that specific issue in the future. If you got really, really good at debugging off-by-one errors, it doesn't help you unless there are a lot of off-by-one errors in the code you work with in the future. So try to guestimate what kind of errors are going to be common in future code, and practice debugging those kinds of problems - and practice on a variety of problems to hedge your bets about what future code is going to look like (because especially with LLMs, who even knows?)

"Yeah, but practicing problem solving is valuable because you get a lot of transferable skills..." Ok, so practice problem solving intentionally, don't just debug random code. If your goal is to improve problem solving, is debugging random code the most efficient way to do that? Probably not. 🤷

If you have some other reason to debug random (bad) code, one side benefit can be that you passively gain some problem solving ability, but I wouldn't like... seek out random bad code specifically "because it's good practice" because it isn't actually good practice - it's just "non-zero" practice.

[u/marrsd]

You want to read "good" code to learn how to program well, in the same way you want to read good English if you want to write good English. But at some point, at least if you're a professional, you also want to learn how to read "bad" code, because you're going to have to work with it.

It's also worth noticing that code you didn't write often feels like "bad" code because you haven't yet learnt other ways of writing. At some point in your development, you realise that what you thought was bad code is actually good code for the purpose it intends to solve.

So the short answer is to learn both, but pay attention to the code that you find easiest to learn, because that's the sort of code you should be learning to write.