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.
Stop The Endless Firefighting
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
Write a test that fails to ensure the problem exists. This is basically reproducing the bug.
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.
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!
Confidence From Your Code
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.
Disaster Recovery
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.
Being an Analyst
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.
Working in an Office Space
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!
Spending Time with Family
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.