Story of the utility developer
A few years into my career, I noticed I was only working with the (even then) outdated “classic” ASP. I certainly did not want to work with ASP forever. This .NET thing was new and cool, and it seemed to fix 90% of my complaints with classic ASP. My company had various projects underway. One was a rather large (and important) Java project. I pulled a few strings and got put on the project.
I few things I should note: I would have preferred a .NET project at the time, but the company didn’t have one (I don’t recall if there wasn’t one, or just one that I could be placed on). I had done some work with Java back in college, yet I was worried it wouldn’t be smooth transition. I had worked exclusively with ASP and Visual Basic 6 (VB6) since college, and felt comfortable with those languages. In addition, .NET had VB.Net, the successor to VB6. Taking up Java at this time seemed a little crazy. Maybe it spoke to how much I wanted to do something other than ASP.
I arrived at my new assignment and promptly setup my development environment on my workstation. I was placed on a small sub-team with three others, led by a newer hire that knew Java very well. Even though I was nervous, I felt good about my situation. I had been in a similar situation on my first project while I was learning ASP. Even better, I now had a few years of professional experience. The non-programming parts of software development wouldn’t be as foreign to me as it had been just out of college.
As expected, much of Java looked foreign. The language itself was familiar, but the projects and applications were structured nothing like I was used to. On top of that, we were using a bunch of weird middleware products I’d never heard of (and would never come across again after this project). I was having a hard time getting a handle on everything. There was so much to learn, and that was just my small little sub-team.
I plodded along in my assignments, turning out what I thought was decent code given the circumstances. I knew what I wrote six months down the road would be a lot better, but that was the best I could do at the time. I interacted with a few of the other sub-teams, ensuring our work integrated with theirs. All the sub-teams were growing, and quite a few new developers joined us on the project. All of them had more Java experience than I did. I was now the odd man out. The Microsoft guy on the Java team.
A quick aside — I enjoy helping people, especially helping others learn to code (or learn to code better). I am very grateful for the mentors and coworkers I’ve had over the years that have taken time to help me be a better me. The least I can do is give back.
Given my nature, I found myself working with another developer on a different sub-team. I don’t recall how we got on the subject, but he was struggling to create the code for the UI in the design documents (a UI that only corporate apps can dream up). This developer had been working on Java his whole career, and our careers were similar in length (2-4 years).
As I helped him, I had a one of the more important revelations of my career: It didn’t matter what the language was, the core concepts and patterns used where universal. While the language might change, the same things I’d done in ASP where just as applicable in Java.
I found myself in this situation a handful of times. For the first time on the team, I felt like I was adding significant value. And I wasn’t even working on my assignments half the time. The project lead was a friend, and I found myself talking to him in his office (usually after hours when he wasn’t in his endless meetings). I kept him briefed on what I was doing and how I was assisting the team.
A few weeks later, the lead called me into his office. “Jason, I have a new assignment for you.”
Great, I thought. I finally found my groove and now things would be changing. I prepared myself for something new, but not quite what he had in store.
“I want you to be a utility developer.”
What’s a utility developer, I thought. That sounds weirded. I wasn’t sure I wanted to be a utility developer, whatever it was.
“We’re going to take you off your [sub-]team and have you assist everyone on the project, as needed. You won’t have any tasks on the project plan. Just help anyone who needs it and keep the project moving forward.”
My mind was blown. On the positive side, this was high praise. I was helping people and that provided more value than working on tasks directly. On the other hand, I was going to have to learn, at least at a high level, all the various technologies and parts of the whole system. I cautiously accepted my new assignment and got to work.
Over the next few weeks, I helped all the teams, as needed. I learned more technology in those weeks than I had on the project to date. I got to talk to everyone, learn from everyone, and generally grow myself more than I had in a long while. I continued to learn that I could tackle any problem (except for being on time for the 8:30 AM daily meeting).
Unfortunately, the role of utility developer didn’t last forever. I don’t recall exactly how it ended. I did leave the project before it was completed (only to return later, it was large and long project). Perhaps I was needed in classic ASP land again. Whatever the reason, I left the project with more confidence than I had had at any point in my career up to then.
Soon after, I started to be the team/project lead on many of my projects. I’m thanking for the time I spent as the utility developer, doing a little bit of everything, but most importantly, making sure the project moved forward.