Fred Clift: Imprisoned in the Internet

IT/Computers/Etc - Love it or Leave it

nospam@example.com (Fred Clift) — 2007-12-11T16:58:20Z

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

Next up: Seek some job experience while still in school - you may want to switch!

7 things part 3 - fix the problem, not the symptom

nospam@example.com (Fred Clift) — 2007-12-02T02:20:32Z

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

Next up: part 4 - "Your Field - Love it or Leave it"

7 things you need to learn in college - part 2

nospam@example.com (Fred Clift) — 2007-11-17T04:04:18Z

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

See Part 1 to read about the importance of communication.

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 knowlege 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 embarassment 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 technolgies, 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 knowlege.

Next up: Part 3 - Fix the root causes of problems - don't just band-aid symptoms.

7 things you need to learn in college - part 1

nospam@example.com (Fred Clift) — 2007-11-16T21:26:03Z

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.

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

Next up - #2 "you will make big mistakes, but you can learn from it and move on"

welcome

nospam@example.com (Fred Clift) — 2007-11-16T21:23:07Z

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.

Fred