Archive for the ‘Work life’ Category

Clarify user expectations to the minute to eliminate frustration and extra work

February 9, 2012

Vague timeframes like “ASAP” or “in a few days” are a sure way to get sorrow into your work day.  You’ll likely spend too much effort getting something earlier than the customer wanted, or later than he expected, leaving him frustrated.

Consider this simple request: “Can you get me the number of widgets we sold in 2011 ASAP?”  What exactly does “ASAP” mean?  Always ask for clarification.  “When exactly do you need this?  In ten minutes?”  You might get an answer of “Within half an hour. Jim has a conference call to London at 11:00.”  Or you might get an answer like “Oh, no, by the end of Tuesday is fine.”

This is also the same approach to take when someone asks “How long will it take for you to do X?”  She doesn’t really want to know how long it will take, but rather if you can do it in the timeframe she wants.  Therefore, don’t answer the question, but instead find out what the user actually wants by asking “When do you want it by?”

Make sure you always get time requirements down to the minute, not the day.  For instance, if a user says “Can you email me those numbers by Wednesday?” when exactly does that mean?  You might take that to mean “some time on Wednesday”, but she might mean “Wednesday at 8am because that’s when I come in and will want to incorporate them into a report.”  When 8am comes and no numbers are in her mailbox, you look like a chump.  If it’s the other way around and you get her numbers sooner than necessary, you’ve prioritized her work higher than other tasks that need to get done first.

There are all sorts of vague terms to clarify.  “End of business” usually means “I really want it the following morning”, and “by lunchtime” probably means “when I get back from lunch”.  In all cases, clarify to eliminate misunderstanding.

Finally, close the conversation by reiterating your commitment and include your understanding of the time frame.  “I’ll email you an Excel document with those numbers by 4pm tomorrow.”  This makes everything clear and gives one more chance for potential misunderstandings to be made explicit.

Advertisements

How to deal with busybodies at work

October 17, 2011

They’re young or old, male or female. Every workplace has them. They’re the busybodies who want to tell you how to live.

  • “I can’t believe you’re using an iPhone.”
  • “Are you and Kathy going to get married some time?”
  • “Another diet Coke? That aspartame is no good for you.”
  • “You’re going out without a coat?”
  • “You’re eating THAT?”
  • “Your kids shouldn’t be watching that much TV.”
  • “Why wouldn’t you drive an American car?”
  • “Have you thought about exercising?”

The busybodies at work can find anything to discuss and let you know what we should be doing differently. They tell us that we should be doing things their way. The right way.

As geeks, we are good at discussing the merits of an argument. We think we can explain our point of view and the other person will leave us alone, having seen the logic of our answers. We might think that explaining “I’m well-versed in vi, I have a large ~/.vim directory of plugins, and it fits my work style” will leave the emacs fan satisfied that we’ve made the right choice for us.

But it doesn’t work that way. The busybody comes back with an answer that takes ours into account, but still tells us we’re wrong. “Sure, but emacs probably also has all those plugins, and it can also…” For every argument we make, the busybody has a counter-argument.

It’s an interesting game, but the only way to win is not to play.

The way I don’t play this game is with a simple, non-judgmental response of “Thanks, but I don’t care to discuss that.” It doesn’t give the busybody any foothold to argue further. If he comes back and says “Oh, I know, but don’t you think you’d feel a lot better if you just smoked less?” I can reply, unchanged, with “Thanks, but I don’t care to discuss that.” If he still comes back, I can say “Thanks, but I don’t care to discuss that. I need to get back to work now.”

I’ve also found that providing justifications for our choices in life has a negative effect. Explaining our actions to others who have no business in our lives tells the busybody that he is right to be meddling in our lives. This is the wrong message to send, as no justification is necessary. It only encourages him in the future.

If you’re old enough to have a job, you’re old enough to make decisions about your life by yourself.

I don’t begrudge the nosy their motivations. I like to assume that they’re only looking out for what they imagine are my best interests. It doesn’t make their comments any less rude, but it does make it easier for me to not feel insulted by them.

On technical issues, I have to give the busybodies a little leeway, but not much. If a co-worker wants to turn me on to a new tool or technique, then that’s certainly OK. What’s not OK is badgering me about it after I’ve made my choice. I typically will say something like “I see that there are merits to using zsh over bash, but I prefer bash. If you think that zsh should be mandated in the department, why don’t you take it up with Dave and we’ll see if we should set shell choice as a standard.” That often gets the busybody to back off because he doesn’t want to risk losing his own freedom to choose.

