Reminiscing on your career as an IT professional, what was the biggest lesson you learned?

[If you can accompany your answer with an story, anecdote, link to a website, article or book it would be great thing to inspire and teach the young IT professionals!]

+49  A: 

Never stop learning.

+18  A: 

Estimates are always off by at least 50% either way.

Florian Bösch
+98  A: 

Never be afraid to say I don't know.

Exactly what I was thinking, Brent.
Except when your boss asked you what progress you've made since he last saw you!
My favorite answer in interviews! Works very nicely if you say it confidently.
Vulcan Eager
@Ali: ROTFL, I've even done that!
+9  A: 

Software engineering is a very young industry.

Romain Verdier
But its age already is comparable to the lifespan of the average human, so we all had time to learn.
+4  A: 

Utilize user usability testing! despite all internal testing, in the end we are all developers or at least familiar with the ideas and we do not look at the application the way the average user does.

+6  A: 

Marketeers make a world of difference, there are very few good ones, but those are invaluable: it is only with a great team that you can make a great product.

Amen. I learned this one the hard way.
Brian MacKay
+12  A: 

Your hard drive can and will fail. It's not a matter of if, it's a matter of when.

+38  A: 

If you are running late, behind schedule or whatever with a problem that you are stuck on:

Ask for help sooner rather than later

The typical scenario is that you are coding away, something doesn't work but it seems trivial and you should be able to fix it yourself. You don't want to ask someone because that makes you look like an idiot so you frantically soldier on trying weird things, continually making the wrong choices and you end up in a total mess.

When you eventually ask for help, the first thing your helper says is " How on earth did you get into this mess?. Why didn't you simply ask someone?"

The corollary being 'only ask for help if you need it'. It takes a while to find that balance.

I've worked mainly on the system administration side, having only just started out recently and my number one lesson has been "Never be afraid to make mistakes."

They happen, more often than most of us would like to admit and the key is to own up to them, learn from them and make sure you never make that particular one again.

+28  A: 

I learnt that backups are your friend.



It takes at least that many times to drive the lesson home. For me, it was at least three.
Greg Hewgill
+4  A: 
  • Never be satisfied with requirements from business. In fact, never be satisfied at all... until its done. Completely.

  • If you are working in a large corporation, you shall regard Dilbert comics strips as a 'pictorial documentary' and the book The Joy of Work (by Scott Adams) as the Bible.

+4  A: 

Regardless of how smart are you, you can't do everything by yourself. Cooperation and 2+2=5 is the winning math.

Ilya Ryzhenkov
+11  A: 

Don't get upset when a bunch of error reports start dropping in after the software is deployed. That means that people are using it and they think it is good enough to spend time and energy to write error reports.

Programming is 50% development, 50% fixing bugs. If you're good.

+20  A: 

Assumption is the mother of all screw-ups. Never, ever assume anything when it comes to circumstances in which defects are reported. Always check the obvious first, before looking for more esoteric causes.

When you hear "But I just assumed...", you know something has gone wrong.

Also, demand evidence. You need something objective (such as log files) to use for investigation. Going on user/integrator reporting is not enough. Human memories are known to be less than perfect; rely on what the machine generates.

Jason Etheridge
+1  A: 

Keep focus on what you intended to do. Once I created a form in a web-app where people had to enter their address. I started looking for a list of all possible cities in my country. After a while I found that such a list did not exists. Why not? I tried to find the answer to that question. It gave me insight in how names of places and cities are registered by the government......

..... And then I decided to just have a field on the form where people could enter the city of their address. I lost half a day searching for a list of cities I didn't need at all.

(I saw programmers spend weeks of time on functionality a customer never asked for.)

+4  A: 

Never trust the data. Validate your inputs.

Anecdote: I spent two weeks looking for a bug in production code. After many a debugging session, I found out that one of the 12 data files I was working on was corrupted. I had checked all the other eleven files and I had checked the start of the 12th. Sure enough the end of the file was bogus. I lost two entire weeks when I could've found it in mere hours validating the data before sending it to processing (I got lazy, there was a lot of data to process and the 11.5 first files were good).

I was "lucky", it was a numeric simulation, not something security-sensitive or anything critical.

+2  A: 

Making developers troubleshoot and fix their bugs (ok, only big production issues), regardless of time of day (i.e., usually at 3am), improves the quality of their software and changes the way they develop it.

