Do you challenge your assumptions?

On Monday I’ll be starting a new job as a Senior Software Engineer. The title can sound impressive, but in my experience, it’s more of a generic title that if you’re not a new college graduate, you’ll probably have that title. In fact, the only time in the past 6 years that I haven’t been a senior software engineer was when I was the only developer on my team.  So I’m not sure what actually makes someone a Senior software engineer, by that, I mean when someone says they’re a senior software engineer, I cannot say with any reasonably certainty anything about their skill level. I have some thoughts on what being a senior developer should entail. One of them is that a senior software engineer should challenge his/her assumptions on a regular basis.

Sadly, this isn’t a common practice. I’ve worked with  more people than I can remember who do things the same way they’ve always done things. If you ask them why, they probably can’t answer you. Typically, they’ll tell you it was how they were taught 15 years ago when they graduated college, but they won’t have a reason why that company did it that way.

I’m reminded of a story I heard several years ago. A mom was cooking for a special extended family dinner. As she was preparing the roast, her daughter watched her cut off the end of the roast before she put it in the pan. The daughter asked her mom why she did that. Her mom replied, “Well honey, that’s how your grandma taught me to make it.” So the daughter went to the grandma and asked “Grandma, why do you have to cut the end off the roast before cooking it?” To which the grandma replied, “Because my pan was too small to cook an entire roast.”

The granddaughter asked a simple question because she wanted to learn. She wanted to be like her mom and make nice meals. That simple question revealed an unnecessary step. It would have been really easy for her to see her mom cut off a chunk and figure that you had to do it. It also would have been easy for her to not go ask her grandma, figuring “Well, if this is how it’s been done for the past 2 generations, who am I to challenge that?” But that’s not what happened. Also note, she wasn’t questioning her mom in an intimidating way, she wasn’t challenging her. Instead, she was curious about something and wanted to learn more.

That same attribute is something that I think should be required for someone to call himself/herself a Senior software developer.

So what made me think of that today?  As I was thinking about my new job I started doing some reading about project structure. Part of the reason I was doing this is that I know this new job has both Java and .Net developers.  As much as I like to joke about the main difference between Java and C# is where you put the curly brace, I know that’s far from true. But this got me to thinking about how I’ve done things in .Net.

My first .Net solution had 1 single assembly. It was a WinForms app that had forms and code behinds and logic and DAL all shoved into one application. After that application, however, every single .NET app I’ve written has had no less than 3 assemblies. One for the UI, one for the logic and often one for the DAL.  One project I worked on had 40 separate assemblies. The last template I used at work had a default (not including testing assemblies) of at least 4 assemblies.  Often this is done to try and separate concerns. I’ve been guilty of that myself, if I create a separate assembly, it’s easier for me to not allow my domain model to be displayed in my view, for example.  But there are definite trade-offs. Each assembly has to be built, each assembly has to be maintained and versioned (if you’re doing things correctly.)

There are some advantages of having separate assemblies. For example, if you wrote a service that would hand data to your Android, IOS and web clients, then it would make sense that it should be separated. But honestly, that happens FAR less than everyone thinks. In fact, the last time I can remember that happening on a professional level was about 9 years ago. We had a service tool at Caterpillar and we had some architects take an entire 6 month release cycle and refactor out a large portion. It was no longer going to just be used by dealers, it was going to be used in the factories as well. Rather than writing a tool for the factories to use, they refactored and created a separate COM assembly that now both the factory and end user would consume.

That project has shaped my thinking, in both positive and negative ways. I’m more aware of the pain it takes to split out functionality once it’s baked into something. However, realizing that’s only happened once in the past 9 years also lets me know that I don’t need to go to drastic measures to prevent something that in my experience happens about once a decade. So the next time I start a project, I’m going to deliberate over every assembly. The same as I try to do about deliberating over functionality. New project creation will now be a tangible reminder that I need to challenge my assumptions. Just because the last project worked a certain way doesn’t mean this next project will be identical.