Seven Companies Later, I've Learned My Lesson

15 YOE and I’ve worked at some big name companies. None of them will show their codebase to an interviewee. All of them would view 7-in-5 as a massive series of red flags and would likely toss your resume to the side.

So, some advice from someone who has been doing this a while and had to learn this the hard way: the ego you’ve got going on will stop you from being the kind of developer you think you should be. The most amazing developers can jump into a bad codebase and make a difference. They focus on lifting the people up around them and understand that software is a team effort. They roll up their sleeves and make things better rather than leaving because things aren’t perfect.

There are absolutely bad codebases and shit companies and all kinds of other bad news. I’m not stating that you should stay at a bad job. I am saying that it seems like you’ve got some stuff mixed up. You want to be the kind of person people look up to and who can mentor other people? You have to sit down and do the work at a place where things are downright bummer town before you’re going to learn what you have to learn for that.

If you ever want to be hired at a big-name company, you’re going to have to find a job and stay there a couple of years. Same if you ever want to be considered a senior engineer.

Yeah, I've only worked 8 companies, but only 2 of them had decent code. One was a startup, and one was a small contracting business with a strong focus on code quality. In those cases every or almost every employee was a coder (even the HR guy had a pretty strong tech background).

The other places were all larger companies that had at some point decided they should write their own software. It all made money, but it was all of seriously questionable quality.

It's been somewhat frustrating that the processes (business users, budgeting, QA process) don't allow much developer latitude to fix/improve parts of the software that 'work' if there's no clear business 'ask' for the change (not allowed to make changes to code that isn't directly involved in a change request from business users). They didn't care in the least if it was buggy and difficult to maintain as long as it was making money.

While I prefer to work with good code, I don't mind too much if their code is bad as long as they're paying me well and not pushing back too hard when my estimates for a change a longer than might be expected due to code issues.

Older the company's code, the messier it is. As more and more developers come and go and contribute to the code base, the messier it becomes. Just like a rental property. Do you think the landlord will keep the proprety as clean and maintained as his own residence, just so the tenants can feel better?

I have worked on projects with code bases ranging from 5 to 20 years old. Code so bad that it can give mental health issues trying to read it :)

If you are lucky, the company will allow a complete rewrite for whatver reason, and the cycle starts again.

Tools have gotten better, so it's easier to write cleaner code and prevent devs from straying away from standards.

After switching 7 companies in 5 years, I can tell you one thing with full confidence: Clean code and good architecture? Yeah, that stuff's for the streets.

The irony in this comment is almost too much.

YOU'RE THE PROBLEM.

7 companies in 5 years means you aren't even average. you're below average

I absolutely love the idea that you have any clue what you're talking about when you haven't stuck with a company for more than 12 months.

Complicated things are complicated. Who knew?!

If you get hired on day one in a startup on a greenfield project and have all the aspirations in the world to make things perfect from day one - spoiler alert: your codebase will turn "bad".

Large organizations running large projects require a lot of engineers writing a lot of code. There's just no way to ensure its all perfectly written and architected. Most of the time you have to be pragmatic and compromise sacrificing quality or tech debt for getting something done and out to users asap.

> Now we’re out here paying 10x just to keep the apps breathing under the weight of all that code smell and tech debt.

Yeah, like I said, complicated things are complicated. They are paying top dollar for people that know what they are doing to A) navigate the existing codebase and B) to make it better. Bitching and moaning is only going to get you so far - and from the looks of it that's about 9mos at any given role.

17 interview rounds

The pope was elected after only 2 rounds of voting.

They don’t need to rope in 20+ people across 4+ interviews over 2+ weeks - not to mention the obligatory “coding test” that is only there for middle manglement to feel useful - just to hire anyone’s sorry ass.

There's no time to build super solid code unless you're a decent sized company already or have funding and know the app will be successful.

Like we don't know if this app will ever see the light of day, so might as well get it done fast and save everyone money..

I'm also working on like 5 projects so I gotta get this done lol.

Honestly I have a project with really really solid code but it was made years ago and I wasn't involved and the time it took to learn how to make even simple changes was a bit frustrating lol. Now thst I'm more familiar with it, it can be nice. But sometimes I'm like man you could've had this less abstract and I'd be done hours ago

Also, quick PSA: I’m not joining any company again without a quick tour of the codebase I’ll be working on.

Add more companies on the resume within that year scale and no company will hire you anymore either.

You sound fussy and arrogant.

Good advices and thanks for widening our eyes.

The thingsis that most tech companies started from experimental codes that continue even after growing into giant tech.

Many leaders think that the risk of maintaining messy codes is lower (by paying excellent software engineers) rather than refactoring to clean code which can slowdown or even break their production app.

0% of companies worth working for will show you a line of their codebase before you sign a contract.

Clean code and good architecture is also impossible, because clean code enforce bad architecture. Assuming you mean literal "Clean code" by famous politician and part time programmer uncle Bob, and not just "have any sane code guidelines that are actually enforced."

The best you can realistically do in an interview situation is to ask about what code guidelines and standards are followed, and how they are enforced.

As other replies mentioned your ego is in your way. If you just want to work on most elegant code base, you are not worth hiring. No company that has software that went through a decade and different groups of developers is clean. Software grows, requirements change and also the developers and their opinions change. There is deadlines and sometimes you just go for the working solution, not the beautiful one.

If you think you are a good developer, take on the challenge. Your job is not just working with beautiful, clean code base, but help moving towards this. Instead of just adding to the mess, write tests and refactor. If you don't get the time to do it, document the hard to understand parts and layout a plan on how to make it better.

I would always take on these kind of challenges in the companies I worked for and while I thought 90% of the code base is pure mess, I helped making it more robust and enabled bigger refactorings through integration tests I added. This quickly lead to me being promoted several times and getting more responsibilities.