David Grieser

Back during a lot of my leadership training, there was always disucssion of what made a great leader. It was probably 4 or 5 years later that I came up with an idea.

A great quality of a leader, is the ability to follow.

This idea was sparked by a conversation I had with my mentor at the time. She just got done explaining the team building that happened during a leadership conference she went to. Each exercise seemed to be more challenging than it should have. As I asked her about the difficulty of the new activities, I became so excited about the new team building I hadn't experienced before.

This is when she explained that these weren't new activities. The difficulty was the perception of everyone there. Every member of The team thought they were a leader. So when it came time to doing the activity, they all knew how it should be done. This caused the group to struggle and not accomplish the activities in the allotted time.

After a few months of thinking this over, I finally came upon the quote I mentioned above. Through team building you learn how to work together and accomplish tasks that would be impossible alone. Given a certain task, 1 or 2 people will rise up and be the leaders of the group for a specific activity. If you then take this same group to another activity, it may then be time for another member to lead as they are the one with the most experience.

This isn't done for the power or the notoriety, but rather for the good of the group. It is in those cases, it is best to follow.

You hear the loud-pitched fire alarm going off, alerting you of smoke… It could be real fire! Fortunately in most cases it’s just over-cooked food.

Now imagine burning food every week, day, meal, or hour! The battery in your fire alarm might just give up. Or you, tired of the annoying and incessant sound, might just pull the plug!

While we’re quick to pull the plug on fire alarms, why have we let them become the driving force for software development?

Pssh… you might be think that you aren’t firefighting all the time, but rather just “maintaining software”.

Where do you draw the line?

If users have random issues with the software and just clearing the cache or tweaking some data in the database fixes it, then you might be firefighting.

When you know you have deal with this issue for another user, or maybe even the user before, then you might be firefighting.

You deployed a new feature, but have made multiple releases, each involving tweaks to make it work right, then you might be firefighting.

At this point, you’re probably asking yourself, “How do I get out of this situation?”

Or if you aren’t at the stage yet, you will be eventually. Ultimately it will impact your productivity and happiness as a developer.

Lets go back to the small gains we want to make and have control over.

Most developers when they get into a job, have to maintain some existing application. After all it’s a great way to learn the code base. However, you won’t be tempted to change any of the code, because if you do, you’ll have to own up to it when it breaks. Hence you get thrust into firefighting mode from day one!

We can break free from this cycle, but it will take a small investment right now.

As you have issues come up, begin to write tests for them. Yes I know this is easier said than done, because management might be breathing down our neck to ship, and you might have a rather large code base to contend with.

This is why I’m suggested a small investment.

Follow these 3 simple steps the next time you fix a bug
1. Write a test that fails to ensure the problem exists. This is basically reproducing the bug.
2. Write a test to validate existing functionality of the problem area. Make sure to break the existing code to validate your test isn’t a false positive.
3. Change the code to get your test to pass!

Eventually, you’ll need to repeat Step 2 for other paths of your existing code base. It will take some time depending on the size of your code base. But if you can start to practice writing tests as a habit, then you’ll make progress sooner than you realize!

As you continue to write tests you’ll build a regression test suite that will that will get you closer to total test coverage of the codebase.

The benefit of doing this is that as you move forward, you will not have to think that something broke from your latest fix, because your tests already inform you of this.

It might take awhile to put out all these small little fires, but since you aren’t just blowing on them till they are embers to come back, you’ll have more time to develop code, rather than just maintain it!

Is that feature done? Has that bug been fixed? These are the types of questions programmers get asked. Usually from a product manager that has a timeline and needs things done. This is their job. Yours is to provide the end result and know that what has been developed works! But sometimes you’re just not sure.

You may be fortunate to have a manager that pushes back for you to give you the time you need for development. If not, how do you manage these expectations? How do you go about gaining this confidence in yourself and the code? What can you do to bring about change? For now, focus on the small gains and what you have the most control over, the code you write.

Test Driven Development

One of the ways to gain confidence is to test your code. Often developers approach testing by placing debug statements in their code to make sure something works correctly. However, that is an ad hoc approach. It makes the code less readable, plus it doesn’t provide the reader (a future developer and maintainer of the code) any context!

