I’m frustrated with myself. I spent 5 hours this week wrangling with dot files, homebrew, ruby, Jekyll, AWS, and a ton of Googling – just so that I could compile and deploy my blog on my laptop.

Let me say that again. I spent 5 hours trying to compile my blog.

This is a classic example of diving into something tech-first. Sure, I could have used WordPress & MailChimp to schedule this post in advance, but that wasn’t exciting enough for me. I had to roll everything by hand and now I have to maintain it too.

The hacker mindset is a powerful, but double-edged sword.

Getting caught up in the tech can help you learn & discover

The first time I saw Twilio’s API in action, I was hooked. It took 4 lines of code to send a text message to my phone. I immediately incorporated it into all my late night hacks. My apps could text me now and it was mind blowing!

That motivated me to learn more about Python, APIs, JavaScript, Heroku, and git. For every problem I came across, I knew there was tech out there, which I could use to solve it.

It also led me down some very deep rabbit holes, including home automation with Raspberry Pis, router-level ad blockers, my first Roku app, and many other educational, but half-finished projects.

When you’re just exploring, it’s super fun to get lost in tech. But deadlines change everything.

In business, production takes priority over exploration

With my blog, I let technology get in the way of my goal: publishing new posts every other Thursday. It doesn’t matter how much I learn about Jekyll and Ruby if I can’t meet my deadline.

At work, you have to take a very different approach. If your boss asks you to build feature X, look for the simplest way to implement it and meet all the requirements, using the tools you’ve already mastered.

If you think feature X requires or would benefit from new technology Y, do this first:

• First, determine if there’s a way to build X without Y, and how long it will take. This is your path of least resistance.
• Create a timeboxed ticket, to explore the feasibility of tech Y.
• Estimate how long you think it’ll take to implement X with Y. Then double it.
• Consider who’s going to maintain this code. Will another engineer be able to take over this project easily, without help? If you use Postgres everywhere, does it make sense to add NoSQL to your stack?
• Talk to your team about what you’ve learned and make a decision that you can all live with.

In many cases, tech Y is the wrong choice. But this way, you’ll learn about it anyway, without derailing your timelines, and you can apply those lessons in the future.

Bottomline: Tech is cool, but it’s not the end goal. Focus on the problem instead of the tools.

Otherwise, you’ll be left with an overbuilt pile of markdown that nobody will ever see.