Learning To Code: Product Dev 101

A few weeks ago, we welcomed a Computer Science engineer to our product team, and I began thinking about the journey a new hire must undertake. That’s when the germ of this article was laid in my mind. One simple question: How do you morph into a product developer from scratch?

Here I try to elucidate in what I hope are simple terms — the why and how of product development.

Why we program computers?

We want machines to do things we are too lazy or busy to do. We want to delegate unproductive or repetitive tasks.

We started from very simple tasks like mathematical calculations, and we build on top of those.

Computers understand only very simple binary arithmetic, unlike humans who are intrinsically capable of understanding beyond logic.

Building on top of binary logic, we were able to make computers seemingly understand complex symbols, and hence program them using higher-level languages.

Note that even though computers seem to understand languages which have complex symbols other than 0 and 1, they are able to do this because these languages are what we call formal languages. In simple words, these languages are very strict. There is a very specific set of rules which has to be followed in order for the computer to understand it (via interpreters, compilers, and assemblers).

It follows that computers can’t understand what we call natural languages (like English), which humans can because humans are capable of processing non-strict syntax and grammar, and even able to correct errors (unlike computers, which usually just report errors). Using even more complex programs and routines, we are trying to make computers do that using natural-language processing, and machine learning. But these attempts are not nearly as good as actual human intelligence (and probably never will be).

Why we need programming languages?

What do we do when someone doesn’t speak our language?
We either learn theirs, or we hire someone who knows both to help us communicate: the interpreter.

Our relationship with the computers started with the former way. We learned to program in machine language.

At the very lowest level, computers just process numbers. So, we need a way to express our programs (which are a set of sequential instructions that tell a machine to manipulate numbers) so that the computer can understand and execute.

Writing these instructions in binary is hard. Harder than waking up early on a Saturday.

We wanted someone who’d do what an interpreter does. Or, rather, something which would do that.

So, we eventually developed a slightly more programmer-friendly language called Assembly, and a program that would help the machine convert assembly code into binary for execution. We call that program Assembler. I just realized I called Assembly programmer-friendly. I’m not insane; read on.

Since it still was very technical and hard, we developed other higher-level languages using Assembly.

A typical programming language allows you to:

1. Define data and how it is stored (using variables, data types etc) typically in RAM (or registers).

2. Mathematical operators that help manipulate that data.

3. Flow control mechanisms like if condition, loops etc that allow expressing non-linear flow of instructions.

4. Modularity and structuring using procedures/functions/classes and packages/modules/libraries that allow managing code in multiple files.

5. IO operations. While it is enough for a programming language to manipulate data on its own, a truly practical application must interact with external entities like files on disk, network, databases, and the OS.

6. Other goodies
The syntax and standard library make up the rest of what makes a programming language a practical development tool.

How to learn a language?

Learning a language can be broken into three parts:

0. Hello World

Every programming course will probably begin with a Hello World program that just outputs the simple “Hello World” message. This is a great first handshake with the world you’re diving into.

1. Learning the basics

This involves acquainting yourself with the syntax, data types, the operators, the conditional statements, the loops, and the basic modularity paradigm of the language.

A few simple practice problems are enough to get a good enough grasp of these concepts.

Example: a simple menu-driven command line mathematical calculator

A comparative study with a language you already know can help expedite the process.

For example, for someone who knows Java, learning Python by its differences with Java can be useful (as it was for me).

2. Implementation of Data Structures and Algorithms

Implementing Stacks, Queues, Linked Lists, and a few simple DAC, DP, and Greedy Programming algorithms, goes a long way in building on top of your knowledge of the basics and the syntax.

3. A complete backend-driven project

Writing a tiered web-application that communicates with a database, and studying the best practices, dependency management (since you’re going to need a lot of external dependencies to write a practical web-app) will help round up the process of converting your knowledge of the language into being skilled in a platform.

So, that’s it, right? Not too hard; you’re busy browsing StackOverflow, happily hacking away at a piece of Python script to log your friend’s keystrokes; or maybe you’re converting someone else’s logic to code in return for money. It pays bills, right?

But it’s time to grow up.

This may make you a programmer, but that is just one thing you need to be on the way to Product Development. It’s not only about coding. There’s a lot more to practical Product Development. There’s a reason people spend years earning a degree.

What makes me a Product Developer once I know coding?

I’ll try to break down some essentials of Product Development here:

1. Documentation

If you spend more time writing about the code that you’re writing, are going to write or have written, you’re on your way to making your own and your team’s lives easier.

You cannot tell someone to RFTM if the manual doesn’t exist.

As my previous leader used to say, the worst documentation is better than no documentation.

2. Tests

Almost always the most overlooked aspect of the development process, this is the most critical. Testing serves the dual purpose of not letting you make mistakes, and also uncovering the mistakes you already made. Developers are especially bad at testing because testing your own code is hard. But it’s not too hard a concept to grasp: everyone makes mistakes. But you needn’t allow all of them to reach production.

Find them! Burn them all!

3. Collaboration

You don’t develop products in isolation. You may begin alone, but at some point, you’ll need people to contribute. And working on a software as a team is a wildly different beast. You’ll need to learn supporting tools and technology like Git and CI, and also need to learn writing code with a decorum agreed and acted upon by the entire team.

And play nice with the others. It’s still just a piece of code.

4. Ambiguity Resolution

As a Software Developer, if you’re not doing this… well, you’re not a Software Developer. At best, you’re a tinkerer who knows a programming language.

I cannot stress this enough: Software Development is knowing exactly what you’ve got to do.

No, you’re not going to just know.

No, no one is going to tell you everything.

The SRS won’t be sufficient, even if there is one.

It IS your job.

Ask questions. It won’t be wrong to say that the title more suited for a Software Developer is Ambiguity Remover.

Without requirements or design, programming is the art of adding bugs to an empty text file.” — Louis Srygley

5. Product thinking

Finally, once you’re an Ambiguity Resolver, you need to start thinking several steps ahead of software, code, languages, technologies or platforms. Think what your users need, nay — want. Think what you want your users to want.

But above all, think which problems are worth solving.

As a Product Developer, solving technical problems is superseded by ownership of designing the product.

Parting words

Development is not an easy activity. It requires laser focus, and a necessary attention to detail. Probably a good idea to keep a pair of headphones handy.