Techniques For Describing/Translating What You've Been Doing All Day

Question

Come the stand-up meeting every morning I frequently (usually during early/mid code iterations) have difficulty describing exactly how I created value for the company the previous day.

The words out of my mouth usually sound like "I further iterated the code". Which, while true, is pretty undescriptive.

I think it comes from my inbuilt "tech translator" which has built up over the years as I have learned that if I actually say what I did that day, peoples' eyes glaze over and they lose interest because it's too complicated/technical.

Plus, I may be a cynic, but I often feel it would just take too long to explain why what I did was necessary - and in any event, often what I did is based on intuition/experience/a-feeling-I'll-need-it-down-the-line rather than any coherent satisfying soundbite.

Does anyone else have this problem, and if so how do they deal with it?

Answer 1

Firstly, it is a good question to be asking, and lots of us have this problem. There are two questions hidden here really: How do you translate technical things for a non-technical audience? How do I determine the actual value of my work to the company?

Question 1 is something that gets easier with practice, and it is worth practicing. Often we can't explain things well because we don't understand them well ourselves. If I'm interviewing a PhD, and they couldn't explain their thesis to me, I used to think it was because I was too stupid. But having met a lot of very smart PhDs, the best ones are the ones that can explain it to me, and they usually understand their subject the best.

Imagine explaining to someone non-technical who you love, eg your spouse, parent or child. That way you will hopefully be pre-disposed to be patient and clear without being patronising.

Question 2 is a great question because it can stop us wasting time. A couple of follow up questions are useful here. How will this help me or someone else do something faster? How will this allow someone to do something they couldn't do before? How will this relieve frustration for someone? Nearly all programming benefits come from the answers to one of these questions.

Answer 2

In your team, how is work assigned to individuals? By the project manager, self-selected, done in the team discussions?

How do you know what you're working on, and why? I have to say this:

intuition/experience/a-feeling-I'll-need-it-down-the-line

is a bit of a concern. If you don't know why you're doing something and how it contributes to the overall project (even if that contribution isn't immediate) why are you doing it?

When you check in the code that results from your activities, what change reason are you going to give? "felt like a good idea at the time"?

Paul.

Answer 3

I empathize, I have a similar dilemma except not with explicitly technical things.

I find as a product of working in programming spending much time dwelling on abstract concepts when it comes to serialize/flatten these abstractions of the mind, they arrive at the mouth and implode into nonsense.

I often find my vocabulary the limiter, the language that has to be used to describe the abstract is incomplete. How do you explain things such as knowledge you obtained solely through years of observation and cause-and-effect and intuition that outside patterns you cannot back with any rational facts?

I often get inklings that the way a certain code or path is flowing just feels bad, and I can't say why, and when I'm right, I just go "told you so".

I feel in some cases, we may be doomed to have this problem, or cease to be good at what it is we do.

Outside this, the only thing that only half works is by having a semi-technical person whom knows the problem domain, but doesn't have to get their hands dirty, and is good with people skills.

Most the time they'll find a good way to make up something that makes sense to your target audience.

The other 'half' work part, is when you hear them explain it, and they didn't explain what you did, then and only then can you know that its wrong, and you tell them, and hopefully they'll learn. ( The effect of somebody else explaining what you did is somewhat clarifying )

Answer 4

mitch - isn't the context of the stand-up based on all other devs being present??

in these situations, i find that it's beneficial to evolve a technical shorthand in order to quickly describe an issue, so that someone else in the stand-up can give an equally succinct and quick suggestion as to possible solutions. otherwise, i think you face the dilema that you've just described.

i'm sure others will contibute concrete examples of this if it's part of their experience but i know that in our shop, we use little buzz-words to encapsulate 'generic' descriptions of the type of problems that we are facing and/or what we've achieved.

Answer 5

Another idea. Presumably you are at stand-up meeting with other developers sometimes. And hopefully some of them are better than you at this. Listen carefully to what sort of things they do, and then copy their example. Maybe ask them for advice. And then add what you learn here, so we all can benefit.

Answer 6

Get a book on software engineering, and pay attention to the process (in particular why a developer role overlaps with design). It will help explain what you're doing when you're not coding and fixing bugs.

Answer 7

Try to make some simple variation at first. For example there may be slightly better and slightly more complicated tasks. So you may say one day that work goes on ahead of planned schedule. And other day that you do good work handling tough assignment well. Next do some more simple variations. You have nothing to loose, so it probably not so important how long it would take before it becomes really advanced reporting which will impress everyone.

Answer 8

My limited experience (at least in a large company) is that many managers don't care about the specifics but rather about the metrics. In other words, if there were X open issues on day Y, they want to see that there has been progress on some of these issues by day Y+1 (ignore open issues for now). They need to show the trend to their higher managers, etc.

A good methodology for tracking tasks and issues and features (e.g., consistent use of bugzilla) can then help: you can simply enumerate the issues you've been working on (especially if titles are meaningful), and then explain your contributions in each.

The team can eventually build a routine for these meetings where everyone reports this, and the manager asks for details only if necessary and often offline, where everyone else doesn't get bored with unrelated details.

It's also useful because people get a sense of expertise and ownership in the project.

Answer 9

Are you using cards for each task that you are working on at the moment? If so, then perhaps the issue lies in saying how far through a card you are rather than getting technical or non-technical. There should be a way to say that you did this step on this day as if you are repeating what you said the day before there is the question of, "Are you making progress?" as while sometimes there can be something that will be a week's worth of work and you may state that you are at x/5th of the way done, there should be some way to check that this is in fact how things are going.

Answer 10

As a computer science student taking too many CS courses this semester, I have had a lot of difficulty here - to the point that I almost think I need to take an English course. Ahh!!

But seriously, whenever somebody suggests a "usual" problem - maybe social or whatever - I've been translating it too frequently into some of the logic problems I'm always confronted with. And that level of formalism naturally makes me sound either arrogant or incredibly nerdy - both of which do not contribute to my communication skills.

If people are not going to get whatever you are working on, don't bother explaining it. The goal is to make it sound similar to some hip web technology that people ARE familiar with. Face it, nobody could have predicted the various dynamics that reshape the world (not just web stuff, but otherwise) - so the best you can do is liken it to something cool.