- Your team mates shouldn’t have to read the PRD to get context about code they are reviewing. Name methods, variables, files in a way that gives more clarity to what it’s doing.
- Focus on reducing request times. This can be done by moving non critical tasks to background jobs.
- Related to this: Show something is being done to the customer ASAP while you do the main work in the background.
- It’s good to challenge product teams requirements in the ideation phase as product folks don’t always think about (or may not be aware of) performance while deciding on upcoming features. Developers should call out things that could lead to poor performance.
- While coding, avoid loops/iterating thru all to do calculations. Related: careful loading all records from DB. Example: to check if atleast 10 records exists, use User.first(10).size instead of User.count
- If you have to update a lot of users manually, try doing it in real time instead of a rake task. Trigger the update when the user completes an action.
- Use a linter/code formatter that everyone in the team follows.
- Write tests for the code you write. Don’t have to test external gems behaviour.
- Measure test coverage. Aim for > 80%
- Use error monitoring alerts. Make it loud. Better to catch and fix errors initially before it starts affecting more users.
- Use environment variables / public configurations. This way you don’t have to commit code to change things which could be changed via env variables.
- Get warnings, performance error notifications while you code.
- Also use external services for improving performance. Then identify slow requests and fix.
- Don’t ignore staging environment warnings.
- Get other people to review your code. It’s more efficient to get/give fed feedback in one go. Review/read other people PRs as you’ll pick up things you didn’t know before. While reviewing it helps thinking how this can go wrong.
- Before writing any code, go through the requirement and break it into smaller tasks. Make a checklist and identify blockers if any. Clear the blockers before you start coding.
- Avoid working on more than 1 task at a time. Less chances of coginitive overload.
- People shouldn’t need to ask you what you’re doing. They should look at the todos, see the checklists and know the status of a feature.
- Before coding, agree on contract between front end and back end developers.
- Before coding, understand what the inputs and outputs will be. Example, if using an external API, test the API response with a curl request and share with product team or test with external services to see if this is what they expected.
- Before coding, ask yourself how this will affect backward compatibility.
- Write tests for backward compatibility.
- Better to not code a feature rather than to code, and then realise it’s not working as expected.
- Over communicate, especially with remote work.
- Give uninterrupted time to developers to code.
- Cultivate a culture of asynchronous communication. Most of the time you don’t need to reply to other people immediately. * Expectation of immediate replies, constant notifications decrease productivity.
- But it’s important to have some time overlap among team members. I'd settle for ~ 2 hours of overlap a day.
- Avoid meetings when possible. Needed if you are stuck with blockers.
- Don’t work more than 8 hours most days. It’s hard to be consistent if you’re putting in 10+ hours or working till 3AM.
- Avoid pushing to production during non work hours as it requires more people to be up.
- Use emojis in slack. It build rapport.
Recent Articles:
Top comments (0)