- Idea: Use DnD with a timer for a pomodoro/pairing stint.
- Enforce discipline in certain chat rooms, perhaps even have a code of conduct. E.g. no chat in notifications rooms; keep "for fun" discussions in a separate room.
- When pairing, as a senior dev, you can slow down and ask the more junior dev to explain how this or that works.
- New (especially junior) devs on a team do not know if they fulfill your expectations, so explicitly inform them what your expectations are and follow up on how they're doing.
- Can run usability tests, e.g. task someone to perform a task in a limited amount of time, see/ask what is difficult.
- Retrospective interviews, "What was difficult?"
- One team puts up post-it notes (and adds +1:s) to track painful places in the code. And act on the worst ones. When they fixed one of the hotspots they found several bugs.
- We talk about "good design" but don't measure it. Do we even know what we mean when we talk about "good design"?
- Code review can do a lot
- "Don't make me think!"
- "It's not the users fault" – so it's not the code reader's fault, although…
- …we also need to educate people and have some baseline. Like the legal concept of a "reasonable person". Not being the target audience (eg a Python dev on a Java project is not the target audience).
- Affordances. Comments ≈ "press this button" notes.
- Tests ≈ use cases, user stories?
- There is a book: https://leanpub.com/usablesoftwaredesign
- In review, instead of "your code is not clean" try "it is hard for me to understand"
Parallels between training as an athlete and training as a developer.
Interval training ≈ katas.
Do it slowly and with good technique first, then add speed.
When driving, you sometimes need to slow down (into a corner) to go faster (out of it).
Role-played example where team mate A wanted team mate B to start being on time for standups.
In the first scenario, A said "you're always late" and so on.
In the second scenario, A was empathetic and approached it more like "You missed a funny story by C at standup today. Sorry you missed it."
A revealing self-correction: "Can we help you be on… be in the stand up?" Started saying "be on time". "Be on time" is what A wants. "Be in the stand up" is what B wants.
Everyone has an "emotional bank account". When you do something that is important for the other person, you make a deposit. E.g. give a rare book to a book lover. (If the book lover gives away a book, that may not be important to the other person.)
Achieve success by the other person's metric (not your own) to get capital and be listened to. E.g. your boss's metric.
To gain trust upwards: be transparent (in a way they understand; "transparency" in jargon they don't know doesn't count). To gain trust downwards: keep commitments.
Not everything in a workplace is "politics". "Politics" is when people have hidden agendas and you can't figure out their motivations.
You need to prioritise, focus on a few things. Finding problems isn't the difficult thing. The hard part is picking what you can live with NOT changing. (We discussed this in the context of an appointed team lead picking what parts of that role to focus on, but it of course could apply more widely.)
So many things are about setting expectations. Instead of spreading yourself too thin as a leader, go to your manager and say "I will do X and Y but not V and W. Is that OK with you? Let's find out now and not wait 3 months and then find out that you're unhappy."
Nice syntax in a deploy bash script (I like how it puts options on their own line and front-loads interesting values):
foo=bar
command \
--foo=$fooNeat Vim plugin with different-colored nested parentheses: https://github.com/luochen1990/rainbow
Rubbery Mac keyboard covers for e.g. other keyboard layouts that you can put on or remove in seconds: http://kbcovers.com/