Month: September 2020

You’re just starting out as a programmer, so you’re looking for some tips on how to get started.

Maybe you’ve landed your first job. Or you’ve just finished school. Perhaps you’ve done what many of us before you (including me) did and simply said “I’m a programmer!” and got to work. Either way, congratulations!

Here are a few tips for beginner programmers that will help get you on your way to a new career.

There’s No Substitute for Getting Your Hands Dirty

You can read hundreds of books. You can watch thousands of hours of YouTube. But nothing makes you a better programmer than, well, programming. Stop preparing and start writing code that solves problems.

This practical experience needs to involve both of those activities, though.

Writing code is important, of course. Your goal is fluency: the ability to write code without having to think about writing code. You want to think in code. This comes from repetition. From putting finger to keyboard and cursor to editor.

But problem-solving is just as important. Code kata and basic exercises do a lot to create fluency, but taking real-world problems and translating them into code is the critical skill you need to develop.

So, here’s the first of my tips for you beginner programmers: Find real problems and write code to solve them. Write a replacement for the ls command. Create a simple video game with your favorite language. Take a task that would benefit from automation and write something to address it.

Be Practical

Once you’ve decided to solve a problem, whether it’s on the job or for your own practice, stick to practical solutions.

What does that mean?

Well, it depends.

Practicality is often in the eye of the beholder. However, it often means implementing the simplest solution with the most efficient tools in a sustainable way.

The simplest solution might not be the easiest or the cheapest. But it’s a solution you can reason about. And it’s one that you can describe in a few sentences. Take time to think about how you’re going to solve a problem. Can you describe it out loud to someone who isn’t working on the project?

Note that I didn’t say you needed to describe it to someone who isn’t a programmer. Just to someone who’s not up to their elbows in the same project.

Sustainability is about how long a solution will last. Can you update it if new requirements emerge? Does it require periodic maintenance? If it does, will the maintenance be simple enough that you actually do it? Will the solution grow with your system? You might think that you’ll never need to come back and change this code after you’re done. You’ll be wrong.

Often, practicality comes down to your tools, though. Are you using the right tool for the job? Is it time to learn a new tool or language? JavaScript is great for the web, but not so much for system administration tasks. Python is a great general-purpose language, but writing Python directly for the browser is fraught with peril.

Sometimes you can’t choose the tool because your boss or team has already chosen one. Well, then, for better or worse, that’s the right tool.

But Don’t Get Caught Up in Other People’s Dogma

X language sucks! Y editor is garbage! Developers that use IDES aren’t really developers! Z operating system is the worst!

The tech world is fraught with dogma. Stay away from it. Dogma is how learning stops.

Unless you’re very lucky, you won’t have many choices when it comes to tools in the early stages of your career. But don’t sweat it. Do the work. Learn the ropes. Solve problems.

Stay away from dogma. It’s OK to have opinions. I have tons of ’em. There are tools I won’t work with. There are jobs I won’t take. I’m also 25 years into my career and looking at retirement. I can afford to be choosy. So are a lot of the people trying to sell you on their dogma.

Stay Curious

The opposite of dogma is curiosity. So, instead of avoiding tools because of what you read online, check them out if they look like they might be useful. Then kick the tires and slam the doors.

Every tool was made to solve a problem. But that doesn’t mean it’s a good tool. Maybe the designer fixed a problem you don’t care about. Or the solution may be flawed. But someone took the time to create it. It may be worth playing around a little.

Don’t limit your curiosity to tools, though. Learn about the problems you’re solving. Look past the list of requirements you’ve been given and learn about your customer’s problems.

I can’t stress this enough: True mastery comes from understanding the problems you are solving with your code.

Don’t Be Afraid to Make Mistakes

You’re curious. You’re experimenting.

And you’re making mistakes.

This is OK. And it’s not only OK—it’s inevitable. Don’t be afraid.

This isn’t a license to be a “cowboy.” Measure twice so you only need to cut once. Pay attention to what you’re doing. Learn how to use unit tests to catch mistakes before they happen. Try to test your theories in low-stakes environments.

But if your boss fires you for an honest mistake, they did you a favor.

Watch Your Personal Time

Programming can be a demanding career. But it’s very rewarding in terms of both personal satisfaction and financial remuneration.

It can also eat your life.

Guard your personal time and make sure you don’t spend too much of it on taking your work home. The personal rewards of coding make it easy to blur the line. They make you want to take home your job writing Python code for a trading firm and apply it to robotics. That’s cool. That’s fun.

But get away from the keyboard and get out and see the world. Your sanity will thank you for it, and your career will benefit from broader horizons.

Relax and Enjoy

One last tip for you beginner programmers: Don’t obsess over tips.

Programming is a great career. They’re paying you to play with computers. Plus, they’re paying you to learn about new fields and solve problems for them. It doesn’t get much better than that!

(But, if you do want more tips for beginner programmers, check out our Lessons From a Veteran series, where we ask veteran developers about their journeys and what advice they have to offer to aspiring programmers.)

This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!).