Ask HN: Codebase at my work is a complete mess, what should I do?

Welcome to the real world. I had the same thoughts when I first joined.

Learn to enjoy the feeling of thriving in a mess. Don't let yourself become fragile by it. Try to slowly turn that frustration into appreciation that you're growing as an engineer. Being an efficient, competent and likable worker even around ambiguity, spaghetti code, pressure and less-than-optimal communication will make you a rich and happy engineer.

The industry is much more than just hard skills. Build trust and improve as you go.

>Should I just go and basically say that this person did a bad job?

You wouldn't be correct in saying that. That person delivered a project that works. In the beginning of a project, that's all that matters.

>I'm so frustrated and depressed by it.

Should you feel like that? It sounds like you're working to make things better.

This Simon Sinek interview about millennials in the workplace might resonate with your situation: https://www.youtube.com/watch?v=hER0Qp6QJNU

I’d probably start by writing unit/integration tests. Once these are in place, you can easily start „fixing” the code. The thing about tests is, especially integration tests, it is relatively easy to explain that you write them to better understand ins and outs, as well as business requirements.

I can appreciate this point of view but I think you are missing out. We learn as programmer's by making mistakes and experience. Familiarizing yourself with a crappy codebase (you didn't write) not only helps you get better at debugging but holds a wealth of experience of what not to do. As you don't write shitty code yourself, how else will you learn to deal with these problems? Everything we do should be to further our own skill set. My first real programming job was working with quants who wrote 1k single procedure Perl scripts, you had to scroll your editor to the right to see all the indentation from conditionals. When I look back it's one of my most valuable learning experiences.

I'm going to embarrass my friend and plug his leanpub book, Scary Large Code Surgery with Pivots, because it was so similar to your story, except he wasn't new in his career.

Step 1 of rewriting a code base that doesn't have any tests: commit to not rewriting anything until you've covered it with tests and understand all the moving parts well enough to be sure you know what you've broken.

Chorn asked me to make sure that nobody pays for this book, so I (...won't provide the link... edit: free link below), it's on Leanpub. The idea of a "pivot" is to invent a mechanism that lets you treat each line of code the same. You need to have a process that you can use to catalog, understand, and test everything objectively and without getting hung up. If you removed any arbitrary line of code, or changed it to call a different method, that should cause a test to fail. The most important part (and it's been a while since I read the book, but...) commit that you are not going to fix anything until you have tested everything.

It will be grueling. The net effect of this hell should be that you will never question, or allow anyone to question, the value of automated testing at build-time ever again. The tests are what allow you to refactor with confidence.

If the management is on board with this strategy, then you have already won half the battle.

They may already know they did a bad thing, but your outlook on a piece of code is different before it has been made successful and people are using it. "What am I gonna need that test for? That shit is a waste of my time, I don't even know if this is gonna work in the first place." That might not even have been wrong at the time. There are plenty of ways that people can convince themselves not to write tests. Some are external pressures. If you build a great piece of code and are late to market, beat there by your competitors, that could be an even more serious problem. If the code is poorly designed, but it is working and people are using it, now you have a different problem.

The main idea of the book is that when your code has become successful and is in use by hundreds of people, the game changes. You can't responsibly make major changes to code you don't understand fully. Take the time, that's the job! And good luck.

Edit: I found the coupon link, coupon price $0.00

https://leanpub.com/scary-large-code-surgery/c/ohai