Are you serious?
Yes. However, don't get me wrong. What I'm talking about is not minor issues, but major outages caused by the developer and affecting many customers.
Actions --> Consequences. Makes sense to me...
Most code I've written at 3 AM ends up rewritten at 11 AM the next day. We all make mistakes in the middle of the night.
Ben Robbins
(I suppose I should have phrased my answer better. Editing it now would appear as though I'm covering my tracks.) I didn't mean writing code at 3am -- I meant fixing crashes due to bad code/design. Yes, this sometimes involves making small changes to the code so that it can survive till the morning.
+25  A: 

Honesty is the key to any career/relationship.

I learned very early on that being brutally honest about your skills and experience was vital to my career advancement. Colleagues and management can smell doubt and fear as though it's the latest cologne.

  • If you're not sure, tell them you're not sure - but stress that you're itching to find out
  • If you're positive (or almost positive), be 1000% positive and aim to prove your method/suggestion/best practice - even if it means you're working 20 hour days for the next 6 months
  • If you were positive and now aren't sure, make sure you come out and admit defeat. Management won't care if you said you could, but couldn't early in a project or enterprise, however, come to them late in the game (when you've known for a few days) and you'll be doing tech support before you can say singleton.
+1  A: 

If you are running into a problem and just cannnot find the answer, take a break, go for a walk and think of something completley different. It will help you to focus on the problem and to look at it from a different angle. Chances to find a solution are much better then.
Another very good possibility is to have a chat with your neighbour and tell him your problem. Sometimes the right idea comes into your mind just because you've talked about the problem instead of chewing over it.

Roland Schneider
+4  A: 

quotes by Mark Jason Dominus:

11901 You can't just make shit up and expect the computer to know what you mean, Retardo!

11906 Look at the error message! Look at the error message!

11908 Premature optimization is the root of all evil.

11911 You wrote the same thing twice here. The cardinal rule of programming is that you never ever write the same thing twice.

11916 Always ignore the second error message unless the meaning is obvious.

1920 The error message is the Truth. The error message is God.

11963 It's easy to get the wrong answer in O(1) time.

+18  A: 

Be careful which jobs you accept early on, you will be pigeonholed.

I wish I knew this when I first got a job. Then again jobs were so scarce I was lucky to have a job at all....
Which is exactly the basis for 90% of the Dilbert comics.
Daddy Warbox
+1. However, you need the luxury to be able to do so.
Dimitri C.

The most important thing I learned was to real understand something before explaining it to someone asking for help, so you are really sure you need help. I learned it as the Teddy Bear Principle. I explain:

If you can explain what you need to a Teddy Bear you wouldn't be able to explain to anyone who may have any question about it. Usually before asking a friend's help on a function or class, try to explain to your Teddy bear(or even your Ultraman figure or Darth Vader egg) what you want help about. From my experience, just explaining it will make you find the solution to the problem most of the time, without bothering no one. (and avoid answering no to questions like: Did you include the stdio.h ?)

Fernando Barrocal

I have to give two answers because I can't decide between the philosophical answer and the technical answer.

Philosophically: Strive to learn more theory in addition to the "how to" technical stuff. As languages and tools evolve, the technical stuff will also evolve and you will constantly have to learn that anyway. But much of the theory and history will remain a solid base no matter how the languages and tools change.

Technically: Separation of UI from Code from Data Access.

Doug L.
+9  A: 

Few points I can add towards 'the success of a s/w career'

  • Be confident in your skills
  • Getting a team which exposes great +ve attitude towards the work - this gives you a great learning opportunity and a cool working environment
  • Keep learning new things in your free time- S/w industry is very immature and new things are coming every day.
  • Listern patiently to others opinion. Especially when you talk to a client.
  • Share your skills - Help others and the community with the knowledge you've got.
  • Make sure you communicate both the issues and your success mile stones with your team.
  • Learn to say 'Sorry I don’t know'. But always give it a try before you say that.
  • Make sure you get proper recognition and appraisal for your good work.
  • Accept your mistakes and take that just as a new learning opportunity
  • Manage your time effectively,
  • Give very high importance to the work-life balance
Jobi Joy
Great list. I would also add "lean to listen" -- too often we are so brilliant, the amazing ideas bouncing around in our brains create such a din we don't hear what the customer is trying to say. And sometimes they are right and we are wrong.
I completely agree with that point and that is a real situation which came across in my career too.
Jobi Joy
+16  A: 

