There are many approaches to being a software developer. I’ll start by saying that in my decades of experience there is not one approach that is better than another. To me, differences in approach typically are due to the trade-off between time and cost. These differences in approach are quite fine and I’d argue often can produce a better result.
There are many types of software developers out there. In my experience, there are three main phases of maturity all software developers go through as they progress in their career. Some spend an entire career in one phase, some transition quickly and some spend time at each level.
On my teams, I have had developers in all phases, and of all types. I’ve tried to be consistent and teach the same techniques and use the same processes and see where that takes them. On my teams, we typically come back to two mantras of software development. First, to choose the best solution to the problem and not just the comfortable solution. Second, build things that have a singular purpose. Both of these are foundations for good software development. In my own experience, it took many years to develop these foundations.
My software developer origins
When I started writing software, times were much different than they are today. First, I had to use books to find my algorithms or I was tasked with inventing them myself. You read that correctly, I didn’t go to the internet to find answers! There was no Stack Overflow or GitHub. In fact, the internet, while it had been invented, hadn’t been released for public use yet. The reason being, when I started writing software, I was a child in 1987.
I was programming on an Epson Equity I+. My experience started with a GW-BASIC manual and a DOS based text editor with a GW-BASIC interpreter. A couple years later, I got my first compiler called QuickBASIC which served as a graphical IDE. It wasn’t very feature rich, but the additions in features led to a new dialect of the BASIC language called QBasic. QBasic taught me a lot about being a software developer and we had some fun together. I can still recall trying to build adventure games. It was a great challenge figuring out how to make it all work.
The architectural seed was planted
My software had no flow, no design or architecture, and took advantage of every bad habit a software developer could have. The funny thing was that it worked anyway. I was able to create working programs by trial and error, and lots of determination, even without having formal training. I got by with using my GW-BASIC manual, MS-DOS 3.0 manual, and my own creativity and desire.
Writing software in this way was very challenging. I constantly came to obstacles in software development I didn’t know how to pass. The only way I knew how to solve these problems was a brute force approach. I would just change one thing continually until I got where I wanted to go. Once I had luck in passing the obstacle I had wasted much time and energy, but luckily I was young and I had both of those in reserve. Ultimately, I knew I needed a stronger foundation if I were to do anything with building software.
Finding a foundation
After my childhood experience, I took college classes on Visual Basic (VB), Java, C, COBOL, and SQL, among other languages. I was then on my way to a degree in Computer Information Systems. From taking these courses I was building a foundation for my future career. Because of my earlier self-training, I often found myself ahead of the others in my classes. I ended up learning more by helping them solve their homework problems than I did solving my own.
In my career, I started using VB, Java and SQL. This was at the beginning of the 2000s at this point. Still no major internet resources. We bought books and tried things out, did a lot of inventing, and still a lot of brute force approach. The foundation I received at college was invaluable. It gave me some algorithms to fall back on like bubble sort, quick sort, binary search, etc.. Still, many of the algorithms I was implementing at this time were brand new to me. To top that off, all of my Java development was without an IDE. I also did a chunk of my VB and SQL development was this way too. This still produced some pretty sloppy code, but it worked. This carefree approach fueled much of what I was doing at the time.
In late 2001, we decided to use Microsoft .NET release candidate using a new language called C#. Yes, we used it for production systems before it was even released to market. Guess what? There was little to no documentation or resources, and still no internet resources of note to fall back upon. We were flying by the seat of our pants. The IDE was very feature rich for what I was used to at that time. Even with that, it was very buggy and nothing like the very developer friendly modern IDEs. Needless to say, those solutions were pretty carefree too, but like all good software, it worked and our solutions were no exception.
The first software developer
I have spent a good chunk of time here talking about my origins and carefree software development in my early days. It goes without saying, when I refer to three phases of software developers, the first developer I am referring to is the Carefree Coder. This is not meant to be insulting or degrading. I got patents during this phase. It is a fine place to make a living and I spent over 15 years in this phase.
The Carefree Coder knows enough to get by, but doesn’t really care what they are producing as long as it works. Efficiency, and maintainability be damned, they will churn out code quickly and seem to run on a never-ending battery powered by coffee, soda, beer, pizza, and whatever else they can ingest quickly that gives them the energy to keep powering on. Pride is found in a quickly completed task that works.
Maturing into the second software developer
As my career progressed, I started to care about the systems I was building in a different way. I was no longer trapped in a mindset where all I could focus on was the next feature. My software development concerns shifted to efficiency and maintainability. At this point, I knew there was more future on the horizon than just tomorrow. We started adding more and more users. This created challenges of scale where we had to overcome bottlenecks in the system.
The next step was investing time in trying to architect better solutions in the software. I wanted cleaner code that utilized more of the features of an object-oriented language, like C#, such as abstraction, inheritance, and polymorphism, among others. Efficiency was another major concern. I needed to write more efficient code that took advantage of the host environment resources such as CPU, memory, storage, and network utilization.
At this time, I took on more responsibility over the formation and management of our development teams and processes as well. In considering what was best of the business, I first had to consider what was best for my teams. They needed to believe in the way we did things, and feel a sense of ownership not only of the product but the development process. I knew that if I had a team full of happy developers that felt pride in what they did and if they were growing in their role, then our business would reap the reward tenfold. I had now shifted to what I’ll refer to as the Trailblazing Coder. The Trailblazing Coder is fitting because I was paving our way through uncharted territory. I had to build our teams, lead, teach, architect, and still solve problems at a great rate.
This journey from Carefree Coder to Trailblazing Coder was a journey of several years. This was in the early days of development shops outside of Silicon Valley giving away perks like team building activities, free food, remote work, and unlimited PTO. I was lucky enough to get buy-in from the business to implement many of these things and they worked. As the Trailblazing Coder, I not only changed the culture where I worked, but I was able to change the way we did everything in regards to software development.
We became an Agile shop, started using used tools like JIRA for managing our projects, switched to Git for source control, implemented unit testing, and migrated to CI (Continuous Integration) and CD (Continuous Delivery/Deployment). We implemented software development patterns, contributed to private and open source libraries, and utilized open source libraries from package services such as NuGet. It was refreshing that we now did things not just to solve the problem at hand, but for our team building also.
I saw the light as the third software developer
From the successes of being the Trailblazing Coder, there were also problems that came about. First and foremost, our project delivery rate started to plummet. It was a slow drop off at first, but it grew. Almost immediately, we found we were spending a lot of time writing the same code many times to try and get it to fit with all the new patterns and processes we were utilizing. We also found that in an effort to build bigger and better things, we spent time trying to future-proof our solutions. We were writing code we would never use, or at least not use for a very long time. Worst of all, some of us found ourselves suffering from paralysis by analysis.
The first place I looked was at the man in the mirror. I was scrutinizing everything we were doing to make sure it was in the best interest of my team now, my future teams, and the project at hand. I know if I was doing this, my teams were doing it too. It took time, but we were able to overcome these challenges.
One of the first things we tried was implementing a principle from XP (eXtreme Programming) called YAGNI. YAGNI is short for You Aren’t Gonna Need It. We started looking harder at building just to the requirements and not trying to future-proof the software. We were able to cut out building code we weren’t going to use almost entirely. This improved our delivery, but wasn’t the one silver bullet.
The second problem we addressed was continually rewriting code. Through the solution to this problem I also found the way to eliminate paralysis by analysis as well. Solving this problem transitioned me into my third type of developer, which I’ll refer to as the Enlightened Coder. As the Enlightened Coder, I built a new system for writing software utilizing things we were doing already, but just tweaking it a bit. This system allowed for shortened development cycles and also shortened bursts of attention span.
Maintaining focus is always a challenge for software developers. A break in concentration for a developer in the zone sends them all the way back to square one. Instead, this new software development technique relies on understanding how to construct an application using what I refer to as scaffolding the application. Some others may refer to this concept in a negative light, and refer to it as boilerplate code. Either way, it is tying the code together utilizing interfaces to build the structure of the application and then going back and implementing singular purposed logic components one by one.
Following this system requires a shorter attention span and if interrupted only sends the developer back to square one the current implementation, and not the entire application. It also works very well for unit testing, as things stay very simple, but chain together to make something complex. Also, taking advantage of interfaces is a great compliment to good mocking with unit testing.
Three developers in conclusion
After working as the Carefree Coder, Trailblazing Coder, and now as the Enlightened Coder, I feel I have a unique perspective to bring to software development. Since my childhood adventures in software, I have spent the majority of my life as the Carefree Coder. It is a fine way to create new and exciting software. Being a Carefree Coder provided a livelihood for me when I didn’t know if I would get that chance.
While scaling up, I started leading teams and I realized I needed more from myself and my teams. This launched me into my journey as the Trailblazing Coder. I spent ten years in this phase, and learned a lot about how to make better software and systems, as well as how to attract and retain talent.
I’ve spent the last 8 years in the Enlightened Coder maturity. I think as you graduate through these levels, you don’t lose what you had, you just gain more. Being the Enlightened Coder has taught me that more than anything. I took what we were already doing and did it better. That doesn’t mean my system is perfect, but I know it is perfect for me and my teams.