161–170 of 222 posts
Earlier quoted context omitted.
> One big problem I see nowadays is that more people do not care about the details... I think people today care about the details just as much as people used to. It's just that there are so many more details to care about today. The exhaustive CYA-flagging of risks (and similar behaviors) denotes more a problem of how incentive are aligned in that workplace rather than any lack of skill with words.
CYA?
Earlier quoted context omitted.
This. I can tell HR, my lead and skip about how good my communication, soft skills and team work have been this year but come comp review they don't give a crapola about any of that. All they look at is how many sloc I've shipped.
I'm fascinated: does your company/manager truly track SLOC and promote based on that? Or is SLOC here more of a proxy for "features shipped"? Because if this is what's happening, I'd encourage two changes: 1. Communicate differently to HR, lead, and skip - either use different approaches of documentation, or point out different aspects of your contributions 2. If trying various different approaches don't work... leav…
I've done everything you're recommending. CEO doesn't care about any of that. Only metric they care about is money made and code shipped.
They do say they care about communication and apparently track it but I havnt seen it reflected in comp reviews so my conclusion is code shipped is the only metric.
We have sloc and pr tracker stat pages so Im making a guess they are using sloc.
Here is my competing take: The biggest problem I see in developer communication is what I call the "assumed context" problem. As in, you talk/write to people as if they know all about your code, except the detail being discussed. In reality, they usually have much less detailed understanding, and you're making no sense to them. I'm pretty sure this is related to people "on the spectrum" often having low "theory of mi…
I work with a developer* who draws labelled boxes and arrows for diagrams and posts screenshots of code in response to questions I put to him. I can't say I've been able to find more than a handful of places where he's put words together into sentences and paragraphs. Getting useful information out of him is like pulling teeth. Even when he could link to code on the git server, e.g., he doesn't. His screenshots are t…
Here is my competing take: The biggest problem I see in developer communication is what I call the "assumed context" problem. As in, you talk/write to people as if they know all about your code, except the detail being discussed. In reality, they usually have much less detailed understanding, and you're making no sense to them. I'm pretty sure this is related to people "on the spectrum" often having low "theory of mi…
I think this is a big one as well, and would go one step further and say that anyone no matter their place on the spectrum may fail at communication in this way. I bet most junior developers know what I mean, if they've sat in meetings with senior guys talking about something esoteric. One simple trick, I think, is to avoid extensive use of pronouns. A sentence like "Because of that, it doesn't find it there" might b…
In overstated form, my version of the idea is: “never use ‘it’”—because a student just learning mathematical language will have many different ‘it’s in mind, or, even worse, no clear idea of what ‘it’ is. (For example, I'll often see an application of the derivative summarized as “since it is negative, it is decreasing”, which is correct only if you change ‘it’s midstream—but students often don’t realize that they are, or should be, doing so.)
Here is my competing take: The biggest problem I see in developer communication is what I call the "assumed context" problem. As in, you talk/write to people as if they know all about your code, except the detail being discussed. In reality, they usually have much less detailed understanding, and you're making no sense to them. I'm pretty sure this is related to people "on the spectrum" often having low "theory of mi…
The idea that programmers have a poor theory of mind doesn't stand up at all in my experience. I remember once seeing the inbox of someone working as a sales-ledger clerk. It was full of messages with the subject "accounts query", or a small variation of that. The ones with subjects like "query for account ACME-37" were from technical staff. Similarly if I ask "when do you need those figures?" and I get the answer "n…
if you get an email from me, and when you want to follow up you're thinking "what was that phone number I should call?", don't worry, I have already put it in the subject line along with the person's name and the deadline
Someone wrote that code is meant to be read by people, and secondly, by the computer. Lack of writing skill could spell trouble for the quality of the code, should anybody need to read it, days or months later.
Earlier quoted context omitted.
I don't think I am on the spectrum ( I mean, I guess technically everyone is, which is why its a spectrum ), but I do know that I was ..what is a good word.. chastised.. no.. maybe gently admonished for putting up very long detailed summaries with some discussion of potential risks involved in an assumed approach, potential tradeoffs and pitfalls. It really depends on your boss, but I come from compliance world, wher…
I agree (I think). I think the point is that by talking about the details the receiver doesn't get it more - it's more that some details stick instead (and thus the big picture is lost). Thus, the only way forward is to summerize, and then point out that there are details/nuances (but not getting into it). Only if the there's interest in those nuances, then it's relevant going into them. Same as with physics. First y…
Earlier quoted context omitted.
I work with a developer* who draws labelled boxes and arrows for diagrams and posts screenshots of code in response to questions I put to him. I can't say I've been able to find more than a handful of places where he's put words together into sentences and paragraphs. Getting useful information out of him is like pulling teeth. Even when he could link to code on the git server, e.g., he doesn't. His screenshots are t…
Ivwould feel a bit offended if somebody would send me screenshots withoutva word of context. Often times the explanation of the context is a big part of a solution to a problem, or even shows the problem to be non existing.
By the way, I double-checked my assertion that he doesn't use words, in case there were some documents I forgot or had missed. Nope. At best, his diagrams or screenshots will have captions. Those captions remind me of the sort of useless comments we've all become conditioned to ignore.
x = y + z; // set x to the sum of y and zLast year wrote a technical writing advice checklist for engineers called How to ask for help in Slack : https://thundergolfer.com/communication/slack/2021/02/24/how... . I was at Canva, a fast growing company adding 500 engineers a year, and the tenured engineers were getting hit with a lot of questions and help requests. I thought about this list a lot, and believe that maintaining adherence to all 10 checklist ite…
The problem with stuff like this (or ESR's How To Ask Questions The Smart Way) is that they only really get through to the people who care enough to want to improve themselves and their interactions, which is probably like 1%. Maybe it's easier if they're employees. But my overwhelming experience out there in the wild is that people ask terrible questions which can't be answered, because they put zero effort into any…
Just forcing a URL, screenshot + expectation has improved reports drastically. Before, we'd get a partial screenshot that shows some random widget where nobody knows the URL it's from, or what it should be looking like, or whether it's actually something that looks wrong, or just something that's worded incorrectly, or that there should be a link on some term in a text.