Manage expectations, learn to say "no".

When you're designing a system people will continually ask for more and more. If you try and please them you will go nuts. Set the expectation that they are getting X, and X only - and if the Y that they're asking for is possible then it will be considered for the next update.

Steven Adams

before you roll anything out TEST TEST TEST, and make sure you have a solid back out plan.

Also, users are you friends and your enemies. Take on board what they are telling you, but never take for granted that all the things they are telling you are accurate.

+3  A: 

Keep it simple principle (KISS) The most simple way of doing something is often the best, over complicating a problem often just causes large problems in the long run.

Dean Maughan
+3  A: 

"It works on my machine" doesn't cut it. It HAS to work for them, too.

Peter Bromberg
+2  A: 

It's (almost) never a bug in the compiler.

Josh Matthews
+4  A: 

You'll meet most of the code you write later on in a dark alley and it will be angry. Always try to write maintainable code and/or documentation. Keeping it simple helps a lot here.

I had 2 projects which I had to come back to 2,3 years after the code was written and it wasn't very fun.

I have code I came back to after the Christmas break..

Don't be nervous ever, others always thinks that you are a magician "can do anything, everything in no time, but lazy".

Amr ElGarhy
  • Get written requirements/amendments whenever it is possible.
  • Never delete any of your work related emails(especially if it is from business).


Potentially Fatal Errors Successfully Ignored.

Not an unimportant acronym.

Peter Turner
+3  A: 

There's a quickest way to add feature X, and there's the right way to add feature X.

When you're newly starting on something, the quickest way is almost never the right way.

However, if you've previously done everything the right way, you'll soon enough find that the quickest way is the right way. If you haven't, then you'll now have to add feature X in a slower and worse way!

Because of this, working on any project for a reasonable amount of time will either feel like affirmation that you are coding super god, or that you have produced a horrible abomination unto this earth.

Although you don't know it yet, there will always be another feature X to do after the current one that will further compound whichever of those feelings you now experience.

Never just do it the quickest way! By the time it starts to hurt enough to want to rewrite it properly, you'll need a fair amount of time to do it.

+3  A: 

Being right is irrelevant. Worry about getting paid.

Peter Wone
+10  A: 

Never be afraid to ask for more money.

As a contractor, I would know my rate was too low in the market by the number of calls I received in the first week. I kept good records and upped the price $5/hour for all new contacts. I would also negotiate the ability to be paid for at least a 50 hour work week.

Larry Smithmier
Excellent advice.
I am still following it today. I have altered it somewhat since I am currently working full time for a contracting firm, but we always ask about early completion bonuses and price at the boutique end of the price range.
Larry Smithmier
+7  A: 

I learned that many (if not most) software defects are the self-inflicted results of overconfident developers creating overcomplicated designs (implementing the designs poorly is common but not necessary). Nothing is more important in any field of engineering than the KISS (Keep It Simple, Stupid) principle.

When I learned to stop creating things that weren't necessary, and to stop over-engineering my code to accommodate imagined future uses that never materialized, programming became easy and fun.

+12  A: 

Always negotiate deadlines/deliverables.

If you get your work/life balance right, you will be happier. A happier coder is a better coder.

Don't hesitate to do overtime IF the situation requires it, but make this the exception rather than the rule. You'll find that simply discussing WHY the job can't wait until the morning makes most people realize that it actually can.

Also, once your employers see how easy it is to get some free hours off you, they might start abusing it. Don't take this unnecessary risk.

Under promise and over deliver

You don't need to take the risk of under delivering. If you over deliver on everything you do, people are always impressed. Keep this in mind when you make promises. I find it easier to negotiate the terms beforehand than making excuses or disappointments later on.

Find the balance between being realistic and being positive. It's a flaw to have the crazy "yes, we can have that enterprise app done by next week" attitude. Maybe it can be done, but again, why over promise?

re: overtime. I worked as a contractor for many years and believe that you should always, always, always be paid for work that you do. If your job doesn't pay overtime, take it out in comp time. If your company doesn't have formal comp time, talk to your manager, they can still work it out.
Larry Smithmier

Try first Before give up, try out at least five times in different way. Take a break & try one more time. Discuss with friends/colleagues and try for last time. If nothing works, then change yourself :-)

+1  A: 

If your function code doesn't fit on one page then it might be time for another funtion.

