Like how my biggest weakness is that I work too hard.

Yup I have realized that too, it's just two faces of the same coin. I have also found out that what I really WANT to do is usually not something I'm good at.

For example I consider myself good at being a middle man between backend and analyst (I work as a data engineer in between) because none has the time and interest to communicate with each other -- so I usually took up the initiative and clear up things. I also work in small companies where people are expected to wear multiple hats, so no one gets their toes stepped on. But oh how I HATE that part of the job. How I want to get into some low level programming which is further from the "stakeholders" and the scope is larger than two weeks! Then I did a bit of low level projects and found myself not really good at what I want to do -- at least not good enough to even think about applying for such a job where everyone has done projects left and right when they were in schools. The mental doesn't help either. I might be able to be more productive if I don't need to work or/and don't have a family, but I can get rid of none.

I've seen the duality helping in some cases and being a problem. IMO, the problem part essentially arises when your trait overruns the goals / priorities of the business or your manager is ineffective in communicating the right thing to you. Business usually looks for realized impact as a metric

I guess this is a relatively common observation nowadays https://medium.com/luminasticity/your-greatest-strength-is-y...

This reminds me of the coding interview I had where I completely missed a requirement because of my desire to get the code out there. Still got the job, so I can't complain!

Great framing of an issue and it's something I'm going to be thinking about over the weekend. Thanks for sharing!

I would conceptualize it rather differently. Let say you have two daemons inside, Fast Coder and Detail Scrutinizer. It is about checking how much power every one of them is given on two separate scales (every each of them working in their dominion). If you switch on only one and neglect the other, you can get into trouble (or not, depending on the circumstances). Anyway, these are two variables, two facets, and knowing how to mix them appropriately makes the whole difference. It's like internal combustion engine mixing few kinds of fuel. What you get at given moment depends on the mixture of these different qualities.

Your leader should think of that, not you. It's _their job_.

They should pair you, the speedster, with an accurate careful reviewer that doesn't code very fast. Pronto, that combination makes both 'weaknesses' disappear.

That's because they are not weaknesses. Humans fail, all of us. Teams exist for that.

Making a team work in harmony is your leader's responsibility. Do not let them slack on this. They are paid good money for this expectation. You are not, you earn as a bottom feeder. Why do his job?

He should also hire the right persons, looking to complement the team. If some skill is missing (like QA or review experienced engineers), that's their fault, not yours.

I think strengths are more difficult to define than weaknesses, because they are very context dependent. “Speed” may be useful in certain situations, but in many cases “speed” can be harmful in more ways than just overlooking details. You miss out on opportunities to learn, to ask for help, to become better at thinking critically as a software engineer.

What the idea of “strengths being weaknesses” reflects is how much we identify with our present state of ability. It seems like we get it backwards. We ask our jobs to fit us as people, rather than how we as individuals can become best for the job.

I've said something similar for a while. That dual interview question "what is your greatest strength? what is your greatest weakness" is a very bad question.

Your strengths and weaknesses are joined at the hip, and they are the two sides of the same coin which is your personality.

In some contexts, your personality becomes a strength. In other contexts it becomes a weakness.

The trick is whether you are able to recognise under what circumstances your personality becomes a strength, and what you then do to allow you to play to your strengths, and maximize its effect, or obversely, whether you are able to recognise under what circumstances your personality becomes a weakness, and what kind of external mitigations do you or have you then put in place, to minimize the effect of that weakness.

So in that sense, the typical "I work too hard" passive-aggressive response is a bad response. A good response would be that you tend to be a hard worker, which is good when you need to be relied upon, but bad in terms of having work-life balance and getting easily burnt out. Hence the external mitigations should be a clearly negotiated work package which insists on sticking to work hours and allocated holidays.

Or, another example, adaptability. Adaptability is great if the role requires it. But it's a curse if you find yourself becoming the "go to" man for all bunch of unrelated things, which then distract you from your number 1 task and opportunities for growth. So the mitigation strategy is a clearly defined role and responsibilities.

This is a good insight, though I wouldn't limit it to software engineering.

I've discussed with my therapist many times that my biggest mental health challenges are from the exact same personality traits that bring me my greatest joy and value. Every maladaptive trait has its adaptive aspects and vice versa. If I were to try to eliminate those maladaptive aspects, I'd probably lose much of the adaptive side as well.

There is a real zen to being able to note that the things which cause the most anguish also cause the most joy and accepting both sides of that coin at the same time.