So you're new to the developer life. This can be an intimidating time, even for the most skilled and hard-working people. Starting a new career can be overwhelming at first, but you are not alone, and your anxiety will pass shortly. To help with this transition, we have put together a few pieces of advice that will come in handy when you begin this journey.

Onboard Efficiently

As a software developer, you will work on many different projects in many different languages over the course of your career. Software is an ever-changing field and you will be challenged to adapt quickly to new technologies and new patterns. Learning how to onboard onto a new project efficiently will make you a valuable asset to your company and will prove your adaptability.

Once you are assigned a new project, here are some steps you can follow:

Understand the purpose of the project. Your project manager and developers who have worked on the project are there to ease the process of getting started.
Get the project running locally. Once you have access to the repository, check out the README. Did you have any problems setting up the project? Was the documentation clear? If it was not clear, your first contribution to the project should be modifying the README. This can get you acquainted with the process of adding to the codebase and may speed up onboarding for future developers.
Read the code. What are the different components and how do they fit together? What is the structure of the code? Try to determine where certain things live in the codebase. Try to schedule a meeting with a developer familiar with the codebase to get an overview.
Contribute to the project. Read through previous PRs to understand the pattern of introducing new code to the codebase. Are commits structured in a particular way? Pick up small tasks and begin contributing as fast as possible! No task is too small as you’re getting comfortable with new code.

No Stupid Questions

As a developer, part of the daily routine is to solve problems. In certain cases, your first instinct might be to Google the problem and attempt to solve it. That’s reasonable. But sometimes, you’ll spend too much time turning your gears to find the answer yourself, which can be frustrating. You are surrounded by highly experienced developers who are always there to help. Ask them for help! Try to run ideas by them before you begin problem-solving. Sometimes it’ll take them less time to debug something or come up with an implementation plan, which is beneficial to you, your teammates, and the company. Other times, you will just figure it out yourself while attempting to explain it to someone else .

If you have doubts about the software requirements, make sure to ask your Project Manager or the person in charge to clarify before you begin developing. You wouldn't want to implement an entire feature only to find out that you made a wrong assumption.

Asking questions takes practice. If you do it more, you might see yourself asking more of the right questions to the right people, articulating your questions more clearly, and increasing your productivity.

There’s probably a better way of doing that

Before you dive into development, check if accepted solutions already exist for the problem you are trying to solve or the feature you are trying to implement. Packages are your friend! Reinventing the wheel can slow down development, and your final solution might not be as robust as the widely used one.

Check the codebase for similar patterns
Research existing packages or libraries
Find code solutions from reputable sources (StackOverflow, relevant GitHub issues, etc)

Before committing to an existing package or library, here’s what you should ask yourself:

Is this tool actively maintained?
Is there a community of developers who use it?
Is this tool difficult to configure?
Is it easy to adapt to fit the needs of your project (in terms of style, functionality)?
Can you solve the problem at hand without using this tool fairly easily?

Poke around the hosted source code if the package or library is open-source make sure you understand what the tool is doing and how it is doing it. Check the date of the last commit to determine whether or not it is well maintained and check the number of downloads to identify if an existing community exists.

Just because a tool exists, does not mean you have to or should use it! If you are unsure about using this package or library, ask your teammates and talk about what you have learned in the research process.

It is difficult to change the way you are used to doing things, but sometimes it will make your development process more efficient. This applies not only to writing code but also to your general workflow. You might find yourself doing a repetitive task, or doing something that feels too hard. In those cases, there’s probably a better way of doing it and that is the time when you start asking questions to find out how.

Get it done first, improve it later

If you’re coming straight from school, you might be used to reading the requirements for a project, spending long hours writing some working (or broken) code, then submitting your work. Now that you are in the “professional world”, you might feel the pressure of only writing pretty code. This makes sense, but you shouldn’t start thinking about complex optimizations if you haven’t written a solution yet. You should focus on getting the work done:

Get the code working end-to-end.
Refactor. Improve your design. Make your code readable and maintainable for other devs and your future self.
Make it faster. If you have serious performance issues, fix them. But if it’s not necessary then it might be worth leaving as is, or asking for second and third opinions.

As a junior developer, you might not even know what an improved solution could look like. This is your chance to ask for help, read through the codebase to identify good practices, or take advantage of code reviews.

Source Code Management

Source Code Management (SCM) tools such as Git provide a history of code development. These tools are used for tracking and managing changes to code.

Git is not the only form of SCM but it certainly is one of the more popular tools, especially here at MojoTech. Git allows you to create a copy of your repository which makes it nearly impossible to mess up previously merged work. Having good practices for source control on a project will make looking back a previous work almost effortless. It will also make it easier for others to be able to read your code.

