My TL;DR style notes from articles I read today.
- Don’t rush to write code. Think about the problem first and think out loud.
- Ask as many questions as you have about the problem before starting to solve it.
- Don’t strive to impress with the right answer, talk about all approaches you can take and talk about the tradeoffs with each.
- Plan your solution with a pseudocode.
- Talk out loud about what you are doing while implementing the solution.
- Write comprehensive test cases.
Pro-tip by the author in case you are stuck: Some of the best problem solving happens when you can align the strength of a specific data structure to a problem’s bottleneck.
Full post here, 8 mins read
- Go for regional deployment, validate the change and then go for global deployment.
- Choose deployment windows during off-peak times for each geographical location.
- Any deploys triggered automatically should not be executed during off-work hours or weekends.
- Use testing & canary analysis to validate code before it is pushed to production.
- Deploy to production exactly what you tested.
- Know how to roll back any deploys quickly.
- Use preconditions to verify the expected state.
Full post here, 9 mins read
A few learnings from the post:
- Use incremental snapshots of data for backup after one initial full snapshot to reduce both storage and recovery times.
- Save on storage costs by deleting all but the last two copies for recovery purposes.
- To ensure data integrity, verify these last two backup iterations daily.
- Compress, encrypt and transfer the backup to offsite storage to build further security.
- Using snapshots this way is a more expensive process than more traditional backup technologies. But it reduces time and processing power for both the user and the service.
Full post here, 6 mins read
I share these TL;DR versions of articles on software engineering that I read every weekday through my newsletter - in.snippets(). Sign up here if you liked what you just read.