When joining a new team or working with a new contractor, one of the most important things is determining if they are a good cultural match for you and your existing team. This can be quite difficult to get right, and in a world full of people behind a screen all across the globe, it is even harder sometimes.
While I don't believe in formulating human communication and connections, you can refer to this as a playbook detailing me as a professional. It is an attempt to document how it is working with me, my values, my working style, my priorities, management style, pitfalls, and even an FAQ section for your reading pleasure!
If you disagree with something written within, please feel free to open a pull request 😊
I care about the people I am working with. Even if we have our disagreements over work matters, you hate my jokes and coding style, or you are a T'au player, I still care about you. I value and try to foster a working environment where everyone goes home without any unnecessary grief and stress.
This means that if a team member is stuck or struggling, I will drop whatever I can to help. Be it with coding a solution, designing a system, having a shitty day, or what have you.
This doesn't mean that I will happily miss deadlines and avoid work. Consider that a fully working team is more productive than me focusing solely on my work while someone is stuck on a task for three days.
This is something I go over in detail in a few of my posts; please refer to them for more information. Please find a summary below.
Failure states are a failure of the system designer. I will not do something that creates a fail state for the program, team, or stakeholder.
I would highly appreciate the same. In practical terms, giving me all the required information before I start on a task, helping me prepare for a presentation, or letting me know if something is not going as planned if I have a dependency on you.
I respect you, and I believe you are doing what you are doing because you are good at it. I highly appreciate when this is understood by both sides.
Please understand that the majority of my day-to-day work is solving logic puzzles, reviewing existing solutions and optimizing them, and talking about tech. If I am asking questions or challenging something, it's because I want things to be done as good as they can and/or learn more about what is happening.
Respect, similar to trust, is earned, and once damaged, it's hard to recover. I will do my best to raise any issues if/when I feel disrespected, being lied to, or similar. I appreciate it when people do the same.
I know how to be diplomatic, passive-aggressive, cryptic, manipulative, and aggressive and how to go "by the book." That being said, I strongly prefer being as direct and open as possible with the people I am expected to spend a good chunk of my week with.
I highly value direct and timely feedback, getting straight to the point, and being kept in the loop about things.
- I dislike coding alone in front of a live audience. Both as the coder and as the audience. If we're pair programming, let's please make it dynamic.
- I need information to do my job successfully. I also don't know what I don't know. I don't mind discovery / reverse engineering tasks, but please understand it's going to take much longer. I will be miffed if, at the end of it, your feedback includes phrases such as "Why didn't you follow X," "Usually we do it like Y," and "That's not what I meant."
- Sometimes, I genuinely don't know things, and I might not know enough to make an educated guess. It's frustrating for everyone involved if we dwell on it for too long.
- When working with existing processes and solutions, one of the main things I am trying to understand is how they work and why they work like they do. I have my own opinions on solutions and how things should work, but it's important to understand the context before going ahead and changing things.
- I will always consider the end user of the product/application when developing. I dislike doing things just because that's what everyone else is doing or using technology for technology's sake.
- I am very used to working with a variety of frameworks and tech stacks. I can pick up on things quickly as long as I have the space to tinker.
- I often change my working locations as required. I might take my tablet to the sofa to read something for work, go to a cafe to code a feature, or bunker down at my desk with headphones. Please be mindful.
- I am very direct and very friendly.
- I appreciate asynchronous communication.
- I strongly prefer meetings with agendas. If I don't know what the meeting is about, I will probably skip it.
- Before we have a formal technical meeting, I prefer to have a document/POC ready so we have something structured to talk about.
- It doesn't mean I am working just because I replied to your Slack message. Often, I will check my work messages while waiting in a queue, waiting for my coffee to brew, at a restaurant waiting for my food, and so on. If it's something I can respond to in the meantime, I will, but there's a high chance I won't have my laptop with me or the time/space to work on something more.
- When available, I will make use of message scheduling. Often, I might think of something after the standard working hours or something to be discussed at a later date. In those cases, I will send a message with a delayed delivery, usually to be delivered as the first or last thing in the day, depending on the nature of the message.
- I dislike cold calls, be it on my phone, slack, discord, or whatever.
- Unless I am streaming, I don't feel comfortable sitting for hours upon hours in a video call.
- I want people to be able to make mistakes in a safe environment. Experimentation and learning from one's own mistakes are some of the most effective ways to learn and build into something glorious through the joys of multiple iterations.
- I am supportive, but I will challenge you. I want people to fly free and do better than I ever could.
- People and their families are more important than the company. If I ever work in defense, aviation, banking, intelligence, or any other very critical industry, my opinion might change.
- I will provide direct, constructive feedback on a day-to-day basis. Weird middle-management gamer moves and discussing how things are going once a fortnight are not my style.
- Humour is my default reaction. It doesn't mean I am not taking a situation seriously if I joke about something.
- Thanks to my Mediterranean upbringing, I can come across as stronger than intended. I mean no harm (most of the time, anyway).
- I can be quite casual and use a lot of colloquial terms such as "gamer" and "based."
- There's a chance I might not remember your full name, exact job title, or some other detail. I mean no disrespect if I say something incorrectly; unfortunately, my memory is terrible when it comes to names.
- My memory is terrible when it comes to buzzwords, terminology without context, names, and acronyms. Don't be surprised if I don't remember what SOLID stands for, what's the dependency inversion principle, what every design pattern is called, what's the name of the new tool we're using, or the quirky internal product name.
- I don't get offended easily; if you manage it, congratulations.
- Just because I might not share some beliefs with a group of people or care about different causes, it doesn't mean I don't respect them as people or that it gives you a free pass to actively shit on people around me.
- I am not great at small talk; I'd rather deep dive on a topic. I promise I'll do my best regardless.
- If I am breaking eye contact and looking into the abyss or scribbling something, it doesn't mean I am not paying attention to you. I am thinking.
- I often think ahead and have multiple internal debates by the time you've finished talking. Please let me know if something doesn't make complete sense or if something needs more explanation.
The M18 Hellcat tank destroyer is a strong contender for this title. It weighed only ~18 tons yet packed a high-velocity 76mm gun capable of penetrating most German armour of the era, and it remains the fastest armoured fighting vehicle the US Army ever fielded (~60 mph). That combination of speed, light weight, and hard-hitting firepower gave it an exceptional firepower-to-weight ratio compared to heavier contemporaries like the Sherman or the Tiger.
If we broaden "vehicle" to include aircraft, the de Havilland Mosquito makes a compelling case: built largely of wood, it weighed around 11 tons fully loaded yet could carry a 4,000 lb bomb load (or four 20 mm cannons plus four .303 machine guns in the fighter variant) and outran most interceptors without needing a fighter escort. A phenomenal power-to-weight story.
So: Hellcat on the ground, Mosquito in the air — both brilliant examples of doing more with less.