How to write code?
Software development strategies are not one-size-fits-all. As companies evolve from startups seeking product-market fit to established entities, their approach to writing and shipping code must adapt to their changing needs and resources. So, how to write code?
A small startup with (almost) no customers trying to find their place on the market
Speed, speed, speed. In the early stages of a startup, the primary goal is to iterate and experiment rapidly. Speed is essential as the company tests various hypotheses to understand what resonates with the market.
Here's what's important if you're at the company at this stage
- quick iterations, frequent deployments, easy rollbacks
- implementing only essential features to test ideas
- limited testing, often manual, focusing on critical paths
- not solving already solved problems, for example, it's better to use an existing UI library instead of writing your own components that end up costing more and being worse (have you ever tried to implement combo box by yourself and handle all the accessibility features?)
Startups with product market fit
Balancing speed with quality. Once a startup finds its place, the focus should shift slightly. While maintaining a degree of speed, there's a greater emphasis on stability and quality.
Now that company has more resources, here's what's changing
- it's time to do more rigorous code reviews and have some form of QA processes
- introduce some automated tests for core features, preferably e2e
- begin optimizing for scale and performance
- refactoring scrappy code from the company's early stage and managing tech debt
Established company
Emphasizing quality and reliability. Established companies with a stable user base and market presence must prioritize high-quality, reliable software.
Important changes
- start extensive automated testing, including integration and end-to-end tests
- investment in CI/CD pipelines, monitoring, and logging
- introduce strict coding standards, thorough code reviews
- emphasis on security, data integrity, and recovery
Side projects
It is a special category. It's one of the important things you can do as a software engineer to level up your skills. Integrating and using a given technology all by yourself will always give a much more in-depth understanding of how it works than just fixing/improving things at your work. This is the main reason it's ok to overengineer your side projects. Use whatever technology you want or need to learn.
Another aspect of creating side projects is standing out from the crowd. Engineering roles are becoming more and more global, so just being 'good' is not good enough. Creating your own things makes you stand out. You show that you like what you do and that you can create things. Share it with the world. It can change the trajectory of your career.
In summary, it was knowing when to prioritize what makes you a sound engineer. Code is just a tool, not the end goal. Use it wisely.