The one thing that makes this man stand out in my memory is that whenever we parted ways, he would say “make it a good day”. I usually said “you, too”, or something similarly uninspired.

What he was saying finally struck me one day. He was not telling me to have a good day. He was telling me to make it a good day.

As nice as the sentiment sounded, I didn’t really see how it applied to me. My job sucked, and it was causing me all kinds of stress – even to the point of visiting the emergency room. I experienced a lot of anxiety and had a few panic attacks.

I got to the point where I reacted badly to everything that happened at work. I can remember telling my manager more than once that decisions made by upper management were going to cause me to have to take another trip to the hospital. He finally got tired of my complaining and told me that work was not causing me stress; it was my reaction to work that was causing stress. That was not the answer I was looking for, so I added him to my mental list of stressors.

Fast forward a couple of years to a new job. As I’ve mentioned before, I’m now leading a pilot project using an agile process (Scrum). For the first several iterations everything annoyed me. My developers couldn’t follow simple instructions. They couldn’t write good code. They had to be constantly prodded to keep them going. Every day had its share of “what now?” moments.

For some reason I started thinking about the man at the gym again. This time, it paired perfectly with my old manager’s advice. Despite my annoyances, work continued to get done and things were working. It wasn’t the work that was bothering me. It was my reaction to work.

I’ve been trying to be very mindful of how I’m reacting to things at work. I still get pulled in a lot of different directions, and I’m still having trouble getting my team involved in the process. What I’m not doing is worrying about it. I’m learning to be more aggressive about my time management. Instead of wondering why my team can’t grasp simple process concepts, I’m asking them how I can explain or demonstrate it better.

Don’t get me wrong. There are a million things I’d like to change about my environment and my team every day, but instead of waiting for a good day to just “happen” to me, I’m becoming an active participant and “making it a good day”.

In the last several weeks, I’ve noticed that my anxiety level has plummeted, my stomach is not upset every day, and I’m sleeping better. That’s good enough for me.

The single largest variable on any development team is the developers. I’ve found that moving to an Agile process like Scrum can really expose developers who’ve been hiding behind “traditional” processes.

Therein lies one of the biggest problems I’ve run into. One of my developers is not what you could by any means call a self starter. He has been able to get along well with the official process, which does not do a good job of tracking what developers are working on. Now that he’s been thrown into Scrum, it’s become quite obvious that he really doesn’t do anything until somebody nags him long enough to get him going.

This is where inertia comes in. This developer is a textbook example of an object staying at rest until the team lead can poke and prod enough to finally get him moving. His previous lead had simply taken it as granted that he would have to spend a certain amount of time micromanaging to get any work out of the developer. I think it’s a waste of time and energy for me to constantly remind him to pick a task and work it, but that’s what I’ve been reduced to doing. This week, for example, it took two days of nagging to get him to perform a ten minute refactor. (I would have done the refactor myself, but I have to trust that my team can do their jobs, too.)

I don’t know how to engage this guy. I can spend time collecting data and create metrics, but I don’t think that’s an effective motivator. What I’d really like to see is a commitment to the team and to the project that leads into a desire to pull his fair share. I don’t even know if these are feelings I can engender in this developer.

Motivation is an issue for teams using any kind of development process. Every team member reacts differently to various inputs. Some members like recognition, while others prefer a bonus. Some just want to be left alone so they can do the bare minimum to get by. I’m hoping this isn’t the eventual outcome with this developer.

(Click to get the shirt)

I’ve been coding with an agile mindset for quite some time now. Some practices have become second nature to me over the years. One of these practices is aggressive code refactoring, coupled with test driven development (TDD).

I’ve been adding new functionality to our system at my new job, and as usual I’ve been following my standard techniques. My part of the system involves handling certain requests and responses. I wrote unit and functional tests for the request half of the equation, then began to tackle the response side. As I added (and tested) functionality, I began to notice a large amount of similarity in the code. This in turn led me to create an abstract base class for both request and response, pulling up all of the shared functionality. This resulted in the actual request and response classes being quite small, with just a few method implementations from the base class.

