Everyone's a Maker Now

Everyone’s a maker now.

Everyone’s a maker, everyone’s a project manager.

If you’ve ever worked in an engineering team then you might recognise this trope: engineers only respect other engineers. Everyone else is just in the way of them writing their beautiful code. Designers add unnecessary frills, stakeholders ask for features that suit the business and their customers rather than what can be solved in pure code, and project managers demonstrate a pesky insistence on asking ‘when will it be done?’ like they don’t know you’re a genius and it will be done when it’s done and you get to decide what done looks like.

That’s all changed with the advent of coding assistants. The old order is crumbling. Roles are dissolving. The “us and them” between engineers and “the business” lines are being erased.

Now everyone who wants it has got access to an engineer that never gets tired, never questions ‘why are we doing this?’ and never adopts that patronising “I would explain but you wouldn’t really understand” expression on their face.

Did I say engineer? I meant teams of engineers. Now it’s possible to harness multiple coding assistants together. You’ve got a development team all waiting for your instruction.

Engineering skills just moved up the stack. It’s not about understanding the code, it’s about giving clear instructions so someone, or rather some thing, can write the code.

Everyone’s a maker now. The old gatekeepers are dead. That senior engineer who only wants to find reasons not to do the work? You can bypass that guy. Coding assistants give you the option to explore multiple approaches to solving the same problem. 

You’ve got options now. Explore building it in node, Python, hell you could even ask it to use Perl or Erlang and it won’t answer back with a “nope” or a “why”. It’s all “sir yes sir” unquestioning compliance.

Of course it’s not easy, if it was, we’d all be doing it.

That unquestioning compliance means it will literally follow your instructions. If you don’t get the instructions right, it cannot get the output right. It does not think for itself.

You’re still responsible for the code your assistants create under your instruction, same as you were when you hand typed it into your IDE or editor of choice. All the choices were yours, you are the “single wringable neck”.

You don’t have to look under the hood as long as the code you write is air-gapped from the rest of the production environment. Coding assistants in the hands of non-engineers work best to deliver a proof of concept or demonstrate the art of the possible. For anything else, there’s still the requirement to integrate into production and non-functional requirements like security, will it scale? persist.

But everyone’s a maker now. It’s hard to put the genie back in the bottle once you show people something they want or value. And, token cost aside, it’s cheap to explore and iterate towards a Minimum Viable Product.

You just have to learn to give instructions. Like Einstein said, if you don’t know it well enough to explain it in simple terms then you don’t know it well enough.

The new engineers are project managers, technical writers, and people with a dream. The most successful right now are the ones who most effectively learn to talk to a machine to get what they want.

Learn how to decompose a problem into its atomic parts, spend time organising those parts into a logical build sequence, think about the relationship between the parts and how to manage them so they’re only coupled enough to get the job done together. 

Learn by doing. 

The old ways are dying, the new order is yet to be defined. There’s opportunity in the chaos if you want to look for it. 

Because everyone’s a maker now.