Stop Analyzing and Start Doing!

I’m an engineer and developer and if you’re a regular reader of this blog, you might be too. We are known for our left-brained, logical thinking. We pride ourselves on designing solutions by designing and thinking through and analyzing lots of potential pitfalls. Afterall, we want to build a great solution that not only solves the immediate problem but can stand the test of time!

Why solve just the immediate problem? While we’re at it, why not try to think through every….single…use case? We wouldn’t be good engineers if we only solved the immediate problem and moved on, right? That would be a major hack!

No. Just no.

There are times when it’s critical to spend lots of time up front on tasks thinking through everything that could go wrong. But, we’re not structural engineers or high-rise architects. We’re automation enthusiasts and developers!

Developers work with text; not load-bearing walls that may collapse and injure people. If a bug is found in the code, hit Delete a few times, type a few keys on the keyboard, check it in and voila, problem solved. We didn’t even have to get up from our chair.

If fixing problems in code is so easy then why do a lot of us (me included) spend forever bogged down in overanalyzing. Sure, we need to put some thought into the code we write, but if you’re spending an hour trying to shave off a millisecond from a PowerShell script, you may need to speak to a therapist.

Agile programming and DevOps is all the rage these days and for a good reason. They are determined to teach you to ship; ship now, ship in an hour and keep shipping! Keep delivering value to the business. You’ve got pent-up business value in your head. Check that into source control now instead of thinking it’s not sufficient.

When you waste time overanalyzing and designing solutions for problems that don’t exist or may never even exist you’re over-complicating the solution and creating more code that has to be maintained over time.

As you get more experienced, this problem will not get any easier. Newbies may know how to solve the problem one way. The boss hands them a task, they complete it and are none the wiser. Where a newbie knows of one way to solve a problem and none other, an experienced developer knows ten. The burden of choice is laid upon the experienced dev which makes the problem much harder to solve, but we can do it!

If you want to get better at a career in programming or DevOps, don’t invest a ton of time trying to learn a new way to loop through an array, shave off a few seconds from a script or find a .NET object that’s more “efficient” than a native PowerShell cmdlet. That’s just all syntax and best practices that’ll come to you over time. Instead,

  • Learn how to control those OCD tendencies of yours and focus on delivering value that’s good enough for now.
  • Learn how to make better decisions when you can spend some extra time vs. when a deadline is looming.
  • Learn how to make those tough choices to take on technical debt when it’s necessary.
  • Solve the immediate problem and move on. If possible, build a framework for future additions, if necessary.

Follow these steps, and I guarantee your boss and your organization won’t ever notice that you “hacked” together that function to get the product out the door. I promise.

Leave a Reply