Writing Code is the Least Interesting Thing I Do

What value does an analyst bring, if not writing SQL?

** None of this was written by AI** ;)

The barrier to entry for writing code and pulling data has nearly dissolved for any business that allows their employees to use AI with their code / data. Many data professionals are watching this data free-for-all with a sense of horror.

A lot of posts have cropped up criticizing AI-generated code and how accurate it is(n’t), and fiercely defending the job of the SQL-writing data analyst. I think they’re missing the point.

Writing Code is the Least Interesting Thing I Do

I was recently talking with my manager about what value our team provides, and here’s a screenshot from that conversation.

Anyone talking about how AI is going to take our jobs because of its ability to write SQL (even from a messy database) - is focused on the wrong thing.

I think a lot of non-data people think that the meat of what we do is writing code, because it is the most unique and obvious thing that a data analyst needs to do.

I agree with those people - AI is going to take away the job of writing SQL. It has already taken it over a lot from my day-to-day!

Watching this wave of people in non-data roles get their hands on AI and suddenly not need an analyst to write their code anymore has got me thinking.

What makes me special? Why is the data analyst still an important role, when someone without a data background can have AI write their code?

Arguing that humans can write code better than AI is essentially a non-starter.

The person who is using AI to write 100% of their code is likely producing a ‘close to correct’ output 10x faster and 5x prettier than the person who is droning on about semantic layers and blah blah blah.

But I actually think the other things I have been trained to do are way more interesting than just writing code, and I would much rather spend my energy defending my right doing those things.

End-To-End Analytics

My argument is that being a data analyst means creating end-to-end analytics projects, and writing code is just a small slice in the middle.

In fact, I think a good data analyst is essentially a data product manager and most projects we deliver are data products that we managed from inception through delivery.

A good analytics project begins with a problem, or a question. “We don’t have endless resources for hosting webinars. Should we focus on AI, or CI Pipelines this month?”. Or “Traffic is down to our website, which is where conversions happen. Why is that happening?”.

My job starts there. I need to have:

• A good enough relationship with stakeholders that they trust me and want to come to me with their problems.

• Business context so I can talk with them about their problem and how we might use data to solve it without ever mentioning a table name or the word(s?) SQL.

• An understanding of how data & projects work within the organization so I can give an estimate of what is realistic, what we have data to report on, and timelines.

Next comes scoping. Data analysts learn early in our careers that if we don’t scope a project well at the beginning, it will either blow up into a multi-year problem, and/or nobody will ever actually use the output.

So we scope the project, and we specifically make sure we are building something that solves a problem, it is something stakeholders actually want, and it will be delivered in a place/ format they can use.

Next comes the building. Writing code happens here! But it’s actually more complicated than that.

Where is your code going to live? Do you need to merge the code into your central code base? Should it really be calculated in the prep layer? Does anyone else need to be able to reuse the code you’re writing?

Claude is not good at existing within a shared system, because the ‘system’ often consists of the institutional knowledge that is the hardest to enforce. It is exceedingly easy to write code with Claude, make Claude skills, even make your own vibe-coded apps.

Why look for documentation on shared practices when that is the case?

I also find that it simply takes time and experience to have good judgement when it comes to the outputs that AI is giving you.

I can tell now when a response from Claude was way too easy, or conversely, way too complex. But that comes from my familiarity with SQL / our database and having an expectation of generally what I am expecting.

Inevitably, building any project is complicated because you’re almost always going to run into things you didn’t expect. Maybe someone else was supposed to deliver something and got delayed, and now you are blocked. Maybe the requirements changed. Maybe the data turned up some surprises.

It’s part of my job to be able to navigate those things that come up while maintaining good relationships, managing scope-creep, and staying on track with what the business needs. And the ability to do all of that only comes with experience and hopefully a good manager along the way.

Once the work is built, it’s time to deliver. Here’s where junior analysts screw up the most. It is tempting to try to deliver everything. Why wouldn’t your stakeholders want to see every metric at the same time?

It’s my job to deliver something useful. Sometimes that means I deliver an alert instead of a dashboard. Sometimes that means I deliver a one-page dashboard with a relatively small amount of information on it, because everything else is just noise. Other times I deliver a complex output, but carefully optimized to be used by a handful of specific executives.

I see AI get lost here a lot. The internet is full of criticisms from people who will “never use AI because AI is taking away our ability to think”.

You can get overwhelmed with the ability to deliver so many things in such a short period of time that it’s easy to lose track of what you should deliver, and why.

Some projects end at delivery. But most of the time the work is nowhere close to done. Delivery often kicks off a process of feedback, iteration, and eventually - monitoring. I try not to create things that are going to be abandoned in a few months.