Watch for the surprises

September 23, 2011

Look for and act on the surprises around you ever day.  That’s where we have the most opportunity to make changes for the better.

Yesterday, amidst all the discussion of CERN’s announcement that it seemed to have measured neutrinos moving faster than light, Mark Jason Dominus reminded me of the line often attributed to Asimov that the sound of scientific breakthrough is not “Eureka!” but “That’s funny…”

Back in the late 90s, I had a new boss in the IT department. When he called his first staff meeting, he told us to bring some sort of metrics from our areas of responsibility.  I’d recently created the company’s intranet, so I ran some reports of hits by top-level directory from the Apache logs.  My boss gave my stats a cursory glance, handed them back and asked “So what surprised you?”  The question itself surprised me.  “Now that I look at it,” I answered, “I didn’t expect that the /foo directory would be getting so many hits.”  Then came his crucial follow-up: “So what should we do about it?”

So what’s going on around you that you didn’t expect?  Are you even looking?  How?  Where?

Look at your server log files.  Try to absorb patterns.  Who’s requesting the same non-existent .GIF file every 11 minutes?

Run a profiler on your code. Why is the sort function being called so many times?  Why would a simple string transformation function take so long to execute?

Measure your system performance with a tool like Munin or Cacti.  Look for use spikes.  What happens at 3:30am that thrashes the system?  Why do the cache hits drop to near zero twice a day?

Always keep an eye open for the unexpected behavior, the strange blip, the neutrino that took 60 nanoseconds longer to get there than expected.  Then follow up on what you find.

Crappy job? Tough it out until the new year

November 23, 2010

December’s the worst time to look for a job. The job market stinks, of course, but in November and December, it’s even tougher to get hired.

As the holidays approach, people go on vacation. Managers who drive the hiring process scramble to cover missing people. Schedules turn into Swiss cheese. When the day-to-day operations of a company turn patchy, hiring falls by the wayside.

