15 Tips on How to Improve as a Junior Developer

This article will go through tips on how to become a better programmer and is written by Natasha Postolovski, a Graduate Software Developer at ThoughtWorks. You can follow her on Twitter: @npostolovski.

As a Junior Developer, I often seek feedback from more experienced developers around me to learn how I can improve my code and be better at my job. At ThoughtWorks, I’m lucky to be surrounded by people who care about sharing what they know, and helping others to be better. Six months into my career as a Software Developer I feel like I’ve learned a lot about how to avoid some of the most common mistakes Junior developers make, and I wanted to share these tips with you today.

Whether you’re working your first Software Development job, learning to code and building your first app, or hoping to break into the industry for the first time, I hope you’ll find this useful

Official docs over Stack Overflow

When you first start learning to code, Stack Overflow is your best friend. It allows you to make progress when you’re uncertain, or when you run into bugs that you don’t know how to fix. But I’ve noticed that more senior developers are much less likely to seek out answers on Stack Overflow, and instead prefer to turn to the official docs for the language or tool they’re using. They understand the benefits of having a real understanding of the tool or language they’re trying to work with, not just seeking out a quick fix in order to solve the problem at hand. Whenever I end up on Stack Overflow, most of the time it’s because I don’t have a deep enough understanding of the technology I’m working with. It can be helpful in a pinch, but shouldn’t be used to cover up a shallow understanding of your chosen tool or language.

Nii Ashikwei Tetteh is a software developer at ThoughtWorks, and has also been a trainer at its five-week boot camp for graduate (Junior) developers, called ThoughtWorks University. He has worked with dozens of Junior developers, and says: “While it’s good to reach out to the larger community and use example code or find solutions that work, it’s much more important to understand why and how they work, and what you could have done to get there on your own.” He says that while reading documentation can be a little boring, it’s crucial to gain a real understanding of the language or framework you’re dealing with.

Zoom out

Junior developers tend to have a much smaller zone of focus when working within a system. It’s as if we look at the code through a microscope, while more senior developers look at it through a wide-angle lens. More experienced developers will take time to think through the potential side effects of what they’re working on, as well as how it fits into the overall system. They’ll ask questions like: is this consistent with how things have been done elsewhere in the codebase? Is the code reused elsewhere in the system? Will this code be easy to maintain in the future? As you work, remember to zoom out and think about how your code fits within the context of the system as a whole.

Do your own quality assurance (QA)

Most teams will have some combination of automated and/or manual testing to ensure that new features meet requirements, are of high quality, and don’t break any existing functionality. You may even be lucky enough to have a dedicated tester on your team, someone who can make sure that what you’ve built is fit for purpose and think through a variety of scenarios to test. In Agile environments, it’s an anti-pattern when work is pushed back (i.e. from the ‘In Development’ stage, to the ‘Review’ (QA) stage, back to the ‘In Development’ stage again). This usually occurs when the developer did not understand or did not meet the acceptance criteria – the laundry list of things the work must do in order to be considered ‘done’.

By doing rigorous testing if your own work before it gets to this review step, you’ll get better at producing quality work, thinking through test scenarios and edge cases, save time for the rest of your team, and keep work moving forward rather than backwards. If you’re working alone, this additional QA step is even more important. If you don’t discover bugs and errors before they make it into production, nobody else will!

Don’t ignore the world around your work

It’s easy to feel like nothing is more important than the next feature or problem to be solved. Meetings, research and time spent gathering broader context for your work can feel like painful interludes between getting your hands dirty in the code. However, you’ll soon come to realise that understanding the whys of what you’re doing are more important than the hows. If you’re missing context or an understanding of the business, industry or organization that you’re working within, you may end up building things that people don’t need, or won’t use. A significant chunk of Junior developer mistakes are due to us misunderstanding or making assumptions about the domain we’re working in. Take the time to understand how things work in the real world before trying to translate them into code.

Tests are your safety net, and your compass

Writing tests is extremely important for Junior developers, especially when you’re working on a team, or contributing to a larger system being maintained by multiple developers. Tests are an excellent way to drive out your implementation, but more importantly for Junior developers, they’re a fantastic safety net to guard you as your work. Good tests will let you know as soon as you’ve broken something. Try to run your test suite at intervals as you work to make sure nothing you’ve done has had unintended side effects. Tests will give you the confidence to make the changes and improvements that the codebase needs.

If you’re working on your own and not yet writing tests, it’s worth taking the time to learn to write unit tests in your language of choice.

Separate your concerns

Whether you’re working with object-oriented or functional languages, a good separation of concerns is the mark of a skilled developer. Experienced developers have an instinct for identifying separate concerns and the boundaries between them. But what does ‘concern’ mean, in this context?

