7 things every new programmer should know
Source: Phil Johnson,
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.”
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.”
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.”
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.
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.
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.”
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.”
| }
|