Coders for hire? Perhaps not. "Coding" is a term that has been quickly adopted to describe the (often very well-paid) profession and hobby of millions around the world, likely due to its brevity. However, its terse and increasingly commoditized usage is doing a disservice to the highly educated individuals that are performing the complex, non-trivial work of building today's software systems. So what should the process of engineering a software system be called? Just that:

Software engineering.

You are a software engineer, and you create software systems. The word "coding" traditionally refers to and is derived from the concept of encoding and decoding, the process of taking a concept in one language, presumably a human understanding, and encoding it into a computer language, such that a computer can perform the instructed process.

That's all fine and well, except that it only describes a small fraction of the software engineering process. Building software often involves a thorough understanding of the systems being built on, including memory, performance, and power; it requires coordination across multiple types of systems including storage and network; it fundamentally includes the design of how the computer will go about performing its task, evaluating numerous approaches that may ultimately produce the same result at first glance but each having different long-term trade-offs and consequences. Being able to evaluate these approaches and design the optimal one is precisely what makes software engineering now one of the world's highest-paid professions -- it's hard and requires time, effort, and experience. And reducing its function to simply the act of telling the computer what to do in a language it understands is a gross simplification of the process.

We don't call civil engineers "drawers" even though the final task of their trade is illustrating a blueprint for a structure to be built. You can't just go to an "AutoCAD bootcamp" to learn how to design a bridge. You can go to a "JavaScript bootcamp" to learn how to use a JavaScript interpreter -- but that's likely not your end goal.

"Coding schools", "coding bootcamps", and "learning how to code" are not accurately portraying the curriculum they are teaching. They describe one aspect of it -- the syntax and semantics of computer programming languages, but they (ideally) are also teaching aspects of memory, debugging, compiling, deploying, and anything else required to actually run a program of more substance than "Hello, World!".

"Programming" is a term that does more widely describe the technical process of "creating a computer program", but still doesn't encapsulate the knowledge and experience required to actually create a good one. It more wholly describes the "doing" part of the process, but touches very little on the "thinking" and related aspects. If you ask an API design question in your #programming Slack channel, would that be out of scope? For brevity purposes, the verb "programming" can make sense in some contexts. However as a noun, I highly doubt your organization is interested in hiring "programmers" -- you're looking to employ software engineers, at whichever skill level or product complexity.

This may all seem like pedantry, but it's important that one of the fastest-growing professions of the 21st century takes pride in its craft and avoids inaccurate trivialization. Universities and online courses alike should be more honest about what they're actually intending to teach, and while an argument can be made that software engineering sounds harder and scarier to newcomers than simple coding, a solution isn't to hide its complexity under the rug. Likewise, non-technical founders, hiring managers, and anyone looking to have software built should understand that in 99% of cases, they need to hire an engineer, and let the weight of that need settle in for a bit.

If you produce books, you aren't just a writer. You're an author. If you build software, you aren't just a coder. You're a software engineer.