It has been my personal experience, over 25 years in the industry, that often times the bigger the company the worse the code.
It's not an absolute rule, I've certainly inherited projects in a consulting capacity that were written by small teams and were atrocious. But more often than not, a small team working for a small company has fewer of the internal "forces" that incur "technical debt."
Those forces are things like
- Silo'd teams working on a common code base in parallel but never talking to each other, thus duplicating code and having wildly different conventions
- Layers of middle management each with different management styles, leading to inconsistency and product-wide short-cuts
- Dealing with sudden success-induced scalability disasters that result in bandaid solutions
- More employee churn which means that the way we did things yesterday is not the way we're doing things today because someone new is in charge ... more inconsistency in code and software decisions
- More "old code." Companies very rarely do rewrites and when they do they're often failures. So the bigger the company, the more "legacy" spaghetti code typically because you don't fix what isn't broken (especially when the entire system is broken because it's one big giant mess that no one understands and yet somehow it actually works ... as long as we don't breathe on it or get a sudden surge of new account sign-ups).
Yep. I work for Big Tech, and our CI was lacking for a very long time. Integration testing isn't prioritized at all. Ironic to write code in an overly pedantic language with type safety, spend 3X that time on unit tests with near-100% coverage and what-if analysis, and still have the thing just not work in the end.
For my own projects, I went TDD with integration tests first, and it paid off in both the short and long term. Soon after activated CI (thanks Heroku Pipelines). Actual functionality was more complex than what my day job project does, and my way of doing things wouldn't have been allowed there, yet it was more stable in the end. Amazing what you can do when nobody is telling you what to do.
I think the impressive thing would've been you being able to achieve that while coordinating with multiple other people. Anybody can write "perfect" code with enough reading/practice. I think being able to fit your code within the context of a codebase is another skillset entirely and presents entirely different challenges regardless of management influence
One time I used that approach was in a small startup. I was working with frontend contractors, so I collaborated with them on FRs, API design, and bug reports, but it was mostly separate coding-wise. TDD and docs mattered a lot due to the 12hr time diff and language barrier. The only other backend dev came at the end, and I handed the whole thing off to him. Aside from that, business people.
I only write code that's just good enough. My goal was to quickly handle the business requirements that were a bit of a moving target and keep prod stable, and I did. If we had more people, a few parts of it would've been handed off as services that work similarly to my piece. And I know they would've been fine because my system was nothing special or pretentious, just your typical NodeJS/Postgres backends plus a few other pieces. The frontend devs understood it well enough to tweak new features occasionally if I was asleep.
Big Tech(tm) team would've been fine with this too. We have roughly the same-size system and resources I did, and similar relations with internal customers, except 5 backend SWEs instead of 1, and except we're forced to do things the hard way. FRs take forever, and the system is flaky.
It's not an absolute rule, I've certainly inherited projects in a consulting capacity that were written by small teams and were atrocious. But more often than not, a small team working for a small company has fewer of the internal "forces" that incur "technical debt."
Those forces are things like
- Silo'd teams working on a common code base in parallel but never talking to each other, thus duplicating code and having wildly different conventions
- Layers of middle management each with different management styles, leading to inconsistency and product-wide short-cuts
- Dealing with sudden success-induced scalability disasters that result in bandaid solutions
- More employee churn which means that the way we did things yesterday is not the way we're doing things today because someone new is in charge ... more inconsistency in code and software decisions
- More "old code." Companies very rarely do rewrites and when they do they're often failures. So the bigger the company, the more "legacy" spaghetti code typically because you don't fix what isn't broken (especially when the entire system is broken because it's one big giant mess that no one understands and yet somehow it actually works ... as long as we don't breathe on it or get a sudden surge of new account sign-ups).