9 Relatable Rites of Passage All New Developers Go Through
You made your first real blunder at work. You got yourself in a tangle trying to rebase. You’re banging your head against a wall with legacy code. These don’t sound like success stories, but we’re here to tell you that these rites of passage (even if they’re painful) are a natural part of the journey. That’s not to say you have to “pay your dues” or suffer to belong in the developer club. Whether you’re in your first entry-level tech position or trying your first-ever coding course, we hope that these common pitfalls make you feel validated and a little less alone. Remember that with every frustration you experience, you’re adding to your expertise. Here are some of our favorite new dev rites of passage.
Your first “off-by-one” error
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Jeff Atwood
Software Developer and Author
You probably encountered this classic programming problem when you were first learning to code. To the uninitiated, an “off-by-one error” (aka OBOE) happens when a loop, array, or some other iterative process incorrectly accesses elements or performs operations with an index that is either one less or one more than it should be. If you’ve ever started a list with 1 instead of 0 by mistake, you’ll know what we mean. There’s something uniquely frustrating but ultimately satisfying about realizing that your issue is down to this common pitfall. It feels momentous and yet it’s easy to fix. Win!
Solving a programming problem away from your desk
Programming is at its core problem solving, which is a creative endeavor. So it’s no surprise that some of your best work happens when your brain is processing the problem in the background. There’s nothing quite like the feeling of taking a break, walking away from your screen, only to have the solution present itself to you as if by magic (except it was your brain — how cool is that?).
“But it works on my machine”
The build succeeds when you’re working on something locally, but when you try to push it to GitHub, you get an error message that appears to have nothing to do with any of your changes. What gives? Annoying as this discrepancy is, it’s a developer cliché for a reason, and getting one example under your belt is part of the journey. You’ll quickly understand why it’s important to test your code, and have a good opportunity to practice your debugging skills.
Forgetting that user-facing logs are public
Leaving an embarrassing (or unprofessional) message in user-facing logs is a rite of passage for many developers, according to Tyler Williams, Lead Software Engineer at WalterPicks, although he has “somehow avoided this fate.” These types of faux pas are often committed when your brain is fried because you’ve been working up against a tight deadline. Consider this example a cautionary tale and try to avoid it yourself (see the next point).
Your first all-nighter
If you find yourself debugging ‘til all hours to meet a deadline, you’re in good company with many developers who’ve gone before you. (Fun fact: We recently found that 7% of our learners are the most active between 12am and 6am.) It’s one thing to be handed a tight timeline, but another entirely when you were the one who estimated how long it would take. Mike Terhar, a Customer Architect at Honeycomb.io, has been there a few times in his tech career as a System Administrator and Application Security Architect.
Mike has sage advice for avoiding this time management pitfall: “If someone is trusting you to determine how long software takes to write, add the caveat that you aren’t sure how long debugging and deployment will take. These things can be orders of magnitude longer than the actual programming task,” Mike says. “Like cooking, applying heat isn’t the entire duration. There’s prep and mixing, sure, but there’s also shopping and plating and cleaning.” Building in more time for yourself to test and debug will help ensure your all-nighter is a rite of passage rather than routine.
Inheriting a legacy codebase
Unless you make a career out of only working for startups and building from scratch, you’re going to encounter legacy code: existing software that has been developed over time and may be outdated or poorly documented. When you’re brand new on a tech team or at an organization, inheriting legacy code can feel insurmountable, Mike says.
“When I was working at a financial institution mid-career, learning about each generation of systems was as much information as for a masters degree,” Mike says. “The 1990s stuff was still running under the 2000s and 2010s stuff. All future efforts were being added on top of 2010s stuff, and nothing was ever decommissioned.”
If this “opaque nightmare” is your fate right now, congratulations on this milestone (and also, don’t panic). There are some tools you can use to navigate a legacy codebase and gain context on the decisions that went into it: “Observability and OpenTelemetry are finally making it better, but it’s really hard. Some SCM systems can give clues as to what happened, especially if they tie back to an issue tracker. Git blame and old issues can paint a picture,” says Mike.
“But even then, a lot of times the ‘roads not taken’ aspect was discussed ad nauseam in meetings and the only record is of the chosen path,” says Mike. “You can’t be expected to know that stuff.” So don’t be too hard on yourself. Over time, working with code that was written by someone else becomes easier.
Your first big mistake
Maybe you broke production or deleted something important. Gulp. Making a major slip-up at work is never fun, but these incidents are significant learning experiences (and can make great stories later). Most seasoned developers have some horror story about an oversight or poor choice that landed them in hot water. Your mistakes don’t have to define you, but how you respond to them can — check out our post about how to recover from a mistake at work for our best advice on how to turn the situation into a personal growth moment.
Your first rebase
Git. Love it or hate it, it’s the version control system of choice for a lot of tech companies, so you’re bound to get tied up in merge conflicts at some point (even senior developers do) or need to fix a mistake in an earlier commit. (Did you know we have a free beginner-friendly course on Git and GitHub?) Interactive rebase is a really handy Git tool for tidying up your local Git history, but it can be confusing. While trying things yourself is an important part of learning something new, this is a case where we recommend sending up a flare if you get stuck. Which brings us to the next rite of passage.
Learning to ask for help
There are no prizes for doing things the hard way. Knowing when to ask for help and having the confidence to admit “I don’t know how to do this” is a milestone in itself. So if you’ve been going round in circles on a programming problem, stop and get help. This could be a great time to try pair programming to help you get unstuck.
There are many more examples of rites of passage for new developers. The next time you run into a prickly challenge, remember that these moments of frustration are making you a more experienced and seasoned programmer.