Table of Contents
- #1 Get an overview of what you need to know
- #2 Be patient
- #3 Make sure you have small success moments
- #4 Have someone senior to guide you
- #5 Learn the terminology
- #6 Speak with peers as much as possible
- #7 Learn how to help yourself
- #8 Always use diff
- #9 Make good use of the debugger
- #10 Develop a sense of what’s right
What I wish I had known from the start. Mentioned below are my top 10 tips – hopefully this will prevent a fellow junior developer from getting off on the wrong foot.
#1 Get an overview of what you need to know
So you want to be a developer? Great, time to hit the books! But where to begin? Well, this is the first and probably most important question you need to ask yourself. Unfortunately there is no “one topic” which you can learn that will enable you to deal with all forthcoming development tasks. In fact the dazzling array of technologies can be quite overwhelming as a greenhorn. Hence you need to figure out what areas fall into your ballpark and how they are intertwined with each other. Take this example: As a web backend developer I needed know-how about the Symfony framework. But before I could even think about learning Symfony, I was obliged to understand object-oriented PHP. To understand object-oriented PHP, it was beneficial to take a glimpse at procedural PHP and do a refresh of object-oriented paradigms. Once I got that down, I had to work out the way MVC-frameworks function and so on and so forth.
Try to draw up a learning map for yourself to support structured, efficient learning and only tackle one topic at a time. If you have trouble coming up with the necessary topics or relationships between the topics, have a senior or peer assist you or try gaining information from learning platforms (e.g. lynda.com, teamtreehouse.com), communities (Stackoverflow, Youtube) or blog articles. Also keep revisiting the map from time to time with your gained knowledge. Even if this looks like an unsolvable puzzle laid out in front of you at first, I promise it will make much more sense later on.
#2 Be patient
Set your expectations realistically: Rome was not built in one day and you are not going to turn into an imba developer overnight. Be aware that programming is a mid- to long-term endeavor in which you will take small steps to reach a greater goal.
#3 Make sure you have small success moments
Programming will frustrate you time and time again – no matter how long you have been in the game. Obviously the less experienced you are, the more potential for frustration lies ahead. Therefore it is key to have small success moments in order to keep yourself in a good mood. At the end of the day we’re all human beings with emotions and feelings attached – if we don’t keep ourselves content it will be harder to get going.
#4 Have someone senior to guide you
The best way to guarantee these small success moments happen is to have a senior developer at hand who will point you towards the right direction once you encounter a problem. It happens all too often in the beginning: you’re stuck because of a minor detail like forgetting to import a class or not noticing you forgot to close a bracket since you’ve been looking at that code snippet for the past hour. These blockers can freeze you up til the cows come home whereas a senior programmer will point these issues out in the blink of an eye. As a result, one minute of their time will save you a lot of frustration.
#5 Learn the terminology
Interaction with your technical peers is tricky when you don’t speak their language. If phrases like “Simply stash your changes, checkout a new branch, pop your changes and commit them to remote” makes you go “say whaaaat?”, you should spend some time learning and understanding the terms you need to communicate with your colleagues. Only this way you will have a mutual understanding of what they are referring to and actually pick up their advice.
#6 Speak with peers as much as possible
In reference to the previous two tips, exchanging your thoughts and approaches to a problem with your peers will always broaden your horizon. They have been practicing this craft way longer than you do. More often than not there will be different ways to solve a problem and you may have found one that works – still your peers will likely be able to tell you about two other approaches that work even better.
#7 Learn how to help yourself
Especially when working with Web Technologies, chances are that someone else already stumbled upon the same problem you are looking at and asked the question somewhere on the Internet. 9 out of 10 times you will be able to find the answer on the web (Stackoverflow, official documentation of the software). If you can’t find the answer you are most likely looking for the wrong terms, your problem is project-specific, or, although I sincerely doubt it, the question really hasn’t been asked.
As you evolve as a programmer you can’t keep bugging your colleagues every time you’re stuck. Learning how to google for your answers will go a long way.
#8 Always use diff
You just finished coding and are eager to commit your changes? Wow, hold your horses right there son. Always use diff first. Always. Use. Diff. Diff basically shows you the current version of the code compared with the code that contains your changes. Maybe this feature is named differently in your IDE or VCS but any state-of-the-art developer software will offer this functionality. Needless to say that you can avoid countless mistakes by taking a quick look in the diff. Maybe you forgot to delete that last dump you inserted or you worked on two changes simultaneously and don’t want the other change to be committed.
#9 Make good use of the debugger
As a junior developer it is hard to cohesively understand every granular step that is executed in the code. Thank heaven there are debuggers which depict just that! Stepping through the code will teach you a lot about how the application is working and setting up watch for variables will show you how values get altered in each step. Therefore I believe that the debugger is the best non-human teacher you can get in the beginning.
#10 Develop a sense of what’s right
As you shape your development skills and become more proficient, try to get a sense of what good code and bad code looks like. You should be able to quickly recognize when something smells fishy. For example if the same thing is coded in multiple places, it’s time to think about refactoring. If values that should be variables are hard-coded you should change it. If there is bogus code and you’re absolutely sure it’s no longer used you should clean it up. If values are altered in one place and subsequently altered back a few calls later somewhere else, this might be the start of spaghetti code which you should avoid at all cost.
In the long run making the switch to being a developer is about managing your expectations, being patient, persistent and willing to learn. Practice makes perfect and if you have someone competent who shows you the ropes, I’m sure your journey will be successful.