You instead want to take a test driven development approach. You start by writing the test cases, along with the conditions that need to be satisfied to pass the tests, before you write your code.

The benefit to this approach is that you can repeatedly run that test to know your code still works the way you expect. The not so known advantage is that when a bug shows up 2-3 weeks later (or longer), when you look at that code, you’ll have a basis for how it functions and can fix it quickly.

Applying it to Legacy Systems

I suggest this style approach because I have taken it myself. Being tasked with adding a features to a legacy Classic ASP site, I knew making changes was going to be difficult. With very little structure and pages consisting of 1,000+ lines, introducing new code could cause things to break. Realizing this, I decided that a small library would be helpful; however, how would I write any tests?

To test this new library I happened upon a blog of someone who had done something similar. As to not repeat myself, I started with his code as a basis for testing.

• The first tests were just to validate that a method call would produce a certain set of HTML tags.
• Then I included some tests to handle both fetching and submitting data into the application’s database.
• Once I had the pieces in place, I wrote some helper methods so inserting the code was as close to a single line as possible.

This code later went into production and I considered all was well. About a month later, the senior developer ping me and let me know there were 2 issues that had come up from the feature I had written.

After looking at the examples, I went straight to the tests. In both cases, I had not written a test for using this code in the way that was causing an issue in production. These tests were written (red) and then the functionality was implemented (green). I even got to refactor some of the duplication. All of this took only a few hours.

The final time there was an issue, I had it resolved in under an hour

Taking a test driven development approach improves code quality and boosts your confidence as a coder. Plus it saves you time and make you a more productive developer.

So I have been in charge of setting up a disastery recovery (DR) process. When I first look at what was needed, it became clear I would have to walk through all these steps on a clear environment to make sure I didn't miss anything. This also made sure that what I recorded was actually necessary.

I then took this to the next level. Due to the way the system was structured in regards to production versus development environments, I choose to integrate our DR process tightly with newer releases. This causes us to practice DR monthly if not weekly. We were also able to find ways to make the whole process easier. Finally, it helped us move forward with newer technologies, since we immediately had to figure out the deployment process.

Whether you are bringing on board new developers or actually having to recovery from a failure, weaving this into your everyday process turns certain incidents into another common step.

Anytime I am given any task to complete, I like to know as much about what is going on as I can. This lets me make the best call at the time. It is also a crucial part of developing software.

Too many times, I am getting a demo of the application from a developer and it becomes increasingly clear that they really don't understand all the business logic that is going on. There is just interpretation of a request from users for a feature. Certain features are known to run and others are a constant headache for the user.

When you don't do user interviews directly and get all your information second hand, you will probably always be solving the wrote problem. Sure, the user's boss shouldn't be messing up one pass of a phrase in the game telephone, but that seems to be the case.

Look at the overall picture, do a deep dive when necessary, and broadly think how a solution can be created.

One of the biggest benifits of working on site is the interaction with other developers and employees. Yet it seems that communication is somewhat lacking. Sure people will wonder around and talk at cubes, but most people don't take a break and just relaxing for 15 minutes. This can be super useful, whether you talk about work or not.

I will however listen to music on my headphones because you have have a lot of different conversations going on around you. I think this job is the first time I've ever thought I heard someone saying, "Corporate accounts payable, Nina speaking. *JUST a moment." I'm not bothered by this, if anything I find it amusing.

In a way I think I got lucky. My cube made is an awesome guy and we talk about various topics. Seems like everyone uses sarcasm to both have fun, but also cover up the negativity. Work is what you make it and I'll focus on awesome!

So I grew up with my mother and sister. It wasn't until my late 20s that I got to meet my mom's side of the family. This was a very interesting experience for me. Meeting a lot of people that love me just for being family. I embraced and it and realized that this was something I would always be thankful for.

This was then followed up by going to a reunion on my dad's side of the family. It was a very different experience because of the way they all grew up, but it still had the underlying ideals of love for family.

I even got to spend time with my brother and his family. Here was a family unit that worked as one, but were different pieces of a puzzle. I was in shock with how much they all cared about each other and made sure each of them were alright. All it did was make me smile and that much happier about them being family. I got to spend about two weeks with them working remotely and it was some of the best fun I've had.

I look forward to spending time with them again, but that will have to wait as I have to be on site for work these days.