Entries by Fred Clift

moved server, realized that it's been 2+ years since I posted, and I have the notes still... perhaps I'll get back to it. Probably not knowing how busy things are

4) IT/Computers/Etc - Love it or Leave it

I'm of two minds here, but let me tell you the more dominant one first.
If you are embarking on a technical/computer/IT career, please please do
everyone including yourself a favor and do it because you enjoy working
on that stuff. I've met a bunch of people who enter technical fields
because they think they can make a good buck there but they really don't
like it at all. People who do not enjoy their jobs do not do a good job,
well, rarely anyway. Companies produce shoddy work, customers are
irritated, coworkers are irritated, etc when their employees aren't
passionate and engaged.

My other view point on this is that if you can tolerate a technical job
that it may be a good idea to pursue it even if you aren't passionate.
People have house payments to make, food to buy, etc and of course you
choose something that will make you more money - especially if your
other options are equally unpalatable. So, for pragmatic reasons you
might find yourself in a technical field even though you don't want to be.

My advice in this case is to find something about your job you like and
learn about it. You CAN positively change your attitude and interest -
you're not stuck with your likes and dislikes - I'm not saying that
you'll turn yourself into a rabid technical evangelist, but you can
change your own feelings and find interesting things.

So, my advice is "(Learn to) Love it or Leave it" - There are many many
ways to make a living and there are others that will make you decent
money - if there is something you like, you can probably find a way to
turn that into a way to make a living, with work of course. (No, you
probably will not be a professional video game player, no matter how
much you want it).

I can't tell you how much time is wasted, and how many times I've been
irritated by people band-aiding problems because it's short-term easy.
In the long run, most band-aids are going to end up costing you more
than if you just bit the bullet and fixed the problem in the first place.


3) Fix the problem, not the symptom

Even better, redesign your system so that the problem isn't even
possible. You can divide folks into two schools of development thought
(gross generalization alert!). One group says do the easy implementation
up front, so we can have something working now just like in agile
development. The other group says 'agile' means doing the simplest thing
that will meet what we actually need to do, and part of that is to not
have a system with 10 single-point-of-failures - lets spend a bit more
time and make the design of something that wont permanently suck. This
may or may not actually be outside the scope of "do the simplest thing
that will work" but... well, in this not-so-hypothetical example (one I
see regularly in my day job) it turns out that if you want your company
to stick around for more than 5 or even 10 years that perhaps you don't
want to paint yourself in a corner in the first year of business.

One note - there are times that other rules trump this one. (a tribute
to Noah Falstein of the '400 project'
) There are some
reasons to fix a symptom rather than the real problem.

For instance, perhaps the real problem isn't known and no amount of
clever debugging can turn it up. At the aforementioned day-job with
verio we have a lot of OS modifications - custom kernel work done by
some really smart guys I work with. Sometimes our mods don't play well
with other stuff and debugging an issue can take weeks, or in a few
cases, months. If there is an easy way to avoid the bug (e.g. keep the
server from crashing due to vnode-locking issues in a copy-on-write
filesystem for instance) while the bug is really being fixed, then by
all means, put the band-aid on and then fix the real problem with the
time it bought you.

I guess what I'm saying is that sometimes the choice of a band-aid is
probably about weighing the costs of doing nothing, the relative ease of
the band-aid, the relative ease of the real fix etc. One of my other
entries on this blog will be about understanding the business of your
business so that you can more effectively make these kinds of decisions.

Anyway, the real point I'm trying to get across is that your desire
should always be to fix the real bug. I've worked with people in the
past that were oblivious to this concept and they spent their time
constantly putting out fires rather than redesigning their systems to
make the problems not happen. It is irritating to me to see the lack of
concern for "oh, we have a job set to reboot that server every night or
it crashes too much"....