I was hired into a mess.
At most software companies, that’s called normal. Software development is a blend of science and art, where the normative state is for things to be at some level of disarray. Even the best teams are composed of people, and everyone makes mistakes. Besides finding the balance between crossing every ‘t’ and releasing sometime this century inevitably leads to shortcuts.
Assuming you do everything correctly, you will still end up with a pile of code that is not structured correctly for some future demand. As long as you are successful, you will have many future demands. More likely, someone else will have demands to satisfy on your pile of code. It’s tough to jump into another person’s art and “take it from there.”
So given the way things tend to go in software, the mess I stepped into was not too surprising. In fact, it was a great time to be hired because there was a serious problem to solve, which gave me a chance to be part of the solution. Also, the management was committed to do the right thing, even if it meant (as it turned out) taking a year to overhaul the architecture. Kudos to the management.
Through that year of intense development, I became an expert. While we were pounding the software into shape, my enterprise software expertise was forged. I wasn’t alone. That experienced turned out a dozen experts who went on to lead other initiatives and teams.
That’s one way to become an expert. Take on a difficult challenge and see it through. By being directly involved, you gain knowledge and insight that no one else has. Congratulations. You are now the go-to person for maintenance issues and sales people who want to push the limits of what they can promise customers.
When our year-long recovery project was over, we decided to fix our development process to avoid the mistakes that caused the architectural problems in the first place.
Despite preaching agile to customers, the development team was following textbook waterfall development methodology.
- Write a complete requirements document.
- Hand off to developers to implement their interpretation of the requirements.
- Hand off to Quality Assurance testers who immediately would find ambiguities in the requirements, bugs in the code, and gaping holes where entire features were missing. Turns out that some of the features were deemed “stupid” by the developers, so they didn’t bother putting them in. They also didn’t bother to tell the PMs about it. They were avoiding a fight, or at least deferring it.
Kind of dysfunctional.
So we decided to adopt an agile methodology. That’s with a lowercase ‘a’ to emphasize pragmatism over dogma. Agile was in its early days, and we needed an expert to show us the way. Luckily, a leader of another product team was said to be an agile guru. For the sake of the tale, let’s call him Bill.
Bill is the kind of expert that is book smart, and he loved to preach things by the book. The problem with Bill was that he wasn’t great at following his own advice. That’s because pure methodologies tend toward being impossibly perfect, and perfection is unattainable.
The same is true of design patterns. They show how to put together some code for a certain effect, but they leave out what to do at the fringes because they’re just patterns. Not instructions on how to assemble the whole quilt.
Bill was the kind of guy who would spend hours and hours reading up on the latest theories, which is how he became a “guru.” He just never applied the knowledge to see if it really worked. Often in a follow-up discussion with Bill, I would learn that what used to be an “essential” step in the process was now considered to be an anti-pattern, something one should avoid at all costs.
Bill is a bleeding-edge, book-smart expert. He stays up with his reading while you fall behind trying to follow his advice.
That’s not a total knock on Bill. There’s value in being pointed in a good direction. We were able to extract a pragmatic approach out of his purist advice without too much trouble. That new process served the team well for many years.
Another way to be an expert is the fake-it-till-you-make-it way. That takes chutzpah or nerve to boldly declare that you know the best way, while your confidence is based more on optimism than expertise.
Hey, I suppose I have used that strategy to reach some of my proudest moments. At that same company, I led the charge into cloud computing without quite knowing how it would turn out.
The cloud became an obvious thing some six or eight years ago. At that point, Amazon had been working on their API-only strategy for a decade or more, Salesforce opened its APIs and hosting with sforce, Google was installing data farms for its cloud offering, Microsoft had Azure going on. The skies were dark and stormy with so many cloud solutions overhead.
Meanwhile, our company was still debating it. Success makes one cautious, so having a debate was not unreasonable. But at some point, it’s time for action. So a few of us charged ahead, and as a byproduct, we became the experts in cloud-based software development.
That’s chutzpah, with a ‘khuh.’
Now I am at it again. I left that company and have been working toward starting Happy Spirit Games for online games and training. Play as you learn. Learn as you play.
What do I know about games? I have been working on my own games in my spare time since I was a teenager back in the 1980s. Nothing too fancy, but good enough to play. I even sold a few copies of an original that I wrote in the mid-90s for Windows 95.
After that, I got busy working on “business solutions”: information systems, online advertising, insurance platforms, and so on. All very important. All very serious. I used my game coding time as a way to keep up with technology that was too experimental for work. Once I became a big-shot manager, I used it to keep my coding skills reasonably current.
But now, through an act of sheer chutzpah, I am a full-time game and course producer. My first game is StoryTime — and I will warn you that it needs a major overhaul. Still, it’s playable and you might enjoy poking around on it, if only to spark some ideas of your own, or for future bragging right that you got to play the original.
My first course is called Design a Game, and it’s almost ready. The course is designed to help beginners get started with game design. For anyone starting out, taking the course is a great first step toward becoming an expert in your own right.
Since you are still reading, here’s a quick recap of how to become an expert.
- Spend time solving a major problem. By the time you are done, you’ll be one of the leading experts in that solution.
- Read incessantly, always staying up on the latest thinking, even if it turns out to be a bad idea. No one will fault you too much for being ahead of the curve.
- Apply chutzpah, or nerve, or guts and imply that you know more than you do until you really do know more than you did. Ha. This way is the most fun.
Thanks for staying with me until the end.
If you are interested in creating games of your own, read more about the Design a Game course, and sign up to be notified when it’s ready.
Sign up for my newsletter. You’ll be the first to know about new games and courses as they are released.
This post first appeared on Happy Spirit Games.