Checklist for Onboarding Developers to a Project
Written on January 7, 2018
Estimated reading time :
5 mins
Background story
- The quest to carry out greenfield development - its a dream of most developers…especially the newcomers. I can’t fault them. Most legacy applications have a bad name.
- However, the history of the application matters. Its life time, the quality of refactoring if any, the quality of the people who have worked on it, the type of management supporting it - all play a role in its maintenability.
- It helps to have a smooth & structured transition. I created a checklist which I use whenever I move into a project or others move into my project.
Checklist in summarized form
-
Meeting with the Project manager(PM) / Scrum Master(SM) / Team Lead(TL)
Introduction to the team
Application walkthrough
Architecture walkthrough
Process walkthrough
Grant Permissions
Application setup
Self Study : Understand the application
Pair with a developer for a story
Audit
Checklist in detailed form
- Meeting with the Project manager(PM) / Scrum Master(SM) / Team Lead(TL)
- Initiator : PM or SM or TL.
- A friendly introduction followed by a walkthrough of the agenda to be followed (ie the rest of the checklist !)
- Introduction to the team
- Initiator : PM or SM or TL.
- The people working on an application are the most important part of it. Hence this meeting is high up on this list.
- A friendly introduction to everyone in the team with a summary of their roles.
- Application walkthrough
- Initiator : Product Owner(PO) or PM or SM or TL
- The SM or the TL can give a summary about the why & what part - ie the need of this application & what it does.
- It would be great if the Product Owner is present to explain the impact on the business.
- Architecture walkthrough
- Initiator : The TL or Architect or a Senior Developer
- Assuming it is a standard web application, the walkthrough can cover :
- Application Architecture (eg : Microservices or Monolithic structure)
- Supporting software (eg: Docker)
- Web server (eg: nginx)
- Programming language(s) (eg : Node.js)
- Database(s) (eg: PostgreSQL)
- Backend framework(s) (eg: Hapi.js)
- Frontend framework(s) (eg: Angular, Bootstrap)
- Versioning (eg : Git via Github)
- Cloud Infrastructure (eg: AWS)
- Based on the role of the developer (eg : frontend developer), more details can be provided on the related technology.
- Process walkthrough
- Initiator : The PM or SM or TL or a Senior Developer
- Framework followed (Eg : SCRUM)
- Tools used (eg : Atlassian toolset of JIRA, Confluence, Bitbucket etc)
- Schedule of team meetings (eg : Daily SCRUM, Planning, Sprint Demo etc)
- Ticket resolution (eg : who picks what, initial implementation plan to be shared, definition of done etc)
- Code repo branching strategy (eg : Github branching model)
- Testing strategy
- Grant Permissions
- Initiator : PM or SM or TL
- Code repo access (Eg: Github)
- Wiki access (Share Project related codes, metrics) (eg: Confluence)
- Issue tracker (eg: JIRA)
- Application setup
- Initiator : TL or a Senior Developer
- Usually, this should be a simple step thanks to a well configured Docker setup but it can be complex in some legacy projects. So some handholding can get things up & running fast.
- Self Study : Understand the application
- Initiator : The new member !
- Understand the tech stack & fill gaps (if any).
- Understand the application code base
- Q&A round with a Senior Developer would be a good way to end this step.
- Pair with a developer for a story
- It is a good idea to pair the new member with another member of the team.
- A story or feature which gives a good idea about the application or the type of work to be taken up by the new developer is ideal for this.
- The new developer also gets a taste of the whole workflow (ticket start to finish).
- Audit
- This is a step which adds a lot of value to the application. Especially if the developer has some experience & the application is a legacy application.
- A number of good practicies, good conventions, potential performance optimizations have come out in such audits since the new developer brings a fresh perspective into the team.
- A discussion of the points with tickets created & prioritized would be a good output for this step.
The order of the list can be tweaked - just ensure the listed activities happen.
This checklist has helped me & others a lot as it brings some form of structure into the knowledge transfer. To some extent, it also makes you organized (or atleast appear to be !).
Feel free to suggest improvements in it !
ps : The reality remains that most developers will be involved in brownfield development for most of their careers (probably a 80:20 ratio).
Working on an existing application can sometimes be very good. Opportunities to refactor code for optimization, performance improvement, remove bottlenecks etc often come up in such applications leading to a lot of learning.
It helps to have side projects to channel your creativity & skill.
