How To Sleep Well As A Developer

Getting a good night's sleep is important for a developer. It is easier to sleep well when you aren't worried. Here are some tips for software projects that might help.

• Think as much as possible up-front. It isn't realistic to expect to know everything about a problem before you actually try to solve it, but it is worth it to spend as much time as possible thinking before typing. Bad ideas are easier to discard than bad code. Brainstorm. Get peer review. Use structured tools to describe your problem, requirements and suggested solution.Try to find blogs and open source codebases you can borrow from. Ask dumb questions on Stackoverflow. Write as much down as possible.
• Think about your tools. Why are you using a certain database? A certain language? Often these are fixed due to some institutional bias. Otherwise, prefer tools that are appropriate but also mature. Pioneers often just get arrows in their backs.
• Think about your schemas. Schemas are worth calling out all on their own. Your systems will live or die based on your database schemas, and they can be hard to change (if not impossible). Bad schemas will defeat tuning anywhere else in your stack. In every way you were taught to care about algorithms and data structures, you should now apply to database schemas.
• Design your environments. At a bare minimum you will typically have development, testing and production environments. You may also want dedicated chaos and load testing environments. Use tools that allow you to easily retarget your code to new environments with the appropriate changes. Docker is good for this.
• Insist on simplicity. Avoid needless layers. Avoid protocols and abstractions that your coworkers describe as "nice to haves" and "future proofing". If you need it later, add it later. Avoid concurrency if you can; you are writing a program, not an operating system.
• Prototype. In no other engineering endeavor do craftspeople presume to build the proper thing the first time. Prototyping can help reveal surprises. This is a great use for a dynamic language.
• Measure everything. In your development and test environments, you should be measuring basically everything that isn't a constant expression. Use an analysis tool like DataDog or NewRelic to help you get a grip on the data.
• Log as much as you can. When things fail, you will be glad you were as verbose as possible in your logging.
• Attack your own code. Unit tests, chaos tests, security pentesting, performance profiling, distributed tracing. None of these are perfect, but do them anyway.
• Separate concerns. ORMs might be evil but developers writing arbitrary SQL is often worse. Try to strike a balance. A good data access layer can also help you to effectively introduce caching. Caching is useful because caches are dumb and will force you to introduce simplicity in to your data model.
• Treat documentation as a deliverable. Many projects fail or are abandoned because they become opaque. In any other industry, documentation is an accepted part of the deliverable. Maintain it like code.
• Monitor for failure and firedrill recovery. Everything fails. Be able to detect failures and recover from them. Rehearse recovery scenarios. Take sensible measures to ease recovery.
• Above all: communicate. If you can't, your team is in serious trouble.

last update 2017-12-28