The Core Basics

Nov 25
22:00

2002

Richard Lowe

Richard Lowe

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

... I was asked "What are the core basics that someone who wants to move beyond ... ... that's an ... question that I actually get asked quite a bit. You see, I have been

mediaimage

Recently,The Core Basics Articles I was asked "What are the core basics that someone
who wants to move beyond 'beginner' needs?"

Well, that's an interesting question that I actually get asked
quite a bit. You see, I have been "in the business" for 25
years. I started as a programmer on the old 16-bit PDP-11
computers (when 128KB of memory cost $10,000 and fit in a
refrigerator box, and a 10mb disk was HUGE) back in the late
'70s. I moved up to "operating systems guru" on the "new" 32-bit
operating system called VMS. I was actually quite good, and
could program assembly language faster than virtually everyone
could code BASIC (someone dared me to prove this once so we
took out a stopwatch and programmer a database application, and
I finished it in a quarter the time as the expert BASIC
programmer).

>From there, I moved onwards to design and analysis as well as
project management, then to higher management (working my way
up to a Vice President). Now I am a director of a multi-billion
dollar company (Director of computer operations and technical
services).

Why tell you this? I've managed hundreds of people and have to
deal with the question virtually every day (now I manage about
a dozen). People (from my own department and others) ask me
questions like: What should I do next? What training should I
be doing? Should I be attending conferences? What books should
I be reading? I always answer carefully, as this could mean the
difference between employment or unemployment, or a good raise
and a not-so-good raise. I want people to do well, so I try very
hard to guide them properly.

What is the most important thing I've learned? Perhaps it
sounds corny, but it's the ability to look and to see what's
actually there. To examine a problem and see the problem, with
no bias or assumptions. To look at a project plan and pick out
all of the assumptions (which can then be tested for accuracy),
or to look at a program and see the bugs or flaws.

An example? Sure. Someone I knew worked for one of my peers.
Over a period of several weeks, I kept hearing about a severe,
horrible problem which was delaying a major project. It was not
my project and I did not manage the person, and had my own fires
going, so only heard about this in the weekly meetings. This guy
worked on this problem for weeks, literally weeks. He changed
code over and over, tested and retested, had meeting after
meeting, involved a dozen other people and spent tens of
thousands of dollars of consulting money.

One day I happened to pass him in the halls and got into a
conversation about the problem. I could see he was upset and
decided I could possibly lend a few words of advice. He
described the issue and my jaw dropped open. He was trying to
figure out why some critical numbers were not being transferred
from the payroll system to the general ledger. It was critical
that these numbers show up in the general ledger.

I successfully kept from laughing out loud as I explained that
the payroll numbers didn't show up on the general ledger
because the payroll programs didn't post to the general ledger.
It was quite simple really, and if he had taken the time to
actually ask the users he would have discovered that they
hand-entered the numbers after each payroll. What happened was
one week the numbers didn't get to the general ledger and he
assumed there was a problem. If he had simply looked at what
was there to be seen, he would have discovered that the payroll
person was out sick that week. A temp had run payroll, and
hadn't known to enter the numbers in general ledger. It was
that simple. There actually was not a problem at all, yet we
spent over 200 man-hours and twenty-five thousand dollars to
try and find it!

The second most important lesson is that people are important.
People are not machines, they are not commodities and they are
not objects to be manipulated. People have feelings and they
are to be allowed to be themselves, to have rights and freedoms.
That does not mean you let them do whatever they want (you have
to manage things if you are a manager) but you have to
understand, communicate and respect them.

Why is this important? If you treat people badly or don't
communicate with them you will find them uncooperative and
even belligerent at times.

I've solved so many problems that simply resulted from treating
people like trash that it's mind numbing. I remember a time that
Sam, a colleague of mine, was trying to set up some testing time
with our users. He could not get them to test anything. He
complained over and over that they didn't understand how
important this was and they were sabotaging his project.

I talked to some of these users and found out what was really
going on. Sam was simply not communicating well. He was trying
to set up meetings and get testing from people who were already
overworked because it was quarter-end and they had books to
close. He was demanding their time and kept telling them they
had to help. He didn't seem to care about them, and thus they
didn't care about his project.

I knew this was important so I told him I would get his testing
done. He agreed, and I individually talked to each person, and
found that they really did want to be involved. They just
wanted to be treated like human beings. I called some lunch
meetings and bought everyone pizza and soda to discuss the
issues (even remembering the vegetarian pizza for the
non-meat-eating members of the group). I worked with their
bosses to arrange schedules and sent special thank you notes to
everyone (carefully carbon copying their supervisors). Before
long, the entire team was involved and the tested was completed.

The third most important thing is "be completely and totally
ethical at all times". Never, ever violate your integrity.

For example, I had a boss named Gary who assigned me to create
a warehouse system. I wanted to talk to the customer, find out
what they wanted, then write a proposal, get it approved, write
a specification, get it approved, then write a more detailed
design specification, and finally write the code. My boss didn't
like that at all. He said the customer wanted results, not paper
and words.

He told me to shut up and watch an "expert" at work. Gary then
spent one hour (!) interviewing the customer, then told me to
start writing code. I protested, but was young and dumb and did
what he said.

The effect was catastrophic. The system took ten times longer
than expected, required thousands of man hours to debug and has
been a maintenance nightmare. Why? Because we could not do what
the customer wanted for the simple reason that we did not ask
them, then tell them back what they said (and repeat until
done). That's the only way to be sure you are doing the right
thing. What we wound up doing was writing and rewriting and
rewriting until we got it right.

The final irony? Years later the customer asked me why we
hadn't written a proposal, a specification and a design
specification. They said it would have sure made things a lot
easier for them! Now that I'm older and wiser, I would have
held my ground and done the right thing regardless of what the
"expert" thought.

The next thing to do is to do the best possible job that you
can do. So do whatever you need to do to understand your job.
Read books, attend seminars, network with peers, go to classes
and continue to learn every single day. That's right, set aside
some time every single day to get better at your job.

If you want to be a webmaster, then BE a webmaster. Learn what
it means, learn how to do it, and learn what you need to learn.
Then put your learning to work and be the best webmaster you
can possibly be. Create excellent web sites and deliver
excellent products to your company, your users and your
customers.

The final advice, perhaps the most important thing of all, is
to be happy with what you do. Be happy with your job. After all,
you spend a fair portion of your life, perhaps the majority of
your life, working. If you don't enjoy what you do, then are you
truly happy?

I've seen more people miserable with their jobs that I like to
think about. People who are hanging on to collect a pay check
instead of doing something they really like.

I know none of this appears to have anything to do with
computers or the internet or anything else, but it does,
believe me.

We IT people tend to be introverted, we tend to think of
computers as more important than people, and we tend to have
these huge, silly biases which do nothing but make our lives
difficult. All of this gets in the way of doing our jobs and,
more importantly, being happy with what we do.

So learn and continue to learn. Be happy and stay ethical.
Treat others with respect and communicate freely and opening
with everyone. And be the best that you can possibly be. That's
the advice that I will give anyone who asks.