On various occasions lately, I have again heard product people talk about joining or thinking about signing up for coding classes or bootcamps. Mostly product managers, but also other product-related roles, like marketing folks, salespeople, or designers. And they don’t seem to be alone, looking at the continuously growing number of participants.

I have spent the last 15 years working as an engineer, leading development teams, but also as a product lead, giving me a chance to look at this from different angles.

Here is my take on it, what misconceptions I see behind diving into coding, and why I think it can even be problematic for your work in a product team.

Reasons why product people join coding courses

Let’s look at different motivations that might drive you to consider learning how to program.

You want to change your career and become a software developer

First off, here is a good reason to dip your toe into coding:

I’m seriously considering changing my career, there seem to be so many opportunities.

And before you quit your current job, taking some online classes, maybe building a first project, can be a great way to get a feel of whether this line of work might actually suit you, and if you can picture yourself doing it 40+ hours a week.

And going on to join a dedicated multi-week coding bootcamp, can very well open up a path towards landing your first entry-level developer job.

But, as Peter Norvig famously said,

Expect to put in 10,000 hours before calling yourself an experienced programmer

Keep in mind, that you’ll have a lot of catching up to do, considering that most engineers started coding when they were teenagers.

But what I’m going to talk about are the following bad reasons to learn to program.

You want to learn how to build prototypes

Nowadays this is arguably the worst reason to embark on a long, often nerve-racking journey through programming tutorials and online coding classes.

I want to be able to build quick prototypes to demo ideas for new products or features.

Undeniably, especially if you are a Product Manager, it might be part of your job to explore ideas, demo variants to stakeholders, or gather first feedback from users. You might think how great it would be to build a first version by coding it on your own.

But while there are apparently exceptions to this, in most cases there are simply easier and quicker ways to do this.

In a true design-thinking spirit, you build prototypes “to fail quickly and cheaply.” From sketched paper prototypes to clickable software prototypes, or generating them from your designs, there is plenty of ways to achieve what you need without writing a single line of code. And even if you decide that you need a working MVP, a no-code solution might be all you need.

You want to improve collaboration with your developers

What I’ve heard a lot more from people on product teams motivated to learn how to code, is

I want to have a better understanding of my developers’ job and how they build our product and have more educated conversations with them.

First of all — great idea!

Knowing more about your product and how it’s built will certainly lead to better communication in your team.

You can write better tickets for change requests if you include important details and consider interdependencies to previous features. You can also conduct more educated testing if you know edge cases and how different parts of the application are actually connected. And there will certainly be fewer misunderstandings if you have a deeper understanding and can follow the arguments and concerns of your developers.

As a side note, with today's tools, it's quite tricky to maintain a deep understanding of your product, as I wrote here.

But yes, more insights into your product are definitely desirable.

But is learning to code the right way?

The thing is, well, it probably isn’t.

Why coding skills won’t make you a better product person

Let’s have a look at what you can get out of a coding course and compare it to what your developers do on a daily basis.

What you will learn in a coding class

We’ll imagine you want to take a beginner’s online course for javascript and its’ popular React library, because you heard it’s very popular and building a frontend, so something you can look at and click on, sounds like a great way to learn to code. A Google search quickly reveals some popular educational resources for beginners.

First of all, be prepared that it might feel a bit like this:

But what can you actually expect to have achieved by the end of it? Usually, courses aim to put you in a position where you can build your first own project.

So let’s say you build a guide for the world’s best surf spots.
You will be able to set up the project, build the website with some dynamic functionality — maybe it loads and displays the current weather data from a server — and you’ll learn how to style everything just like you want it with CSS.

Great! You actually built something and it is working — you will never have to miss a wave again!

But the big question is, how does it benefit you in your job?

Your motivation was to understand your developers’ work and the application your team is working on, so we need to have a look at the different aspects of the engineering job first.

The daily work of your developers

Let’s look at a simplified breakdown of the programmer’s job and required skills:

I’ll make a deep dive into these different aspects in an upcoming article for a truly better understanding of your developers’ challenges and the way they actually work. But a quick look at the two main aspects:

1. Coding

The very obvious part of the job is, well, developers code. These are the basic, universally applicable skills on the dev’s belt. It’s nothing project-specific. This is working with the syntax of the programming language, the features of the framework being used, and the capabilities of the platform (read browser, or iOS and Android).

You might be thinking

I got it, this stuff can be super complicated and it’ll take me forever to develop proper coding skills

But this is not my point. In fact, I’m pretty sure you overestimate how hard the coding part is.

