I consider the ability to work with legacy codebases an essential skill. If you can’t do that, you’ll be changing jobs like other people change underwear.

Any codebase that sees real usage will accumulate cruft, odd behavior and legacy code over time. Dealing with that and assessing what’s worth refactoring and what’s best cut or even just left as it is to reach a business goal is the skill that differentiates a seasoned engineer from a code monkey. That shitty legacy code is often what brings in the money to sustain the company, otherwise it would have been turned off long ago.

Microservices don’t help much in that regard: each micro service can look squeaky clean from a code perspective and the whole system can still behave in shitty, unpredictable ways. (Been there, seen that)

It’s also not about fitting in: taking on a shitty codebase and transforming it into something better is an outstanding skill and requires constant communication with all stakeholders, especially when you want to cut legacy stuff. It’s certainly not something for people that prefer a quiet corner.

Are you saying you don’t change underwear often? ;)

Not every few hours and I’ve seen people quit a job between starting late on the first day and an early lunch break. So literally faster than I usually change my underwear.

These people should have asked to see a sample of what they were going to have to work on.

They didn’t even have a look at the code. Their task would have been to write and maintain end-user documentation and they left before they even had computer and stuff set up. Just never came back from lunch. Said they’d not feel up to the task. I was just a student at that time, so I can’t really say if that was a hiring fuckup or just an odd person. Certainly one of the weirder things to witness in my career.

Most likely explanation is that this person received a better job offer and did not wanted to let your company know.

>and micro services. Work in the cloud. Avoid enterprise.

How is this even related? Worst code I've seen was in financial sector, but the project is so huge that is no chance of upgrading it without complete rewrite, 65% of code when I left it was still in Java5 with no option to upgrade to 7 any time soon, it's just too big, so we can understand why it's shit. Second worst code was in a startup, micro-service oriented code, k8s, dockers, javaEE, angularJS and angularIO + TypeScript. There was literally shit, HTML injection in chat-box, >200 JSON endpoints with something that mimics REST (it was closer to CURD than to REST), SQL injection using JSON objects was possible, deployment of new version of a microservice usually took 4-5hours, only if any of model classes haven't been changed. Now I work on medical software, the only split we have is frontend has own repo, backend has own repo, two monoliths. Best code I've ever seen, perfect organisation, good class and field names, easy navigation. I see completely no relation between code quality and microservices/monoliths, what I see it that sane people write good code.

Sure, enterprise is slower with moving with technologies, but that's because they're bigger and decision on upgrading Tomcat to the latest version might cost thousands monthly if there is a single performance regression. It doesn't mean that code is shit because they still use jQuery instead ReactJS.

>Work in the cloud

How is that supposed to help? Moderns devs already have to know JSON, XML, XSD, 2 IDEs, 10 testing framework, at least 2 frontend frameworks and languages, at least 2 backend frameworks and languages, so here, have this k8s YAML configuration and this docker-compose and Dockerfile so you can... avoid shitty code? Also, have this microservice oriented stack, learn how to do distributed logging, autoscaling, self-healing architecture, deploy chaos monkeys in your cluster.

Thanks. Saved me a response :) I am in an Enterprise and we have deployed cruft code into the cloud :) and were even cloud native or whatever bullshit bingo brings up next in terms :)

Some of the worst code bases I have ever seen are cloud-based SaaS products. Including one that was bought by a large database vendor in the last 12 months for north of $US1B.

Aconex by Oracle?

Not going to name names unfortunately, especially not to an account created for the purposes of posting one specific comment.

People can make their own decisions about this, yes. But an important point I love seeing in a top comment is that almost always it's hard to inherit someone else's code. It almost always looks bad at first. I'm more of a manager than a coder but I've worked a lot of small places and I can tell you, every coder who has worked for me has tried hard to keep code clean, and every coder who's replaced those coders has thought the code was a mess. The only time this didn't happen was when there was really a team of coders working together. Any single coder is almost always going to produce code that looks messy to anyone else. You can say you're not going to work on code like that, but in my experience you're also choosing, in that case, never to work for a small place.

Well, that makes you a colleague who I would not want to have around. Someone who only cherry picks his duties and cannot work beyond greenfield projects.

I agree that work should produce happiness. And I agree there are places where the work is not everyone's fit (e.g. bureaucratic customizations). But being not able to cope with bad code is a no go in my opinion.

With microservices, clean code becomes largely irrelevant compared to other concerns such as logging, monitoring, tracing, API patterns, configurability, scalability, timeouts, retry logic, circuit breakers, etc. If the code sucks, you can just take 2 days and completely rewrite the codebase, whereas if the microservice doesn't adhere to 12factor.net, you're in for unwelcome surprises.

That said, any codebase that has seen a few years of maintenance and further development is going to look complicated, especially if you're too young and inexperienced to recognize that each of the annoying edge cases was put there to fix real production issues. Rewriting sounds like a good fix, but it will take a very long time and in the best case you'll end up with a newer codebase that looks just as complicated to a person just entering the business as the one you were attempting to replace.

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.

Working on legacy codebases better designed than I could have come up with hasn't been much of an improvement for me. There is a certain quality of "habitable" for a codebase that tends to get tossed when people create a tightly abstracted object-oriented design. Peter Norvig and Richard Gabriel in their writings mention organizing software "fractally" from top to bottom, which I haven't really been able to figure out yet, other than it must involve some careful use of repetition. Apparently, it can help create those qualities.