• Areas of responsibility in the code
• Areas of focus in the code
• Or a particular ‘job’ the code is doing

Junior developers often struggle to identify and separate different concerns. A good rule is to create one file for each area of responsibility in the code.

A useful trick for identifying separate areas of responsibilities is the ‘AND Test’: if when you are describe a file or class in your code you need to use the word ‘AND’, you’ve probably identified responsibilities that could (and probably should) be separated.

Here’s an example:

The Conference class is responsible for scheduling AND displaying conference timetables. (Fails the AND test).

Instead, what about:

The ConferenceScheduler class is responsible for scheduling conferences.

The SchedulePresenter is responsible for presenting schedules.

When you divide your code like this you may end up with files that are quite concise – less than 50 lines, even. This is OK! An application composed of small classes that work well together is likely to be much easier to work with than a monolithic application composed of several large classes that each do many different things.

Write short methods

If there’s one code smell I see often among Junior developers, it’s long methods/functions. A common pattern is a method, named after its end result, which does absolutely everything needed to achieve that end result, often over many lines of code, and working at a very low level (manipulating strings, looping over data). This can make your methods hard to work with and understand – in fact, there are few things more intimidating than trying to understand a long, complex method that triggers a Rube Goldberg Machine-like chain of events in order to achieve some end result.

One way to approach this is to allow your implementation to start as one long method, then break it out into private methods that perform a step, and document what is being done.

Here’s an example in Ruby. We want to be able to call a method that makes us a delicious pizza with our chosen toppings, something like:

def make_pizza_with(toppings)
  preheat_oven
  divide_and_roll_dough
  add_toppings(toppings)
  bake_pizza
  slice_and_serve
end

The ‘make_pizza_with’ method calls a number of other methods that each perform a step in the process. They each have their own set of sub-steps that go into completing them, for example:

def preheat_oven(temperature, time)
  walk_to_oven
  turn_on_oven
  turn_dial_to(temperature)
  set_timer_for(time)

You could easily implement the ‘make_pizza_with’ method at this low level of detail, eliminating the separate steps and instead including all the various details needed to make a pizza, like walking to the oven, taking toppings out of the fridge, or getting a pizza tray out of the cupboard. And yet, a recipe written like this would be quite annoying. As a reader, we’re interested in the high-level steps in a process, not all the nitty gritty details. Your code will be more readable and easier to maintain if you treat your methods in the same way.

But when do you extract parts of a large method into smaller methods? Often, you’ll find that when you have an urge to write a comment to explain what part of your code does, you should extract it into a separate method instead.

Seek constructive criticism

Praise is fantastic, and it’s something that we seek out to fuel us and keep us going. While praise is important, constructive criticism is also essential to help you improve as a developer. You’re a Junior developer because you still have a lot to learn, and constructive criticism can help you identify those areas where you can improve your approach, and your code. If you work with other developers who are reviewing your pull requests, you’re probably getting regular feedback on your code on a line by line basis, but may be missing feedback on your overall approach to solving problems, or other skills like how you work with others on your team. If you work on a team with a different development workflow, like pairing, you’re likely to get much more immediate feedback.

The easiest way to get constructive criticism is to ask for it. Ask someone who’s worked with or seen your code to coffee and say you’d love to get some feedback from them. Give them some notice so they can think of concrete things to say. Do them the favour if giving them some feedback in return. If you ask for constructive feedback, people will most likely think of something to say, even if it’s not that big of a deal. Remember that the issue likely isn’t as bad as it seems in the moment, and that if this person is taking time out of their day to give you feedback, it means that they care about your progress. Andy Marks is a software developer with over ten years of experience. He says: “If you take pride in your code, it shows when you read it. If you don’t take pride in your code, that also shows. The people who recognise your sense of pride are people you want to work with.”

It can be more difficult to gather feedback for developers who’re working alone. Find ways to program with others whenever possible, whether that’s contributing to open source, taking part in hackathons, or having pizza and code sessions with developer friends.

Find a mentor

Whether you work on a team with other developers, or do most of your programming alone, a technical mentor can help you grow your skills faster and avoid common mistakes. The question is, how do you actually get a mentor? Rarely do we walk up to a colleague or friend and say ‘Will you be my mentor?’ Instead, it often starts with asking someone to coffee, and goes from there.

Software Developer Nii Ashikwei Tetteh says: “We’re building on work that started decades ago, and those that came before us even by a few years have a wealth of knowledge we can benefit from. You will always be responsible for doing the groundwork, but you should have someone who can have some objective oversight on what you’re doing and where you’re going if you want to make sure you don’t deviate from your goals.”

Codementor is also another place to find long-term mentorship from expert developers.

Get really familiar with your text editor/IDE, and know its keyboard shortcuts

