What a marketer has to learn to ship software — and it is not syntax

I never learned to code. I want to be exact about what that means, because it is easy to hear it as false modesty and it is not: I did not take a course in a programming language, I did not work through a syllabus, and I could not have written from scratch the applications I have shipped.

What I did instead was start building, and get better with each thing I shipped. Two years in, the question I get most from other marketers is what they would actually have to learn. Here is the honest answer, which is both smaller and stranger than most people expect.

#It is not the language

The thing people assume is the barrier — the syntax, the semicolons, remembering how to write a loop — is the part that has genuinely gone. An assistant handles it, and handles it better than a mid-level developer did five years ago.

But something subtler is also true. You cannot review what you cannot read, and reviewing is the entire job. So you do end up learning to read code — fluently, in several languages — without ever sitting down to learn a language. It arrives sideways, from reading thousands of changes and deciding whether each one is right. That is a real education and it is not the one anybody advertises.

#What you actually have to understand

Almost all of it is operational rather than linguistic. These are the things that will hurt you if you do not know them, roughly in the order they will come up.

That your machine is not the world

The single most disorienting early lesson. It works here and fails there, and the reasons are environmental: a value that exists locally and not in production, a file that was never committed, a version difference, a path that only exists on your laptop. Until you understand the distinction between where you build and where it runs, every deployment is a mystery.

Where secrets live, and where they must never be

Not in the code. Not in a file that gets committed. In the host's environment settings, and rotated occasionally. This is a twenty-minute thing to learn and the consequence of not learning it is the one the internet will remember you for.

Where the data actually is, and who can reach it

Which parts of your application run on somebody's device and which run on a server you control, because that boundary is the security model whether you designed it or not. Anything the browser can do, a user can do deliberately. Anything you check only in the interface is not checked.

How someone gets in, and what happens when they should not

Sign-in, sign-out, sessions, and what a request from somebody who should not have access is supposed to receive. This is where being non-technical is genuinely dangerous, because a broken version looks identical to a working one from the outside — it lets the right people in, which is all you tested.

What your product does when it is wrong

Not whether it can fail — it will — but what the user sees when it does. An application with no considered failure behaviour is not finished, regardless of how well it works when everything goes right.

Version control as a safety net

You do not need to be fluent. You need to be able to see what changed, go back to a state that worked, and understand that history is permanent. Learning this early converts a category of catastrophic mistakes into a category of inconvenient ones.

#You learn this by shipping, not before it

I did not learn any of the above and then start building. Each item on that list is there because it went wrong once, in something real, at an hour when I would rather have been asleep. That is a slow teacher and an unusually effective one, because the lesson arrives attached to a consequence.

The structured study I have done is not in programming at all — AI and agentic systems programmes from Anthropic, from Microsoft, and a generative and agentic AI course from Saïd Business School at Oxford. What those gave me was not implementation ability. It was vocabulary: enough conceptual structure to ask a precise question instead of a vague one, and enough grounding to recognise when an answer is confidently wrong.

#What you bring that is genuinely rare

Marketing teaches you to judge whether something lands — whether a claim is believable, whether a flow makes sense to a person who has never seen it, whether an interface is confusing in a way its author cannot see. Engineers spend years developing that and many never do, because it is not what their work rewards.

You also know what a product is for, which sounds trivial and is not. A very large amount of software is built beautifully and answers a question nobody asked. Coming from a discipline whose entire purpose is understanding what people actually want is not a deficit to overcome; it is the half that has not become cheap.

#The part nobody can do for you

Most of your time will not be spent building. On my projects the research comes first, the building is the fastest phase by a wide margin, and the overwhelming majority of the effort goes into polishing, fixing and auditing afterwards. If you are not prepared for that ratio you will ship a great deal of unfinished software and mistake it for a body of work.

And you have to read the changes. Every one, before it lands. It is the slowest habit I have and it is the reason I can make any claim about what is in a codebase I did not type. It is also, incidentally, how the learning happens — the education is not separate from the discipline, it is the same activity.

So the honest list is: less syntax than you fear, considerably more operational understanding than anyone mentions, a genuine willingness to spend most of your time on the boring end, and the patience to read. None of that requires a degree. All of it requires actually doing it, which is the part that filters people, not the technical difficulty.