Plannedscape Postings

  • Blog Home
  • /
  • Programming Languages - Part 2: Choosing A Language

Programming Languages - Part 2: Choosing A Language
Advice Depending On Your Situation

Posted by Charlie Recksieck on 2019-11-21
In Part 1 last week we figured that top tier, household-name programming languages have a life span of 25 years whereas more marginal ones it’s more like 5-6 years of real relevance.

We also should probably operate with the assumption that over time, technologies tend to accelerate, so these programming language lifespans might be getting a little smaller.

For purposes of this article, now that we know that major languages don’t exactly disappear overnight then let’s examine how the choice of programming languages affect programmers, companies and individual projects.

Who Is Affected

When I said just above about looking at programmers and companies, we should probably think in terms of more specific categories. When talking about developers, deciding what languages are best for them might matter differently if they are a computer science student, a software employee or a freelancer.

And when we talk about companies then are we talking startups, companies that outsource development or ones who hire full time developers?

Factors In Project’s Language Decision Making

* Availability of qualified people
* Current employee skillsets
* Compatibility with what company/companies are already using
* End of life concerns
* Availability of buy-vs-build code (or free code)

Language Decisions For Aspiring/Student Developers

If you really want to dabble and learn a language just to tell yourself you did it, then my advice gets really easy: Google "learn Python" or "learn Ruby" and you’ll have a working program by the time you go to sleep tonight. Otherwise, keep reading.

Choosing a language can be a huge career decision. Although I posted a fun schematic decision tree at the bottom of this section, do your research.

Upon doing some simple Googling on this subject, you’re going to see the best advice there is: Become an expert at one language, then because familiar/proficient with several others. Personally, I think that is great advice. According to our premise that major programming languages will be relevant for 25 years or slightly less, that’s a pretty good run. In theory, you can work half of your entire professional career in just one language.

If you can identify an area you’d like to work in, then that really helps. If you think you want a lifer career building non-web, internal, non-customer facing applications, then learn the tougher more lower-level languages like C or C# (which, once you’ve learned, make it much easier to learn somewhat related languages like Python and PHP). If you know you want to be a front-end developer, or you’re coming at it from being a graphic designer who knows HTML and CSS, then make sure you know JavaScript and PHP.

All that being said, the last time I had to hire a new, junior programmer on our team you might be interested in my main criterion: I really didn’t care about which languages he knew. I only cared that he was self-taught. To me, I knew we were going to throw a lot of new things at him, so I rate the most important young coder’s asset it the ability to learn. That’s just my approach and my two cents.

Make sure you use the great resource (as mentioned in Part 1 of this post) is the TIOBE programming community index (it charts the most popular languages, as defined by web searches) and especially scrolling down and tracking languages’ rankings over time to gauge trends.

Let me also leave you with this terrific flowchart from the folks at (click for large version):

Language Decisions For Employed Programmers

This is where you’ve already got some chops, have been working a while, but want to make sure you’re employable. First, let me reiterate that you should be expert in at least ONE language. So, if you have been working with VB .NET and you don’t think you could call yourself an expert or pass a prospective employer’s skills test, then you should double down on your language ASAP until you’re an expert.

Then the rest of this is common sense. Have a goal of what industry and job situation (software development company, in-house for a major company, startup) you want. Then look up job listings that match those and see what they require. It isn’t rocket science.

If you want the simpler answer though, more and more I think you need to know Java and Python.

Language Decisions For Freelancers

The skillsets needed for freelancers is pretty similar to what we need to know here at Plannedscape, although we have a few people and good partners to subcontract to or use for referrals so there’s that.

Solo freelancers don’t get a lot of multi-million-dollar projects. As a result, you’ll probably need to be nimbler and need to be everything to that company, and maybe even also be a web developer. When you hear "full stack" you’ll probably need to be solid with your CSS, an appropriate backend language like Python, PHP, JavaScript, be a good SQL or MySQL database administrator, and more and more these days know a major cloud system like Amazon Web Services or Azure.

