7 things every new programmer should know

Veteran software developers share the lessons they’ve learned over the years about how to successfully navigate the professional coding business.

A man sitting in a chair next to a sign that says Free Advice

If you recently joined the world of professional software developers you make think, thanks to your education and/or training in computer science and programming, that you have it all figured out. Developers who have been around the block a few times, though, want you to know that there are a bunch of things you should know about the business of writing code for a living that you can’t learn from a university course or a coding academy.

To find out what those things are, I spoke with a number of seasoned coding veterans, all with at least a decade (sometimes multiple decades) working as professional software engineers and I asked them what they wish they’d known when they first started to code for a living. Whether you’re a recent graduate starting your first developer job, or an older worker who’s transitioned to programming, use the arrows above to read 7 pieces of advice for newbie programmers from those who’ve been there and been doing that for years.

See also:

Up your coding game with these 7 habits of great programmers

Welcome to the IT workforce! Here’s what we wish we’d known on day 1

Just their type: 11 keyboards beloved by programmers

Quality is line one: 8 characteristics of good software code

A mechanic working under a car
Learn about the underlying systems

A big part of software development, of course, is knowing programming languages. But, as several people shared with me, developers also need to know about what’s going on lower down the stack.

“Lots of languages abstract away from what is happening at the system level, and that abstraction is useful because it allows developers to be more productive much of the time.” said Pete Bull, a support engineer at Acquia. “But when you hit a roadblock, a really nasty bug, and need a deeper understanding of what's happening under the hood, well it's a useful skill to be able to debug a process and look at the system calls and really see how a piece of code is interacting with the rest of the system,” he wrote via email.

Likewise, Robert Douglass, VP of Customer Satisfaction with Platform.sh told me,“When I was just beginning programming, there were a lot of things that I really didn't understand about computers themselves. File systems, networking, and how things are kept in memory are three obvious examples. This meant that I would not necessarily understand the goals of some of the programming constructs I was being presented with.”

A screenshot of someone using the command line
Know command line tools

As a developer, chances are you’ll spend a good deal of time working with a fancy IDE or code editor. However, also knowing how to get things done at the command line could occasionally make your life easier.

“Sometimes you find yourself on a machine where stuff has to be done right now and tools are very limited,” one 20-year veteran programmer, who wished to remain anonymous, told me.  “Know the shell like you know how to breath. Tools like find, comm, diff, vi/vim, sed, awk. How to write little scripts right on the command line to find the file that needs to change right f’ing now because production is broken and Joe who fat fingered a URL in said unknown file is on vacation in Fiji.”

Bull, who started using Microsoft tools, then slowly moved to Linux, agreed, saying, “I would have learned the ins and outs of the command line and all of the useful utilities that are available on a *nix system. I can actually recall code that I wrote years ago, and probably spent days or weeks working on, that probably could have been done better in a grep + awk one-liner.”

A bug zapper
Your debugger is your friend

A good chunk of your time as a coder will involve tracking down bugs. Dave Varon, a bioinformatics developer at Novartis, emphasized the benefit of a debugger and it how can outweigh the initial costs of your time. “Learn to use your debugger!” he told me. “Take that extra day or two to configure it. When you don't see the expected result, just debug it: set breakpoints, step through your code, and esp. 3rd party code. It will save you days of frustration, and even better, you will learn things about coding you can only learn by reading someone else's code.”

A sign saying Sign Under Test/Testing in Progress
Learn to write tests

Some developers feel that unit testing, that is, writing tests to validate that small units of code are doing what they should, is critical. Count Richard Handloff, a database developer with Strategic Power Systems, among those people. “I think the best bit of advice I'd give someone who wants to learn to program is to learn to write good tests and learn to write your tests really early in the process,” he wrote to me in an email.

The word Change
Plan on change and learning new systems

Everyone knows that technology changes quickly these days. That applies not only to our beloved consumer goods, but also to the underlying systems, languages, and tools that programmers use to do their jobs.

Adam Wulf, a mobile developer and founder of Milestone Made, recommends that new coders be prepared for, and stay ahead of, change. “Right now, I'm of the mind that you should plan to learn essentially brand new technology stack every ~ 4 years,” he said. “Good foundational knowledge is always applicable, but the tools and tech you'll use every day will be completely different every 4 years.”

“Projects are never written in just one language using one framework anymore,” said the developer who wished to remain anonymous. “You are never going to work on just one thing in one project, get used to moving from project to project and from language/technology to language/technology,” he wrote.

Three kids playing with a ball on a lawn
Play well with others

Despite the stereotypical notion of programmers working alone with their headphones on, developers still have to work other people. Ben Miller, the CTO of Sinclair Digital Ventures, emphasized the importance of being able to work as part of team to your career success. “Big projects mean lots of moving parts coming together and how they fit together and divide up the problem can create impossible engineering problems if you aren't careful.” he wrote via email. “Before trying to optimize that one algorithm, work with the team and make sure there isn't a re-division of the problem that makes each person's problem simpler. Coding is a team sport!”

Varon reiterated the importance of people skills, saying “If you can't figure it out yourself by re-intuiting the API or debugging, ask for help. Just because you think you've written a masterpiece doesn't mean it isn't crap or can't be better. Just like in college, other people in the room have the same questions, or questions only you can answer. Develop a rapport with colleagues. Often just stating the problem aloud enables a eureka moment.”

My anonymous source also shared a similar thought about the benefits of being a team player. “Stepping up to the plate and doing what is asked of you even though it is grunt work will keep you employed as well,” he said. But, in that situation, he also warned, “But be careful, you may get stuck doing it all the time.”

A necklace with the words Fear and Less
Don’t be afraid to code yourself out of a job

Miller had a particularly interesting piece of advice which, at first blush, may not seem intuitive. “Coding yourself out of a job gets you promoted,” he told me. “Find the simplest way to solve problems and make your code resilient and maintenance free and people will give you more and more to do. They will even ask you to teach others to do what you do,” he explained. “In short, worrying about (or at least coding for) job security puts a damper on your career.”