I didn't start learning software development because I wanted to change careers.
I started because I was tired of solving the same problem in five different tabs.
My day job is in performance marketing. Campaigns, lead quality, conversion tracking, CRM workflows, reporting, and the conversations that eventually turn an inquiry into a customer. From the outside, that sounds like a collection of marketing tools. In practice, it's a collection of systems that rarely agree on what happened.
And at some point, I stopped asking which tool we should buy next and started asking whether I could build the missing piece myself.
The campaign wasn't the whole story
Imagine this fairly ordinary journey:
Someone clicks an ad. They fill out a form. The lead enters a CRM. A salesperson follows up. The customer asks questions on WhatsApp. Weeks later, a deal might close.
Each system can tell you something about that journey. None of them necessarily tells you the whole story.
An advertising dashboard knows what a lead cost. A CRM knows who owns the lead and which stage they're in. A messaging system holds much of the actual conversation. A spreadsheet might be where someone finally tries to connect the dots.
You can run a successful campaign and still have no easy answer to a basic question: Did the people we reached become good opportunities?
That question sent me further into software than any programming tutorial did.
I wanted fewer handoffs, not another dashboard
At first, the fixes were small.
A report that pulled the same numbers together without copying them by hand. A CRM rule that moved a record when the right conditions were met. A script that flagged something a human should check instead of waiting for someone to notice it.
Then the questions got more interesting.
Could we see what was happening across sales conversations without opening every individual chat? Could an internal tool give people the context they needed without giving everyone access to everything? Could we make the customer experience less dependent on someone remembering which system to update?
Those questions led me into APIs, data models, web interfaces, permissions, and eventually mobile apps.
I didn't approach them like a software engineer designing a grand architecture. I approached them like a person trying to get through Tuesday without losing track of a customer.
That distinction matters.
A technically impressive system isn't necessarily useful. A useful system takes one painful piece of work and makes it boring.
Marketing turned out to be a surprisingly good place to learn engineering
Marketing teaches you to think in sequences.
An impression becomes a click. A click becomes a form submission. A submission becomes a conversation. A conversation might become revenue.
Software makes you ask what happens between those steps.
What if the webhook is delivered twice? What if the CRM owner changes? What if the messaging service disconnects? What if a date is saved in one time zone and displayed in another? What if the dashboard says "success" but the underlying operation never completed?
These aren't abstract edge cases when real people are relying on the system. They're the difference between a workflow that works in a demo and one that survives a normal workday.
I started paying more attention to error states, retries, logs, and permissions than to how impressive a feature looked on a screenshot.
Maybe that's the biggest shift: marketing asks whether a process converts. Engineering asks whether it behaves correctly even when the happy path breaks. You need both.
AI made building faster, but it didn't make judgment optional
AI coding tools changed how quickly I could move from an idea to something testable.
I could describe a workflow, inspect a first implementation, see where it broke, and iterate without spending weeks getting comfortable with every library involved.
That speed is real. So is the temptation to confuse speed with reliability.
An agent can generate a plausible integration that handles the main use case and quietly ignores duplicate events. It can write a dashboard that looks polished while the underlying metrics are defined inconsistently. It can automate a browser without knowing whether the last click really saved anything.
So I developed a different habit: ask what can go wrong before asking what else we can add.
I want to know what the tool is allowed to touch, what happens when it fails, whether we can verify the result, and how to reverse a change.
AI can help me write and understand code. It cannot take responsibility for the business process on the other end of that code.
The most valuable automation is often invisible
There's a certain satisfaction in building something flashy. I get that.
But the automation I'm happiest with is usually the one nobody talks about after it's deployed.
A record reaches the right person. A status stays accurate. A notification appears only when someone needs to act. A report answers the same question every Monday without anyone rebuilding it from scratch.
No one opens a meeting by celebrating the absence of a broken workflow.
That's probably a sign it worked.
It also changed how I think about buying software. I still use plenty of existing products, and building everything yourself would be a terrible use of time. The goal isn't to replace every subscription with a custom application.
The goal is to recognize the gaps that matter enough to fix.
Sometimes that means configuring a tool properly. Sometimes it means a simple automation. Occasionally it means writing actual software.
What I'd tell someone starting from a non-technical role
Don't start with "I want to learn to code."
Start with a recurring problem you understand unusually well.
Write down what triggers it, which systems are involved, what the correct result looks like, and how you would know something went wrong. Try to make one part of it easier. Measure whether that actually saved time or improved a decision.
Only then decide whether you need an API, a script, a database, or a whole application.
You also don't have to become the person who builds everything alone. Knowing enough to frame a problem clearly, evaluate a technical solution, and work intelligently with developers is already a powerful skill.
For me, learning to build has made me a better marketer because I understand more of the machinery behind the numbers. Working in marketing has made me a more practical builder because I'm constantly reminded that a feature is only valuable when it solves somebody's problem.
I still work in marketing. I also build software.
These no longer feel like separate parts of my career.
Top comments (0)