Strengths Are Your Weaknesses

I think this also happens at the company level. You get good at delivering a certain type of solution using a set of technologies. You build excellent infrastructure and expertise using these, which is a strength!

However, without active effort to build capability in strategically important areas, your weaknesses can ruin you.

It works at the personal and company level. I’m the deep thinker/researcher type. At my age, that’s all for the good because you go up through the ranks until that’s a very valuable attribute. When I was younger though, I had to work hard on time-boxing and delivering the “good enough”; skills that are still vital when planning at the large scale.

The strengths and weaknesses are indeed two sides of the same coin.

Anecdote unrelated to programming - when climbing (on a climbing wall or bouldering) I was significantly stronger compared to my peers. Because of this, I was the best (or one of the best) in my group for the first year of two. But then I hit the wall - at some difficulty level I couldn't just bruteforce my way to the top, and I had to learn proper techniques, footwork, unlearn bad habits - things my peers were doing for the past two years already.

There’s a school of thought in management where you get your team to lean into their strengths and find ways to mitigate their weaknesses, rather than spend much time on them. The idea is, if you’re a person who moves quickly vs going super deep on every possible use case, you’ll always be shit at going super deep (I know I am), so you’re better off getting even faster and pairing with a deep investigator to cover your blind spot. And vice versa, of course.

I'm not sure that follows from this article. In fact, I think the logical conclusion of the article is that, by trying to grow (address weaknesses and turn them into strengths) you're actually creating strengths, which in turn creates a weakness.

I think it's possible to grow in positive outcomes of behaviors, but I also think this article is trying to get at something intrinsic within each one of us. Identifying where our personality quirks lead to strengths and weaknesses, and accepting that, is related but not quite the same as identifying concrete positive and negative outcomes of behavior, and trying to change our behaviors to align more to the positive outcomes.

Not sure if the link I'm trying to make here will be clear, but... I had an interesting conversation with my wife the other day. She conceives of who she is largely through the behaviors she expresses, a kind of de facto self-definition. I tend to have a self-conception that's a little bit more abstract and rooted as much in my feelings, thoughts, with some aspirational quality, that my behaviors sometimes live up to, and other times don't.

I see this a lot in hero shooters, like Overwatch and Marvel Rivals. A hero you're great at but is bad for the job is worse than a hero you're bad at but is good for the job. It's funny to watch people complain "But I'm not good with X!" then they switch and are at the top of the leaderboard.

I am a good programmer and believe in well-behaved software.

My coworkers aren't, but I was shocked to learn they believe all software is inherently brittle and fragile.

I fix issues at the root by changing code.

My coworkers fix issues by publishing user workflows which can avoid triggering issues, or removing execution paths featuring buggy code, etc.

My coworkers work less than I do, so I'm trying to be more like them.

Yes, the world is more complicated than any description of it. No, that doesn't make heuristics useless.

The trick is to understand that heuristics are approximations and not to replace the territory with the map.

This isn't like most of the trite management tidbits you're comparing it to. All they're really observing is that there are no such things as "strengths" and "weaknesses" in the absence of context—there are only traits, and those traits may be useful, neutral, or counterproductive depending on the situation.

This principle shouldn't really be controversial because it's basically a law of nature. It's why small mammals took over from large reptiles after the asteroid hit. It's why New Zealand's flightless birds thrived until the introduction of the cat. Enormous size and cold bloodedness were an advantage until the climate changed. There was no need to waste energy on wings when there was no predator to eat you. Nature doesn't have a concept of strengths and weaknesses, nature has a concept of fittedness for a given environment, and we see the same thing with individual humans.

Haha this rings true for me. I am far less emotionally invested in my work than most of my peers, and as a result have a reputation for unflappability and being able to get along with everyone

lazy engineers automate stuff better :)

> In the example used, I don't think strength (speed) is the same trait causing weakness (overlooking).

Yeah, I think so too. I think the core points are that the article makes are very reasonable ones, that deserve a better example (and there are certainly attributes of people that act as a double edged sword).

But surely you have seen that places which practice design reviews and code reviews and double down on building tests, tend to be slower shippers and deadline missers?

