How to Dickson
Welcome to my personal how-to. If you're reading this, we're currently working together or will be soon. This is a guide to me and how I work - what to expect out of the average week working with me and my personal guiding principles. It was written to accelerate our working relationship and to avoid misunderstandings in the course of our work.
If what you read here is not what you get, please let me know. This is a living document and I'd love to receive feedback 😊
These principles shape my thinking and decision-making processes.
- Cause: I will only work on products which I personally believe in. For example, I'll never work on a product that serves ads even if the technical challenge appeals to me because this is the antithesis of what I believe in.
- Engineering excellence over delivery: I'm an engineer first and foremost. This means I will often prioritize aspects like code quality, performance and testing over product delivery. That said, I see the necessity of reacting quickly to urgent and critical situations, but there should be a plan for paying off any technical debt incurred when doing so. If you see me going too far with this though, I'd be grateful if you point this out.
- Understandability first: modifying a running system requires an understanding of how the system works. Code is read many more times than it is written. When understandability is at odds with performance or verbosity, I'll always choose understandability first. You'll also see this influence how I review or author merge requests.
- Writing: writing is not only an important communication tool; it also makes the development of complex ideas possible. When raising merge requests and writing code, I'll tend towards being more verbose for the avoidance of ambiguity or doubt that arises from this lossy transfer of information.
Feedback: I am objectively unoffendable when receiving constructive feedback. I'd really appreciate your candor and objectiveness. If they're things that I don't understand, I'll be happy to discuss it over coffee if you're open to doing so1. Likewise, I'll reciprocate if you're open to receiving feedback as well.
I believe in offering praise in public and criticism in private. It's also much harder to provide negative feedback to someone if that's the first time any feedback is being provided. Hence, it is my habit to let you know if I think you've done something well.
I hate attending meetings as much as anyone else. Here's what I'll do to make it as productive as possible if I conduct meetings. I hope that you'll do the same.
Send presentations a reasonable amount of time beforehand: if slides are used, a lot of time is wasted if the meeting is the first time attendees are reading the slides. It also causes the slides to compete with the speaker for attention. This will enable more productive discussions to happen during the meeting.
If I've read the slides beforehand, I'll come with questions. If not, I'll tell you so.
Meetings should have a well-defined objective: it should be clear why each person is there. I'll ask for clarification if I'm unsure why I'm in a meeting.
- Written communication: there should be some form of lightweight written communication to summarize the outcome of a meeting if needed. If I'm facilitating a meeting, I'll take notes.
- Timebox: meetings should always be timeboxed. If it's clear that more time is needed to achieve the intended outcome, end the meeting and arrange for follow-up action.
- I use headphones to avoid distracting others around me with the output of my screen reader. If you see me with headphones, this is not a sign that I shouldn't be disturbed - feel free to talk to me. If I need a block of uninterrupted time, I'll enable Do Not Disturb mode on Slack.
- If you're asking me about something with reference to information in a screenshot, I'll ask that you copy and paste the piece of code / log / error message etc first. This makes it much easier for me to read and also has the side benefit of making its contents searchable on whichever instant messaging solution we're using.
- I work after office hours as well as on weekends occasionally. I may send you messages after working hours but do not expect an immediate reply. Feel free to respond to it on your next working day.
- I get carried away especially if I feel strongly about something during a meeting. If I'm speaking for too long and taking too much time out of the timebox, please chime in and tell me so. I won't take it personally 😊
- I'm an introvert by nature and being around too many people exhausts me. I work best in a small group of not more than 10. If I'm silent, I'm still recharging from a previous interaction involving a larger group.
- I don't work to well when pair programming because I find that it interferes with my thought process.
- I love to start new things but might sometimes lose interest if I get distracted with an influx of work or new ideas that are likely to come to fruition more quickly. I'm working to get better at this. Let me know if you see this happening.
There are no stupid questions, only questions asked without effort. We all start from somewhere and admitting that you don't know something is the first step to move from Unconscious incompetence to Conscious incompetence and later to Conscious competence2. There will also inevitably be things that you couldn't have known especially if you're a new team member.
I am more than happy to help if the question clearly demonstrates that some effort has been made into finding a solution first. However, I get triggered if you ask questions without effort especially if you expect prompt replies. For example, questions that have solutions readily discoverable on Google.
These are things that had a major impact on how I think.