I am not a patient man. It is one of the main reasons I went into software
engineering. It is very quick to think of an idea and convert it to machine
language. This desire to do things as quickly as possible has served me well in
that past, but lately it has caused great harm. An example and then an
explanation. I have been working on some systems at work that require a lot of
tinkering with some of the special database sauce we use. An unfortunate side
effect of this development is the need to constantly replace rpms (a kind of
specialized automated zip file). I was having great difficulty getting the
system updated with my changes so in my haste I just uninstalled all the rpms
of a particular package so I could reinstall all my newly built ones. Of course
what I should have noticed was I was uninstalling rpms that I had not built new
versions of. There is a sudden clarity when your console stops accepting
commands. In that brief window before you get told for certain that you lost
your connection you curse the gods, which for me happen to be the trinity of
Richard Stallman, Dennis Ritchie, and Ken Thompson. As you can surmise the
system died a quick death. And since the issue I was working on was hardware
dependent I had to develop on an actual blade instead of a virtual machine so I
had no snapshots or backups to revert to. Thus the afternoon was lost to
resuscitating the system via the HP ILO system and
its fantastically poor console. It was a huge pain, a waste of time, and
ultimately did no good to helping debug the problem. The solution it turns out
was far more targeted, I just needed to update a few system files instead of
blowing out all these rpms. So what is to be learned from this? Be patient and
be sure of what you are doing before acting.
The thing is, I used to get by wielding a giant hammer but I need to be more
comfortable with the scalpel. If I had just taken the time, talked to people
who knew the issue, and acted with a bit more foresight I could have saved
myself much gnashing of teeth. I chose an engineering example as I tend to like
thinking with that discrete mindset, but the lesson should be applied
elsewhere. The problem with impatience is its side effect, anxiety. I have been
kind of obsessed with grand schemes that can be rapidly achieved. Then,
inevitably, when things begin to drag I grow agitated that my plans are not
proceeding with the rapidity I prefer. Take my house hunt for example. Many
dreams, little progress in resolving them. I could buy a house tomorrow, but,
given the options available now, it would be a poor call. Rationality in
conflict with impatience creating anxiety.
Not sure how to resolve the quandary. Engineering-wise the solution is
simple: be more deliberate in action. I should work harder to understand the
systems I work with and only make the smallest possible changes at a time.
Personally though it gets harder to fix. If I do all I can to achieve something
and yet it remains unachieved the only result can be frustration. The beauty of
software is understandable systems where input produces expected output. When I
expect the same from the world disappointment will abound. Impatience is just a
byproduct of this unfortunate truth. It is as if I am desynced from reality,
like we are running on separate clock cycles. I expect one
speed of progress and get another. In time I hope to sync up, but until then I
remain impatient.
Aside: I goggled this title before using it and seems I was not as clever
as I thought. A regrettably common occurrence. I still like it though so I
am going with it.