Not saying that you in your ideal company suffer this problem, just the vast majority of the people who have taken your advice...

I come to you with a major refactor, +400 lines -600 lines, so like if you printed it out it's a 25-page diff, if someone is now reviewing my design or coding, they potentially have half an hour to an hour's work trying to fully understand this and make sure that I didn't break anything in that refactor. Post-hoc ain't the way here. I sometimes feel like I'm the only person who will read through such a long diff and understand it and come up with useful feedback. Everybody else is going to lean on testing, which to be fair to you is one of your bullet points, but consider that it's one of the major points.

And why did the refactor get that big in the first place? Because of the merge latencies, because of the review process. The more resistance you place here, the more gets buffered into a feature branch, and the more you have to review later.

Some shops do well with that, I worked at one once, we actually worked ourselves out of a job by finishing everything ahead of deadlines. (We were making a game that wasn't very fun at a company that was not principally interested in making games, so we were forcing the issue to a head of whether they wanted to keep taking this risk with a dream team of programmers or cut their losses and double down on their core.) But the major thing that we were doing different, has nothing to do with your bullet points. In the abstract, it was that, we didn't have performance review hanging over our heads. And therefore we didn't have every single developer working on their own separate thing in the system, so that they could call it their own and claim it on paper at PerfTime. Which meant that we could pair program organically, “hey you mind if I look over your shoulder?”. We all merged into dev, everyday, multiple times a day, and that's how we saw that someone else was working on the same part of the code that we were working on, and then we talked about like how are we going to not step on each other's feet? We had also decided early on that we were going to have a centralized place to push out feature toggles, it was kind of janky but it was available for QA department, yes we had a separate QA department, so that they could tweak which things were going to go out versus which needed to be baked more.

The is exactly the advice that one of my favorite podcasts, Manager Tools, would prescribe. Don't give feedback about emotions or internal feelings, give feedback about behaviors. Telling someone they are acting like an asshole can be met with, "but, no, I'm not acting like an asshole." Telling someone, "When you cut off people mid sentence and speak loudly, you will have people complain about you." gives them actionable ways to change their external behavior in the future. It doesn't matter if they are still an asshole on the inside.

Out of curiosity, what were the 4 behaviours and alternatives?

Using the post’s framework, I wonder whether his “assholery” had any positive flipsides— maybe something like speaking openly when others (politely) wouldn’t?

Yeah that's my logic too. "It's full moon again... better make the most of it!"

Count yourself lucky you can clearly demarcate the start and end of your system. You view this beautiful system moving in your mind in splendid isolation dancing in synchronized dare I say celestial harmony.

What I see is that same thing and then I zoom out and see it embedded in an endless barn full of pig shit with all sorts of oddly dressed people shouting at each other. In this pig farm your beautiful celestial system is a small pearl, lying somewhere on the ground in a corner.

Try to bring that into harmony.

That's because you are likely a perfectionist. I've learned to let go and allow for there to be holes in my work (because 90% of my projects should be linear after requirements are known, but we live in a fantasy world where you're expected to put the shingles on the roof before the walls and roof are built).

Maybe that is your biggest weakness.

Maybe working less hard on higher impact things would be better. Or maybe you'd be more creative if you didn't work so hard.

It's definitely worth exploring.

This is a big weakness of many, many folks. Knowing when to work hard(er) and when to take time to recover is important in pursuits both mental and physical. You see it all the time in sports(e.g. overtraining) and careers (e.g. the father who spends his nights at work and misses his kids' events).

That’s funny; My biggest strength is that I don’t.

for people who haven't seen Trainspotting: https://www.youtube.com/watch?v=8rPOC78NuQk

For yourself? Or your Company? That is big difference.

> 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.

Just curious if you have ever felt that it's hard to demonstrate your value to the organization if you're a "glue" guy like that. (I have also worked in several small companies, but only as a partner or an executive.)

I've found that the older and more experienced I get, the more specificity I want in how the value I provide will be measured.

> I have also found out that what I really WANT to do is usually not something I'm good at

Snap. How I've made this work in my career is being the guy who does the shit that nobody knows how to do