This is why I love rotated wide screen monitors. :-) Your point is still valid.
Larry Smithmier
+12  A: 

CYA (Cover Your Ass).

Make sure you can always prove later what really happened, especially if you don't trust the other parties involved. This means:

  • Keep all your important e-mails. They might come in handy in arguments later.
  • Confirm oral agreements by sending an e-mail. For instance: "As agreed earlier, we will go that way.". If you don't get a response to it, you can assume this is accepted.
yeah - I'd prefer to use the "record to remind" strategy - don't minute things down to CYA or spank- rather to remind people of decisions and commitments - usually people will argue because they simply cannot remember what was discussed. :)
  • Learn to say "no" and "I don't know" on correct circumstances.
  • Pleasing clients doesn't mean following all their specifications. Gauge if there's any spec that is not feasible and explain why.
  • Asking for a second opinion to your colleagues, will help you know if your idea is good or not.

code more!

Definitely not. Code less but smarter!
  1. do not overcommit!! the biggest mistake programmers make is overcommitting in terms of either features or release dates to their supervisor. always calculate a probable estimate, and then add buffers...believe me, we need a lot of them while we code.

  2. don't be afraid to ask for help

  3. admit your mistakes and learn from them.

Ashish C
+25  A: 

First make it work, then make it better.

Don't try to fit all the cool features in there on the first try. Don't try to make your first version extremely fast by using a very complicated datastructure. Try not to spend too much time building in hooks you might need in 10 years.

Instead, build the simplest thing that does the job, first. Then, optimize, add features (not all at once). For each of these, follow the same rule.

Jan de Vos
+1. Andy Hunt and Dave Thomas call this a "tracer bullet" in their book "The Pragmatic Programmer".
Dimitri C.
+3  A: 

These have been my big lessons so far...

1 - Learn something new every day - even the small things.

2 - Ask for help sooner rather than later.

3 - Show your code to other people - and listen to their comments.

4 - Look at other peoples code and talk to them about it.

5 - If you can't figure out a problem then take a break and come back to it in 10 or 20 minutes - makes finding a solution so much easier.

6 - Read more.

7 - Code more.

8 - Backup, backup, backup, backup. Probable the biggest lesson of them all.

Simon Knights

Once upon a time i had "LIFE" now i have a computer


you have to trust people... but in the end, you cant really trust people

+2  A: 

There is always one more bug !

In other words, never think your environement is perfect. There is always something somewhere that will need to be fixed, improved, or changed.

+8  A: 

I've got three main lessons rather that just one:

1. Don't give people what they ask for, give them what they need.

Very often you'll receive requests from people who are non technical asking for a particular implementation. I've often found that the implementation they are asking for doesn't really solve their problems, they just think it does based on their own misconception about the system. So always ask people what their real objective is and then try to figure out what solution would work best for them. It may sound like common sense, but I've seen way too many teams delivering what the client asked for only to find later that they've delivered a lemon because neither party had taken the time to understand what the right solution really is.

2. No matter where you are on the pecking order of a team or project, you CAN make a difference.

The pulse of a project aligns itself around the people who make things happen at all levels. So be proactive and take responsibility for making sure the project or team does the right thing, rather than just writing it off as lack of omniscience on the part of management. Things can get better.

3. It's more important to manage people's perception of the problem than it is to fix it.

I've found many times that if I provide a clear explanation of a problem or an issue and people grok the implications or consequences or even just the current status, they are almost always willing to make allowances in terms of schedule or resources. And in some cases, I've even been told that they'll live it with it and that it's not worth my time fixing it.

+1 for the 3rd point.
  1. You can never plan enough.
  2. Communicate, communicate, communicate
+2  A: 
  1. Results are what counts - ideas without action are useless.
  2. Don't be afraid to say "I don't know".
  3. If you make a mistake, admit it, learn from it, and move on.
Rob Wells
+4  A: 

Don't take all the responsibility for a problem. Sometimes you can be furiously trying to solve a problem alone and carrying the problem on your back. Get other people involved, escalate, get other folks involved.

This may seem a bit backwards. but it can be extremely stressful when you don't get others involved and management will never know there is pain and your working at 2 AM unless you tell them.

Brian G
+3  A: 

I have learnt that the calmer you are, the quicker you get the results to the problems.


So many lessons... One that I tend to live by is "Don't take anything at face value".

