5 ms·

There's clearly one very easy fix that nobody seems to have mentioned so far: Communicate in a better way. I found that the overall performance of a programmer

by WA 13y ago

There's clearly one very easy fix that nobody seems to have mentioned so far: Communicate in a better way. I found that the overall performance of a programmer is very hard to judge from the outside, especially from less-technical managers. But managers are there to allocate resources and track progress. Tracking progress is the most single crucial thing for them. They want those tickets closed and they don't care about the bug. They don't understand that 1 line code might take a week and at other times, you do 500 lines of (easy) code in a few hours. Getting a negative review could mean from the manager's perspective: You don't appear to make much progress. The solution then is not necessarily to become faster (although that might be an issue as well), but to learn to communicate in a manager-oriented way. This could be a very simple status update email once per day and a summary of progress once a week. Don't communicate weakness ("I'm very slow at this"), but problems and their solutions. E. g. "The multi-threading task was implemented in a very inefficient way before. Occasionally, it leads to errors that are very uncommon and thus hard to trace. I'm working on it and I have an idea for a good solution that will increase performance as well, but it might take a bit more time." Or turn the task back to him: "I can't reproduce the error in a reliable way. Could you please provide test cases / test data that lead to this error?" These might be some more or less contrived examples, but you get the gist.

dvanduzer 13y ago
I'm going to read the rest of this comment about the "very easy fix" of communicating better, and then edit my reply if I think there's anything else to say.
- mikevm 13y ago
  > I'm going to read the rest of this comment about the "very easy fix" of communicating better, and then edit my reply if I think there's anything else to say. I'm going to reply to your comment, so that in case you will say something worthwhile in your future edit, I could edit my reply to your reply if I think there's anything else to say.
  - dvanduzer 13y ago
    I was quite honest about what literally happened there. If you truly believe that learning to be a better communicator is extremely easy, why would you need to state that prior to several paragraphs of explaining how to be a better communicator? Ask any educator about the effectiveness of lectures beginning with "X is easy, just follow these 5 weird tips!" Either the 5 tips are trivial, or you were lying about it being easy.
    - WA 13y ago
      Becoming a better communicator surely requires practise, but there are some very easy steps that produce instant results. Short daily status emails and/or weekly email status reports are EASY and yet it isn't done by all developers. This is waaaay easier than improving your skills on debugging multi-threaded systems. The latter is definitely a noble goal, but will fail short if you don't even write that stupid status report once in a while. And yes, these tips are utterly trivial but nonetheless important. Do you write status report emails?
      - dvanduzer 13y ago
        I do write status report emails, but that kind of communication has operated very differently at every different organization I've worked in. I'd assume the department responsible for debugging kernel driver bugs is far less interrupt-driven than the operations-oriented departments I base my experiences on. The common thread though, was usually about prioritizing between the work we already roughly understood how to do. The more common communication failures were about coordinating and scheduling. But when you're doing something specialized enough as debugging multi-threaded embedded drivers, and you have a specific metric like bug closure rate, then all of that information is already captured in the bug log. The first response in the Ars thread says that keeping detailed notes for yourself is both a powerful tool to help you learn, and also a tool for communicating in very specific ways with the rest of the department. One reason better communication isn't a "very easy fix" is that multiple people are involved, and you can't just force everyone to pay attention to all the relevant information already available. Alternatively: I worked on a small development team / startup with daily stand-ups that would tend to last 15 or even 30 minutes. Not a single person in the room ever seemed to know what they were going to say prior to opening their mouths. No amount of "leading by example" seemed to convey the concept that summarization is the most important feature to communication in daily status meetings.

by WA 13y ago

dvanduzer 13y ago

I'm going to read the rest of this comment about the "very easy fix" of communicating better, and then edit my reply if I think there's anything else to say.

mikevm 13y ago
> I'm going to read the rest of this comment about the "very easy fix" of communicating better, and then edit my reply if I think there's anything else to say. I'm going to reply to your comment, so that in case you will say something worthwhile in your future edit, I could edit my reply to your reply if I think there's anything else to say.
- dvanduzer 13y ago
  I was quite honest about what literally happened there. If you truly believe that learning to be a better communicator is extremely easy, why would you need to state that prior to several paragraphs of explaining how to be a better communicator? Ask any educator about the effectiveness of lectures beginning with "X is easy, just follow these 5 weird tips!" Either the 5 tips are trivial, or you were lying about it being easy.
  - WA 13y ago
    Becoming a better communicator surely requires practise, but there are some very easy steps that produce instant results. Short daily status emails and/or weekly email status reports are EASY and yet it isn't done by all developers. This is waaaay easier than improving your skills on debugging multi-threaded systems. The latter is definitely a noble goal, but will fail short if you don't even write that stupid status report once in a while. And yes, these tips are utterly trivial but nonetheless important. Do you write status report emails?
    - dvanduzer 13y ago
      I do write status report emails, but that kind of communication has operated very differently at every different organization I've worked in. I'd assume the department responsible for debugging kernel driver bugs is far less interrupt-driven than the operations-oriented departments I base my experiences on. The common thread though, was usually about prioritizing between the work we already roughly understood how to do. The more common communication failures were about coordinating and scheduling. But when you're doing something specialized enough as debugging multi-threaded embedded drivers, and you have a specific metric like bug closure rate, then all of that information is already captured in the bug log. The first response in the Ars thread says that keeping detailed notes for yourself is both a powerful tool to help you learn, and also a tool for communicating in very specific ways with the rest of the department. One reason better communication isn't a "very easy fix" is that multiple people are involved, and you can't just force everyone to pay attention to all the relevant information already available. Alternatively: I worked on a small development team / startup with daily stand-ups that would tend to last 15 or even 30 minutes. Not a single person in the room ever seemed to know what they were going to say prior to opening their mouths. No amount of "leading by example" seemed to convey the concept that summarization is the most important feature to communication in daily status meetings.