1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
---
.title = "Communication",
.author = "Martin Ashby",
.date = @date("2024-03-01T14:40:50Z"),
.layout = "single.html",
.custom = {"comments": true},
---
I believe that in software development, being open and working in the open are crucial to wellbeing and efficiency; even moreso when working remotely. There are 3 things that I think should be communicated: intention, struggle, and progress. Communications should be clear, public, searchable, and regular. This post explains my thoughts on the subject.
## Intent
Communicating your intent ensures that you are aligned with your colleagues. If I write something like "I intend to fix this N+1 query problem in the billing service to reduce page-load times, which will improve our users' experience with billing and reduce our resource usage", this could elicit a couple of different possible responses from colleagues. A couple of examples follow:
A project manager who has attended a recent strategy meeting might chime in: "oh, didn't you hear last week? We're no longer billing customers any more, so that service will be deprecated soon!". This example is contrived; a decision to stop billing customers would probably be widely advertised throughout the company. However, I think that no single person can know every piece of relevant information in a medium to large company, and by advertising your intentions you can re-align yourself with your colleagues early enough to avoid wasted effort.
An alternative scenario might play out like this: a co-developer says "don't bother fixing N+1 issues, we're switching that program to use SQLite so the roundtrip inefficiency of N+1 queries will be negligable". At this point I and the other developer might discuss these two alternative solutions to the problem at hand, and come to some agreement about what the best approach is before either of us starts to actually work on the solution.
This isn't foolproof - it might happen that nobody with the right additional context reads your message, so you go ahead and do the work anyway, and it turns out to be wasted. However, with this approach I think it happens often enough that wasted effort or conflicts are caught early and resolved, to make it worth your time writing a few messages about what you intend to do and why.
## Struggles
Communicating your struggles ensures that you don't stay stuck on a problem that someone else has already solved. If I write something like "I tried to fix the N+1 problem, but now 50% of page loads are experiencing FooException, and I can't see why yet", then a knowledgable colleague might pop up and say "oh, I've seen FooException happen when you ask the database for too many rows with an IN clause".
Of course, before writing the message you should probably _search_ your company's chat for FooException. You might also search StackOverflow or Reddit (or wherever you get your advice from on the internet). If your colleagues are taking the same approach to communication, you now have some additional clues without interrupting anyone else or waiting for a response. This is why I think chat needs to be searchable.
Sometimes you are the first person to see a particular problem. In this case, writing about it is a great way for the _next_ person to encounter that problem to get some clues about it. That next person might be yourself in a few months or years. If the problem is with something that's open source, you should also write about it on the internet somewhere: maybe file an issue on the project's public issue tracker, ask a question on StackOverflow, even post on your own blog; anything that is searchable.
[Linus' Law](https://en.wikipedia.org/wiki/Linus%27s_law) is phrased as "given enough eyeballs, all bugs are shallow"; even just one pair of additional eyeballs on a problem has a good chance of making it easier to solve. By writing about your struggles, you are putting problems in front of more eyeballs.
I think that personal struggles should be communicated as well. If my kids are sick and I have to take a couple of hours away from work to care for them, it's better that my colleagues know that instead of getting frustrated when I don't answer. Be reasonable with this though, people are very variable in how much they want to share about their lives and hear about your life. It's probably better to leave it at "I'm going to the doctor" instead of going into detail on your nasty rash.
## Progress
Communicating your progress ensures that both you (and your boss) know where you are. This is important to keep the project managers happy, and they in turn keep the stakeholders happy (well, at least informed if not actually happy). Communicating your progress can also make you feel good. Especially milestones; it's worth giving your colleagues and yourself a pat on the back when you hit some significant point in a project.
## Downsides & Difficulties
This style of communicating is not a panacea, and there may be significant downsides. For example: your boss might decide to fire you for taking off for an hour a week to look after your grandma's cat. If you had kept quiet, you would have kept your job. Although this example is facetious, it's easy to imagine situations where exposed misalignment causes more friction than simply not communicating.
Some people find it uncomfortable to communicate openly about things they are struggling with, because they fear being seen as incompetent. This is a valid concern.
In both of these examples, I think the problem is the environment, rather than the communication style. Open communication makes you vulnerable, so if your environment is hostile rather than supportive then you will suffer for it.
## Conclusions
I am fortunate enough to work in a very supportive environment, so I try to communicate openly and publicly for all the benefits listed above. So far this is working well.
Disclaimer - absolutely none of this is scientific. I have no measurements or data to back up what I'm saying here, and I have not even gone looking for existing literature on the subject. These are intuitions that I have built up from working in 2 quite different software companies for ~ 14 years. Take any advice with a big grain of salt.
|