What I really mean by that is that you usually need to keep digging to get to the root cause - be it a defect or a new requirement. Users may say "it's slow" and genuinely mean it, but when you finally get down to it you could end up with "this thing I do every day takes way too many keystrokes", which is a completely different problem to solve.

So keep asking the stupid questions until you understand!


Automating daily backups is best possible investment.

Take DAILY backups! Backup to multiple locations, with at least one offsite location.


There are several here that I agree with so I won't repeat them But one I learned a long time ago was:

Don't be afraid to say "It's my fault".

Take responsibility and fix the mistake - explain how you'll prevent it from happening again. Your reputation for honesty will really help sometime down the road when someone tries to blame you for something that wasn't your fault.


You can never have enough clarification and detail with project requirements.

+1  A: 

Realize that specifications are going to change. This is simply a quirk of being human in that there are those frilly elements in the UI that will likely get changed on a whim that one has to be prepared. It may be that you make a change and then have to undo the change.

Don't take it personally when your code gets thrown out. An example here is a new feature you spent 3 weeks working on and the person responsible for the project decides to cut that part as it isn't really needed and this other thing over here is, so get that done... NOW!!!! (Somehow it almost always seems like software should create itself instanteously but that rarely happens)

JB King

With new technology, programming language and frameworks popping up everyday, there is no way to learn them all; so don't over extend yourself, learn what interests you. If you are interested in something, it's more likely that you will spend time on it and really use the new knowledge.

+2  A: 

Don't get trapped putting out fires. Take time to do some fire prevention.

One commercial development project I was working on got into a sad loop of quickly fixing showstoppers and releasing them only to find customers found more showstoppers. After some intense negotiations with management we put in a daily build and test system and had a 3 month feature freeze to fix items on the bug list without adding new features. It wasn't as bad as management had thought. Our distributors liked the idea and helped supply some tests for our daily build and test system.

+2  A: 
+1  A: 

Obviously, this questions is highly subjective.... My story: I should have went into consulting, then self-employment 10 years sooner than I actually did! I did'nt think that I "knew enough", but after a year or so of being a contractor and then venturing out on my own, I realized that I had known everything that I needed to know already. I had good mentors and learned a lot in the 15 years prior.

Optimal Solutions
+1  A: 

The discovery of a mistake that you have made should never be covered up or brushed over. Find the correction as quickly as possible, then go confess your error and offer the solution. Work tirelessly until you have made it right.


Don't be afraid to tell others if their coding is faulty. But do it carefully.


Expanding on Larry Smithmier's comments above:

Understand that, ultimately, your productivity can't be measured with static code analyses - but rather only as a function of the business value delievered in terms of either increased effectiveness (higher sales), efficiency (lower costs), or both.

Be as objective as humanly possible about the business value you deliver, but then don't be afraid to ask for compensation commensurate with that value. Because - be it salary, hourly rate, or fixed price work - if you don't ask, no one else will. It can be a real scary thing to do at first; but at some point, you simply have to step up and ask. No one 'makes it' without taking on this level of responsibility for themselves somewhere along the way regardless of the business they're in.

P.S. Also understand, the folks you'll be asking have every right to squawk a bit about such a request and prospect; in fact, if they don't squawk at least some, then you're probably leaving money on the table.

J Healy
+1  A: 

Three things:

1) If you work in close relation with your users never implement anything unless they at least ask you twice for it.

2) Never implement new features unless you have a written request ( mail is just fine )

3) Always write down who made you change something so you can let users discuss over it instead of gettting all the blame.

+1  A: 

I learned that it is way too easy to underestimate the time it will take to complete a project, and so it is very easy to underprice yourself too.

+1  A: 

Lesson 1, if you made a mistake admit it as soon as possible and go to management with a plan to fix it. Mistakes you point out are far less damaging to your career than ones other people find that you caused.