So far, this activity should seem pretty normal to most developers. As I said, it’s pretty much second nature for me, and I don’t even remember consciously making the decision to make the abstract class. Imagine my surprise when my team lead admonished me for creating and abstract class, and warned me not to do it again without explicit approval.

Of course I had to ask why we would not refactor code in this manner when the opportunity presented itself. My lead’s answer involved several parts, none of which have convinced me that refactoring is bad:

1. The abstract class is not consistent with the rest of the system. This, to me, seems to be a fault of the system. I’m not knocking consistency, but at some point you have to realize that you may be building something that’s consistently bloated/overcomplicated/etc.
2. The abstract class changes the design. Huh? Sure, if I go generate a UML diagram of the system, there’s going to be this abstract class and inheritance there. This is the only place the design is different. Requests and responses are being correctly handled just like the legacy ones in the system.
3. Too much refactoring is bad, and each case should be thoroughly examined before code is changed. This is how religious wars start. My lead claims that developers start out on the “no refactoring” end of the spectrum, simply because they don’t know any better. Once they learn about refactoring, they then swing to the “refactor everything” end of the spectrum where anything and everything is a potential target. Seasoned, knowledgeable developers fall somewhere in the middle. I got the impression from this speech that my lead considers me to be on the radical end of the spectrum.

Why are people like my lead so scared of refactoring? The arguments given really seem more like rationalizations than actual reasons – they don’t really stand up to scrutiny. I have a hard time believing, for example, that my lead truly thinks that the system is better because each request and response is a totally separate class, albeit with most of the code copied and pasted from one to the other. If anything, he should know that this approach leads to more problems, no matter how pretty it keeps the class diagrams.

1. Watch your finances. We attended a conference shortly after I joined. We stayed at expensive hotels and spent several hundreds of dollars a night on dining out an entertainment. The company covered all costs. Overspending can lead to problems…
2. Be careful how you cuts costs. About six months after the conference, it was determined that the company was not making as much money as expected and that cuts would need to be made. In order to avoid laying off anybody, salaries were cut. My salary was decreased by 50%, which imposed quite a hardship. We were promised that the cuts were only temporary, and that as soon as salaries returned to normal, we would be reimbursed for all of the money we lost. Which leads to the next point…
3. Don’t lie to your employees. Turns out that the whole promise of reimbursement was just a pipe dream. I wasn’t too surprised by that. What surprised me was that the pay cuts were not equal, as I was told in the initial meeting. I actually took the highest cut – other employees took a 10-15% cut. I don’t care what kind of policies you have about keeping salaries secret; people will talk. If everybody is not getting the same treatment, tell them so and why. Of course, this behavior continued right on through the end of my employment…
4. If you’re laying off employees, do it right. This does not mean telling an employee that he needs to take all of his vacation time, then take unpaid leave until things "turn around". This goes back to my previous point – we both knew that there will be no turning around, and that it was a ploy to keep from having to pay me for accrued vacation while screwing me out of employment benefits since I wasn’t formally laid off. Also, remember that you’re running a business…
5. Don’t play favorites. Oddly enough, I was the only one on my team who got pseudo laid off. The other team members were old friends of the CEO and owners. Coincidence? I think not. My team lead had a habit of not showing up until almost noon and leaving to "work from home" around 2 in the afternoon. This usually meant that he checked in whatever code he had when he left, more often than not breaking the build. Whenever he worked from home, he seemed to always have problems that would prevent him from receiving IMs or email. The end result was that the entire team would be stalled until he came in the next day. He had been given many warnings, but he also played golf with the CEO quite frequently, and I think the CEO allowed his personal feelings to get in the way of business decisions.

   I’m not saying "Oh, poor me" here. I had my share of friction with my managers, so I was not surprised to get the axe. (Post coming soon on why managers don’t like me.) I was surprised that a guy who flat out refused to do work that was assigned to him would get to stay.

I got fed up and told the company to suck it up and lay me off. Luckily, I found a job within a couple of weeks and didn’t need to file for unemployment. A couple of weeks after I found my new job, the entire company went belly up. Maybe with better management and practices, the company would still be around. Maybe it was doomed from the beginning. Either way, I came away with some hard earned lessons that I won’t forget any time soon. I may not ever own a company, but many of these points apply just as well to managers and team leads.