8 Important Lessons for Programmers That I’ve Learned at 18
After all, age is just a number
Approximately one year ago, I wrote a piece for FreeCodeCamp, called 7 Important Lessons About Programming That I’ve Learned at 17.
I never expected that so many people would be willing to hear what I had learned about programming. Thus far, 31,000 people have viewed the story, with an average reading time of 2.5 minutes — not terrible for a five-minute read.
Since then, I’ve continued programming on my own, but most importantly, I got my first full-time programming job. I’ve learned a lot this past year, and I’m once again going to share some lessons I’ve learned.
I’m still far from being an excellent developer, but I’m a little closer, so here are eight more lessons I’ve learned for programming, from an average 18-year-old developer.
Don’t Fall for the Appeal to Tradition
The logical fallacy “appeal to tradition” is an issue than can frequently appear among software developers. The key phrase to know if you’re falling into this trap is “we’ve always done it this way!”
Especially as a new developer, it can be hard to suggest new ways of doing things. If a more experienced developer is falling into this logical fallacy, it’s important to call them out on it. Or if you are an experienced developer, don’t be afraid to try new things.
Everyone benefits if there is a faster, more efficient to do something than the old way — so always keep an eye out for ways to improve.
Developers like to do things so that they can know it will work and so they can get the task done quickly. This usually means doing things in a way they already know, but it certainly doesn’t mean that’s best.
Developers Need Breaks
More often than not, I have breakthroughs in a problem while doing nothing productive. Whether it’s moments before falling asleep, on a walk, talking to someone, or eating a snack, a lot of developers’ brains are churning in the background to solve the problem at hand.
It’s important to find the right time to buckle down and grind to solve the problem, and the right time to step back, take a breath, and approach it in a little bit. Just as a watched pot never boils, a hunted bug never moves.
That’s not my best quote, but I think you get the sentiment. As a developer, it’s important that you take breaks throughout the day. Without them, you can get stuck: stuck in your code, stuck on a bug, or stuck in the same pattern.
Take some time to make yourself a better developer; take a break.
The Programming Language Matters
The programming language that a developer uses matters more than people think. This isn’t me trying to say that certain languages are better than others. The language is important for a developer because it’s like another workplace relationship.
All day as a developer, you’re going to spend time writing code and reading code and tweaking code and correcting code. If you’re doing this in a language you hate to work in, you’re not going to be as productive, and your developer morale is going to suffer.
While I believe it’s true that you can do essentially the same stuff across Python, Ruby, Go, and PHP, they are vastly different to work in. If you can, try to work in a language that makes you happy, not one that makes you frustrated.
People Are Always There to Help
As a new developer, whether new in experience or new to a company, it can be daunting to start working. It could mean an unfamiliar language to use, a new codebase to learn, and a lot of new tools and services to set up.
This isn’t a recommendation, this is a must: You have to get help from others who have more experience than you.
Do you know what the best part is? Ninety percent of the people you ask will be able to help you. Decent people actually enjoy helping others, and it also makes sense for the business. It’s beneficial for the business that any developer who is struggling to write some code gets help. The faster you can solve your problem, the faster you can move on to the next bug or feature.
While more experienced developers may be working on things more important, they’re still going to take time out of their day, when appropriate, to help you.
The trick is asking. If you never ask, you’re never going to receive any help.
The Best Developers Aren’t Developing
There’s a common but insulting saying that “those who can’t do, teach.” When it comes to software development, I don’t think this could be farther from the truth.
The best developers are helping other developers develop — that’s a good tongue twister. Great developers are often promoted into leadership positions where they will begin to help younger developers write the code.
They may have job titles like team lead or lead developer, and they are disguised as the manager of a team. Will they be able to tell you about that obscure array function you’re looking for? Absolutely not. But will they be able to give you advice about programming and feedback on your code? Absolutely.
Of course, there are exceptions to every rule. I’m not saying every manager or CTO is going to be a good programmer. Just don’t be afraid to turn to them for developer help if they are technical.
Great developers lead other developers; they’re not people who can mystically code for 20 hours in a row on a Tuesday.
Get Good at Git
Git is a language in itself. The amount of time you spend to master a programming language, you’d need to spend to master Git.
Git doesn’t feel especially hard when you’re a developer working on your own. You
git add and
git commit, and then you
git push — that’s about the extent of the complexity.
When having to work with other developers, Git becomes essential. It is what allows developers to work separately but together. Git can be hard to figure out: merging code, different branches, old commits causing problems — there’s a neverending list.
Save yourself a lot of time and learn to use Git well so you can work with other developers more efficiently.
Loops Are Deceptively Dangerous
Loops appear to be these nice, simple pieces of code that are often taught to new developers. And while loops may be simple, they are dangerous territory in which to do your work.
First, there is the case of the infamous infinite loop. Nothing can more easily break a program than an infinite loop. Unfortunately, they happen more than we expect, but thankfully they’re easy to spot and can be handled quickly.
Second, loops can take up a lot of time and resources. A computer can loop through something really quickly, except when you fill the loop up with all kinds of shit for the computer to handle. Having large
if statements, another
API calls, or
database calls are all great ways to slow down your loop tremendously and take up a lot of resources.
Keep your loops simple and easy to understand, and never, ever, underestimate the power of your loops.
Coding Challenges Are Not Evil
Most developers know the dreaded technical interview. The whiteboard set up in the corner of the room. Fresh markers ready to be uncapped and used for the first time. What’s going to happen?
You’re going to have to solve a coding puzzle in front of your potential new employer.
This experience has turned many people off of doing challenges like these. They seem pointless; they rarely have real-world application and don’t reflect the abilities of my development skill.
While that may be true, these exercises will still make you fundamentally a better developer. They’ll expand your brain, and they’ll push you to write nice, concise code. It’s not something you’ll be able to see short-term results out of, but it will help you be a better developer.
Also, as a nice side note, they will prepare you in case you do have to do a classic coding challenge in a technical interview.
Thank you for reading about eight more lessons I’ve learned while continuing my journey programming!