Thoughts on Clean Code, OOP, SOLID & TDD?

The codebase for most high-growth tech companies is very, very far from perfect. On my teams at Meta and Pinterest, there were often entire modules that had no tests. This is especially true for the mobile (Android) teams I was on, where tests were often considered a nice-to-have.

I don't have much opinions about SOLID or other principles. Honestly, it's never really come up unless you're doing a completely blue-sky project (which is rare).

What kind of startup will you join? The answer obviously depends on how long it's been around, how many engineers it has, etc, but my initial reaction to 100% test coverage is that it's too extreme.

As a new engineer, I'd spend the first few months simply following the existing patterns. Don't try to introduce new patterns. There's probably a reason why the company's codebase looks the way it is (the answer may very well be something unsatisfying like, "we've had higher impact work that needed to land"), so make sure you understand that before proposing any changes.

I totally get your point, but it all comes down to the question: if it wasn’t for hyper growth would you invest in a more strategic approach vs. a more tactical approach that companies like Meta are known for across the industry? I’ve heard that the “move fast and break things” motto at Meta led to its code base suffering, with unstable and hard to understand code. I guess you’re the right person to confirm if that’s true or not.

To my view point, a tactical approach creates technical debt that is hard to maintain. Similar companies like Google chose a more strategic approach by placing a high emphasis on high quality code and good design.

Truth is that both companies are equally successful. But if you would ask me as a developer in which company it would be more fun to work, I would choose the latter.

I agree on your thoughts regarding 100% test coverage and I already had my concerns around that. I understand that nothing is ideal in the real world, and you should always make compromises. What I’m still struggling to figure out is what’s the sweet spot of compromising between strategic vs tactical approach.

The startup I’ll join is building an MLOps platform and I’ll be working primarily with Python and Rust. Afaik the engineering team has around 10 engineers working on the product.

Forgot to mention that the company is a Microsoft-backed Series A startup that has been around for 6 years.

Commenting as Google engineer here, and I just want to caution against making general statements about codebases of large companies as a whole. Google has plenty of terrible pieces of code. The product I'm currently working for has plenty of code that's not covered with unit tests, especially those written in the earlier days of the product, when it wasn't even clear the features involved would generate traction/users.

Software isn't written a vacuum; ultimately, the goals of software is to deliver value to customers who are willing to pay for it. As such, the constraints on the software very much also depend on these business factors. Since software isn't a religion, but a tool - we can sharpen the tool as the needs change.

As you onboard, I would advise observing both the software needs and business needs of your team. It may not be wise to give too much recommendations before you understand how exactly you can add value to your new team.

Some questions you can ask to help you determine what kind of technical direction your new team should go towards:

1. How long is the current software expected to live? Do you expect to need to throw out or rewrite the code a few years down the line, either because the business evolves very fast or the tools are evolving very fast?
2. How much difficulty does your team have in moving fast and implementing features that drive value for your business? How much difficulty does the business have in scaling existing features (how bad are the oncalls?) How much of that difficulty is caused by lack of tests (and thus lack of confidence in the code change), lack of proper separation of responsibilities (spaghetti code?), or something else?
3. How many people will reading and editing the code, now, in the near future, and in the long term? If the startup is located in a slow-growing business (6 years and still series A seem slow?), then maybe there isn't a ton of engineer who's going to suffer low productivity due to tech debt. It may also be easier to navigate around tech debt with a smaller team, than with a giant engineering organization thousands of features in-flight.

Having said all that, I would say that it's never bad, for yourself, to write high quality code - I would apply 20/80 rule here. If you can spend 20% extra time to produce 80% better code, do it. Mayb you can get 80%, or even 50% test coverage with minimal effort? It's likely worth it and leading the way yourself probably the best way to change code quality culture in your team if that's something you desire to see.

Thanks for the detailed feedback! I just want to emphasise that my comments regarding coding approach in both companies are coming through books or forums that I’ve read over the internet, that’s why I asked Rahul to confirm this assumption. I should have made this clearer in my initial post :). In any case, that doesn’t change my concerns around strategic vs tactical approach and your response clearly highlights one thing: there should always be compromises depending on the organization needs.

Your comments are extremely valuable nonetheless. I agree with not rushing into making suggestions during my first couple of months in my new team and I should focus on understanding the processes and what are the pain points.

Commenting on the growing aspect of the company, they got a series A funding a year ago, since they moved into a different product direction since the initial one, thus the late funding I guess? Not sure about that tbh.

I'm glad you found my comments valuable! I hope they are able to help you on your journey.

One thing I'll say, is that almost every engineer appreciates good code, good designs, and great unit tests. I've personally read Clean Code and had to learn a lot about how to write good code, both here at Google and elsewhere. If you are curious about Google's own decision making regarding code health, maybe checkout https://www.goodreads.com/en/book/show/48816586.

That being said, you don't want to be the lone-wolf clean code preacher. That's a very common failure mode for engineers and it will only make you and your team bitter. Since software is a group effort - you'll likely have to earn their trust initially, and you'll probably need to introduce some of these concepts slowly. But please do. As a TL, I love it when people are thinking on their own about how to write cleaner code, about how to bring about better code over time. It takes time and good relationships to build this type of culture.

Best of luck!