Embracing Something Hard

If you look at my LinkedIn profile, you’ll see that I have been around for a while. I was a Software Developer for many years beginning in 1991 at a small 2 person company in Waterloo, until a stint in Denmark gave me a bit of a wakeup call. When I came back to the United States in January 2011, I changed from a Software Developer to a Software Developer in Test.¹ While I started my career “making things that work”, after 20 years I was more focused on “making things work better.”

That career change was a wonderful and happy change for myself that I have never looked back.

To be specific, I am not a tester. I do know a lot about testing, but that is not my primary focus. My focus is looking at interconnected systems and figuring out how to improve them. It is not about breaking things, like a lot of people assume, but making the team around me better. It is about standing up and mentioning that having 5 developers struggle through the same setup process for 4 days each is just plain inefficient.

It is about standing up and mentioning that having 5 developers struggle through the same setup process for 4 days each is just plain inefficient. Solution: Add a responsibility for documenting the setup process for the first person, with each subsequent person responsible for the process of updating the document to current standards. Benefits: The team owns the process and its updating, with a clear path of responsibility if it doesn’t work the next time it is used.

It is about looking holistically at a group of systems and, while developers enjoy being creative, focusing that creativity on the parts of the systems that will benefit them and the team the most. Solution: Use templates and common libraries where possible to reduce the amount of “creativity” needed for anything remotely common to as close to zero as possible. Benefits: The team spends time on stuff that needs to be solved and not stuff that has already been solved.

It is about asking each member of the team what they expect of documentation from the projects that their projects rely on. Solution: Setup a set of “how-to” guides that documents common practices for the documentation of projects for the team, hopefully with a “dummy” project that gives a live interpretation of those guides. Benefits: The team writes a set of documentation for their systems that looks like they were written by the same team, instead of a mish-mash of people thrown together.

My job is as much about asking the simple but tough questions, as it is about having an idea on how to respond to both the questions and answers that follow those tough questions.

The actual job is almost always about automation or process, it almost always involves changing the way people look at things, and unfortunately it almost always includes having someone’s ego bruised along the way. Partially due to me having Autism, I can see certain patterns very easily, almost as if I was reading a book. Changing the way developers look at things almost always brings around the bruised egos. A lot of developers associate code they write with themselves. As such, saying that the code or process can be improved becomes confused with saying that the developers themselves can be improved.

And yes, when that happens, it is often the people asking the questions and making suggestions on how to make things better that take the brunt of the anger that results.

I still remember my daughter asking me one time why I liked being a software developer in test, as I am often frustrated with people over a perceived lack of momentum. Thinking about it quickly, the immediate answer was easy: I am good at a decent portion of it. If you are in a box and looking around you, all you see is the box. I am able to elevate my perspective to a higher level and not only see the one box, but the boxes around it. I can see how they are stacked, and if they are looking like they will tip over. That came second nature to me. But it wasn’t the complete answer.

Even as I responded with that answer to my daughter, there was something missing in that answer, and it bothered me when I thought about that conversation over the next couple of years.

It was years later during one of those teaching moments we as parents have with our children that it occurred to me. I was reminding one of my children that we have a saying in our family: being knocked flat on your ass is not the last step, it’s just the step before we pick ourselves up, brush ourselves off, and try again. Yeah, having issues and making mistakes sucks, but they helped make us who we are, and it’s how we stand up again that defines us.

It was then that I realized: I became a software developer in test because it was hard. I wanted the challenge to make things better, and to help others get better at what they were doing. I knew I was going to encounter stubborn people along the way, but I was determined that I would try and figure out a way to get through to them. Sure, I get knocked flat on my rear end a fair number of times, but I always get back up and try again.

And it wasn’t just the other people, it was myself. I had to learn when to strive for perfection and when to strive for “just good enough”. I had to learn to find the balance between what I felt was the right decision and what the right decision was for the business right now. I had to learn that while my own passion and vision were wonderful, unless I was able to share those things in a way that others were receptive to, they meant nothing. I had to learn to get in a state of continuous learning.

After all that time, I finally had my answer: I liked being a Software Developer in Test because I was good at it and because it was a hard challenge that forced me to learn and grow.

That takes me to the last couple of months.

For a long time I have wanted to start my own blog and help out an open source project. I was under no illusion that either objective was going to be easy, I just didn’t have a clue about how different it would evolve into from what I thought it originally was.

As I was going through and picking out a platform for my blog, I kept notes and started to turn them into articles. That was relatively easy. Or at least the first pass was. I found out that when it comes to articles, I want to make sure I am saying the right thing in the right way, and can literally spend 45 minutes working on one sentence. Shortly after that, I also learned that I can spend 5 minutes getting said sentence in a way that makes sense, add text a marker like **TBD** before it, and then come back to it at the end of the article. And yes, following that, I realized that about half the time, going downstairs and doing something totally unrelated caused me to think of THE EXACT phrase that I needed within seconds of coming back after the break. Yup, learning is fun, and hindsight is perfect!

This blog isn’t hard in terms of writing for me, but the production of it sometimes gets me. If you want to stay on track, you have to give yourself some kind of schedule. For me it was to publish once a week on something technical. It is a challenge to always make sure you have a couple of articles on the go at any time, and that you can polish one up and publish it on a weekly basis. I also have to balance the writing with exploring stuff so that I can write about it in my blog. And I realized I have to extend that out 4-6 weeks to give me time to go through a good ideation process.

In picking a theme for my website, my attention was drawn to the Elegant theme for its simplicity and crispness. Looking into the documentation a bit, I noticed that some things were close, but not spot on. I wanted to get one of those features working for my website, so asking for some help getting it working, I changed the document to better document what needed to be done. The change was welcomed, and I volunteered to help out with any other articles. That is how I started contributing to the Elegant theme.

What does it entail? Take the work I am doing for my blog articles, subtract the subject matter research, in certain cases add some localized research, and supplement that with making sure I write the articles in a more professional and international. ² On top of that, apply a bit of my developer in test training and try and make sure I have a solid theme, and that I am making the process easier for me and other users of Elegant in the process.

For sure, doing these things at the same time can be nuts, but I am thoroughly enjoying the challenge. I am growing both personally and professionally as I work though things on each project, some inside of my expertise and some outside of it.

Sometimes I wish there were more hours in the day, but I wouldn’t trade the learning I am doing for the world.

Yeah, it’s quite often hard, but it wouldn’t be worth it if it wasn’t hard, would it?

Like this post? Share on: Twitter ❄ Facebook ❄ Email

Comments

So what do you think? Did I miss something? Is any part unclear? Leave your comments below.

Comments

---