I’ve grown a lot as a software engineer since I graduated college. Many colleges don’t teach real world interaction with a team and common coding standards. If you are just starting out as a developer or are more on the junior side, this post is for you. Many of my points come from real world experience and the mistakes and learnings I made along the way.
Expect a lot of comments on your first PR.
Just remember this is normal for starting developers, especially those who are fresh out of college. Co-workers who have more time and experience will point out flaws, spaghetti code, or over-engineered code that may be hard to read. They may have a certain way of writing code that they expect you to conform to – this is all okay. As you work on more and more stories and receive feedback from your peers, those comments will gradually diminish in number.
Writing maintainable and readable code is just as important as getting the feature done.
When you were in school, you might have written a lot of code expecting that you would be the only one who could read and understand it. Perhaps your professor only cared about whether the thing you built worked or not. In the real world, you will most likely be working in a team. Even if you can finish a feature a few days before everyone else, it will be useless to the business and the team if you are the only one that can understand it. Naming variables and functions well goes a long way. Being consistent in your codebase also helps. If you switch teams or move to another job, and you have left behind unreadable code, your former team will have a lot of refactor work to clean up on your behalf. Good code is simple. The easier it is to read, the more value you add to the business, not to mention the better relationship you’ll have with your team.
If you are not sure about pointing stories or time, over-estimate.
For those who work in an agile process (Scrum in particular), there is a good chance that you will have to point stories. If you are not sure about what your acceptance criteria should be, ask questions. If your team isn’t sure about the story, ask for it to be a spike (a task for gathering information rather than delivering a feature). If you can identify clear parts of the story that are defined well, ask for the story to be broken down into small digestible chunks. If you understand the acceptance criteria, but don’t know the code base, then factor in the time and degree of complexity to understand that code and seek guidance from someone more senior.
The simpler the code is, the better it is.
There are times when you want to handle all possible situations when developing a feature. Be wary, as this can lead you to over-engineer (build more than what is required). Employing TDD in your development process will help prevent over engineering and keep your code simple. A good code review culture is also imperative to prevent this from happening.
The company may have a certain or specific style of coding.
Throughout your career, you will inevitably pick up certain styles of coding, as not all companies adopt that same style. Focus on the present and your current objectives, wherever you are – try to understand why your employer or client has chosen that style of coding and how it helps the business.
Focus on learning AND the job-at-hand.
As a junior software engineer, you should be learning something new everyday. It doesn’t have to be about the best coding paradigm or language; rather, it can be about the business or something you didn’t know about yourself.
Sometimes you might feel like you are stuck in a rut. This is a good opportunity to re-evaluate your current situation. Are you taking any steps to learn more about the process? The code? The business? Is there anything you can do to improve the business overall? Reach out and see what you can find. If you feel like you have done everything you can to learn about the business, then it might be time for you to move on and find other opportunities.
No language or framework is a silver bullet.
There are constant arguments and favoritisms about a particular framework or language. “React is better!, ” “Go is more performant than Node,” are just a few examples of opinions you’ll hear. What really matters is the mindset that all frameworks and languages are tools to help meet business requirements. Choose the best one for your use case and get the work done.
Finding a mentor is essential for your professional growth.
Regardless of whether you’re assigned a mentor on Day 1 or you seek out a senior team member to serve in this role, having a mentor is key. If you’re lucky, you will identify with two or more mentors that will debate with each other on which methodology is better. Take the time to learn from your mentors – it is the fastest way to become a senior developer yourself.
It’s okay to make mistakes.
Don’t panic! I know it’s easier said than done when for example, you accidentally force push to master (don’t ask!). Like driving, the worst thing you can do is panic. When you make a mistake, seek help immediately and explain the situation in full detail. Even if it’s a major mistake, you are helping expose a weakness in the process which can be refined to stop similar mistakes in the future.
Ask questions if you are stuck.
Of all the things I’ve learned on my way to being a better developer, it is to simply ask questions when you are stuck. Time-cap it when you are stuck in a problem. Try thirty minutes to an hour. Try listing out possible solutions and go through them one by one. Once you’ve exhausted your ideas, seek help. Another pair of eyes can help open new perspective on a problem. This can also help build relationships in a team and achieve a win.