If a man has a story to tell, he doesn’t ask himself, “What language should I tell this in?” He uses the language that he has, and works from there. Just as the man starts with an idea for a story, a programmer must start with an idea for a program.

Once the idea is there, all programs—even simple ones—consist of pieces. A piece to talk over the network. A piece to draw to the screen. A piece to do whatever… The internet is littered with great programming languages and great open-source code libraries. The best code is code that has already been written, so scour the internet for languages and libraries that best suit your needs.

For certain domains, the language has already been chosen. When writing Linux device drivers, it has historically been a case of C, assembly, or bust. Until recently, the same could be said for browser clients and JavaScript. Move outside of the special cases, and almost every language is an option. Take server-side web development — Commercially successful systems have been written with C++ (OkCupid), Go, Java, PHP (Facebook), Python (Reddit), Ruby (Basecamp), etc., etc.

Languages are full of trade-offs. A language that helps in the beginning can hinder in the end, and vice-versa. Complex programs, regardless of language, look very similar to each other under-the-hood — As the scope widens, the trade-offs become apparent. Of course, that is not a suggestion to write your next program in brainfuck. It is a suggestion to find something you’re comfortable in, stop sharpening your pencils, and get to work!

A few caveats about choosing languages and libraries:

• Keep it open source. Troubleshooting interactions with black-boxed proprietary code is a miserable waste of time. It is like driving blind. Don’t do it.

• Don’t compromise on great documentation. If I had to choose between a so-so language with great documentation or a great language with so-so documentation, I would choose the former. Good documentation lets you program with confidence. Poor documentation wastes your time.

• Strive for cross-platform support. Every supported platform provides an opportunity for user feedback. User feedback is pure gold! It is quality assurance on someone else’s dime. It can also be a completely different perspective on your program — the kind of insight you and a hundred employees would never see because you’re all in too deep.

  Cross-platform support also has a way of bringing very subtle bugs to the surface. Look at these bugs as an opportunity, and fix them!

Also, do not let language snobs poo-pooh your language choice. If a pokemon character says PHP is an embarrassment, but you like PHP, don’t learn Python. Write something in PHP! Facebook did. If the strikeforce says you’re a luddite for using C, but you like C, don’t learn Rust. Write something in C! That’s what Theo de Raadt does. There are programs out there written in Excel VBA that have been bringing home the bacon for decades. If that can be done with Excel VBA, it can be done with anything.

After the tools have been chosen, it is time to haul ass to the finish line. Finishing is very important — even if the program is a little rough. If you never finish a program, it is a tell-tale sign that you would be happier doing something else with your life.

Stan Lee once said:

“Great ideas are a dime-a-dozen. It’s all in the execution!”

The truth is, even after you “finish,” you are never really finished. There is always room for improvement. Look at what GNU and Linux did to the old proprietary Unixes, what Facebook did to MySpace, or what Google did to Yahoo! In each case, organizations that were leading with years of work and loads of cash were outdone by small teams of programmers persistently pursuing quality.

“Where should I start?”

Write a program. Finish it. Keep improving it. Everything else can be Googled.