title

The Issue with Onboarding

We’ve talked before about the two sides of development projects, the abstract idea of how a problem is going to be solved verses the practical, coded implementation, how when one developer has to translate between these roles too often it introduces inefficiencies. What about how this affects working together?

We’ve all experienced bad communications in teams, and CRANQ can help with this, but in this post I want to speak about a less day-to-day situation where good knowledge transfer is key, onboarding.

With established teams, you already share an understanding of how your processes work. When a problem is discussed, you know which parts of the systems are relevant, what the right questions to ask are. As new developers, all this knowledge needs to be built. Often, at a new job we’ll spend our first weeks getting acquainted with the virtual layout, unable to do any work until we know how it would fit in, taking time both from ourselves and from our coworkers.

This is because traditionally, the idea of what a system does is bound to the code. It is not enough to jump into the repo and explore the folder structure; very little is clear to us at a glance. Answering “is this relevant to the work I need to do now?” is difficult, so we spend hours of time when we could be building instead learning the ins-and-outs of things that are not important just to know they are not.

A Better Way

So what’s the alternative? Better filing systems, mentoring from senior developers who can accelerate the understanding of new developers’ and clear high-level documentation all go a way towards making it easier, but none of these are a solution. Is it just a necessity of the job, something we’ll always have to deal with?

No, it is not, but to solve it we have to innovate in the way we develop. That’s where CRANQ comes in. CRANQ is a new development platform pioneering a new way of coding.

Programs built in CRANQ are highly visual and viewable from the top down. They allow you and your team to quickly understand what the program does, before you get down to studying how the code is implemented. This means that you develop an understanding of the program abstractly before taking on the practical parts.

When onboarding as a new developer, we can immediately see how different parts of the program connect, which parts are essential and what needs working on to solve a particular problem, without having to get into the details elsewhere. We can get working without any delay.

For managers, this compartmentalization also means that access is easily restricted. Developers can understand programs without having edit-access, or even read-access, to most of the code, so permissions don’t need to be granted where they aren’t necessary. Better security, with no lost functionality.