Getting a new developer up to speed is one of those 80/20 tasks: there is an easy 80% that goes quickly, and a hard 20% that takes longer. The easy part is the big picture: what tools the team uses, where the source is, what the build process involves. The hard part is in the details. Coding standards. Preferred practices. How to deal with the inevitable idiosyncratic aspects of any software development process that has been running for more than week.

The usual onboarding practice is to run a new developer through the big picture, point them at a collection of documentation, connect the with a mentor, and let them muddle through the details from there. This is a lengthy process, and learning from documentation is often not the best way to go about it even when the docs are up to date. My own practice has been to encourage new developers to update the docs as they learn from them, so as they discover inconsistencies and obsolete sections they can keep the words in line with reality.

Modern software development tools like Komodo IDE offer a better way of doing all of this. Komodo IDE has had the ability to enforce coding standards for a long time, and that’s already a big step in the right direction, as new developers in an organization will get continuous feedback on preferred practices. Well-thought-out, uniformly enforced coding standards make it impossible to tell who wrote what code without looking at the commit logs. This uniformity makes it much easier to reason about a large code-base.

The human brain can only keep five to ten things in focus at once, and every time a developer has to remember something trivial like the difference between get_foo() and putFoo() something else is pushed out of their attention. Using Tutorials For New Developers The ideal onboarding tool is a set of tutorials built into the development environment, and our 10.1 release of Komodo IDE provides development teams with the ability to have exactly that. Tutorials can access any aspect of Komodo IDE’s workflow, and they let dev teams create a collection of HowTos that will ease the integration of new developers.

Tutorials are living, active, documentation that give a developer who is new to the team an immediate, hands-on experience with the tools they will be using. Tutorials can be referred to immediately from within the day-to-day development environment, and they can be continuously enhanced and maintained to reflect actual team practices. And unlike static documentation, tutorials necessarily follow the “show, don’t tell” rule of good communication.

I believe that documentation ought to be as close to the stuff being documented as possible. It increases relevance and eases the unavoidable maintenance tasks. Putting development process documentation into tutorials that are run right in the IDE is the best way to do this, and helps take care of the last 20% of developer onboarding that can otherwise require a great deal of downstream effort.