A few years back I joined a company that didn't know much about building software. At the time I didn't know much about building software. This combination was bad for the business because I built several large systems over the year I was employed and none of which was maintainable. This was equally bad for my career because I had zero professional growth during that time spent on project work.
But during the summer of 2007 that all changed. I started reading a blog published by Jean-Paul Boodhoo, who at the time was very interested in unit testing, test driven development, and maintainable software. I started reading about his journey and learned that he valued this idea of self improvement. Something that I hadn't thought much about until reading his story.
You see up to this point I thought the most important thing about writing software was to get it done as quickly as possible. And because I could already do that, I didn't think I had much to improve on. And this mentality was at the very core of each developer I worked with.
But here's the thing, I didn't graduate from college thinking this way. So why did I feel that building software as fast as possible was the only way to do it? I now think it had something to do with the mentors I had internally. They felt the business pressure to deliver software quickly and never thought about the cost to maintain it later. This was soon ingrained into my thought process after a team lead said 'this is extreme programming, quick n dirty'. And because this developer was leading my team I followed by example.
Not having a mentor outside my organization kept me locked in an echo chamber full of bad practices that stagnated growth and innovation within the company. After a few large projects were completed I noticed a slow down in new project work. The company had decided to shift its focus back to the core business competency and we started to work more with the existing systems. We put a great deal of our development resources into adding new features and fixing bugs that had been around for some time. This was my first experience maintaining software and I found that the majority of legacy code was hard if not impossible to read. When I say it was hard to read, I mean that I couldn't understand the intent of the previous developer.
When you don't understand something you can't change it because it's difficult to understand the intended behavior or the context in which it was written. This was a problem because when the business wanted new project work finished quickly they soon get an idea of 'about' how long it takes a developer to do something. So naturally they expect that modifications and bug fixes would be completed quickly. The missing link is that when you work with legacy code you have to do a lot more READING of code and this can be a slow process when the previous developer thought nothing about making the software maintainable.
Back to JP - These articles helped me realize that the software I had been building was not maintainable in any way. I had a lot to learn and it wasn't going to be easy. I got in contact with JP several times and found that he was a great person to help me understand the testing concepts that were new to me at the time. But in addition I found several people locally that could meet up for lunch or drinks after work. This single handedly changed my career and the way I write software today.
With each conversation I took away something of great value. I learned how to do unit testing of legacy code (test after). I then learned how to design business software using object oriented design in a way that was maintainable for another developer. I took my first stab at test driven development, then behavior driven development. But each step along the way I had someone to bounce ideas off of. And each of these mentors had many years of experience building real software that needed to be maintainable.
So if you don't yet have a mentor outside your organization, get involved with the community and find one. It's the best thing I've done for my career and I'll continue to reach out for guidance because learning is life long in this industry.
