If you’re a new software developer and you’re beginning your first software job, you’re probably wondering how you can be the most immediately effective. New developers struggle with feeling unproductive and perhaps even burdensome. However, there are 3 (GREAT!) habits of new software developers that you can begin as soon as possible to lay a positive foundation for the coming weeks and months of your new career.
As soon as you’re able, participate in code reviews, contribute to the code base, and ask questions.
Participate in Code Reviews
Any reasonably mature software organization requires code reviews as part of its continuous integration and continuous deployment strategies. Additionally, code reviews are often a compliance requirement. Getting familiar with your team’s code review process is critical to discovering success as a new software developer.
You may feel you’re unqualified to review pull requests from senior developers or that you have no idea what you’re doing and, therefore, your comments are invalid.
These feelings are untrue.
Competent software developers welcome questions, comments, and opinions. It’s in everyone’s best interest to foster early cooperation among all members, including (and especially!) the new folks.
Code reviews come in all flavors, from sweeping questions about architectural decisions, discussions on best practices, suggestions for improvement or refactors, and spelling corrections or other simple changes.
Regardless of the code review tool of choice, hop in and start reviewing code! Find a spelling mistake. Ask why they left some code commented out. Look up an unusual function you’ve never seen before and try to determine why your coworker chose that particular method over another. Ask a general question about the reason for PR. These simple suggestions will get you familiar with the code and cooperating with your team!
3 Habits of New Software Developers: Contribute to the Code Base
Aside from reviewing code with your peers, you should (as soon as you’re able) begin contributing changes to the code base and making code review requests of your own. Some teams want new developers to dive in head-first, while others take a slower approach to introduce new developers to the code, so make sure you’re lining up with team expectations.
Many software shops will have simple tasks specifically designed to get new employees familiar with their code pipeline. One of my jobs, for instance, had me add my name to an ‘authors.txt’ file, commit it for review, and kick-off build automation. Not a challenging task, but it illustrated the basic software lifecycle within the team.
Regardless of how your team assigns work, try to find something straightforward. Or pair up with one of your peers. If you pair up, however, I strongly suggest you take the wheel and make the changes yourself, asking your coworker questions as needed. It may take longer to accomplish the task, but so what? The experience gained is worth it.
Getting your hands into the code is more than making a logic change. You’re learning how to clone the code repository locally, how to work with whatever environment the application executes, how to test and deploy changes, etc. The more you work in the code, the more you’ll repeat the development lifecycle and, therefore, the more competent you’ll become with the product.
3 Habits of New Software Developers: Ask Questions
It seems obvious, but I’ve sat with plenty of wide-eyed new developers confused by something yet unwilling to ask questions.
Ask questions. Ask a lot of questions. The more you ask, the better off you’ll be. As the adage goes, there are no stupid questions. It doesn’t hurt anything, and asking a simple question can make all the difference in the world.
Don’t limit yourself to the development team, either. There are plenty of other people who would love to discuss their areas of expertise. Ask the product owner why the customer wants certain features or how a change fits into the larger strategy of the deliverables. Ask your senior developers about certain architectural decisions and what they’ve learned about those decisions over time. Rarely in this field is the first decision ever the perfect decision, and you’ll discover that many architectural decisions have proven inadequate over time. It isn’t always a sign of incompetent developers; it’s often a sign of growth!
Conclusion
In my experience, new developers are often afraid of making mistakes. There’s no reason to be. If you performed your due diligence, asked the right questions during your interview, and you’re confident that you’re onboarding with an exceptional development crew, you should be in good hands. Great teams build on the shoulders of everyone.
Don’t be afraid to cooperate with your peers. The success of your team is dependent on everyone, including you. It’s in your best interest to ramp up quickly so that you can be the best You that you can be in this new career!
Ask questions of as many people as you’re able. Ask about the products, the infrastructure, the code, and the support. Submit code reviews. Small changes matter: Your voice is every bit as important as everyone else’s. Make changes to the code as soon as you can; it’s the best way to familiarize yourself with the larger environment and product as a whole!
You can do it!
If you haven’t, be sure to check out a Day in the Life of a Software Developer if you’re interested in learning more about the day-to-day tasks of a developer!