Enter “Will AI Replace Programmers?” Into Google and you will find a variety of articles with differing opinions on the question. The consensus seems to be that it will eventually happen. After all, according to most articles, much of what programmers or coders do is “tedious and redundant work” that could be done by an AI. Whether you believe this is going to happen tomorrow or 20 years from now, the fact that Google, IBM, Microsoft, Facebook and many others are actively working on developing AI that can code is evidence that coding is viewed by many in the business world as an over-priced commodity. Never the less, according to the U.S. Bureau of Labor Statistics, the demand for programmers is expected to continue to grow in the coming decade as software continues to “eat the world” and demand for programmers continues to outstrip supply. This is yet another reason why companies are focusing on developing AI that can code.
So if you are a programmer, what should you do? Well if you don’t plan on retiring in the next ten years you need to start thinking about the value you provide and how to avoid becoming a commodity that can be replaced by software. Of course, you could focus on writing the code that powers AI (the irony is so rich), but that is simply delaying the inevitable. You could learn to leverage AI to write better code. But again, that is also just delaying the inevitable. I believe that to stay relevant and valuable, coders need to learn to think like creatives and entrepreneurs. That’s not to say that many coders don’t already think like creatives and entrepreneurs, but those skills aren’t necessarily rewarded when you have the job title of programmer. As AI gets better and better at coding, programmers need to get better at leveraging software and AI to create solutions that enrich people’s lives and create a better future. This will require a mindset shift away from solving problems that are purely technical or code-related in nature toward solving problems that require a broader perspective. Many of the problems we are facing today and that the next generation will face in the coming decades will require out-of-the-box creative thinkers who also understand software and technology. For some programmers, this is going to be a stretch. After all, you became a programmer because you love to code. But I believe, like IDEO, that everyone has creative potential. I believe that as software and AI continues to “eat the world,” coders need to tap into their creative potential to learn how to leverage software and A.I. to change the world.
I would love to hear your views and opinions on AI and coding.
I'm drinking coffee at Snooze at Union Station in downtown Denver and getting schooled on the importance of focusing on outcomes when talking about the value of software and software development. I am intently listening to my host while chiding myself internally for slipping back into old habits of thinking. We have only just met, having been introduced by a mutual acquaintance. He's a successful business owner. I feel privileged to be sitting here absorbing the kind of wisdom that only comes from real experience. We share similar values and views on a variety of topics.
Why then do I feel like I’m flunking class or trying and failing to grasp the stone from the master’s hand?
It IS about outcomes I think to myself! Then I reflexively start talking about technologies, methodologies, design, programing languages, and a whole host of other topics you might overhear techies talking about on any given day in a hundred offices within a mile of where we sit. I’ve got an MBA. I’ve read all the books. I’ve been coached and have even coached others on the importance of focusing on outcomes. But when it comes to having conversations about creating value, I seem to instinctively regress back to talking about the whats and hows and forgetting entirely about the whys. “Why do I do this?” I ask myself. Is it because that’s just the culture I’ve been in for so many years? Maybe it’s because I’ve always been rewarded for being good at the whats and hows. Maybe it’s just the kid in me still enamored with and fascinated by technology. I’m not sure I know the answer. But I do know that I must learn and internalize this important lesson if I want to take my career and my business to the next level.
Does this sound like you? I would love to hear your views and stories about the importance and benefits of focusing on outcomes in your profession.
I love cycling and I love the Tour de France. This year's Tour was one of the best I've seen in a long time. In honor of the Tour de France, I thought it would be fun to explore some of the lessons we can learn about software development from the Tour de France. So without any further ado, here are my top five lessons we can learn about software development from the Tour de France.
#1 You need a strong team
In this year's Tour, Team Sky dominated the peloton. Coming into the tour, the favorite to win was Chris Froome, the winner of the general classification (GC) of the Tour de France for the past four years. Team Sky's ability to completely dominate the rest of the field is due in part to the strength of their team. Not only do they have some of the best riders in the world, but the way those riders work together is extraordinary. This year spectators and commentators witnessed a drama of sorts play out as Geraint Thomas, Froome's right-hand man, emerged as the leader of the Tour after dominating the mountain stages in the Alps. Everyone was expecting Froome to be upset, but instead he was completely supportive of his friend and teammate and ultimately played an important role supporting Thomas all the way to Paris. One of the reasons that Thomas did so well in the Alps and later in the Pyrenees was that Team Sky has several excellent lead-out riders who set such a fast pace in the front of the group that they totally destroyed the legs of the other teams. Team Sky also has a few of the best domestique riders in the sport. These are the riders who take care of the leaders and the rest of the team, carrying water bottles and food up to them from the back of the peloton and swapping bikes or wheels with them in case they have a mechanical problem. These guys are the real work horses of the team and a critical part of any cycling team's success.
I think you can learn a lot about what makes a strong team, including a strong software development team, watching the Tour de France. First of all, you need to have talented people placed in key roles. Second, you need to have confident leaders who can motivate and inspire the team to perform at their best, but who are also humble enough to support other team members who may be stronger at a particular task or point in time. Finally, you need to appreciate those team members who don't get all the glory, but work hard every day to support everyone else on the team.
There may be one other lesson to learn about what makes a great team from this year's tour and that is the story of the Movistar team which had three individual leaders: Nairo Quintana, Alejandro Valverde and Mikel Landa. Coming into the Tour, there was a lot of controversy surrounding Movistar's decision to have three leaders in the race. Many thought the result would be catastrophic for Movistar because it would cause infighting, confusing the other riders on the team and making it difficult to put any one leader in a good position to win. In the end, Movistar won the team classification and Nairo Quintana put in a spectacular stage win in the mountains. By overcoming some of the challenges of having more than one leader, the team was able to focus on the overall performance of the team. In the world of software development, where the success of the team is more important than the success of any one team member, team Movistar may illustrate the importance and advantages of sharing leadership.
#2 You need support
One of the things that always keeps me on edge when watching the Tour de France on television is how close the team cars are to the peloton and the individual riders. The team cars are responsible for communicating with the riders over radio, providing food and liquids, fixing mechanical problems or providing a new bike to a rider in some cases, helping riders in case of a crash, patching up minor injuries while the riders are racing, and a whole host of other things. In addition to the team cars, there are neutral support vehicles provided by the race organizers, medical cars, people on the race route handing out bottles and feed bags and a whole host of other people at the start of each stage and the finish line responsible for making sure the riders are cared for and supported. In addition to all that, the riders in the Tour de France race on the best bikes in world. You really don't have to watch the Tour de France for long to realize that the riders have a tremendous amount of support.
In the world of software development, having a lot of support is equally important because it allows team members to focus on creating and innovating. Companies like Google understand this which is why they provide everything from free food to child care for their employees. I've been in a few organizations that considered comfortable work spaces, the latest equipment, and other "perks" to be unnecessary expenses. Yet study after study has shown that failing to support the needs of the development organization is a big mistake that can destroy morale and productivity.
#3 You need to train and prepare
During this year's Tour de France, I heard several commentators say that the Tour begins in January. What they meant was that riders and teams begin preparing for the Tour months in advance. This preparation includes getting into optimal shape, training together as a team, doing reconnaissance once the tour route is announced, strategy sessions, planning sessions, and a whole host of other activities to prepare for the race. For most riders, their preparation started years earlier when they joined their first team as an amateur. It takes years of hard work and thousands of grueling miles on the bike to become a professional cyclist. When you watch a professional cyclist like Peter Sagan break out of a lead-out group and sprint to a stage finish at over 40 mph, you realize just how much training and preparation goes into becoming a professional cyclist.
While most of the software developers, designers, testers, database developers, and other members of software development teams I have worked with haven't spent thousands of miles on a bike (though I did work with someone once who actually rode in the Tour de France), they have put in thousands of hours learning and honing their craft. What I find interesting in today's business environment is the idea that someone can take one or two coding classes and then jump right into working on a major software development project. While I certainly support people who want to pursue a career in software, putting someone with little or no real experience on a major software development project would be like entering an amateur cyclist in the Tour de France. OK - maybe I'm exaggerating a little bit. But it's important to consider how well your people have trained and prepared before starting a major software development project. While most organizations do a pretty good job finding and developing talent, I've yet to be part of an organization (which isn't to say those organizations don't exist) that puts the same level of effort into ongoing training and preparation for upcoming projects. In many cases, software development teams don't even hear about a project until a few days or weeks before it starts. In the meantime they are rarely given an opportunity to do the necessary research and preparation required to be 100% prepared when the project starts. What usually happens is the team spends the first few weeks trying to catch up. I wonder what would happen if software development teams approached upcoming projects the same way professional cyclists approach upcoming races - by training and preparing for them well in advance.
#4 You need a winning strategy
When I share my love of the Tour de France with friends, they usually respond by sharing their opinion that watching a bunch of men riding bikes is boring and that there really isn't much to it. To which I respond "au contraire!" and then try to convince them that there is a lot more to professional bicycle racing and that they should give it another chance. While I have yet to convince any of my friends to watch the Tour with me, I have come to appreciate how much strategy is involved. In this year's Tour, strategy was especially important given the difficulty of some of the early stages including one Stage 9 which had 13.5 miles of cobblestones. Professional cycling teams put a lot of thought into how they are going to leverage their strengths while attacking the other team's weaknesses on each stage of the Tour. This year, Team Sky executed their strategy brilliantly, despite the fact that Chris Froome wasn't as strong as they had hoped he would be. The team controlled the race stage after stage, often frustrating other teams who were looking for opportunities to jump out ahead. In just about every case, Team Sky kept their cool and pulled back the other riders, sometimes within minutes of the finish. The reason team Sky never panicked was because they had a strategy for winning the Tour de France and setting their guys up to stand on the podium in Paris.
We are all accustomed to working within organizations that have a strategy and we have all had to align the work we do with the organization's strategy. But how many software development teams also have a strategy - one that allows them to leverage their strengths and attack their competitor's weaknesses? Or one that keeps everyone focused and moving in the right direction while also preventing people from panicking when faced with new challenges. I think we have all been on teams that had to stop everything they were doing to respond to an IT emergency. While there's nothing particularly wrong with that approach, it's a lot like how my friends see bike racing: just a bunch of people moving more-or-less together in the same direction. For many teams, their strategy is: go as fast as you can for as long as you can. But if you did that in professional cycling, you would get picked up and dropped pretty quickly as you struggled to find the energy to stay out in front of the peloton. Get dropped enough times and you'e disqualified. In fact, in this year's Tour de France, that's exactly what happened. Some of the teams decided to go all out on the early sprint stages only to be dropped and have their sprinters disqualified on the mountain stages. How many projects have you been on where you felt like you or your entire team was getting dropped (or burned out) because you didn't have a strategy to keep everyone focused and executing at peak performance throughout the entire project. Perhaps software development teams also need a strategy just like professional bicycling teams.
#5 You need to pace yourself
The Tour de France consists of 21 stages raced over a period of three weeks. This year’s Tour covered over 2080 miles. Each stage has a stage winner as well as points and time bonuses to be won for various classifications, including the general classification (yellow jersey), the points classification (green jersey), the king of the mountains classification (polka-dot jersey), and the best young rider classification (white jersey). While it's a pretty big deal to win a stage of the Tour de France, it's rare for the overall winner of a classification to win more than a couple stages. For example, in this year's Tour de France, Geraint Thomas, the overall winner of the Tour in the general classification, won two stages and Peter Sagan, the overall winner in the points classification, won three stages. Julian Alaphilippe, the winner of the king of the mountains classification, also won two stages. Of the remaining stages, 11 were won by riders who were not on the podium in Paris, one stage was won by the rider voted onto the podium as the most combative rider and the other was one by the first runner-up for the yellow jersey competition. Chris Froome, who came in third place in the yellow jersey competition, didn't win a single stage, but did manage to save enough energy to take second place on the penultimate stage of the Tour to secure a position on the podium.
So what does this have to do with software development? If you are like me, it sometimes feels like you are giving maximum effort during each and every stage of a software development project. Sometimes we call these stages Sprints. In professional cycling, team managers and directors are very careful about making sure to pace the riders so that they have something left in the tank, so to speak, when it counts the most. To do this, they pay a lot of attention to things like maximum sustained power, cadence, reducing drag and wind resistance, and a whole lot of other factors that reduce a rider's efficiency and cause riders to use too much energy. When I think about how most software development projects are run, it seems like the goal is to go as fast as you can all the time, often in the face of various forms of friction and resistance. While I can imagine a team director coaching a professional bicycle racer to shift to an easier gear or get out of the wind or even slow down, I don't think I've ever heard similar advice in the context of a software development project. Of course, much has been written about software development processes and methodologies and maintaining a healthy cadence. But the reality is that we generally don't have a good feel for what a healthy cadence is and we are often driven by a timeline that calls for an all out effort much of the time. I think to some degree this is also because we want to "win" each “stage” of a project by producing the maximum amount of work we can within the time allotted. As Peter Sagan is quoted as saying "Winning is fun. I like fun." But the lesson we need to take away from the Tour de France is that winning is nearly impossible if you don't pace yourself for the long haul.
I hope you enjoyed this post. Thank you for reading. And I look forward to your comments. Vive le Tour!