How do I learn how to write clean, reusable, and scalable code?
I have been working for small companies for the past 5 years where the focus was on shipping the product fast and not necessarily on quality. I am now interviewing at big tech companies where the focus is on code quality and code scalability. I am concerned that even if I make it through the interview phase it will be hard for me to maintain my position after having bad coding practices for many years.
How can I get started in learning how to write clean, reusable and scalable code? I work primarily with JavaScript and Java. Can you point me to some resources to learn how to improve my code and apply best practices that will make me a great engineer? I am familiar with concepts like DRY, SOLID principles but I am looking for something actionable not some abstract concept.
![Senior Software Engineer [E5] at Meta company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fmeta.jpeg%3Falt%3Dmedia%26token%3Da7a5bcc0-e178-4b5b-b71e-09bf6c6aefae&w=48&q=75){kind=small}
![Entry-Level Software Engineer [L3] at Google company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fgoogle.jpeg%3Falt%3Dmedia%26token%3D780356ef-3efc-4728-9eb4-d909b75bb4a6&w=48&q=75){kind=small}
Discussion
(2 comments)- 18a year agoTech Lead @ Robinhood, Meta, Course Hero
Why not just write better code at your current job?
A big misconception I understandably see a lot of engineers have is that in order to ship fast, you need to completely sacrifice quality. This isn't the case. There is generally an 80/20 rule when it comes to code quality where you can get 80% of the maximum quality for 20% of the total possible effort. This includes low-hanging fruit like:
- Making sure that all your pull requests are reasonably-sized, focused, and atomic
- Having basic modularization
- Enforcing standard formatting against your team
- Proactively discussing failure modes and edge cases ahead of time
These are all things that can be easily woven into your work, and it will bear time savings almost immediately. For example, if #1 isn't the standard across your team, each pull request will take days to review because it's gigantic. On the other hand, if people follow #1 and spend the extra 15-30 minutes making their pull request clean, they will save days on each review as it's easier to digest.
I was at Course Hero as their 1st Android engineer when it was just 20 engineers total. I moved extremely fast, yet I had a stellar reputation for high product and code quality.
Now I'm doing Taro which is even smaller and has to move even faster as a company. I still take the time to make sure that the code and experience are clean. Of course, I don't spend 3 weeks teasing out edge cases like I did at Instagram pushing code to 750 million+ users, but I still get 80% of the way there by covering the basic ones.
When it comes to resources, we have a ton! Check them out here (tons of examples included):
- 10a year agoTech Lead/Manager at Meta, Pinterest, Kosei
The best way to improve is from feedback, and since you're a professional SWE already, you have that. You'll get even more of that when you go from small company to big company.
Obviously, you'll learn from the code review feedback you get. But beyond that, spend 30 minutes each week looking at the code changes that sparked the most discussion (most comments/questions) on your team.
- Write down why the code change prompted so much discussion.
- Write down what you might have done differently to reduce confusion.
If you do this for 3 months when you join the new team, I guarantee you'll learn a ton about writing clean, reusable, and scalable code :)
