0

Maybe it is my lack of comprehension with the spoken words in general, and my lack of ease with the native language spoken at my company especially, but I wanted to ask, is it normal to be given or explained software tasks verbally.

Most of the time, I am given tasks where someone explains to me verbally what needs to be done. The information is usually pretty specific, like:

From which process you need to expose what variables and from what task you can then access these variables but you have to be careful about conditions x, y and z. And then when you have done this, this information can be passed on wards to the GUI using this pointer from there and then you cast it back and from the context of the original task you can call ... and on and on it goes.

And as I hear all of this trying to hold all the bits in my head, I usually end up missing some important bits inevitably (like those two variables that were mentioned by the task-giver, I thought he has introduced them in the code already, while in fact, I was supposed to add them for him). And so instead of landing in India, we end up on Hispaniola.

Next thing I hear as feedback, is,

Maybe this [work/task] is too difficult for you.

Maybe this is way above your head.

(Just to be clear, it is not a question of comprehension. I often interrupt and repeat what the task assignee has said to me, in my own words back to him, with the interjection that "I hope I understood that correctly then.", and he says, yes, that is what/how he wants it to be done. If I had the opportunity I would jot down some notes, but still, is this the state-of-the-art industry practice for assigning tasks?)

Why do we have redmine then for example, if nobody ever bothers to use it? (Even if I come back to my seat and write the issue myself (as well as I can recall), no one bothers to look into it. No time. Too busy. Too much bla bla on redmine, they say.)

Or maybe this is totally normal behavior at other companies also, that tasks are explained like little verbal puzzles with the half the things done by someone else and the missing bits need to be filled in by me, using those verbal clues provided?

Also how healthy [and common] is it really to have a codebase where everyone has their fingers in every module? I have had experience working at other places before, where I was the sole owner of a module. We agreed on some interface which the other developers would expect from me. We had static code checkers for quality control. We had code reviews [for quality control]. But what happened within that module was my choice. While the architect/integrator took care of overall balance. Was that an exception?

I have been tolerating the situation for a while now, but I think a parting of ways is inevitable.

Improve this question
6
  • 1
    What exactly is your question? "Is this common practice?" Or do you want to know what you can do to tackle it? To answer the first one: Probably not; it would be highly unusual if there was no written record anywhere of the tasks - does this exist, and if so can you access it? It's difficult to answer the second one without more info. What is your relationship to the task-giver(s)? Are they technical? You could summarise your understanding in written notes, and then email it to them asking for confirmation that it's correct. That way you have some insurance if they come back complaining. – Touchdown Aug 10 '20 at 15:46
  • Thanks for your feedback. My questions is the first one: "Is this common practice?". – user97827 Aug 10 '20 at 15:47
  • Based on my experience and what I've heard from others in the industry, no, it's not common practice to only be given tasks verbally and expected to remember them, especially if they're as complex as you say. If this is the only source of information then I suggest writing notes and emailing back and forth until you and your task givers can agree on a set of requirements, which you can then use as a reference later both during development and acceptance. It may not be efficient but if that's all you have then I guess good luck. – Touchdown Aug 10 '20 at 15:50
  • I suggest writing notes and emailing back and forth until you and your task givers can agree on a set of requirements -> I am afraid I might end up irritating someone and hearing that sentence "this is probably way over your head" even earlier. – user97827 Aug 10 '20 at 15:54
  • 1
    So are people assuming that you're familiar with this codebase when you're really not? In that case, there are two things to be aware of: 1. You will naturally get more familiar with it over time, and 2. It's not fair for them to expect you to automatically know every intricate detail of this codebase after having only just been exposed to it. Even if the tasks are trivial for someone experienced with the codebase, that doesn't mean they're trivial for everyone. If I were you I would ask these clarification questions as long as they're sensible and you've researched beforehand. – Touchdown Aug 10 '20 at 16:06
13

I've frequently experienced this, where tasks are assigned by an offhand comment in an unrelated meeting, or a manager or team lead just walking by and saying, "Hey Meg, do when you have the bandwidth." This even happens when working on a team where issue tracking software (Jira/redmine/boards) is used for the majority of work.

After several missed tasks due to my getting distracted/bad memory/too many details to keep in my head, I realized the expectation is that I would immediately translate the information into a reasonable Jira issue, then complete it. Sometimes (often) that does mean puzzling out all the information that would be in a proper issue, talking to the people doing the other parts, research to understand parts of the code I am not familiar with, etc.

