Before we even start writing code these are some things we should pay attention to.

Clear Requirement Specification

Start by understanding and documenting the requirements thoroughly. It’s the engineers responsibility to know what you are working on, so make sure the task is properly and clearly defined. It’s typically not the engineer’s job to write requirements though so don’t forget to communicate with your PM or stakeholder.

As we work on our tasks we make discoveries or changes in our approach, and it becomes vital to update those specs and documentation for others to be aware of those changes. Otherwise QA or another engineer will expect or attempt something different.

I can’t state enough how important it is to understand the requirements before starting work. On the other hand sometimes you don’t know if something is possible and you have to start with experimenting and prototyping. Consider the result just that a prototype, so preferably throw that prototype away and start from scratch with your new experience.

Consider The User Experience (UX) Design

We only ship good products when we all care for them. Before we write any code we want to have a clear idea of what the thing we’re building should look like and how it should work.

It’s not just the designer or PMs job to care about the users or experience. If something feels wrong, bring it up; discuss options, talk to a designer, solicit user feedback and iterate on designs to improve the user experience.

Design (Architecture) Before You Build

Make a plan for the architecture and design patterns you might use before you start writing code. Use the patterns outlined in this doc, look for internal architecture documentation at your place of work or research good architecture for your platform. This will help in creating a clear roadmap and will make it easier to estimate the complexity.

Designing requires understanding which requires trial-and-error. Sometimes building a proof-of-concept is the best way to design something. Once you have a PoC, try rethinking it from scratch rather than deploying it straight to production. It’s easy to take shortcuts with PoC’s and shipping it could come back to haunt you in the future.

Consider multiple options and involve stakeholders and other engineers before deciding on the final approach.

If we don’t design before we build, we won’t discover where the pitfalls are. If we know where they are we can flag early on where we think there is higher complexity, what needs to be defined better or what might take longer time to to build.

Localization and Internationalization

Consider the global market by designing the software to support multiple languages and cultural preferences. It’s easy to assume a lot of things when it comes to language and localization, like all english speaking people don’t use yards and miles. In another interesting example from a Podcast about scaling Duolingo they found out many people in India have their phones set to English, and even though they wanted to learn English the app was promoting learning other languages starting from English.

Code Versioning and Version Control

Maybe this falls under basic things but, use version control systems like Git to track changes, manage branches, and enable collaboration.

Follow best practices for branching, merging, and tagging.

Establish a workflow which works for you and your team. I’ve written an article on Git Workflows and Principles, please read it for inspiration.

Code Reviews and Collaboration

Code reviews are vital for catching bugs, following coding standards, and sharing knowledge among team members. Some things to consider for code reviews:

• Establish a process if you do not have one.
• Decide what criteria should be met when something is ready for review.
• Decide what the goals of the review is.
• Avoid large code reviews. Risk of error grows as a review covers more and more code. Instead get the author to split the work up into smaller pieces. This is also a code smell.
• Automated checks first. Use a linter, use automated testing. Run them before doing a code review.
• Focus on the code, not the developer. Use constructive language.
• Be specific, avoid vague language.
• Prioritise high-impact issues.
• Avoid nitpicking, or have an agreed on language for nitpicks. E.g. an emoji: 💅
• Don’t forget the positive feedback!

Refactor Regularly

Periodically review and refactor your codebase to ensure it remains organised and maintainable.

Address areas that may have become cluttered or overly complex.

Do not add more features to code which already has lots of technical debt or clearly needs refactoring. This is an excellent opportunity to start fresh. Make sure to bring this up with your team or manager when planning scope and estimating.

Dive into refactoring at depth in Refactoring Principles.

A/B Testing

Consider experimenting with different versions of your app to measure user engagement and gather data on which features or designs perform better. Plan these ahead of time with PMs or designers as it may impact development process and estimations.