Some advice tidbits for rookie programmers

There's a lot of good advice floating around for programmers just starting out. Here's some from me.


I've seen lots of videos and articles giving advice to those starting out in the software development world, and with over thirty years of software development and systems programming experience, I thought I'd throw a few out myself.

I'm coming from the perspective of someone who's been programming since the late 1980s, therefore I don't quite have the perspective of kids entering the field today, but I've worked with enough newbies over the past few years to know what's useful.

Here are a few tidbits, in no particular order.

ABRC - Always Be Reading Code, or ABC - Always Be Coding

This is one I think I preach most to the kids.

If you're not spending the majority of your time reading code, or coding and working on a project, you aren't going to progress.  With GitHub and other places that house public repositories, you have an ocean of code to read.

In my day, if I was standing in line, or sitting in a waiting room, I couldn't pull out my phone and read code while I wait.  You do, so take advantage of that and the tech available to you today.

While you're reading code, take time to read through the issues queues of various projects.  In these queues, contributors post code to bug fixes and issues, with collaboration and discussion with other developers.

Here's an example for an issue in Drupal Commerce's queue (an e-Commerce framework we use); you can see the code snippets and discussion of the approach to the problem.

There are real professionals and experienced developers in these issues queues, so make sure you take advantage of these brains available to you and learn from them.

Write "security-first" code

Learning to write secure code is extremely important.  Writing sloppy code creates opportunities for those looking to capitalize, and is an irresponsible behavior to practice on your client's dime.

Do not skimp on security.  Write code as if you're under a state of siege.

Write clean, simple code

Your code should be very easy to read.  It keeps code more secure, and will benefit you months down the road when the application breaks at 3am and you're dead tired while searching for the bug.

This is where practice and reading code will serve you well.  You can't write clean code if you don't read and write code.

Early in your career, you'll be embarrassed by code you wrote months and certainly years in the past.  Good.  This means you're learning and becoming a better coder.

I see experienced programmers advise to not leave projects unfinished.  I disagree.

This may seem like odd advice, but personal projects you've started are your laboratory.  You get repetitions, and you're able to experiment with tools, various techniques, and implementations you may or may not use on a client project.

Personal projects are your playground, where you practice, and the more you learn at your own pace, the more advantageous it will be to you during your career when you're paid to produce.

My advice here does not apply to paid projects, or projects you care about, but working on personal projects, even if you leave them unfinished or untouched for long periods of time, will make you better.

One big advantage is on a personal project, you'll spend a lot of time figuring out a complex solution.  With that code laying around, when you're working on an active project and have a need for that solution, you can simply pull up that code, which is a big time saver.

Of course, I'm not saying don't finish projects, but learning, practicing, and experimenting is more important than finishing.

Avoid Stack Overflow

If you're looking for answers, I'd suggest avoiding Stack Overflow.  They used to be good, but have really gone downhill over the years.

Look for Slack channels, dedicated forums, issues queues, and other such sources of knowledge like Code Grepper.

Learn the ins and outs of C

I consider C a foundational language.  Whatever programming languages you learn, keep a C base.  The more you understand and think like a compiler, the better you'll be.

Regarding programming languages, don't get caught up in what's "better".  A programming language is a tool, nothing more.  Learn to pick the best tool for the job.

Learn Git

Every developer today needs to know Git and how it works.  Any company hiring developers will require this skill.  If you're the best programmer around, it won't matter if you don't know Git.

Build a project portfolio on GitHub

This is a common piece of advice, and important because anyone hiring will want to see your work.

Another valuable use for GitHub is to look for bugs in code, or code that should be refactored, and submit patches.  These will be visible on your GitHub profile and will show hiring managers that you not only know how to use GitHub, but know how to make other's code better.

Reverse-engineer an executable

Find an executable and learn how to deconstruct it and figure out what it does.  This will display a strong technical competency and will give you a lot of confidence.  It will also look great on your GitHub portfolio.

The first time I did this, a lot clicked for me and I understood software in a new light.

Learn database and network programming

Any project you'll work on will make network connections and need to store and retrieve data.  The database schema will be your application's skeleton, and the network is how it communicates.

It's critical to understand these technologies inside and out so always be learning about the concepts involved.

Work on data visualization projects

The ability to convert data into pretty visuals is a valuable skill to have and will pop on your GitHub resume.  Learn visualization libraries like D3.  This shows off some skills that will also impress non-technical people.


There's plenty more, but this should be enough to consider.  The main points, however, are always be reading code, practicing and writing code on your own personal projects, and make writing clean and secure code a religion.