Adventures in HttpContext All the stuff after 'Hello, World'

Don’t Sweat Choice in Tech: Be Opinionated

Jan 12 2015

Recently I jumped back into some front-end development. My focus is primarily on backend systems and APIs so I welcomed the opportunity to hack on a UI. I keep tabs on the front-end world and a new project is a good opportunity for a test-drive or to level-up on an existing toolkit. The caveat, however, is the dreaded developaralysis. We have so many choices that discerning the difference, picking the “right one”, and learning it becomes an overwhelming endeavor. Should I try out gulp? What about test-driving react? Or should I go with the usual bootstrap/angular combo I’ve come to know well?

It’s hard to balance the cost of time in the present for the potential–and I emphasize potential–benefit of speed and simplicity later when choosing something new. Time is limited; do I need an exploration of browserify, amd, and umd when all I really need is a simple script tag? Browserify looks cool, but what’s the return on that investment? The flood of options occurs at every level of experience; it’s endearing to overhear a debate amongst new developers on whether to learn rails or node first. It’s definitely not helpful when sites offer laundry lists of languages you should learn. C# and Java, really? I’m surprised assembly wasn’t on the list. Judging the nuances of NoSQL options is just as entertaining.

My programming career, now inching the 15-year mark, has seen its fair share of languages and frameworks. Happily I no longer think about ASP.NET view state or the server-control lifecycle. These were instrumental at one time, and even though they are long gone, those experiences helped shape my current opinions on how I want to develop (or, in this particular case, not to develop) software. I didn’t realize I had a choice back then on how I develop: ASP.NET seemed a given. That horrible windows-on-web paradigm pushed me to an intense focus on MVC, now a staple of many web frameworks. In turn, with the advent of APIs and more complex, task-focused UX, I am keenly interested in stream-based programming emerging in Scala and Node. What I’ve come to realize in the tumultuous world of programming, and with constantly needing to level-up, is that frameworks and languages are only part of the equation. The most important part is me, and you: the developer. Steve Ballmer got it right: it’s about developers. Languages and frameworks help us do things but our opinions on how we want to do them is what moves us forward. When a framework matches your opinions, getting stuff done is simple and intuitive. When you feel like your jumping through hoops it’s time to try something different.

My small foray back into the front-end world was met with the usual whirlwind of information. Not to mention the usual upgrade of tools, so any answers I find on google will be outdated:

I just want to throw together a web site. Grunt vs. Gulp? Wait, there’s this thing called Broccoli? Is there something different than Bootstrap that’s less bootstrappy? Are people still using h5bp?

It seemed even the simple go-to of yo angular was fraught with peril: what are all these questions I have to answer? A massive amount of files were generated. Yes, all important and I know all required for various things, but it’s information overload. Why is unresolved added to the body tag? What happens if I hack the meta-viewport settings? What is build:js doing? Should I put on the blinders and ignore? Maybe I should try the possible simplicity of just using npm. I was in it: developaralysis.

Stop. Relax. Breathe. I already knew the simple answer to navigating the awesome amount of choice: opinion. Forget about existing, pre-conceived notions of software. You need to do something: how would you do it? Chances are someone’s had a similar idea and wrote some software. Don’t even know what you need? Then start with something that’s easy to learn. If it doesn’t work out, you’ll have formed an opinion on what you wanted to happen. This is learning by fire.

Opinions have given birth to some of the most widely used software in the world. Yukihiro Matsumoto created Ruby from his dissatisfaction with other OOP languages. Nginx was spawned by dissatisfaction in threaded web-servers. You may not be ready to write a new language, framework, or web server, but your opinions can still shape what you learn and where you invest your time.

Nobody asked me a decade ago how I wanted to write web software. If they did I doubt I would have come up with anything similar to ASP.NET webforms, if I could even have put together a semi-coherent answer. Yet I was a full-time ASP.NET webforms developer, and that’s how I was writing software. Eventually my teammates and I realized this way of programming was utter crap. We asked ourselves that simple question, which we should have asked a lot earlier: How do we want to do this?

At any level it’s important to develop opinions on how you want to achieve goals. Beginners may seem they have a difficult spot because there’s so little grounding to formulate opinions: any answer may appear “too simple”. But the spectrum is the same for experience developers as well. There’s always “something else” to know and factor in behind the curtain. You’re constantly peeling layers off of the onion.

Don’t sweat the plethora of choice which exist. Nothing is perfect, and stagnation is the worst option. Take a moment and develop an opinion on how you want to solve a particular problem. Poke holes in your solution. See if somebody else has a similar idea, or a similar experience. Try something out: don’t like how it happened or the result? Did you leverage the tool correctly? Okay, great, now you have the basis for something better. Develop your suite of go-to tooling. You can keep tabs on the eco-system, and cross-pollinate ideas across similar veins. Choice is a good thing: like a breadth-first search, letting you still run forward if you want.