Never hide the bad news (missing a deadline or can't figure out something or whatever it is, not just mistakes discussed above). Bad news doesn't get better by ignoring it.

If you have a personality conflict with someone, do not let it affect your ability to work with that person and if at all possible take steps to fix the problem. Even if I don't like someone, I never let that stop me from behaving as professionally to them as to everyone else. When the person I don't like does something right (hey law of averages says it has to happen randomly sometimes), I make sure that management hears that from me instead of only complaining. Your valid criticisms will have more impact if managment doesn't perceive you as simply disliking someone.

But don't let being polite and reasonable to the unreasonable people you get stuck working with mean that you don't protect yourself. Make sure to document problems and their resolution.

If you find that you have co-workers you feel you cannot trust, get another job as soon as humanly possible. Trust me, you don't want to stay where someone can make things look as if you did them when you didn't. If the CEO is having an affair with his secretary and promotes her to be your project manager, leave! Do not stay in no win situations and hope they will get better. They always get worse.

+1 for the "with a plan to fix it"
Kimball Robinson
+1  A: 
  1. Be honest and always admit your own mistakes. Don't blame others for them.
  2. Don't be afraid to say "I don't know".
  3. Learn to say "No".
+1  A: 

spend sometime learning how garbage collection works....

Ronald Conco
+1  A: 

Never run a script you don't fully understand on a production server.

In my case it just deleted 2 databases, luckily.

Fabio Gomes

My biggest lesson was in the first year after school.

No-one gives a crap about your career except you.

No matter what the company line, policy or training system, anything the company does for you or offers to you is done for one reason - to maximize your usefulness to THEM. Now, if this matches your own career goals, then you are fine. However, if you want to move in another direction, then expect to meet resistance, sometimes very great resistance.

I have had to leave jobs simply because I was not allowed to pursue a given career path.

I was also told "don't expect ANTTHING from us" when I started working on a Master's degree. Actually, I was told that several times. They were surprised when I went and did it anyway - on my time and with my nickel. One V.P. asked me (afterward) "Why did you bother?", and my reply was "I never did it for you. I did it for ME.". I found a much better job soon after. :-)



Higher up lie. Client lie. Company lie. Recruiter lie.

It's sad but what you going to do.

Change to another job, man.
Kimball Robinson
+1  A: 

Two words: "Different" and "Interesting"

When commenting on an existing system/codebase that is crawling with fleas, it is not always a good idea to openly express such opinions. You may later discover that you've criticised the work of either your client (cause enough offense, you'll potentially lose the client) or colleague (offend your colleague, while creating justification for your client to ask for the flea-ridden system to be fixed at your expense). Instead, say things such as....

Well, its interesting to see that someone thought a bubble-sort algorithm would be the best solution here...


If I had been involved in the solution design, I might have recommended that we do this differently.

NB: If too many of your colleagues/clients become aware that you use this strategy to soften your criticisms, the strategy becomes worse-than-void, due to the fact that when you genuinely find something interesting (as opposed to interesting), you may find people inexplicably upset with you.

+1  A: 

you can contribute to your own downfall


Communicate to the person who is in front of you at the moment. If you don't know their level of knowledge and preferred communication style, find out and take notes.

J.T. Hurley
+1  A: 

Be prepared to reinvent yourself every five years.

Mark Harrison
  • Never be afraid of saying: "No, I won't fix your computer".

  • Don't mention any skill you don't really master in your CV.

Moayad Mardini
Also... Don't mention any skill you no longer want to work with in your CV ;-) Sometimes you simply have to do a (small) job with a certain old / dull / stupid / uninteresting / unknown technology which can become a niche on your CV... Managers pick up on this too fast ;-)
Johan Pelgrim

Be humble.

  • Other developers have more experience (or different expertise) than you
  • "Whate'er thou art, act well thy part." Whatever your responsibility or role, learn to do it well.
  • Juniors will know things you don't
  • You will know things experts don't, but keep some perspective when you find out what those are.
  • Always keep learning
    • What you think you know will hurt if you're wrong, so be humble
    • What you don't know you don't know will hurt, so be humble
  • You are not a representative user.
    • Your preferences and great ideas might not be what's needed.
    • Do user testing.
  • Don't get doctrinaire about best practices, but don't discard them either.
  • Ask for help, reviews, opinions, etc.
  • Pray.
Kimball Robinson

Gathering system requirements from business folks can be very difficult, so help yourself out.

  • Meet face-to-face if at all possible.
  • Pay attention to body language and facial expressions.
  • Use clarifying statements ("so what you're saying is...").
  • Don't try to read the other person's mind. If you find yourself about to make an assumption, stop and ask the question that needs asking.
  • Diagram the process using sticky notes or a whiteboard - make it visual.
  • Be honest, polite, and direct.
  • Don't be afraid to show ignorance of the business process, even if you think you know it. Let the business expert explain it.
  • Unless you're dealing with other technical people, don't blow their minds with techno-speak - it'll shut them down.
David Anderson