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"....

This is part 2 of my series of things you should manage to pick up in
college despite your classes.

These are based on notes from a brief talk I gave to a bunch of
students. The topic I came up with was "What I wish someone would have
told me back when I was in their shoes" or something like that.



2) You will make (terrible) mistakes, but effort and time will help

My first week as a unix system administrator - I got hired because of
who I knew, not my 2/10 knowledge of HPUX and AIX - I did a completely
boneheaded thing. I learned that recursive directory expansion generally
reads '..' before '.' - all I wanted to do was remove a bunch of dot
files in /tmp on the main College of Engineering Computing Center
file-server. Trust me - "rm -rf .*" in /tmp is not what you want to do
when your boss is gone for the weekend. Fortunately I got suspicious
about 45 seconds into the recursive removal of the entire filesystem and
stopped the process. No user data was lost, but the OS was well beyond
nuked... Fortunately my bosses boss was near and patient and several
hours later, the server was back on line. At the time, I felt like I was
a big loser - like I would never overcome the embarrassment of being so
obviously stupid. They were patient with me, and I learned a lot and
became somewhat more cautious and competent. I remember the occasion
with amusement now, and a lot less anguish than I used to. Keep working
to improve yourself, seek training, play with technologies, learn, have
fun, and you'll soon find your mistakes are usually smaller and more
livable. Also remember when you see someone else in the same situation
that you can help them by being patient - by teaching. You can learn a
lot by mentoring others with less knowledge.

1) Learn how to communicate (especially with non technical people!)

I took an undergrad English class (for engineering students) that
started out with the professor saying that we would all learn soon
enough how to write technical papers in our own fields. Electrical
Engineers used different formats and techniques than Civil Engineers and
those are both different from Chemical Engineering scholarly papers. The
point of this class was to learn how to write about technical subjects
for non-technical people. The reasoning went something along these
lines: It does not matter whether you end up in acedaemia or in
industry, you'll need to be able to explain to people what it is you
have or want to do.

If you need to convince the VP over your organization to drop $250K on
hardware to solve a specific problem, you can bet you will need to be
able to explain why. If you want a research grant from just about
anybody, you can be sure that you are much more of an expert in your
field than the people reading the grant. If you can't explain your
technical information to non technical people you will never get
anywhere. At the very least you have to be able to explain to a
non-technical manager what you've been doing and why you should still
have a job tomorrow. You need to be able to write plans for work,
documentation for your software or hardware, release notes, source code
comments, etc. So, learn how to write - practice, write a blog for
instance...

I recently was asked to speak for 30 minutes to students in an IT class
at UVSC (UVU soon). The topic was open but was
supposed to help give the students some idea of what I did for a living,
what they could expect in the future workpalce, or what I thought they
should be learning.

The topic I came up with was "What I wish someone would have told me
back when I was in their shoes" or something like that. All of these
things are things I learned 'the hard way', and for all I know some past
teacher of mine is out there somewhere saying "I Tried!". In at least
one case, I at least tried to learn the message. I'll be presenting
these one at a time as I get time to write.

So my goal is to write down the many stunning, powerful and insightful
ideas that I have. Lets just say between you and me the bar isn't very
high there - I don't have too many ideas that fit those criteria.

What you may get are interesting tidbits of ideas, see what I'm playing
with, find something to argue about, or just have some fun.