How to make sure I understood a work assignment correctly?

Question

Due to my conditions as Aspie, I noticed quite a few times, in working environments, that I have a big communication barrier when it comes to task assignments. Most of the time, I have to work on a project multiple times, as the assignment was meant differently as I understood it. The main problem here is that I'm failing to understand the scope. Or I'm not aware of solutions for problems I just encounter while work is in progress.

A classical (but technical) example that should demonstrate it quite well. I once was designing a visual analyzing tool in Qt. One of my written tasks read like:

Visualizing the main graph in a Qt frame.

So, my project had an additional Qt frame object to be added, as I was new to Qt, I looked up the capabilities of that specific Qt frame object, found that it is able to initialize as an OpenGL frame (what technically, as I know now, works differently as the Qt one). So I realized the whole feature with an OpenGL frame, loaded into the Qt frame. Afterwards my boss wasn't so happy, as he dig up the written assignment and told me, how I can come up with using an OpenGL frame, if we wrote down "in a Qt frame", probably this is the common sense I'm missing, as I can't understand how using an OpenGL frame as feature of the Qt frame, violates "Visualizing the main graph in a Qt frame."

Most of the time, I get the following advice: "But if you aren't sure, just ask!". But I was sure. I wasn't aware that the Qt frame had other means to solve this problem. I just found a way to solve my problem, that respects (supposedly) the requirements. So why should I go on searching for other means to solve it? And if doing so generally, how would I know, when I found the best solution and can stop looking for others?

So how can I make sure having understood a task correct, where I lack the experience to know what ways are available to solve the task and my boss thinks he is clear enough in his wording?

Answer 1

But if you aren't sure, just ask!

This. Because, currently, your approach is:

