🛳️ How to learn frontend programming as a PM
Just enough to be conversant with an engineer. It's not as hard as it sounds!
In last week’s newsletter issue, I explained why it’s important for you as a PM to have some basic competency in writing code. In this issue, I focus on one particular area of modern software engineering, namely frontend programming. Most professional software engineers have at least some baseline skills in frontend programming. Specialists in this this type of programming are called frontend developers.
In recent decades, the web has become the predominant place where people consume information, communicate with each other, and do business on a day to day basis. Even if you work inside a company where your digital business tools are isolated away from the public internet, they are nonetheless typically still “web apps”, in the sense that that they work inside your web browser, served from a private intranet. Consider your typical work day. How often are you using a desktop app on your computer, versus doing work inside of a browser tab? Even traditional desktop apps like email, word processing, and spreadsheets, have versions that work inside a browser nowadays.
So as a PM, it’s very likely that the digital products you ship in your career will often have a web component, if not totally created in a web context. In other words, the majority of digital-enabled business value delivered today in the world economy is via the web. As traditionally non-tech industries like healthcare, finance, manufacturing, and retail increasingly become digital-enabled in the coming decades, they will require software solutions, and a lot of these will be delivered on the web as a platform. There are of course other technology platforms such as hardware and emerging ones like IoT (internet of things). But these sectors are not growing as fast. So especially if you are a non-technical PM by training, it’s wise to at least get some basic understanding of web technologies, as a way to future-proof your career.
What about mobile?
It’s true that mobile has emerged as the dominant technology platform for consumers in the past decade. So there are indeed many PM jobs that require some knowledge of mobile technologies and how to create mobile apps. But if you are not working on a mobile product now, and don’t have an explicit career goal to do so, I would focus on web first. The mobile market will continue to grow, which includes both smartphones and tablets. But the market for enterprise apps, i.e. tools that you use inside a company, is unlikely to deviate away from web significantly in the coming years. And it will actually grow. In other words, there is a growing market of web apps to help business users sitting in front of their computer, do their work. With trends like automation, knowledge work is only increasing. So at least for the next decade, more folks will end up using business tools on a desktop computer, and these will be web apps.
More interestingly, there is a growing trend to build mobile apps using web technologies. This is precipitated by companies wanting to ship mobile apps with developers who already have frontend skills, as well as broader technology architecture reasons. In sum, just as a frontend developer often already has a head start in building mobile apps, as a PM who knows frontend programming, you’ll have a head start in knowing about mobile technologies. So prefer learning frontend programming first, all other considerations being equal.
In the early days of the internet and the web (or the “World Wide Web”), computers would send each other simple text. These early pioneers wanted a way to provide more richness beyond raw text; for example, to indicate paragraphs or headings in a document. A browser would display this text in a web page. Importantly, folks wanted a way to link web pages with each other. (This is something you probably take for granted nowadays, such as when you get sucked down a Wikipedia rabbit hole. This invention of hyperlinking documents together to organize information was groundbreaking at the time.) HTML (Hypertext Markup Language) was invented to support these use cases. “Markup” languages in computer science get its name from “marking up” a physical document with annotations, such as when a teacher marks up an essay homework assignment. Today when your computer browser downloads a web page, it “parses” (which just means the computer “reading”) the document, looking for pre-defined HTML tags that mark up the text, and “renders” (displays) the content in your browser tab, accounting for the HTML tags. For example, if it sees the anchor tag, it will render the associated text as a link, which you can click (or tap) to visit another web page.
HTML was invented to annotate content, but not to determine how it should be styled when displayed. That should be determined by the browser on your computer. For example, should links be underlined? Should they be blue? Or purple? HTML was quickly abused to allow web page designers to style how they should look. (And to a certain degree, it still happens today.) CSS was invented in this context as a first class solution to solve the problem of styling content, instead of relying on HTML, which was not invented for that purpose, and thus not optimized for it. CSS or Cascading Style Sheets, allows web page designers a unique language to style existing HTML content. HTML and CSS go hand in hand. It’s “cascading” due to a mechanism whereby the designer’s rules cascade down, like a waterfall. (It becomes obvious once you learn it.) In the simple case, your browser downloads a web page HTML file and an associated CSS file at the same time. The browser uses the CSS file when parsing the HTML file, rendering the content in your browser tab according to the rules in the CSS file. For example, the CSS file could say links should be displayed in magenta and underlined, and that paragraphs should have 10 pixels of margin at the top.
Contrast this with desktop apps on your computer or apps on your phone. In those scenarios, you first download and install an entire app onto your device. Most of the logic already exists as bits sitting in your device. When you open the app, it may pull in some data remotely from the internet. But by and large, the functionality already exists on your device and is running there. In a modern web app, you are essentially downloading an “entire” app in a real time when you visit a URL in your browser. The browser “runs” the app immediately. Once you close the browser the app, the app disappears from your computer (this is mostly true, ignoring some technical details). Therefore, there’s no notion of “installing” a web app.
Modern web frameworks
Web frameworks are notorious since there’s so many of them, with many passionate communities arguing why their particular framework is better than others. As a PM, you should be aware of the more popular ones. These include React, Angular, and Vue.
How to learn frontend programming as a PM
This overview of frontend programming may seem overwhelming. But know that that’s precisely why software programming is a well-paid profession, and that there’s specialists who just do frontend programming. It’s a deep technical field that requires years of experience to build quality digital products. But as a PM, frontend programming is still very accessible, especially knowing just enough to make you an effective PM, as explained in the previous newsletter issue. To that end, here are few principles to consider when planning what to learn and how to learn.
Hands-on learning is the best learning: Your primary goal should not be to understand intricate computer science theory and definitely not the mathematical foundations of programming. You should know practical skills in order to be conversant with a frontend programmer. That means getting your hands dirty. Fortunately for programming, especially frontend programming, most tutorials show you step-by-step to get an app up and running right away. When you look for a tutorial, find one that focuses on setting up your development environment and getting that “hello world” program working right away.
Video tutorials are great for beginners: When learning difficult technical topics, having a person speak to you humanizes the material, often making it easier to comprehend. Video tutorials are great for this. Especially if you have very little technical background, you should have a human walking you through some basic steps. If you start with a written tutorial instead, it may be a too overwhelming. Video tutorials are slower yes. But if you are just getting started, you want to go slower. As you get more comfortable, you can move onto written tutorials. YouTube has plenty of great content. But because videos there are usually free, they may be outdated or generally of lower quality. I recommend investing in a paid and high quality course on a platform like Udemy, taught by folks who often are teaching full time. Be sure to also read the reviews when picking a course.
Learn one modern web framework: You only need to learn one modern web framework. Especially as a PM, since you don’t need to know the details, once you have a good understanding of the principles of one modern web framework, you can readily translate that learning to another framework. For example, suppose you learn React since your current team uses it. If the next team you join uses Vue, you’ll still be in good shape.
Learn what your team uses: This one is obvious. As a PM, the most immediate purpose of learning technologies, and web technologies in particular, is to be able to do your job better, and that starts with your current job. So you probably want to bias toward the web framework that your current team uses (hopefully it’s modern!). And once you’re comfortable with that you may consider learning others, as a hedge against working in other teams, within the same company, or in another company.
Caution against getting help from engineers: Unless an engineer colleague is an expert at teaching non-technical folks, caution against getting help from them, especially at the beginning. They aren’t geared toward explaining things to non-technical folks, so you might end up getting more confused. It’s not their fault. Just be wise in who to seek help from.
🤔 What should I write about in the next issue of Product Management 101?
Reply to this email and let me know!