Why Every Software Developer Should Work Solo
“Won’t you be bored?” asked Kevin.
He couldn’t believe that I’d be leaving a team of 15-20 engineers developing software for Caterpillar’s equipment to writing a quoting application of a manufacturer in Omaha. Not only that, but I’d basically be by myself. The only one working on the app, and one of 3 developers (the other 2 being ColdFusion developers, and me a Windows developer.)
To some degree I was worried that Kevin would be right. I was going from a place that employed close to 1000 electrical, mechanical and computer engineers. I’d go from getting to hook up to custom hardware and troubleshoot the communications between it. I was leaving behind the opportunity to hook up a laptop to a diesel engine and watch my software run (or fail.)
But as I thought more about it, I realized I wouldn’t be bored. There was a lot of work ahead of me. I was taking on a project in which I’d be responsible for gathering requirements, developing the GUI, creating the application, testing the entire app as well as release management. I couldn’t just tuck myself away in the corner and spend the day looking at data link traffic.
However, as I left that job three years later, I realized a couple things. First, I rarely had a boring day. Secondly, going solo (or close to it) made me a much, much better developer.
What Big Teams Offer
When I was working on a large team, I was able to play a very well defined role. I wrote one, maybe 2 features a release, and fixed a lot of bugs. I didn’t worry about the architecture of a program (or even realize that programs had architecture) we had 2 or 3 super-developers for that. I didn’t spend a lot of time worrying about requirements, or customer requests. Those were usually handed to me in order for me to write some design documents and start coding. I did have to do testing. Obviously, I had to test my own code, but we also split up our regression testing among the entire team. I had no work to do on actually deploying the software. In fact, with my limited role, by the time code hit lockdown I was usually starting to write design documents for my feature in the next release.
Responsibilities of the Solo Developer
All of that changed when I became the only Windows developer on my team. I quickly realized that the structure of my new program was 100% on me. The features, as well as the look-and-feel would get input from my customers. However, what assemblies I had, and the database structure etc were 100% my call. This put a lot of pressure on me. I couldn’t have something that was always breaking down, or was hard to maintain. I had to research good database design principles and learn how to implement them. I had some experience with databases at Caterpillar, but the product was so mature that I don’t think I ever had to actually design anything more than a simple look-up table.
In addition to design, I quickly realized that I needed a way to test my code. If I were to write a feature and then test it at all, it would probably double my development time, at least using the principles I knew at the time. Again, this drove me to research different techniques. It was this process that exposed me to NUnit and automated testing. I started writing test cases and making sure that when I put in 100 feet, I got 3 30foot pieces and 1 10 foot piece. Learning about this technique was just the start, however. My next challenge was to try and get the two web guys to implement it as well. This task proved to be more of a teacher than me just learning.
The last technical task I had to undertake was how to actually do a deployment. For the first few months, if someone wanted an alpha copy, I’d just switch over to “Release” in Visual Studio, do a build, zip the bin folder and give it to them. Obviously this wasn’t something that could be maintained long-term. I quickly found something to build me MSIs and EXEs. I then started using this to create installers. But it was still time consuming. Finally, I found CruiseControl.Net and began to create automated builds. This made building and deploying quite a bit easier, as now all I had to do was click a button on a website, and a minute or two later, I had an exe ready to deploy.
It’s Not ALL About The Code
Despite all the technical tasks that I learned, the most important one was non-technical. It was how to deal with the customers. I was now the go-to person for the entire life of the application. Have a new feature you want? Talk to Nate. Found a bug? Talk to Nate. Wondering why progress is so slow? Talk to Nate. Hate the UI? Talk to Nate.
At one point, I got frustrated with one of my customers and walked into my co-worker’s office. I said “Don’t you just love our customers?” To which he replied “Yes I do. Because without them, I wouldn’t have a job.” At first, I was frustrated, that he wouldn’t share my sentiment. But over time, those same customers that drove me nuts helped make me a better developer. I had to learn to listen to what they were saying AND what they wanted (usually 2 different things.) I also learned how to interact with them. Most customers don’t care about any technical talk. They want a bottom line answer, and they want to know how things are going to affect them.
Overall, if I had not gone to a place where I would be the only one on my project, I would have had the need to learn and grow in the areas I did. I would probably be stuck in the mindset of cranking out the next block of code, completely missing the bigger picture.