The standard workflow at MojoTech, as described by Craig P Jolicoeur in his blogpost MojoTech Git Workflow, is:

Create a branch off of master: this creates a copy of the master branch, meaning that your changes won’t actually affect the source code
Make changes to implement the feature: this is where you make modifications to the code to complete a task. While you are doing this, you should make sure you are writing good commit messages and keeping your commits atomic.
Submit a new Pull Request: once your code is readable and your commits are organized, you can submit a Pull Request. In this step, you can take advantage of the GitHub Compare feature to make sure the changes introduced in each commit of this branch make sense.
Have those changes in peer code review. This is why it is important that your code is readable and your commits are well split. Other people in your team will read your code and comment on it. During code review, you will likely have to make changes to your commits and make use of
git rebase -i master
,
git push --force-with-lease
,
After approval, merge the Pull Request into the master branch.

Don’t be afraid to spend time on your workflow

Being a new developer isn’t easy, but you can make your life more simple by mastering certain tools and customizing your environment. There are plenty of tools to try, which can be overwhelming, but it can also be exciting. Your co-workers are a great resource, so if your company doesn’t have an onboarding tool guide, ask others about their environment and workflow. Don’t be afraid to try different things! For example, if you use a text editor for a while but then find that another has more of the features you need, don’t be afraid to switch and spend time getting up to speed with it. If you’re using the terminal to test HTTP requests repeatedly or inspect your database, know that you can use tools like Postman or TablePlus to make your life easier.

In the beginning, you might spend most of your time searching for cool packages, hotkey combinations, or anything that will make your workflow more efficient. You will likely find yourself performing the same actions repeatedly, to the point where you won’t even have to think to do them in this new environment. The same applies to things like the command line, or browser developer tools. There are tons of resources online for “the perfect coding environment”, but in the end, it all depends on your preferences and your needs as a developer. It’s necessary to spend time on your workflow to slowly build your own coding environment.

Stay Organized

A good way to stay on top of things is to keep a journal (physical or digital) of important work you’re doing every day. These notes will be useful for when the yearly review comes up and you’ll be asked to recall everything you did in the past year.

You can keep track of:

Your daily progress and what you’re currently working on, which is useful for daily stand-ups.
Any blockers or questions, so that you can ask your teammates and keep track of their advice.
Things you want to get better at or would like to learn more about.
Technologies used on the project that you like or don’t. This will be helpful in future projects
Track your role and things you accomplished on a project

Try out multiple journaling methods and find one that works for you. Here are a few that we use: Day One, Markdown, Google Docs.

Stay up to date

Robert C. Martin, or “Uncle Bob”, says it best in his book The Clean Coder - “Would you visit a doctor who did not keep current with medical journals?”

Would you want to work with developers who aren’t up to date with the newest technologies? Technology will continue to rapidly change - and it is part of the job to keep current with industry standards.

At MojoTech, employees exchange Slack messages debating the pros and cons of new technologies and patterns constantly. If your company does something similar, participate! Ask questions, or just read other comments, and try to understand why one technology is better than another, or why it isn’t. If your company does not have a built-in way to stay up to date on technologies, there are other resources to stay up to date, such as reading technology blog posts or working on side projects. Check out The State of the Octoverse to see the latest software trends within the GitHub community.

Take the Opportunities

Every job has its perks, that’s one of the reasons why being a part of a modern company is so appealing. If the company plans an event, make sure to participate every chance you get. Participating is a great way to get to know your co-workers outside of business hours and build those relationships. Doing so will improve how you work together.

Every year MojoTech sponsors all employees to attend a conference of their choosing, which is a great way to connect with coworkers and stay up to date with new technology.

Focus on your own growth

It can be difficult to not compare yourself to your peers. There are so many programmers out there, it’s important to not get bogged down by comparisons - focus instead on your personal growth. You will be learning so much so quickly that it’s hard to think back to where you started and how far you’ve come, but it’s important to keep that perspective.

It might be difficult to not get things working right away or to miss things that seem obvious to someone else, but becoming a good developer is all about getting better at the process of programming and problem-solving. That growth process will involve plenty of failures and frustrating debugging sessions, but each one will result in personal growth that will help you move forward. Just because something didn’t work out, or a feature took you a long time to implement does not mean that it wasn’t valuable.

Be comfortable with being uncomfortable. Pick up tasks that scare you or tasks that you do not instantly have an idea of how to implement. By challenging yourself with difficult tasks, the next time you see a similar task, you will feel more comfortable with it. Eventually, there will be fewer and fewer tasks that seem “scary” to you.

A Starting Point for New Developers