Creating the “Right” Solution The “right” solution is rarely the first solution. That’s the post. The right solution is rarely the first solution. Of course, it wouldn’t be much of a post if it was just a single sentence. However, once you know that the first solution you come up with will likely not be “right”, you can can focus on getting things done. It’s common to overthink a solution to a problem.

Feature Road (mapping) This post is not referring to the roadmap you may be used to when speaking within a development team. We’re not discussing planning, or future tasks. No, here we are talking about how complete a feature should be. Another way to say it would be: “what is ‘done’”? In this post, we’ll go through a situation where we are working on a site where users can view the most recent news articles from various news outlets.

Writing and Refactoring Code No matter if you are writing fresh new code, or re-writing some old functionality, you need to decide how much effort to put in. That may seem like a simple decision to make. Put in as much effort as it takes to meet the requirements. However, in most situations, there are multiple solutions to solve the same problem. One solution may be to hard-code some values in place rather than deciding how they should be set, or shared with the rest of the application.

To some surprise, I actually enjoy unit testing the code I write. I didn’t used to, I’ve only recently come into enjoying testing my code. With these three understandings that follow, I actually enjoy writing tests. Understand this is not an absolute. Depending on the situation, the ideas may change slightly, but overall the concepts remain. Those three things are: Test only the edge of importance, Include all your code in reporting, and finally, write code before trying to test it.