As a solo founder, there were a lot of times when I felt very conflicted about an important decision I needed to make. As an engineer, I often find myself vacillating on some tradeoff between various approaches to a problem. As a programmer, I (all too) frequently find myself stuck trying to figure out some weird bug.
In each of these cases, my natural inclination is to stick with it, and struggle through the problem until I’ve got it all worked out. Sometimes, this can even go on for hours late into the night. However, I’ve become convinced that’s really the wrong approach.
After much painful experience, I’ve taught myself to step away from my desk and go for a 20 minute walk when I find myself in that situation. While walking, I don’t particularly try to solve the problem (though I don’t deliberately avoid it either). Whenever possible, I ask my wife to go along with me.
That 20 minutes away, and especially the mild exercise and change of scenery, resets my brain. When I come back to the problem, I’ve forgotten all of the little details of exactly where I was with it, and I have to start over again. While this seems extremely counter-productive, it’s actually extremely helpful. The process of having to pick up the pieces again resets any erroneous assumptions I’d made about what I thought I understood about the problem, and it forces me to check my premisses about exactly what I think I know. Nine times out of ten, this is exactly what I need to get back on track.
I’ve recently started using JSDOM for testing my client-side code. While I’ve been very impressed with how simple it is to set up, and how fast it is, there has been one major obstacle which I didn’t see documented anywhere else: it doesn’t actually lay out the HTML elements.
width, or other such attributes to the elements. They are perpetually all zero.
Despite this, you can do a lot of rigorous testing, and in a way which is completely identical to how your might set up server-side tests. In fact, I use exactly the same project & test set-up for testing both my regular Node.js modules as I do for the client-side ones. All you need is a little bit of pre-test set-up code to construct the JSDOM window and load a test page, and you’re ready to go.
However, if you want to write tests which verify the layout of things, you’ll need to use another solution.
You’re likely here because you know me, and I shared this site with you. Chances are, if you’re not one of my friends or family, we work together, and I mentioned that I occasionally like to write about things which occupy my mind. Mostly, that’s to do with my work, but occasionally will stray to my hobbies as well.
One of the main things which fascinates me is the relationship between epistemology (how the mind works), and how to write better code. I firmly believe that poor coding style, consistently applied, is better than a free-for-all. However, I also—even more firmly—think we can do a lot better than that. Deliberately matching up how the human mind works with how we write code can yield objective answers to what are generally thought of as subjective preferences in coding style. You can expect many posts exploring that subject here.
I’m also fascinated by trying to improve the processes in our daily lives. This can be anything from brushing your teeth to managing a team. Of course, just the word “process” has a stigma against it as guaranteed to make simple things complicated. I couldn’t disagree more. Process is merely the way something gets done, and a good process is one which minimizes the effort required. This has lead to a strong passion for Getting Things Done (GTD), and I’m sure that will come up often as well.
Finally, there are a bunch of other things which occupy my time and my thoughts: being a good husband & father, listening to and playing jazz & classical music, woodworking, and playing Minecraft. You may well see posts on all of those subjects as well.
So, if any of that appeals to you, bookmark, subscribe, follow, or otherwise just keep an eye on this space.