In 2019 - 2021, I was a technical screener at Turing.
I evaluated take home projects as part of the interview process.
My biggest takeaway was that everyone could build the take-home e-commerce application. But, not everyone paid attention to the quality and health of the code they submitted.
What differentiates healthy code from bad one? Especially when they both do the same thing?
In today's letter, I'll present you four pillars to think about every time you write a single line of code.
For every function you create, or contribution you make, keep these 4 pillars in mind. Healthy code is:
- Maintainable
- Scalable
- Testable
- Secure
1. Maintainable code
A maintainable codebase is easy to understand, easy to change and easy to extend.
Let's take a practical example of some code I found in a real codebase on Github:
At first glance, you can't even tell what this code does. You also cannot add another list item to it without some challenges.
The code needs better formatting, and also better naming of HTML classes.
Now take a look at the revised version of this code:
Something I do every time I write code is do a self review of my code.
Is this code clean ? Can a random person looking at this code immediately tell what it does ? Would another engineer be comfortable modifying this code in future ?
These questions will help you learn the best practices and write better code over time.
2. Scalable code
Scalable code is code that not only works well when you test on your computer, but will also work well when millions of people are using it.
Let's say you work at Github, and your task is to display the total number of contributions made by a user in a year.
Look at these two approaches and try to determine which one is more scalable ?
Approach 1 uses a loop to go through the list of contributions. Approach 2 returns the length of the list.
If you test these two functions for a user with 5 to 10 contributions, there won't be much difference.
But, if you test for a user with 5,000 to 10,000 contributions, that's where you see how inefficient Approach 1 is.
As an engineer, you want to strive to write Approach 2 style code, where you consider the future use cases.
Spend some time to understand the Big O notation, and how to test your application for performance.
3. Testable code
Writing tests for your code will do two things for you:
Increase your value as a developer, and force you to think about how best to write code that is easy to maintain.
Testable code is well structured, and divided into components that are easy to test.
Testable code has a clear separation of responsibilities between different parts.
It takes a lot of practice to write code like this, but should be the goal of every engineer.
Here's an example of code that is testable:
Notice that the code for logging in a user has 5 steps, and each of these steps is a separate piece of code with a clear responsibility.
Writing testable code takes time, and it gets more natural with the more tests you write.
4. Secure code
When growing as a developer, this is one of the things I struggled the most with.
It's human nature to think about the happy path that our code will take, while forgetting dozens of sad paths.
Let me give you an example.
You're working on a login form. Here's a breakdown of the tasks you need to complete:
Your task is to collect email and password from the user and make sure the credentials are correct.
Most developers think this is where the job ends. Rather, this is where you double down to write code that protects against bad scenarios.
Your code should assume the worst possible use cases from your users. That's what it means to write secure code.
As an engineer that writes secure code, this is how your tasks will look like:
When you get a chance, take some time to study the OWASP Top Ten Security Checklist.
Security is not an afterthought.
In conclusion, It's your responsibility to write scalable, maintainable, testable and secure code. You'll be much more valuable than a software engineer that ignores any of these pillars.