I've also gotten in the habit of carrying paper around with me and taking notes, and ending a meeting with my boss by reading back any work I think I've been assigned and asking if I missed any tasks/actions. Then I turn my notes into tickets.

This mostly works because the team overall is expecting work to be entered in Jira. If everyone but you is largely ignoring that issue tracking even exists, it's still helpful in making sure you don't miss anything in your own work, and perhaps useful to you later if you want to go back and see what you were thinking/working from when you made some change 8 months ago, but overall you do lose a lot of the utility of the tracking product if it's being used so inconsistently.

I guess the answer is kind of yes and no: It's very common in my experience for at least some tasks to be conveyed verbally, but uncommon to see such a lax use of issue tracking overall. Single module owners (and the associated 'bus factor' vs expertise trade-off) varies widely by organization, with some places I've worked keeping strictly to owners, some completely ignoring the concept so all devs worked on all modules equally, and some taking a position somewhere between the two, with small sub-teams of devs jointly responsible for several modules.

Improve this answer
1
  • 2
    Thank you for answering all the questions. Much appreciated. – user97827 Aug 10 '20 at 18:57
11

This is quite common, however if you're having trouble understanding, you could either

  1. ask the person assigning the task to you to send it to you in an email, especially if it's complex. (A friendly, "Could you put all that in an email just so I can keep track of it?" or something)

  2. Always have a pen and notepad to hand and write it down as they are speaking - if it's not obvious, tell them that you're just going to write it down so that they can pause where appropriate.

If I had the opportunity I would jot down some notes

What is denying you this opportunity? While it's common practice to assign tasks verbally, it's also very common to make notes of those kinds of tasks!

Improve this answer
5
  • Thanks for your feedback. Much appreciated. – user97827 Aug 10 '20 at 15:47
  • 1
    What is denying you this opportunity?-> the task assignee and the general routine (probably expectation) where such tasks are probably considered too trivial by the people who spent years familiarizing themselves with the code base. – user97827 Aug 10 '20 at 15:52
  • Sorry for bringing this up again, While it's common practice to assign tasks verbally,, -> so it means it is common to not use issue-tracking software like redmine or jira? – user97827 Aug 10 '20 at 16:11
  • @DuckDodgers - Yeah I've worked in a few places where these tracking tools are not used, or where they are only used for big projects. Also if you're new, they shouldn't mind you asking to wait a minute or two while you write it down - they should understand that you haven't spent years familiarising yourself with the code even if it doesn't first occur to them. – colmde Aug 10 '20 at 16:15
  • 2
    @DuckDodgers Verbal task assignment and the use of jira/other are not mutually exclusive practices. A manager may remember to mention the task before having created the task on jira, or having forgotten to, or thought it was already there. It is extremely common for both to occur (eg, my manager will mention the task in a meeting, and make it at the same time). It depends on the manager's preferred method of communication. If I'm given a task verbally that has no corresponding jira task, I will make it, add my manager as a collaborator, and ask points of elaboration that I need clarity on. – stanri Aug 11 '20 at 10:42
1

At the majority of jobs I've had, it was pretty common for people to give me tasks verbally at least some of the time.

Nowadays, whenever someone starts giving me a task verbally, I interrupt them to let them know that I need to write down what they're saying or else I'll forget it. Then I write the task down as they describe it, and if they're speaking more quickly than I can type or write, I tell them to pause for a moment while I'm writing. After they've finished describing the task, if I'm not 100% clear on what I've been asked to do, then I ask questions (and write down the answers) until it is 100% clear.

You might feel like you're being rude or wasting their time by interrupting them or asking them lots of questions. But keep in mind that since they're speaking to you, that means they want to spend some of their own time in order to make it so that you have this information. It's much better to make sure you have everything written down to begin with than it is to have to go back and ask them to repeat themselves later.

If your workplace has a "general routine" of not writing stuff down, then break the routine. It's your least-worst option.

If I'm in a situation where, for some reason, I'm unable to write down what I'm being told to do, then I let the other person know that I'm going to need written instructions or else I'm going to forget them.

Improve this answer
1
  • Thank you! If your workplace has a "general routine" of not writing stuff down, then break the routine. --> I aim to do that from now on. Otherway, it just doesn't work. Indeed being rude or causing inconvenience was the main thought I had had. I will push and see how things improve. – user97827 Aug 13 '20 at 8:57