If you are a junior developer starting in the realms of software engineering, things can often seem a little intimidating. You would assume after four years of college where you spent your time learning the in-s and out-s of data structures and algorithms you’d be ready for the real world. But you quickly realize that there is not just one way of solving a problem, and something that seemed the best approach in theory (that you learnt in school) can very likely not be the right solution in the workplace because of constraints like maintenance, resources available etc. There are so many things to learn, and as soon as you’ve learnt one framework or tool, there seems to be something new out there.
As a Junior developer myself who recently graduated college, here are some tricks and tips I thought I’d share that helped me to learn how to improve and made my transition easier.
- 1. The best piece of code is no code
Our job as developers are not to write code for the sake of writing code. Our jobs are to solve problems to add value. Writing an immense complex function that does fancy operations and looks super slick isn’t necessarily a good usage of your team’s resources. Do not compromise with performance, but good code lies in a sweet spot where complexity and performance are both kept in mind. The more complex your function is the chances are, the harder it is to maintain. If you can solve a problem without even writing code provided all the requirements are met, do not write code. In programming, the rule of least power is a design principle that “suggests choosing the least powerful [computer] language suitable for a given purpose”.
- 2. 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. Make sure you take your code reviews seriously.
When you make a PR- and your teammates are giving you feedback, don’t be disappointed. It’s nothing personal and is meant to make you better. If your code was solving the problem like it was required but your teammate made a wrong assumption and commented on it, that’s good too as it explores the possibility that maybe there was room for improvement for it to be cleaner and less confusing. Make a practice of asking your teammates if there’s anything you can improve on from time to time. Go on a walk with them, and ask them questions like “How do you think I could better at what I do?”, which does not necessarily mean you’re bad but expresses the intent that you know that there is always a chance to get better and you want to work on it.
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.
- 3. Find a mentor. Mentors can help! A lot!
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 can evolve from the appreciation of someone doing something better than you, and your want to learn how to reach that stage. Remember, every mentor or senior developer had to start somewhere and they went through the same road as you did when they started. Be humble and demonstrate that you want to learn from your mentor.
- 4. Learn the ins and outs of your toolset (Language, IDE)
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. Learn all the gimmicks your programming language of choice houses. For example, don’t write your custom made array manipulation method in JavaScript unless you have a real need for it. There are chances that maybe someone has had the same use case and have an optimized method (e.g. map, filter) that would save you both resources and be easier to maintain.
- 5. Pair program with different developers
Pair programming with experience 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.
- 6. Write good maintainable code. Easily readable code is better than documentation
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?
- 7. Expose your ignorance. It’s okay and only fair!
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.
Hope this helps! 😄
Top comments (0)