Like a blacksmith’s hammer, a scientist’s microscope, or a teacher’s chalkboard, your text editor or IDE is an essential tool for your work. If you’re comfortable and quick with your tool of choice, you’ll work faster, smarter, and other developers will enjoy pairing with you. If you’ve ever pair programmed with someone who’s not comfortable with their editor, you’ll know how frustrating that can be. Try to avoid doing the same to others.

It doesn’t matter so much which editor or IDE you choose as your own. In the hands of someone who really understands it, just about any text editor or IDE can be an extremely powerful tool. Take the time to know your tool, and let it help you in return. Andy Marks adds: “If you’re using a modern IDE like Eclipse or IntelliJ and a static language like Java, your IDE will give you lots of suggestions for improvements in your code, like unused attributes and methods, or expressions that can be simplified. Listen to these suggestions!”

Pair program with more experienced developers

Pair programming with more experienced developers can be daunting. They’re most likely faster than you in many senses of the word: faster at writing code, faster at solving problems, and faster at identifying the cause of bugs and errors. ‘Driving’ (controlling the keyboard) while a more senior developer is ‘navigating’ (sitting back and directing) can feel slightly painful if you’re still working out all the shortcuts in your IDE, or how to think through problems on the fly. However, you’ll learn a great deal through pairing. It can sometimes feel easier or more rewarding to work on problems on your own, but you may not learn as much.

Ideally, you’ll do a mix of pairing and occasionally working on your own. In addition to pair programming, Junior developers need the chance to make mistakes, make decisions, and try things out on our own, at our own pace, and the space to figure out how things work without feeling like we’re slowing someone else down.

Listen to and respect more senior developers around you, as well as other juniors

Alana George is a developer at ThoughtWorks, and another former ThoughtWorks University trainer. She says: “I’ve seen people respect the other experienced people around them, but disrespect other Juniors, or think that those Junior don’t know as much as them. Remember that you can learn from everyone around you.” Software development is an enormous field, and everyone has something to teach you.

Use good method/variable names instead of comments

The use of comments consistently divides software developers. Some appreciate a few well-placed comments, while others regard them as almost universally unnecessary. There are arguments to be made for both sides, but either way, moments where you’re tempted to write a comment provide a good opportunity to pause and reflect, and ask yourself the following questions:

• Is this a sign that my implementation is complex or difficult to read?
• Instead of writing a comment to explain what the code does, could I pull the code out into a separate variable, method or function with a descriptive name?
• Do I really need a comment here, or am I just stating the obvious?

“Good comments explain why, not what,” says Andy Marks. “Do more of the former and none of the latter. A well named method or variable will beat a well-written comment every day.”

Expose your ignorance, daily

Software development is an immense, multifaceted field that touches on a huge number of domains. Experts exist in almost every subset of software development, from databases, to security, to performance optimization. Even experienced software developers can’t know everything, and as a Junior, you are most likely missing a great deal of knowledge. The best way to accelerate the rate at which you gain that missing knowledge is by exposing your ignorance.

At least once a day you’ll hear or read about a term or technology you don’t understand. Don’t nod along and pretend you understand – ask. If you don’t speak up, it’s a missed opportunity to learn. You will go further in your career as a software developer if you prize genuine understanding and learning before appearances. You’ll also notice that it’s often the most senior and experienced developers who are most comfortable with admitting when they’ve made a mistake, or when they don’t understand something. Alana George says: “A lot of people are scared to look stupid or expose their ignorance, but it’s something you have to do in order to learn, so ask questions, clarify stuff and then verify your understanding is correct.”

Have side projects

Your side projects are your playground, a place to follow your interests and try out new tools without harsh deadlines or high stakes. For Junior developers, side projects are a great way to fill gaps in your knowledge, build your experience, make decisions – and deal with the consequences, both good and bad – all on your own.

Your side projects don’t need to be big or impressive. In fact, side projects you can finish in a day’s work or less are ideal. They’re small enough not to be daunting, but big enough that they can accomplish something useful. If you’re stuck for ideas, try solving a small problem in your life with a technical solution. For example:

• Build a tool that downloads the session times from your local cinema once a week and emails you if there are any films showing with an iMDB rating of 8 or higher
• Build a simple app to tell you when your favorite band is touring in your city
• Build a custom dashboard for the prices of stocks or collectable items you own
• Create a website to showcase your photography, where each page’s color scheme changes dynamically based on the dominant colors in each photograph

Nii Ashikwei Tetteh says: “In order to keep growing you can’t rely on your main job alone. Your company and its clients and customers each have their priorities, and you have yours. Work life balance is important, but so is making the time and space to do what you want to do with your skills and see how you’ve grown, build something fun and share your skills with the larger world outside of your work.”

Junior developers, what has helped you improve the most? Share your tips in the comments below.