Starting a new job is intimidating. For the first few months, especially if you are a new grad, you just want an instruction book of what to do and how to achieve it. The best companies might have an in-depth onboarding process spanning weeks, but at others, you are shown your desk, sent a few resources by email, and must get yourself started on the path to productivity.
I was in the latter group just a few months ago. I work for a small development team which is part of a government agency. We are a group of just eight developers building and supporting systems that underpin $87 million in annual revenue as well as the parking management systems for cities throughout Western Canada. These capacity constraints simply did not allow for the creation of a comprehensive onboarding process. Plus, there would never be enough new hires to make it worth the effort.
Rather than despair, I decided to onboard myself. Here are some of the things I learned on the path to being a fully contributing developer and a valuable member of the development team.
Determine the rules for how code is written
Companies like Google are famous for their lengthy style guides. If printed out , their Java guide alone is 20 pages in length. Other companies are satisfied so long as your code compiles and the unit tests pass. Most companies are somewhere in the middle.
Some companies mandate a particular integrated development environment (IDE), others strongly prefer a particular IDE but give developers some flexibility, and others are agnostic on the tools you use.
Some companies want everyone to use a specific linter or require comments in certain places. Others may not have any requirement other than that the code be neat and clear. There may also be other unique rules. For example, at my organization, we have specific standards for getters and setters. Instead of generating them by hand or with an IDE, we use the @Data annotation from Project Lombok, which ensures that all getters and setters follow a standard format. Try to figure out all these rules before you are deep into setting up your development environment for the first time or writing your first contribution. It is frustrating to do work and then be asked to redo it because you did not know the rules.
Spend the first few weeks learning the technology stack directly
Our stack consists of Spring, React, PostgreSQL, and Hibernate. When I started, I had a few weeks experience with Postgres and React and had never used Spring or Hibernate. If you are a developer in this position, your new boss is likely aware that you did not come with a complete set of knowledge. Those first few weeks are your opportunity to build the knowledge you will need to rapidly become productive in your new job. Go and find lengthy tutorials in your favorite learning format and block out time to work through the projects they have you develop. Ask what kind of documentation your company hasand take time to read it all thoroughly. There are two reasons to take this approach instead of just diving into the codebase, which was my approach during my first software engineering internship.
Firstly, learning from the codebase means that you will adopt all the poor habits and practices of the programmer who came before you. Just because code made it into production, it does not mean it was well done. It might have a traditional "for loop" that should really have been a foreach or map. Maybe it fails to follow separation of concerns for that particular framework. Several controllers in our codebase have an enormous amount of business logic that belongs in the service layer. Second, it is quite possible that the codebase is out of date, the technology has changed, or that the relevant concepts cannot easily be learned from reading the code. Simply learning from our codebase, I would never have learned about React hooks and would have spent a great deal of time wondering what exactly @Transactional does in Spring.
The path of code to production can vary tremendously. Take notes.
A past company I worked for took code from local to production right after code review. Developers were expected to create a merge request directly onto the master branch. If nobody else was in the office, it was acceptable to push directly onto the master.
I did that for one of my first bug fixes at my new job and that elicited messages from more senior people telling me I should not have done that. Only QA is permitted to merge onto master here.
Your company may also have an unofficial path, one which gets used for bug fixes or nearing the end of the sprint. We have an intermediary step between code review and QA called DEV which often gets skipped. Code review and unit testing also become lighter during periods of heavy load or approaching deadlines. However, QA never gets skipped. Processes may vary. Find out what they are.
Learn to balance both business and engineering goals
In an ideal world, there would be plenty of time to add more unit and integration tests, refactor, and get the views of every team member on the architecture. In the real world, clients want features, senior management wants to hear about progress, the people with the expertise go on vacation for weeks, and deadlines do not disappear just because a bug was hard to find or difficult to fix. At most companies, that means certain compromises will be made. Some companies will push the client to accept a later deadline or management to accept a longer timeframe to do a better job of the engineering work. Other times, it is more valued by management to hit the sprint goals and just use more glue to get things to hold together because of client demands or business needs. You probably have a minimal level of say in which path gets taken, but you want to plan your development work to fit the chosen strategy. You should quickly learn if two components with small bugs or one component without bugs is preferred by your co-workers/leadership by the end of the sprint.
Most early problems have solutions, so ask questions quickly
On my first day, I spent four hours wondering why the main project repository I had just cloned would not compile. I read the build instructions over and over, but couldn’t find where I might have gone wrong. Not wanting to look foolish, I spent that time hunting for things that might cause Maven (a Java build tool) to fail. It turned out that I was just missing a few configuration arguments to specify which properties file I should use. The colleague I asked about the problem recognized it in two minutes. I could easily have wasted another day or two trying every obscure combination of things which could cause a build to fail. In the first few days, things that seem like they should be easy usually are.
Learn to have effective conversations with the non-technicals
Unless your product is a build tool or integrated development environment, there are probably non-technical people who are making decisions regarding your project. It might be the CEO overseeing the company’s flagship product. It could be the manager of the department which will primarily use what you are building. It might be the salesperson who has to go out and get people to buy your software.
As much as we developers would love to blame miscommunication on the technical ignorance of others, no matter who is to blame, we are still the ones who must redo the work when it does not meet the actual need of the end user.
At the very least, these conversations will help you understand the motivations behind why the company behaves as it does. The best case scenario is that costly miscommunications are avoided and nobody is attempting to blame you for a delay in the project.
So how does one do this? One approach I like is to use analogies. I recently had to explain why it was so significant to know whether something would be a one to one relationship or a one to many relationship before development started. In a one to one relationship, one might just add a new database column for that entity and modifying the existing service. In a one to many relationship, a new table would be required, a new entity would be needed, and a new service would need to be built.
I explained it as having one child compared to two at the zoo. If you only need to look after one child, it is perfectly effective to carry them in your arms or on your shoulders and have everything they need in a backpack. They can be left to run around freely as you can always be paying attention to that one child. If you have two children, you cannot easily carry them both yourself. You will want a stroller with space for two. The supplies needed for both might be getting heavy, so some storage in the stroller would also be desirable. You might want another adult to come along to help you. That makes a trip to the zoo with one parent and one child far less complex than one parent taking two children to the zoo.
Another thing which has cut down on repeated work is a frontend first approach. I work on a project where most of the stakeholders are non-technical, so they understand the project through the user interface. Instead of completing all the work and then presenting the concept during stakeholder engagement sessions, the proposed frontend is sometimes built beforehand, approved, and then the backend work is completed.
Find skill deficiencies and try to fill them
Most companies have evolving technical needs. In my job, our latest project is both client facing and user facing, which requires that the user interfaces be more responsive and pleasingly designed than for internal applications. So far, the sprints have been overwhelmingly comprised of React work, something which only one other developer on my team had experience with prior to the project kick off. While I had less experience overall, this deficit made it easier for me to contribute more quickly simply because I was just as skilled at React as most other members of the team.
Keep a notepad nearby, as important information may be just on someone’s lips
Information management is something most companies struggle with and it is rare for everything important to make it into the design document, if one exists at all. Crucial information for some of my tasks has often just been mentioned by one stakeholder casually in a meeting.
If you keep a notepad and pen nearby, you can randomly jot down all the seemingly important things that you hear and clarify it later. Instead, you are faced with the prospect of building a module incorrectly and needing to re-engineer it after sprint review.
While intimidating, the lack of a formal onboarding process can allow you more freedom to approach the job as you see fit and once you have an action plan, it is not all that different from a formalized onboarding process except for the fact that you created it yourself.
Good luck in your new role. Even if you don’t get a proper onboarding, you should have the tools to do the job yourself.