Who am I?
My personality
I am a highly introverted individual, but I am also an outgoing and social person. I took a test at 16Personalities and my result is Turbulent Advocate (INFJ-T).
An Advocate (INFJ) is someone with the Introverted, Intuitive, Feeling, and Judging personality traits. They tend to approach life with deep thoughtfulness and imagination. Their inner vision, personal values, and a quiet, principled version of humanism guide them in all things.
Advocates are the rarest personality types of all. Still, Advocates leave their mark on the world. They have a deep sense of idealism and integrity, but they aren’t idle dreamers – they take concrete steps to realize their goals and make a lasting impact.
Advocates’ unique combination of personality traits makes them complex and quite versatile. For example, Advocates can speak with great passion and conviction, especially when standing up for their ideals. At other times, however, they may choose to be soft-spoken and understated, preferring to keep the peace rather than challenge others.
This means that I might be a little different to the people you normally associate and work with/for. I have my strengths and my weaknesses. But done right I can be a great asset to your project and team.
How I approach my work
- I am the kind of person who tries to look beyond a proposed solution trying to get to the actual problem. Sometimes a customer is limited by the lack of knowledge of what can actually be done, and I like to take the extra round of questions/discussion to narrow down the actual problem, because sometimes a better solution can arise that is actually easier to implement.
- I can voice my opinion about what I think is the best course of action, but I also follow a hierarchy or the majority, so I have no problem going for a different opinion if my suggestion is voted down (unless I think it would be harmfull in any way).
- I try to balance between getting the job done in time and getting it done right. I prefer having enough time to implement a feature so that I can find the best and easiest solution and also have the time to let my brain work on the problem in the background. In my experience time is your best friend. You can bang head on your computer keyboard for hours, and then when you wake up the next day the solution simply appears and you can solve it in minutes. But I know that sometimes you have to get things done as fast as possible (especially if you have to fix a bug) and then I will resort to what I would call "ugly" code to get the job done.
- I value my time and prefer being able to manage it mostly myself.
- I prefer getting things in writing. I have a tendency to forget verbal instructions or "morph" it in some way. So the best thing is to get something in writing. If it isn't provided to me then I usually try to send a summary back to you giving you an opportunity to correct me if I have misunderstood anything.
- If Github is used I prefer opening a PR (as a draft) as soon as I start on a task. I try to describe what the PR is about and use this to keep me focused on what I am actually working on. This also gives my peers and/or project manager the opportunity to make adjustments to what I am working on and comment along the way.
Do's and don'ts
Give me context
I prefer getting as much context as possible. This applies to both features/bugs and other type of communication. Example of bad "interactions" vs good:
Bug report example
Some users experience issues with signing up on our site, can you take a look at that?"
So, what is wrong with this? It lacks information about the importance of the issue and a timeframe. I would prefer something like this:
We have gotten reports from X-people saying that they get an error when signing up. We do have some signups recently, so it doesn't seem to apply to all users. The signup is important and this issue will cost us money. Can you take a look at this as soon as possible?
Feature request example
Can you add a contact us button where members can send us an email?
Similar to the previous example this gives no context. It is a command that does not tell anything about why, the importance of the feature request or a timeframe.
The board has discussed that we should have more interaction with our users and would like to encourage our users to get in touch with us. Our suggestion is a "contact us" button on the site where they can type in some text that will be emailed to contact@company.com. We are hoping this could be done within the next 2 weeks.
This is a much better request. It includes the "why", it has a suggested solution instead of a command and it also has a timeframe.
Meeting request example
Hi, can we have a chat tomorrow at 2pm?
This is a horrible request... it does not say anything about what we need to chat about, the importance or if there are going to be other people at the meeting. This could be something really important, or something really trivial. I might rearrange my entire schedule to accommodate and say yes to the meeting, and it turns out to not be important at all. Or I might think that because I have a lot on my plate that we should move the meeting to next week. Another solution is of course to ask for more context, but that would require a major context switch and the answer back might not come right away. This could cost a lot of time where I could be productive working at the task at hand.
Hi, I have talked with the product owner and we have some questions about the upcoming release. Can the two of us have a chat tomorrow at 2pm where we can get some clarity around some questions?
If possible include me in the process
I prefer being a part of the process that leads to a decision if the implementation will fall on me.