How to Joseph
Hello there and welcome to my personal HOW-TO.
If you are reading this, it is likely we are team mates, or we are soon-to-be team mates. This guide to me was written with the objective of accelerating our working relationship and to avoid any misunderstandings that may arise during the course of our work.
Let’s get started.
Like all documentation, this guide is a living document that will change over time. Check the last update timestamp for validity - alternatively, if what you see here doesn’t match what you get, feel free to raise a public pull request! I’m open to feedback (;
Contents
Usage
This section is divided into a few categories of work-related affairs you should know about me:
Brief Introduction
At $COMPANY, my primary role is a devops engineer and that is what I do most of the time - making the processes between development and production more efficient. I also frequently involve myself in business level meetings when I sense that more engineer representation is required, so I sometimes do things related to what a scrum master does.
Outside of professional work, I do side-projects on developer tools and I am also a musician and an in-training (read: noob) martial artist (wing chun). Academically, I come from a computer science background with a focus on software engineering and algorithms. My side interests include cyber-security, life sciences (genetics), physics (quantum stuff) and sociology.
I am also passionate in entrepreneurship and it is my long term goal to be able to do my own thing. I have started two businesses to date - a t-shirt printing company and a local musician network - both of which I have since long departed from.
Feel free to chat me up if you’re interested in what I do outside of work!
My Values
-
Cause over challenge over people. I only work on products I believe in on a personal level. This means if you’re pitching a feature/product to me for any reason, you would be better off convincing me about the impact I can make and how it resonates with my beliefs. If that doesn’t work, appeal to my inner engineer. I will adapt to whoever I have to work with.
-
Engineering over delivery. I am an engineer first, then a product development guy. This means you can expect me to focus heavily on quality - code quality, feature testability, and system observability. This also means that if we’re on the same team, you can expect me to fight for engineering excellence over delivery.
-
Delivery over innovation. Professionally, I build things that work. This means using the right technology for the right purpose. New and shiny technologies do not impress me until they are battle-tested and though I personally love to use them in my side-projects, I will not choose to use them in a professional setting unless the benefits are obvious and intense and solve a problem we are unable to using more mature technologies.
-
Team, not my, opinion. I strongly believe that the direction of a team should be guided by the team and not any one individual. This means that if I happen to be in a faclitation/authoritative role, I will seek direction/opinions from the team and will proceed with the team’s decision regardless of my opinion unless I have experienced really Bad Things™ with that decision, or it directy goes against the larger organisation’s goals.
-
Team first, product second. Without the team, there can be no product. This means that I will prioritise my time towards building the team and resolving human issues over technical difficulties. This also means that my loyalty lies with you, my team members, and you can expect me to always have your back when it comes to representing the team in product-level discussions.
-
No feedback is bad feedback. It is my aim to continuously improve myself and I will occassionally request for feedback through an anonymous form which helps me gather metrics on how I’m achieving goals I set for myself and how I’ve neglected other aspects of my life during the pursuit of these goals. Please be completely honest with me as this will let me better assess myself. I am un-offendable when it comes to feedback, however, please be objective, and I appreciate it if you would be open to discussing more should I not understand your feedback.
My Strengths
-
Business level interactions. It is within my long term goals to be able to launch my own products, hence I have put in effort and am reasonably good with conveying technical level issues to non-technical people. Feel free to include me in product level discussions if you need help convincing non-technical humans about why we should/shouldn’t pursue a certain feature/how we can do so.
-
Technical proficiency. Being an engineer before a product guy, you can trust that I will bring technical proficiency to the team. Even though I may not be the best, you can trust that I am always seeking to improve myself in software engineering and architecting.
-
Innovation. Despite my values of creating working software, I consider myself to be somewhat innovative and am highly motivated when it comes to creating/using new things for proof-of-concepts/pushing technical boundaries.
-
Resourcefulness. Disregarding quality, I am one of those guys who can always get something to work, albeit usually leaving a trail of destruction. If something hasn’t been done before that I believe in, that triggers me.
Other Things To Note
-
I do not tolerate dishonesty well. I can forgive any mistake, but I cannot tolerate a lack of integrity. This means that should you accidentally do something disastrous, it would be better to admit you screwed up and we can fix the problem together. However, note that this doesn’t mean that there won’t be consequences should the matter be beyond my control.
-
I am by nature an introvert. This means that I work beautifully with small groups (3 to 5 people). Any larger and my silence tends to be proportional in growth to the number of people present. I have put in effort to condition myself for larger meetings, but on my bad-hair days, I occassionally may fall silent during meetings, but this does not mean I am disengaged. I have just run out of mana.
-
I tend towards verbosity. In code and in architecting things, I usually manage to find a beautifully complex way of doing things. While I do have some personal mitigations against this, as my team members, I would appreciate it if you could point this out to me before the damage is done.
-
I speak with colour when excited. In the course of our work, during pair programming or 1-1s, I tend to use colourful language especially when I’m passionate (with love or with hate) about something. If you are not comfortable with this, let me know prior and I will accomodate.
-
I work on weekends. I am lucky enough to be one of those people whose hobby is also their profession - product engineering. Hence, I tend to work on weekends when I really feel for a product, and may send you messages/emails over your time of rest. I do not hold any expectations over you to reply there and then unless it’s tagged as URGENT - which will not happen often. Feel free to reply when your work week starts!
On Reporting To Me
Should you be fortunate (or unfortunate) enough to be my reportee, here is what you can expect from me:
-
Monthly 1-1s. I will conduct monthly 30 minute 1-1s in the mornings (when I still have extrovert mana) at a date/time/latlong which we will settle within the week prior to the 1-1. I will do a check-in with you primarily on matters un-related to work and on any non-technical issues you are facing at work which may hinder your performance or level of happiness. The agenda for the rest of the 1-1 should be set by you and can include technical issues should you wish for that.
-
Set your own standards. I assess you based on the standards you set for yourself. This means that we will work together to understand your short/long term plans and objectives. Note that to me, there is nothing wrong with just wanting to keep your job where we are, we just need to figure out what you need to do to ‘just keep your job’ in the work environment we are in.
-
Consistent availability. Being my reportee comes with its benefits. I believe that people leave people, not organisations, and it is in my interest to assist in whatever ways I can to help you stay engaged to your work and excel in it. As such, I will always be a message/phone call away should you need support in any way, 24/7.
Stalk Me
Sometimes, people (maybe you!) would like to find out more about someone they are working with. Here are some places I am actively providing output to outside of work:
Further Reading
Should you wish to know more about me, this section contains reading materials that I have found to be influential in my way of thinking. Feel free to engage me about any content from these musings by people way smarter than me.
Books
- The Design Way: Intentional Change in an Unpredictable World
- Emotional Agility
- Never Split the Difference: Negotiating As If Your Life Depended On It
- Prove It!: How to Create a High-Performance Culture and Measurable Success
- The Positive Leader: How Energy and Happiness Fuel Top-Performing Teams
- The DevOps Handbook
- The Holy Bible: Catholic Version
- The Art of War
- I Ching - Classic of Changes
Publications
- Martin Fowler’s Blog
- Joel Spolsky’s Blog
- Susan Fowler’s Blog
- Coding Horror
- Mountain Goat Software
- Krebs On Security
- Hackernoon
- FreeCodeCamp
- HackerNews
- Personal Growth on Medium
Newsletters
- InfoQ’s Newsletter
- InfoQ’s Architect Newsletter
- Dev.to Newsletter
- MIT Technology Review
- Thoughtworks Radar
- Kube Weekly