Hiring Low/No-Code "Experts"

Show and Tell
1

A classic from the community formerly known as the Airtable Community, this piece deserves a home where it can actually be found. I left in the original links to Goldbergian Buffoonery, and such a search in the new Airtable Community reveals nothing; I think I was censored. This link might be insightful, though.

I tend to work in the Kuiper belt of complex and challenging integration projects at scale, but I’m not isolated from occasional simple problems where I can learn something while helping others. I also advise many investment groups and companies concerning the bets they place in no/low-code systems and vendors.

With vast experience in fishing woefully architected systems from a cesspool of low/no-code Airtable Goldbergian buffoonery, I feel compelled to offer this advice if you are seeking the right person to lead the development of your future Airtable tech stack.

An appeal to candidates who are low/no-code “experts” is risky because it will entice and attract people who have many skills that have done some amazing things with Integromat, Zapier, and other platforms. But there’s another side of no/low-code power users that may result in the creation (or expansion) of costly, unreliable, and largely unsustainable processes. Some of these candidates seeking work will be ideal; most will not.

This is not to say that low/no-code solutions are impractical or lack investment worthiness, but it is an indictment of the skillset of the typical power-user who has been empowered by the various glue-factory vendors that offer magical and enticing ways to marry systems, data, and events.

In many cases, these application adhesives are a dance with the devil and lacking a deeper understanding of data modelling with a clear focus on the application architecture, there will almost certainly be surprising but sometimes very disappointing days ahead for your solution.

My advice - set the bar a little higher by looking for evidence the no-code/low-code candidates are clearly planning and building solutions with strategic, scalable, cost-effective and serviceable scepticism.

Ask them simply to define “technical debt” or explain the nature of a Goldberg Machine and how to avoid the pitfalls associated with complex dependencies.

I’ve learned that there are two types of no/low-coders:

  1. Those who understand the nature of technical debt, but tend to do everything possible with glue and duct tape to create the best outcomes given the constraints.
  2. Those who only want to see it work (sometimes just once) and get paid.

Your appeal for help should try to slam the door on candidates who are type #2.

Just sayin’ …

3 Likes
2

When the only tool you have is a hammer, every problem looks like a nail. One danger of using a no-code developer who doesn’t know code, is that you may end up with a no-code solution when a coding solution would work better. One danger of using a code-based developer who doesn’t know no-code is that you may end up with a coding solution when a no-code one would work better.

It also is really hard to vet the quality of a developer. Degrees and certifications are poor proxies for actual knowledge as it is possible to self-teach both code and no-code. Using specific vocabulary, such as asking a candidate to define “technical debt” is also problematic. A self-taught developer may not have encountered that particular phrase.

Another possibility is to ask a candidate about a real world situation when the candidate had to go back and update/maintain/improve a complex system that he or she first created years ago. That will tell you an instance of how the candidate actually handled technical debt.

3

I think this distinction applies to code-based developers as well as no/low code developers.

Here are some potential reasons why no/low-code developers might have a higher percentage of “as long as it works” mentality compared to coders.

  • Bill doesn’t interact with novice coders much so he doesn’t see them as often. Plenty of new coders (and their clients) are happy with code that currently appears to produce the correct output.

  • No/low-code developers tend to be self taught, so they are less likely to have teachers and mentors who emphasize the importance of clean, maintainable logic.

  • No/low-code development can produce big effects with quicker development time, so people spend less time creating them and encountering issues along the way. If it takes a few days to build a system, the developer can hold everything in working memory, but as the development cycle stretches into weeks or months, it is harder to keep all the pieces in working memory and the developer naturally has to have better code in order to stay afloat.

  • No/low-code has not been around as long, so less technical debt has come due, so developers are less aware of it.

4

Bill doesn’t interact with humans much.