Yes, experienced developers obviously know a lot of things by heart, they are fast, and they know how to avoid common pitfalls.

But this can still be the stuff that makes them bang their head against the wall.

And the sheer amount of functions and configurations also means, that even experienced developers still frequently have to copy & paste from other projects and look things up in tutorials, or on stack overflow… it’s even a running joke among developers.

So I’d go on to say, a coding class will probably give you a fair idea of the different things developers have to deal with at this level of their job.

2. Managing complexity

The more sophisticated challenge on the other hand is to ensure that the codebase remains maintainable, extendable, and understandable. This also correlates with how robust your application remains, how easy it is to test it, and therefore how confidently you can release your next update.

This is about turning written requirements into coherent logical specs, structuring the application in different modules and components, and managing data flows. This is the real value-add, and where seasoned developers shine.

But coding classes barely teach you anything about this — this comes mostly with experience. It’s simply not required to get started and to build a trivial, short-term project like your surf spot app.

It’s unfortunate because this part of the engineering job is a lot more relevant to the product team. It’s the more high-level complexity and logic of your app that you all have to deal with one way or the other.

Understanding the different components, how they are connected and how they work and process data in different scenarios paints a very good picture of the behavior of your application.

And being familiar with it helps to explain, test, or most importantly, change and add functionality.

Why coding is the wrong thing to learn

So you might read this and think

Okay, so there is more to it, but at least I’ll better understand half of what my developers do. That already helps, right?

Not exactly.

Coding is actually the part you will rarely talk about in your product team. Sure, maybe you might have stumbled across some specific platform limitations in the past that affected one of your features. But other than that, I have yet to see a product team that discusses algorithms or the most effective memory management.

What you do talk about — a lot — is the current functionality of your application, if it behaves as expected, and the best way to integrate desired changes.

As Jeremy Glassenberg, former platform lead at Box, summarizes it:

“Engineers don’t like when PMs tell them how to code. What you will more likely do is whiteboard with them on a conceptual level what the code is doing rather than the code itself. It’s less about how to code and more about understanding the challenges that come with it.”

So if you want to have more educated conversations with your engineers, a deeper understanding of these aspects would clearly help.

Why you might create friction in your product team

As Jeremy mentions, it’s not a good idea to tell developers how to code. And I’ll go even further and say that it could even be harmful if you develop some initial coding skills and are not aware of the more advanced challenges.

Say you want to display an additional piece of information on one of your screens and one of your developers says

Oh, that’s a bit tricky.

You would be thinking back to how you were struggling to get your first data loaded and shown on a page.

Ah yeah, I know how tricky this can be sometimes.

But as a freshly certified “developer”, you might even think

Well, c’mon it’s not THAT tricky. I could do it. And you must have done this a zillion times.

But you might very well be talking about different kinds of trickiness.

Your developer might be concerned about how your requirements might play with the existing features and the current structural design of your application — not about the coding itself.

This misalignment might be quite toxic for your work relationship.

What actually helps to improve the collaboration with your developers

While basic knowledge of coding won’t help you achieve more effective communication with your engineering team, we have seen that deeper insights into the current functionality probably will.

It can help you to write more exhaustive specs for new requirements, and to more thoroughly verify what’s been built without help from your engineering team.

Here are some things to focus on to generate better product insights and foster better communication in your product team:

Understand details

Invest time to more profoundly understand the details and even more complex wirings of your existing features. Establish a common understanding of different pieces of functionality, and the basics of the technologies and tools you are integrating.

Define and verify test cases

Even if you are not responsible for QA, think in terms of test cases and possible inputs and outputs. Make sure to familiarize yourself with data flows because data will often give you a deeper understanding of what’s happening. Reading lines of code won’t.

Do thorough UI reviews

Inspect your UI and dive into different real-world scenarios, across devices, languages, and user journeys to really understand the complexity of your product.

Invest in product documentation

Try to document things. This can be a tedious job, especially to keep it up-to-date, but providing deeper insights for everyone on the product team can be really valuable.

(UI variations documented on appviewer.io)

Not shying away from these technicalities and details is what will actually make you a better member of your product team, not learning the very basics of programming.

What are your thoughts? Let me know in the comments or get in touch on LinkedIn or Twitter.

Till at appviewer.io

---

Read next:

Product teams, do you know your product?
Findings on how tech teams manage product knowledge and why none of it works. About browsing Jira tickets, Figma boards, application code, and Confluence docs.

---

Photos by Markus Spiske, JESHOOTS.COM, Kelly Sikkema, Headway, Ferenc Almasi, Kaleidico, Ussama Azam on Unsplash