About a year ago, I was given the opportunity of my career. Leadership approached me and asked if I wanted to lead a new cloud-native team.

“Absolutely, I do.”

I spent some time assembling a team of forward-thinking individuals from around the development organization at my company whom I thought would make the team a success. I built up a decent balance of people whose experience ranged from just a few years of experience all the way to 20+.

Historically, we had not been cloud developers. We were a big enterprise software company with deep roots in the Microsoft tech stack. We knew everything was about to flip on its head, but the one change we never considered was to the programming language. Why?

Because we had always done it that way.

Why change if it works? It’s what we know, so we don’t have to spend time learning a new programming language. We’re going to spend all our time learning about things like CI/CD, serverless development, and NoSQL.

Don’t Be Afraid to Disrupt

In his book Sacred Cows Make the Best Burgers, Robert Kriegel talks about how old business processes stifle innovation. Processes that should have been re-assessed a long time ago but were never questioned because they’ve always been done.

My team and I quickly realized the programming language we were all used to was not going to work for our new app. We built some Lambda functions that were devastatingly slow due to cold start times. We considered workarounds to make the cold starts a non-issue, but we felt that would be fighting the tools at our disposal.

So we decided to be disruptors. We joined this team to make a change, and we weren’t going to let old processes and sacred cows get in our way.

The decision to go against the grain was a hard one, but we wanted to ensure our success. Disrupting typically means braving it alone since there are no processes in place. But if you have a solid team like I did, anything is possible.

Use the Right Tool for the Job

You wouldn’t use a hammer to drive a screw into a piece of wood or a hacksaw to route the edge of a 2x4. No, you would use a tool appropriate for the task at hand.

Photo by Eugen Str on Unsplash.

Your programming language is your tool. It is literally what you are building your product with. To make the best application in the shortest amount of time, use the best tool for the job.

Here are generally accepted use cases for some major programming languages:

• Python — Data science, machine learning, back-end web development
• C# — Thick client Windows-based applications, games
• Java— Thick client apps, Android apps, back-end web development
• JavaScript— Rapid web development
• Swift — iOS apps

Obviously, there are many more languages out there to consider, but remember that some languages make it easier to solve a problem than others.

Change if You Need To

Early in your development process, you have a window where you can change the programming language with minimal impact on productivity. You’ve done a proof of concept, found some pitfalls, and it seems the risks are greater than the rewards.

Change it.

Minimal work has been done. Get together as a team and talk about the pros and cons. If the team agrees this programming language is not the right way to go, make the call early and switch. The longer you wait, the harder it will be to refactor.

This happened to my team not once but twice. We made a snap decision to go with Python early in the process. After a couple of weeks, we realized that it was not going to be a maintainable language for us given our use case. So we got together, discussed our options, and moved to a different language.

The worst thing you can do is lock yourself into a programming language that won’t solve your problem. Stay on high alert in the early phases of your project to catch it early and make a positive change.

Think About the Future

Photo by bruce mars on Unsplash.

You won’t be on this product for the rest of your career. There will be a point in time when you either get moved to a new project or you leave the company and pursue something elsewhere.

That means you need to think about your successors. The people who come in to maintain the application after you will spend more time in it than you ever did. So think about what will make their lives easier. Ask yourself the following questions:

• Is this language industry standard?
• Can I hire someone off the street to build on this app with minimal ramp-up time?
• Is there community support?
• Can I find questions and answers on Stack Overflow?

As a leader, your job is to make an impact at your company. As silly as it sounds, choosing the right programming language for a project can decide if you leave a positive or negative one.

Start Building

Photo by Markus Spiske on Unsplash.

The worst thing you can do is ignore options because they seem hard. Pursue a direction because it is the right way — not the easy way. Don’t assume a direction because you’ve always done it that way.

“If you want something new, you have to stop doing something old.” — Peter F. Drucker

Try a new programming language that will solve your problem the best way. If it doesn’t work, take the lessons learned and find another one. Be agile with your decisions. Don’t go off the cuff, but make informed decisions with your team. Give it the old college try.

You will find that the earliest decision you make about the technical side of your app — what it’s written in — will make the biggest impact. Everyone has the capacity to learn something new. Don’t be afraid to go down the unbeaten path.

Build. Learn. Innovate. Get better every day.