That might sound like a lot. Nobody said being a freelancer would be easy. Or the option is to go the other way, be incredibly expert at something. Market yourself as a go-to person for just CSS. Or just AWS. Or Go. You see what I’m getting at.

As a young man I used to work as a landscaper, and that job required knowing everything. The only guys in the business I saw thrive were the ones who only trimmed palm trees or only did lawn aeration. If you can get to be an expert in some aspect of software, I really think that’s the way to go. But if your prior career has left you as a "jack of all trades, master of none" then market yourself as a one-stop full-service developer (but keep learning those languages).

Company - Hiring Factors For Full-Time Programmers

These next three sections are short ones for those of you working in companies and are looking for developers to hire or help.

You can probably figure this out yourself, but if you have a lot of legacy Perl or FORTRAN code, that is getting to be dinosaur era stuff, so you better find yourself a specialist. And if you have current projects in C++ then obviously get somebody who’s solid in C++.

Outside of that, we’ve said that these programming languages last a long time. But don’t put too much stock in that or start thinking that "we only need C++". It is an incredible rarity that a hired programmer is going to sit in an office doing nothing but developing C++ code for 20 or even 3 years straight. That’s the exception. The norm is that they are going to be actively working also on front-end, on databases, or both. You want somebody versatile. Or as I said earlier in advice for aspiring programmers, I put the most stock in self-taught programmers. If you hire one, you’re more confident that they can adapt to a new technology.

Another reason why you want some breadth in your hiring decision is that you want to avoid the guy who just knows Python (or PHP, or whatever language). They tend to go down the "when you’re a hammer, everything’s a nail" road. Every time there’s a new project, this developer always recommends Python no matter how wrong it might be.

Company - Hiring Factors For Companies Hiring Contractors

Here at Plannedscape, we do like to think of ourselves as a nimble little company that can handle any kind of software project. Acknowledging that, in the next two paragraphs I’m taking off my Plannedscape business development hat and thinking solely about what’s right for companies.

There really are just two ways to go: 1) Use a contractor for most projects, no matter what they are, and 2) Figure out what technology is best for each project (or divide up into mobile apps, web apps, customer apps, internal apps, interfaces, installing new systems like an SAP upgrade, etc) and then hire specialists in that field for that.

Where have you had a previous software project go wrong: Because your software contractor didn’t know how to work in a particular language or because they didn’t work well or professionally with you? I’d be surprised if it was the former. The working relationship between a company and contractor is not always a natural fit. If you have a contractor you like, to paraphrase Seinfeld, "Hold onto them like grim death."

Company - Hiring Factors For Startups

Startups are a beautiful situation. They are the greenest of "greenfield projects". You have a blank slate to choose whatever platforms, technology, architecture and languages you want.

The nature of your startup or your core idea is a big one. Is your startup definitely a product that needs to be operating on a smartphone? Then your first tech person needs to know Java and/or Python and/or PHP (or a couple others); he/she probably needs to know enough about each to even make the right decision which of those to go with. If your startup is a making a service/app for banks, then maybe lower level like C# or even tying into legacy like COBOL. The point is that you need a great fit among your product, your industry, end user environment and your initial "CTO".

Chances are that in a startup, the "tech guy" or nominal CTO is probably the first, second or third person working on a startup. This might likely be a good friend of yours who’s also excited about the idea, not a contract-to-hire guy. So, your tech friend is the key to all of this. His/her initial efforts are setting the template for everything technical and likely is doing all your development for at least the first year. Hopefully their skillset matches what’s best, or they’re up for putting in the extra time to learn the right language and stack for this whole project - which sometimes is a great appeal for that first tech guy at startup besides just having dreams of selling a business for millions and the impulse to work with your trusted friends ... there’s some appeal in this venture as a skills-learning project, too.

This first CTO will be using a language they’re comfortable with (or working to get comfortable with). Don’t worry (too much) about breadth of skills or programming language until it’s time to hire that 2nd programmer.


What did I leave out or perhaps get wrong? Do you have any other opinions, corrections, predictions? Or do you have specific questions about your situation? We’d love to hear them!


- Fantastic article in how to pick a language from freeCodeCamp and was where I found the flowchart graphic above