There are many ways to look at programming. Some people do it to make a living. Others want to see things working fast and hack it away. Others believe in building a profession from programming and thus seek practices and submit themselves to challenges that expand their views.
It’s very easy to pass judgement on some of these attitudes. I will not do that. People need to live, to support their families, to feel good while working. If anything, we should be happy that we, programmers, have opportunities other people don’t.
Instead, I will present my view on programming. A view shaped by a 40 years love story and a few key events. A view that I feel is shared by a very small minority of the community. I am encouraged to present this view by tweets from the recent DDD Europe conference.
Here’s my view:
I am a designer who happens to use code
Learning from other designers
I am a designer because I build upon the tradition, the practices, the techniques and the principles of design, a discipline that’s thousands of years old. I do this by reading, analysing and adapting techniques used by other designers.
“Design” is an overloaded term that causes confusion in software development. It has at least three meanings: design as result (as in “the design of the application is easy to change”), design as process (as in “I designed it using Test driven development”) and design as aesthetics (as in “I love this design”).
A clear vocabulary is the sign of a mature profession. Therefore, as an effort to advance our profession, I propose fixing the confusion using a more precise set of terms. You’ll find a glossary at the end of this blog post.
In my previous post, I set out three problems that I believe software crafters worldwide should work on in the years to come to fulfill the promise of “raising the bar”. This is a quick update on its aftermath.
In 1900 David Hilbert challenged the best mathematical minds to solve 23 problems. This set of problems has influenced the mathematics of the next century, leading to surprising discoveries. Probably the most shocking discovery was that axiomatic systems have inherent limitations.
Today, a different set of very bright people face a new era. 7 years of Software Craftsmanship has led to changes in the world of software. I can travel almost anywhere in Europe and find a community connected to software craftsmanship. People from the community authored books and articles. We stay in touch all the time thanks to modern technology such as slack, twitter, facebook and meetup. Local communities and companies organize conferences. And a brave member of this community started a newsletter, trying to guide us through the news in the field. We share what we love and we love to share.
I had a wish starting from 5th grade: to publish a book. A wish finally fulfilled this year when my first book, “Usable Software Design” became available on leanpub.
But this is not a blog post about the book per se. It’s not even meant to convince you to buy it (although you should). It’s more about convincing you that you have to publish your own book. It’s fun, it helps you discover yourself, and you might make some money from it. Seriously, start today. And if you think that you can’t, or that you have nothing to say, or that it won’t make money, etc. then read on, because I’ve been there too.
Adapt to Your Constraints and Preferences
Creating anything is hard. But it’s not hard where you expect.
Contrary to what most people think, ideas are easy. Ideas are everywhere. Inspiration is everywhere. Ideas pass from mind to mind and adapt to the recipient’s personal experience all the time. More ideas combine into a new idea. Ideas are easy and cheap and don’t account for much. Execution is what makes ideas valuable.