Do you want to merely write code, or craft groundbreaking software that transforms the world? That was the question I asked myself at the age of 11. And I found later that a lot more people want to know the answer to that.

The usual “normal” path to programming

I start coding at the age of 11. The usual path was you went online, searched for tutorials on how to build something, read through it, and copy-paste code that did what you wanted. However, there was a very big problem with this approach. I never understood what HOW the software was built, because someone else already wrote the code.

If you don’t quite understand the process, you suffer from 2 different inabilities.

1. You are not able to change what you have built in any meaningful fashion. For example, consider that I built the To-Do List app that lets me add and remove items. Then, I’m not able to change it to add a feature like “task priority” on my own.
2. You are not able to use the knowledge gained from creating that one thing to build something else. For example, calculating the factorial of a number has a lot in common with recursively going through a directory trying to find a certain file. These both look very different as a problem domain, but algorithmic idea is almost identical.

While I’m able to see the similarity in the algorithmic ideas, a newcomer might not. The usual mistakes that tutorials of today make is that:

1. They focus only on the code. They tell you to copy different things, but never quite explain the thought processes behind those things. You’re seldom shown generalizable ideas that can be used outside the example being given.
2. A lot of tutorials are copied from other tutorials. Thus, they only “see” the code, but are not able to see the intention of the original author. If these copycats don’t know it, they can’t tell you.

The right path to programming

The right way to programming would include not just showing the person code, but also teaching them the thought processes behind the code. Real-world software engineering is not a clear-cut science, but an art.

And like any art, there are some rules that are hard and fast, and many that are flexible. It requires you to make a lot of decisions in each step on incomplete data, and later learning from the outcome. It’s an iterative process.

It could happen that you decided to use Sqlite for a project, only to later realize that it will not quite work out. At that point, you have to go back to the drawing board. And that’s fine!

Thus, a good tutorial should do the following:

1. Show code as an example, so that things are not abstract.
2. However, show the thought processes behind each of the decisions. If something was a guess, tell the reader that it was a guess. Not everything is a hard-science decision. A good software is never built on the first try.
3. Summarize the general ideas so that the reader is equipped to apply them to their own projects, whatever those projects might be.
4. Teach only things that are required in the real-world. Too many tutorials focus on abstract things that no one really uses.

Without learning general ideas, you’re always hopelessly dependent on someone else to iron out the code. And that’s not a good state to be in for your career growth.

Enter: The Value Artisan

In my over 2 decades of programming, and my leadership positions in different startups, I’ve learnt to not just build good software effectively, but also build ones that are valued.

Too much of the programming knowledge floating around on the internet is just plain junk; they don’t help you improve as a programmer. On the other hand, all the important stuff is usually missed, because many supplying these tutorials seldom have appreciable real-world experience.

I’ve mentored many software engineers one-on-one, but it’s usually only possible for me if that person works with me on projects. The best learning happens when you’re building.

The 2nd best thing that I can do is write down whatever I’ve learnt in over 2 decades of building software. Things that work, are important, and can make the career of anyone who masters them. And I wanted to not just provide “code”, but also explain my thought processes behind them.

If you copy someone else’s solution, that solution might not be pertinent to your situation. However, if you can learn the thought process, then you can apply it to your unique situation to find your own unique solution. And that’s how you end up getting paid a lot for your expertise.

Thus, the intention of The Value Artisan is to give startup software engineers all the thinking tools and capabilities to make them successful in their career. People who will not just write code, but build software that creates value. I’ll call such a person, “The Value Artisan,” because above all else, that person creates value for the rest of the world.