Less than a day Java Developer on boarding

I currently am between gigs and in interviewing was questioned with skepticism about my claim of less than a day to on board a professional developer. The first thing is to define on boarding and how to measure success in the context of a “Professional Software Developer” on boarding.

First to note, I quoted Professional Software Developer if you are not starting with a developer who has taken an oath similar to The Programmers Oath, then all stop! Question why and how this member got past interviewing.

In no way am I speaking about the all-star 10x developer who looks at the project and in 2 minuets rewrites it.

Ok so I am sure there are many more “what about” and “you forgot”. This brings me to the last point, David you are giving away the secret sauce everyone will just take your process and methodology and run with it. I say great if it helps and you can do implement it great maybe my next job, I will benefit from it and start contributing to the project.

As the below title eludes too you must first have a proper development shop. No one is perfect and not all of these items need to be followed this is why I can write this with confidence that unless you have experience with multitude of teams building projects/products you will not know what things are needed and what ones complement the others. Stop do not try to bring on another developer on board until your house is order. I argue if they are a professional developer this showed be a sign to them.

Development House in order first:

1.     Assessment of the current development environment;

a.     Source Control (reference) does the team love or hate it. Can the management explain the reason for which version is being used?

                      i.     Git

                      ii.     Subversion

b.     Project Build Tools, can the full lifecycle of the build be completed on CI and developer machine?

                      i.     Gradle

                      ii.     Maven

                      iii.     Ant

c.     IDE Battle, this can be directly connected to subpoint b, for a number of reasons:

                      i.     The project can only be built in the IDE

                      ii.     The project has dependencies added to it like OS, certain licensed binaries not available on developer box.

                      iii.     IMHO IDE lock-in or cannot build on developer machine points to design decisions that need to be addressed.

                      iv.     My opinion a developer should choose their IDE if they are a professional, they have learned productivity tasks for that IDE as a Professional that you will want to take advantage and even learn. Nothing like my favorite shortcut for my IDE to break the ice in introducing the new member.

2.     The day in the life of a Professional Developer (Beatles 2:21 start)

a.     Code Review, what does it look like, the process tools used to capture the feedback the vibe around the review, who is ultimately responsible for the code? Many of these questions deserve their own post that maybe I will someday write.

b.     Any branch check-in results in the automated static analysis tools running. Let the tools be the bad reviewer not allowing you to merge, the reviewer should be worried about the business logic you are implementing not curly braces and spacing. The reviewer should flag any design or architecture changes the code may be introducing.

c.     Unit Tests testing the code; Junit, Spock and what is measuring the quality of the test Jacoco.

d.     Do they have a fail fast mentality, fail on static analysis, unit tests not passing?

e.     What is the branching strategy is there a merge often fail fast or a wait and merge hell at the end?

3.     Continuous Automated Integration Builds;

a.     What CI are they using does it integrate seamlessly with the development build tools.

b.     This is key do the developers own the build server and the responsibility of keeping it building or is it to the junior IT staff guy?

c.     Is there a continuous feedback loop of failures is it public to the entire organization? Does the organization care or understand what it means?

d.     I have seen countless times setting up and running the builds and making sure all executives have view into the health of the product. Neat story is one time at a startup i.e. the Product was the only thing the company was based on and the top executive stated he did not really care or had the time to worry about the failure or health of the Product.

e.     How many branches are being built, do different pipelines build and run different tasks based on branch and tagging?

Finally, you say we have come to the truth how is it done. A little hint if you have not guessed many reasons for slow developer ramp up is nothing to do with what should be a simple process, instead it has to do with the current environment you are introducing them into.

Process:

Spend 30 minutes reviewing the high-level architecture of the system or product. Allow for 30 minutes for in-depth questions. 20 minutes the developer now explains back to you what the overall driving design of the product is and what the product does. Example, a set of Docker Swarm services that run in Azure that use Redis for shared state and MongoDB as a document store. The product provides a web front end written Angular that allows the customer to store a headshot and bio about themselves for Hollywood talent agents. Here is the next gotcha of the process if you have one monolithic project then stop the only developer you should be bringing on is one that can help you break apart the monolith into manageable pieces. I would recommend a Microservices approach Martin Fowler is a good start to understand it. So, we have a set of projects each one doing one thing very well. This is the test you now should review the tools, design and architecture choices this single service project is using. Example would be this is a Spring boot application that connects to MariaDB using JPA framework with a set of restful services that our called from a http client. Depending on the professional developer git, IDE, java, groovy is installed and ready to go.

If the “professional?”  needs help then spend the 30 minutes tops to install these tools. You may say hey what about a new hired graduate. I say you will be surprised they may be far better off than the crusty developer, if this is not the case, I argue they are not professional yet. All stop this recipe is not going to work for them and not fair to them either.

Ok developer has the basic tools installed now have them build the project. Should take since the project does one thing very well about 1 to 3 tops to build tests and reports fully.

Now pick one part of the code base that either does not have test coverage or needs more documentation and have the developer write one-unit test that asserts what they think the method should be doing major score if they find a failure or bug logic one you owe them beer. Have them assign a code review/merge request, you pair review the request to show them the process for code review and see if they grok the piece of code.

Finally, after discussion and fixing from comments merge the request. The picking should already be decided so everything after that should take 2 hours tops.

I say you now have a professional developer with their tools to produce code installed, tested, working and first commit for them they are ready to get a Story or Bug and start working.