Mind Your Head
Explore how adopting a creative mindset and the Kaizen philosophy enables continuous improvement in programming. Understand the difference between reactive bug fixing and envisioning a better future state for your code. Learn how to maintain a positive attitude and inspire others to innovate, helping you grow personally and professionally as a software developer.
We'll cover the following...
In the 1990s, Bare Bones Software released a text editor called BBEdit with the tagline “It Doesn’t Suck.” It retains the tagline to this day. It was a brilliant marketing strategy. Who’s their market? Programmers.
Programmers can be pessimistic and sarcastic. Many will tell you about 100 things that don’t work for every one thing that does. The highest praise a programmer will often give a product is, “It isn’t terrible.”
Pessimist programmers are in good company. According to some reports, the vast majority of projects fail, around 80 or 90 percent. It’s not that the good 10 or 20 percent succeed; it’s some hodgepodge of good and bad. It almost seems that bland products are more successful, on average, than really good ones. When a programmer says a particular product is not up standard, chances are they are right.
Balancing the odds
When we shift our perspective from “It’s terrible” to “Wouldn’t it be cool if,” we shift from a defeatist mindset to a creative mindset. The best we can do from a it’s-terrible attitude is create something that is slightly less terrible. With this attitude, we can create something completely new.
Creating new things is a practiced skill. Starting from school, we’ve been trained to follow examples and create small bits of new work. With practice, we’ll create larger works and also deviate further from prior examples into work wholly of our own imagination.
Our rate of learning is largely determined by how much we want to push ourselves, and that push comes from our attitude.
Structure for creation
In the book, The Path of Least Resistance, Robert Fritz identifies two structures to interact with our world.
Reactive/Responsive
Reactive/responsive is our default structure, where we react to circumstances. To a programmer, for example, it might go something like this: we want to reduce the number of bugs in the product (responding to testers), and likewise, we want to get the product out the door (responding to management pressure). In such a scenario, we will make fixes that are good enough to fix the bugs without jeopardizing the schedule.
This is also known as a fire-fighting mode. We may put out the fire today, but we never get around to addressing systematic, big-picture problems in the product.
Creative
Rather than immediately responding to present circumstances, we acknowledge the present state and visualize a better future state in the creative mode. For example, we visualize a more modular product and, therefore, a product easier to test and reason about. Guided by this creative vision, we will go into the code looking for opportunities to make it modular as we fix the bugs.
What’s the difference? In the long run, the reactive/responsive bug fixing will leave us with a codebase that’s even more difficult to maintain than when we started. The hard bugs will just be patched over, not fixed. On the other hand, in the creative structure, we have a guiding vision that will improve the code base—including the hard bits—over time.
Creating a vision both creates and requires a positive attitude. We can’t create anything out of pessimism. It also requires hard work to bring that creative vision into reality, but the work is no harder than what we’ll be doing anyway. The bonus is that when we’re driving toward a vision of a better future, the hard work is fulfilling in a way that we don’t get from reactive work.
Evangelism
The next level of creative vision is bringing others along for the ride. In the early stages of our career, we may be on the receiving end of technology evangelism. It’s tremendously fun to believe in what we’re doing. Later, we can create and evangelize on our own.
Evangelism is tremendously underrated in the technology world. People think of computers as, well, boring machines, so what’s there to get excited about? But think about the early, wide-eyed play with computers: didn’t we dive in with vigor and passion? Of course, and that’s why we’re here today, reading this course.
An evangelist reignites that passion and directs it to a vision of something new and extraordinary. (It may be a vision that would be profitable once created, but the focus of evangelism is more about the spirit than the dollars.) This isn’t just the job of CEOs and marketing teams. Programmers can be just as talented at technological evangelism as anyone. There’s absolutely nothing deceitful about technological evangelism; it’s just painting a picture of a better future state so that others can understand it and believe in it. Terence Ryan’s is a great resource for learning this skill. Guy Kawasaki, one of Apple’s early evangelists, gives an overall view of evangelism in his book Selling the Dream.
Now “It Doesn’t Suck” doesn’t seem like such a brilliant product tagline after all, though it still might make people laugh. Think hard about the reputation we want to establish. Visualize and create you five years from now. Are you the naysayer, or are you the one inspiring people to make something cool?