Introducing: The Bee Line Driven Development 🐝

Ladies and Gentlemen, I present to you… the BEE! 🐝

So you’re a dinosaur 🦖 who first wrote code in Fotran and have finally smoked your way into the CTO title without being a cofounder.¹ You pretend to memorize Functional Programming operators like your cable TV channels and you think Hadoop is an attraction in Disneyland.

Now, you’re airdropped into an office seat with zero knowledge of why your production database is using NoSQL, why your Gradle build tool is still using a 2017 version, and your strings are hardcoded in the classes they reside! (In case you’re wondering, I ran into this I swear!)

If that’s not bad enough, you also have four hours every three months to write code (because all other time you have is used up playing office politics, fighting fires, and playing more politics).

So basically, you have so little time to write code in a foreign code base with questionable technical decisions and you need to deliver something useful by the end of the quarter. What do you do?

Fear no more as your resident know-it-all is here to the rescue! (Or send you into deeper despair) Introducing: The Bee Line Driven development! 🐝

Bee Line Driven Development — A nomenclature only a mother would love

What is Bee Line Driven Development?

Because you’re strapped with time, you don’t have all the luxury to find out how the code is structured and where the skeletons in the closet are. You need to quickly bee line into the problem and solve it. All other problems can be solved later. Remember, you are under time pressure and have to context switch a lot as a CTO. In order to do that, here are some techniques to bee line your way through.

Logs. Where are the LOGS????

Behold, a log being chased by bees

The first thing you can do is to bee line into the logs. The logs will tell you exactly what happened. If your team doesn’t have enough logging infrastructure, consider having one in your roadmap. Implementing New Relic is one good example. The logs will help you narrow down the scope of the problem. Before you dive in and write code, you need to know the blast radius of the problem. As soon as you find that out, it’s time to spin up your IDE and start smashing keys.

Bee Line to Universal Search

Modern IDEs will have a universal search function built in. In XCode, you can bring up the Universal Search with Command+Shift+O. In Android Studio, that’s Command+Shift+F.²

If your problem has to do with a particular screen, you can quickly bee line into a text unique to that screen. For example, if it’s a screen with In-app Purchase, you can search for the Buy Now button, like this one below.

Behold, the Buy Now Button

The search result will almost always bring you to a strings file or (dear God please no) it hardcoded in the source code. Using Universal Search, you can quickly weed out vast swathes of code and focus only on the matter at hand.

Go to Declaration and Find Usages

You may also find yourself looking at a different file than what you’re interested in. That’s where the Go to Declaration and Find Usages functions are useful. Most software engineers who stayed in the field long enough should know this hence there’s little need to further glorify their value.

First Make it Work, Then bring someone to make it better

You’re strapped with time. You don’t know modern best practices because you haven’t written a single line of code in the platform you’re fixing. You fear the next 27 year old engineer who sees your code is going to embarrass you in public. What do you do?

Tip #1: Mask Up!

Here’s what you should do. First, you make it work, then make it better. You’re here to solve problems, not to stoke your ego. As a CTO, your job is NOT to write code.³ Your job is to manage the chaos and make excellent strategic decisions. (which by the way, includes hiring the guy who will embarrass you, force you into wearing a horse mask, and make your code better)

Put on the Blinkers. Don’t Solve Other Problems!

As a software engineer, you thrive in structured code. Yet as someone who has seen codebases time and again, there are always things you WANT to fix that doesn’t have anything to do with what you need to solve. You will WANT to solve them. Don’t do that! Because the more you try to solve them, the more problems you’ll uncover and you’ll find yourself wanting to fix everything and ending up derailing you from the actual problem you’re trying to solve. Before you know it, your time is up and nothing is solved.

Remember, your time could have been better invested elsewhere. If it ain’t broke, don’t fix it. In fact, if it ain’t broke enough to warrant your immediate attention, don’t fix it!

A rare image of a CTO wanting to solve every problem in the code base

Closing Thoughts

Most materials on software engineering teach you how to write code and write them well. However, reality is much more nuanced than that. Sometimes, you have to cut corners to get the job done. Yes, it is not the most elegant method when seen through foreign lenses. Yet when seen through the context by which the problem is solved, one might see it differently.

Bee lining into the problem is not always recommended. Yet sometimes, it’s necessary. At times when you have to bee line into the problem, I hope these tips would be helpful.

Happy bee lining!

___

¹ Because the engineers who interviewed you never knew Agile came from XP and you dazzled the COO with your knowledge of malloc and binary file formats.

² By the way, if you do not code with keyboard shortcuts, consider doing that. Keyboard shortcuts are a massive timesaver.

³ And if you think your job is to write code, you are likely a twenty something who cofounded a company, in which case please beg your CEO to change your title to a Software Engineer.