I learned this one the hard way. I’d quit my job early November, without another job lined up (dumb idea #1). I had a big lead on my next job, and the manager wanted to hire me, but he couldn’t round up people for the interviews. You just can’t get a full roster of people for a group interview the week of Thanksgiving.

When we finally got my interviewing process done, my boss-to-be couldn’t get the executive sign-off for my hiring. No one with sign-off authority was around. When that finally happened around the 20th of December, I had to wait another two weeks until the start of January to actually start.

If you’re thinking of starting the job hunt now, grit your teeth and bear it until the new year. Work on new tech skills over any holiday you have, and add items to your resume that you’ve worked on lately. When the new year rolls around, you’ll have the jump on everyone else.

What schools should be teaching IT students

April 18, 2010

This past Friday, I spoke at POSSCON on what schools should be teaching IT students. Here are the slides from the presentation.

How to give a tech presentation; also, column archives now available

March 14, 2010

I’ve been writing a column for PragPub, the free monthly magazine of the Pragmatic Programmers, for the past few months. The latest column is part two of a discussion of how to give informative talks, such as to your local user group.

PragPub is on its ninth issue, and is available in four different formats. You can download the entire magazine as a single document in PDF, ePub and .mobi, just like every Pragmatic book, and it’s also newly available as HTML. The archives of all nine issues are available as HTML as well.

Here’s a list of my columns in past issues:

Every issue has something of interest to me, and I think you’ll find something for you as well.

Should I switch jobs to learn better development processes?

April 30, 2009

A reader who wishes to remain anonymous wrote to ask:

I’m a programmer from the Philippines. I’m kind of a latebloomer since I didn’t take up Computer Science or a similar course in college, but I learned programming on my own. I tried to save money so I can buy a couple of books (although I would love to read more), so I can continuously learn software design and development. For almost two years now, I’ve been landing jobs in companies that really don’t have good processes for developing quality software. I have recently started a job. I’m not an expert, but I know when legacy applications have been built by engineers that also aim to produce quality software. The applications uses an object-oriented programming language, but all of them looks procedural. I still want to continuously learn and be a good software craftsman someday. Should I leave and apply for another job in which I think there is more potential to learn great software development processes?

Thanks for writing. Let me preface my suggestions with the caveat that they’re from the perspective of a programmer in the United States. I don’t know how applicable they are to business life in the Philippines. You’ll have to look at them through the lens of your own culture and understanding.

First, that you are wanting to improve yourself, to improve your skills, to improve your job prospects, means that you have the drive that will make you a better employee and programmer. Being able to write good software is only half of what it takes. The other half is having the drive to apply those skills day in and day out. (The third half is being able to be part of a team.)

It’s good you have that drive, because it sounds like you’re going to have to do much of the learning you want on your own. I would not rely on an employer to teach those skills to you. If your only reason to leave your current job for another is to learn better software development techniques, think twice. Chances are, the company you go to will have the same problems, perhaps with a different flavor, as your current company.

Instead, keep reading constantly. Read books like The Pragmatic Programmer by Hunt and Thomas, and Code Complete, 2nd ed. by McConnell. Read websites like StackOverflow for comments and ideas on how to be a better programmer. There will be much to sift through, but that’s how it goes.

Apply those skills by working on projects outside of work, preferably open source projects. Working on open source lets you work with other programmers around the world who have the same drive you do. You’ll learn and practice, while creating code that you can bring to your next interview to show as an example of your programming skills.

You may also want to try to bring some of these ideas to work with you. As you learn how to write great documentation, apply it to your daily life at work, even if nobody else in the company does. When you learn about test-first development, use it as your software methodology, even when you’re the only one who does. You’ll have better code, better projects, and people will notice. You’ll be leading by example.

Finally, don’t let the bad code get you down. The world is filled with it, especially at work, and it’s just part of life as a programmer. Consider it a test bed for your refactoring skills.

If other TWL readers have suggestions, I’d love to hear them in the comments below. Good luck!

Beautiful Teams

March 8, 2009

beautiful-teams.gifBeautiful Teams from O’Reilly is going to the printer next week, and I’ve been reading the draft. It’s chock full of interviews and stories and opinions about development teams and what makes them work. If you’re a reader of this blog, then it should be on your list to pick up.

Laurie Ruettimann’s four simple rules

November 9, 2008

Laurie Ruettimann over at Punk Rock HR has four simple rules to live by:

  1. Don’t be an asshole.
  2. Don’t divert attention away from the mission and vision of the organization.
  3. Don’t cause problems that are bigger than the problem we’re trying to solve.
  4. If you don’t like it, leave.

Beautiful, every single one of them. I’d like to club everyone who posts at anonymous whining sites like jobvent.com with these rules, starting with #2 and #4.

The Career Manifesto

February 27, 2008

This brilliant list comes from http://www.execupundit.com/2006/12/career-manifesto.html.

  1. Unless you’re working in a coal mine, an emergency ward, or their equivalent, spare us the sad stories about your tough job. The biggest risk most of us face in the course of a day is a paper cut.
  2. Yes, your boss is an idiot at times. So what? (Do you think your associates sit around and marvel at your deep thoughts?) If you cannot give your boss basic loyalty, either report the weasel to the proper authorities or be gone.
  3. You are paid to take meaningful actions, not superficial ones. Don’t brag about that memo you sent out or how hard you work. Tell us what you achieved.
  4. Although your title may be the same, the job that you were hired to do three years ago is probably not the job you have now. When you are just coasting and not thinking several steps ahead of your responsibilities, you are in dinosaur territory and a meteor is coming.
  5. If you suspect that you’re working in a madhouse, you probably are. Even sociopaths have jobs. Don’t delude yourself by thinking you’ll change what the organization regards as a “turkey farm.” Flee.
  6. Your technical skills may impress the other geeks, but if you can’t get along with your co-workers, you’re a litigation breeder. Don’t be surprised if management regards you as an expensive risk.
  7. If you have a problem with co-workers, have the guts to tell them, preferably in words of one syllable.
  8. Don’t believe what the organization says it does. Its practices are its real policies. Study what is rewarded and what is punished and you’ll have a better clue as to what’s going on.
  9. Don’t expect to be perfect. Focus on doing right instead of being right. It will simplify the world enormously.
  10. If you plan on showing them what you’re capable of only after you get promoted, you need to reverse your thinking.

My favorites are #6 and #9. I’m devoting a chapter in my upcoming book to the ideas hidden within #6, which technical people are notoriously bad with.