1. get an idea of how it shoud probably be (with the possibility that it is wrongly understood)
2. dig deeper and deeper to find a way out.
3. find a (wrong¹) way to fix the problem.
4. get in trouble with your manager (who gets angry because you waste both your time and company's time + energy + money).

^{1: By your manager point of view, because it doesn't fit their requirements.}

So, follow your manager's advice. But, and here is the point, not like you do right now!.

I teach technical and safety issues to people who know nothing about them. So, when I do it, I use the old trick of the game where someone has to let you figure out what they're thinking, without saying it namely. I modified the rules here, to fit my needs. It's all based on 20+ years of experience and improvement. And works like a charm.

"What you understand well, you enunciate clearly", said French author and philosopher Nicolas Boileau. So, what I do, is explain something to someone, then have this person, with their own words, explain the same concept to someone else, who didn't hear us first.

If you can explain it, you understood it. If not, listen again, and try again...

My advice is to apply this to yourself. Get the task, and rephrase it with your own words. Then, go back to your manager:

Hi boss, you asked me to do X. I plan on going this way : A / B / C. Is that correct, and what you expect from me? Otherwise, I could also go with D / E / F. What do you think? Is it better or not? Thanks for the feedback.

From here, he will let you know. And you'll know if you properly understood or not.

Answer 2

But if you aren't sure, just ask!

I'd like to rephrase that to:

If you think you know how to solve it, discuss your solution with a team member. Ask a team member if they think your proposed solution is the way to go, or whether there are other ways to do this.

I'm a junior software engineer and still learning a lot. What's done at my workplace, to prevent me from doing the 'completely wrong thing/the good thing in a completely wrong way':

• At the beginning of a story, I team up with a team member.
• I read the story, and as soon as I have an idea about how I'm going to implement it, I give a signal to a co-worker.
• We discuss the solution, whether it's in line with the scope of the story and the existing code-base, and I get a go/no-go,
• What's even more important: I get advice on how to solve it correctly/feedback on whether I interpreted the problem correctly.

This is, as Erik pointed out in the comments, very different from 'pure' pair programming, but the principle stems from it, I'm sure. It's a very good way to get/give feedback and make sure that what needs to be done gets done.

So how can I make sure having understood a task correctly, where I lack the experience to know what ways are available to solve the task and my boss thinks he is clear enough in his wording?

I don't know if it's possible for you (it requires some energy/social interaction) but if at all possible, ask your boss if he would allow you and your co-worker(s) (maybe even 1 designated person), to do the sort of pair-programming I described above. You could even do this together with your boss, although he might not have the time to spare.

If both you and another programmer don't understand what's supposed to be done (or have very different opinions on it), you go to your boss for clarification before implementing the story. Present him with both your opinions and have him make a decision. (In my team, there's a technical lead for this as well).

Especially if you lack experience, you'll need a mentor, a navigator. With experience also comes the ability to understand better what your boss means because you get to know the limits of the code-base. Until then, you'll need an interpreter/guardian to guard you against doing things 'the wrong way'.

---

In response to your comment on 'how to implement this'. First, ask your manager boss:

Hey, as you might know, my Aspergers frequently causes me to misunderstand written things, or take things too literally. There is a workaround for this that basically means that once I think I know what I'm supposed to do, I run this solution by another co-worker and ask their approval. That way, we prevent me doing 'the wrong things/good things in a wrong way'. It saves us a lot of time in the long run, and as I get to know the style of communication within this office better and get more experience with the codebase, it even might take less and less time (until it approaches a sort of 'minimum required effort', since it will probably always be necessary for you).

Basically, how you implement this:

• Ask your boss to allow this sort of pair-programming. Mention a lot of the good points (as above).
• If your boss is okay with it, have him tell co-workers that they're expected to do this with you. (Ask him to do so, don't order him around)
• Make sure you can explain to your co-workers what you're expecting of them (what their role will be): feedback on proposed solutions/a nudge in the right direction if you're on the wrong track. They're not supposed to do your work for you.
• If you have a favorite co-worker (maybe somebody that understands you and your Aspergers a bit better than the rest?), ask them if they are prepared to be your 'standard' go-to person.
• If that's not possible, for each story, ask who is the most knowledgeable on that part of the code-base, and ask them to discuss the implementation of that story with you.

Answer 3

When your boss wrote "Visualizing the main graph in a Qt frame" he probably had a clear idea of how he wanted you to do that, but you can't read his mind. Also, the statement is very short and terse, prone to misinterpretation. Don't blame your Aspergers too much here, everyone would probably be scratching their heads on this one.

So you could have asked for clarification, like "Did you already think about a way to code this? If so please tell, it will save me time." or "What would be your preferred way to implement this?"

In this case the boss would spend 5 minutes to write a more detailed description of your task, saving you several hours in research, which is a good tradeoff.

You could also force yourself to come up with two solutions. Having Asperger could make this a bit awkward, but please hang on.

So here you found a solution with an OpenGL frame. Write a short description of it using your own words while it's fresh, then push it away to the back of your mind, and look for another solution, dig into the docs, it's OK to ask your colleagues (or even stackoverflow). In this case you could have dug deeper into the Qt frame docs.

You don't need to write all the code for both complete solutions, just have a vague idea of how you're going to do it, maybe a diagram on paper with a few notes.

After this write a short description of the other solution, and ask your boss which he prefers. Describe advantages and drawbacks to each solution.

Giving him a choice between two options gives a legit reason for you asking for his help, it should also flatter him a bit that you value his authority.

Also, when you find a solution... everyone has a tendency to think their first idea is the best and only possible solution. So when you have this first solution, play devil's advocate and find all its flaws before implementing it. Maybe you'll find enough to make you think your time will be better spent digging for another more practical solution that wasn't initially obvious. Anyway, having only one option should be a bit suspicious, it's an indicator that you haven't considered other, maybe better choices.

Answer 4

I recently had an interview at a company, which is very sensible for the topic autism at work.

And not understanding work assignments correctly if not specific enough given is a problem they are very aware of from their aspie employees.

He told me about the tools he developed to get along with it, to see if I could make use of them.

And one of them was just something I literally fell in love with.

One of the tools he mentioned, was making not just TO DO lists for work assignments, but also making NOT TO DO lists.

He also mentioned, that he has not had an aspie in his teams before, but he figured this system is also helping his developers not being affected by autism.

I understand that this solution is something thats not easy to learn for an superior who is not open for it.

So my OP requirement of my self being able to bring that system into the position isnt fulffiled by this answer since it requires effort of the person supervising me.

But still I find this brilliant enough to be worth a answer on its own.

Answer 5

... But I was sure. I wasn't aware that the Qt frame had other means to solve this problem. I just found a way to solve my problem, that respects (supposedly) the requirements. So why should I go on searching for other means to solve it?

I'll comment on this part because I've seen it a lot with developers:

1. They take the first option they find (or the first idea that pops into their head).
2. They spend a lot of time on it before getting feedback.

Choosing the first thing they find is usually bad because it means they haven't thought about the problem and the trade-offs. The result is a lot more work (short term and long term).

Spending a lot of time is a problem because they don't realize there are problems until after the time is already spent.

So, before you start coding, spend a little time to find three options and try some basic examples using them. Then present those options with a recommendation and let your manager direct you from there.

And if doing so generally, how would I know, when I found the best solution and can stop looking for others?

This will take experience to develop. But if you can find three options, you can select the "best" from those and know that it is at least better than two others. The act of choosing will require you to think about trade-offs, which will help you become a better developer. And, it gives you a point of comparison when getting feedback, particularly if you missed something.

• Bad: "I know it's been 30 seconds since we talked, but how do I do this?" (No initiative)
• Better: "I spent 3 days on the first idea that came to mind. What do you think?" (Initiative, but no forethought)
• Best: "I spent a few hours (or a day) looking for ways to do this, and here are some options. I like this one most because x, y, and z. What do you think?" (Initiative and forethought)

Answer 6

This sounds very familiar (I have an aspergers diagnosis myself). I would be sure too, in the situation you described.

In the company where I work, we have a general rule (not specifically for aspie workers) to show the result at about 80% of the time allotted.

I personally have adopted it as to show my work when I think I am about 50% done, regardless whether I feel it's good/right or not. In my experience, this helps a lot to stay/go back on track.

Answer 7

When you are provided with less information, you are bound to make assumptions.

I would advice that you solve this problem by

Revisiting and Confirming the Assumptions

The way that you do this is simply by asking confirmational questions

Simply, think of every assumption that you have and confirm it.

Starting with assumptions that are most likely to be untrue.

Answer 8

Increase your chances for feedback

Currently, the issue in your workflow appears to be that you take a task on and complete it if possible - working in isolation until you reach a blocker. As you mention, you've been told to ask if you are unsure - but don't because you did feel sure. This is not a good way to work.

For any problem solving task where there may be multiple solutions to get the end result, it's important to involve people at as many steps as possible.

Understand that asking for feedback is not asking for help

Asking for feedback does not mean claiming not to understand what you are meant to do, or asking questions to get a better understanding. It is not asking them to do you a favour by asking for advice.

It means inviting somebody else to give their opinion on what you're thinking. This is giving them a chance to be involved in your process, and offer their opinion. You should view this as a good thing for them - you are including them in the decision making and giving them a chance to voice any concerns.

With that in mind, it should be clearer that providing more opportunities for feedback will generally be received well by your colleagues and not seen as pestering them for help.

Plan for feedback during your development cycle

So as this is a good thing for your colleagues as much as yourself, it should be clear that asking for feedback more regularly is a good thing. As such, you should mentally schedule time into your planning for when you will ask for feedback.

Some example times it might make sense are:

• After initially reading the specification

• After doing initial research into the problem and finding potential solutions

• After prototyping areas of the problem and finding out new information

• After settling on a final implementation, before fully implementing it

• After completing the minimum implementation, before signing off on it

Depending on the situation, you may want to offer more or less opportunities for feedback. But you definitely need to offer it more often than you currently do. Remember, you are not asking for help - you are giving your colleagues a chance to be involved.

How to ask for the feedback

Now that you've got a plan for getting the feedback - it's important to focus on what you wish to get out of it, and how you can best invite people to give it.

When asking for feedback, I'd suggest including the following:

• Give people a rundown of what you have done so far (which may just be "I have read the specification, and understood it as x")

• Describe what option you think is the best contender ("I was looking at implementing this using an OpenGL frame, which should allow us to do x,y")

• Explain what concerns you have ("But I gather that might be a lot of work" or "Although I'm not sure it's the best, I haven't found any alternatives")

• Invite them to give their thoughts ("Do you have any ideas on this?", "Does this seem sensible to you?", "I know you have experience with y, does that make sense to you?")

The process doesn't need to be formal/written (although it can be if that works best for you), it can just be a quick "Have you got 5 minutes to check some things over with you?" conversation.