Software development can be a bottomless well of languages, build environments, platforms, coding standards, and cat analysis algorithms. For someone who likes to study and learn new techniques, this is great. A bottomless well of stuff to better at. However, after almost ten years of doing just that, I’m willing to make a bold statement: curiosity can be maddening and knowledge can be hindrance.

Curiosity is maddening because the more I learn about assembler, linux, garbage collection, compiler theory, engineering techniques, software principles, functional programming, networking, etc. The more I’m convinced that I know almost nothing about computers.

Every time I turn over a figurative “small pebble” in the software world I end up discovering that there’s entire industries dedicated to what’s under that pebble. Even a statement as innocuous as “I’d love to know how my CPU actually sends input requests to this USB hard drive” - can yield a very long (but interesting) explanation.

Complexity isn’t unique to software development. However, combined with curiosity, software is one of the few fields where there is practically no inertia to ping-ponging. If I like the look of writing client side 3D games in C++, I can be doing it in under 20 minutes for free. 30 minutes later I can be writing a plugin for firefox that makes it purr whenever I visit a website with “cat” in the URL.

You’d think that healthy curiosity is a good thing: over time, it grows knowledge. However, knowledge can become a hindrance if you leverage it a little too much. A simple “Hello World!” application can scream out with potential pitfalls - do we have standard IO? What about cross-platform? What about internationalization? Is there a more flexible design for delivering “Hello” and “World” to the console? What character encoding is being used?

This, I think, is why there’s a significant amount of very young, inexperienced, software developers making interesting—sometimes very valuable—products in the field. They don’t know that their servers will implode once they have a few thousand concurrent connections. They don’t know that it’s going to be very painful to refactor that UI they hacked together with four bleeding-edge UI frameworks. They don’t know that there’s a big competitor in the market with a lot of money. They shoot first and ask questions later, which makes them one of the few demographs doing the shooting.

We’re all aware of this phenomenon. What I’m saying isn’t news. However, here I am, writing heavily designed, SOLID certified, high unit-test coverage software that few people use. Meanwhile, there’s teenagers out there hacking together VR experiences in which I get to fly around space as Thomas the tank engine.

What’s missing? Isn’t the reason we get curious, study, and train so that we can make even cooler stuff? Yes. However, as presented, curiosity is maddening and knowledge can be a hindrance. The trick, I’m slowly convincing myself, is to have a cool and interesting problem or project to apply that curiosity and knowledge to and not get hung up on the details. Otherwise, you may end up spending hours analyzing the random noise of a bingo game.

So, with that in mind, over the next year, I’m going to be making a conscious effort to just “make stuff” and care alot less about how philosophically pure its software engineering is or what amazing 0.5 % speed bonus I’ll get if I change to some slightly newer framework half way though.

Now, all I need to do is write a design document, get people to approve on it, do a technology review, select a programming language, ah yes, mutability is evil! It’s the reason I haven’t created a decent app yet, I should look into Haskell! Ok, now possible test harnesses, oh I wonder what’s the difference between this test harness and this other very similar test harness, that could really have a big impact on my project and I don’t want to make an error before I even start…