Strengths Are Your Weaknesses
terriblesoftware.org
terriblesoftware.org
Strengths are weaknesses because they create a bias to use the strength rather than developing a weak alternate, and you only get better at what you do - creating a virtuous cycle that can quickly turn vicious.
This will happen whenever growth is mediated mainly by feedback loops. (Think hard about that!)
The solution is instead to have a model of what you're trying to grow, whether it's a company or a positive presence in the world, and be willing to sacrifice to make that happen.
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 can see how. In the example given, the strength of coding speed is created via a bias against careful review of edge cases. When it works (most of the time) , you increase your coding speed and reduce review of edge cases even more, until something blows up
The interesting insight from the article is that a coder is not an inflexible monolith - they can vary the expression of a "strength/weakness" pair (strength/weakness being a misnomer at this point in the argument) to suit the circumstances
Some believe we eliminated the need for this school of thought through the DevOps revolution of the 2010s. Dev and Ops became one, married in the form of one man with one job in one company in one world. That was when history and current became one, and the many problems became zero.
With that mentality, why have lawyers for a prosecution and defence? Just have a judge decide.. right?
Your analogy makes literally no sense because what you’re trying to achieve in a courtroom is not the same thing you’re trying to achieve in a software engineering organisation.
Having 10,000 production ready features with 97% uptime and no backups is not desirable. So what has happened instead is a burnout epidemic among software developers who desperately attempt to relearn operations- or a rebranding of sysadmins to be “devops engineers”.
The very real problem you cite still happens in the latter case.
I have almost never seen an embedded sysadmin (as the 10+deploys a day talk suggests; and most people are talking about mentality-wise when discussing devops).
Others think that developers can do the job, but it’s easier than you think to be paralysed mentally by holding too many opposing views at once, which is why those kinds of things are short lived or the developers become the new operations staff purely.
You’re the only one making this strawman argument, here.
> the 10+deploys a day talk
Most teams aren’t doing this outside of a rush to wrap up a feature before a major announcement. It’s not a daily occurrence.
> but it’s easier than you think to be paralysed mentally by holding too many opposing views at once
What on Earth are you talking about?
The reason for this is, as I pointed out, because the organisations that created a hard split had much worse outcomes for customers and themselves. This split might have been necessary in the past, due to the vast gap in skill-sets and operating environments.
However, most orgs now will create a different split where a team manages the underlying infrastructure and tooling (to varying levels, depending on the specialisation required), but developers are responsible for ensuring their code Runs on Prod (tm). This does not mean developers are regularly fitting their own server racks and hand-wiring their networking infrastructure. It means, for the third time, developers own the delivery of their code to prod, end-to-end.
Dev is the sperm, Ops is the egg (or vice versa).
And it takes time for the sperm to talk to the egg. The sperm must travel. He types in Slack "Hello <Name>, I have simple trick to save money for bewba service.". The egg must travel, type in Slack, "I can't find bewba service in our catalog but I can't say that out loud".
Through time and effort, the sperm and egg finally connect, and the bewba service's money guzzling is shaved.
When the scenario is right, the travel time is not worth it. We kill of one of the sperm and egg, and accept the risks. The killed sperm-or-egg leaves the circle, and everybody in the circle is satisfied.
...yes? That's known as the contrast between an "adversarial" and an "inquisitorial" system. The inquisitorial system is more intuitive and more widespread.
A quirk of the adversarial system as practiced by the USA is that judges have no responsibility to make correct rulings. If the law is very clear on some point, and neither party makes that observation to the court, the court is not just not required to know the law, they're not supposed to use that knowledge even if they have it.
I don't really find it surprising that most people think the job of the court should be determining "who's right?" as opposed to "who gave a better technical performance in arguing their case?".
We see this a lot with daring "idea people" types seemingly plowing forward while the actual work is done by everyone around them, curating the firehose of random ideas and making the good ones into reality.
On an org level it doesn't matter as long as employees stay, but that usually doesn't last long.
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.
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.
What is a strength? Something you are inherently talented at? A skill you have plenty of experience with? A subject you have a lot of knowledge of? What you are motivated by?
What is a weakness?
I see that most people are rather adaptable to context. When you're working at a startup building an app make AI complete your Uber orders for you, there's no reason to be focused on making sure the system is scalable to a million requests per second. Most people tend to understand that. They may have a lot of experience building highly scalable backend systems, they may want to build another system like that again because it pleases them to do so. But most people will see the forest for the trees and focus on getting the project out the door in the fastest way possible because they probably won't have a million customers for a long time... if at all.
I tend to look for what people value when building a team. You'll need to match the set-intersection of the teams' values with the goals of the business. People are motivated to work on thing they value. We can tolerate working on things we don't but try to avoid doing that for too long. So if the business needs a highly reliable system because failures can lose their customers millions of dollars a minute for downtime then you'll want to stock your team with developers that value those things the company cares about.
What you're good at today can change tomorrow. You can be better at it. It's a skill, it's knowledge, it's something you can acquire: it's not an attribute or trait of you as a person.
The trick is to understand that heuristics are approximations and not to replace the territory with the map.
In my time in management, I found that the commonplace psychological descriptors we use failed to adequately describe what I was seeing. Two employees may both be “detail-oriented,” but there are subcategories within that depending on where the motivation comes from and those subcategories behave differently. Some people want that A+, some people like their squares square and their circles round (and it gives them anxiety when they’re not). Those groups are different, and I don’t know what to call them.
At bottom, there are ‘simple machines’ of psychology that, in combination with each other, produce behavioral traits at the top level. We don’t really have words for them, or at least not words I can think of for the ones I see.
- George E Box
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.
All weaknesses are strengths in the right context. Yea, perhaps the context simply doesn't exist in the world we maintain, but we can unreservedly acknowledge it's definitely in the "latent space of culture" :)
I don't think that's totally accurate, the article is very clear about the "duality" and "two sides of the same coin" concept. "No such things" dilutes it to something that may be a law of nature but that also approaches a tautology.
I agree with some of the comments picking the original post apart a bit, that the reality is more nuanced. "Coding speed" and "occasionally overlooking details" don't seem so cut-and-dried to me as two sides of a duality. Coding speed is the sum of a number of factors, one of which can definitely be just straight up being able to reason about things and get to a solution faster. Occasionally overlooking details is a symptom of rushing, which does relate to coding speed, but to me does not serve as a great example of the "strength = weakness" duality.
I also don't know if major evolutionary shifts over millenia are a totally apt metaphor for iterated situations involving the same individual human psyche. I feel like you zoomed out and generalized a bit much, which made it less controversial.
Sometimes it's hard to convince people that this works in reverse too. Traits like lack of commitment or emotional distance from work also means they'll be less affected when the org goes in pure chaos mode or the work is boring as hell.
Diversity is also about these kind of differences inside the org.
Collaborative development might have minimized the risk of the production issue.
* Design is not reviewed by other team members
* Coding is not reviewed by other team members
* Not proper automated testing (if it was a regression issue)
* Finally, speed with accuracy is what we need to focus on, while training/practicing ourselves. This comes with experience.
So it is a minor tweak we need to make.
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.
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).
I heard an example yesterday that dealt with a more "universally" negative trait: a boss gave feedback to a colleague who was widely considered an asshole.
Everyone had already told him to stop being an asshole and that didn't help at all. That's not actionable.
Instead, they boiled it down to four specific behaviors that produced the complaints, and then came up with alternative behaviors to execute in those situations.
The complaints went away within a week.
Source: Alex Hormozi
---
Edit: I've just read a few of the other posts on this blog (Terrible Software), they are equally brilliant. Highly recommended.
Using the post’s framework, I wonder whether his “assholery” had any positive flipsides— maybe something like speaking openly when others (politely) wouldn’t?
For example, I would never provide critical feedback within the first 6 months (minimum) of a new hire starting (similar window I apply to providing feedback on codebase issues etc).
It’s very sobering to realize you have to take the bad with the good, and sometimes it’s not worth it. Being average isn’t so bad.
Strength: Seeing the bigger picture and the ability to hold an entire system in my head along with the context of prior projects and the body of knowledge I've built. I can build large complex enterprise systems in my mind all at once and articulate the principles and patterns involved to my peers and clients.
Weakness: I am often frustrated and upset when I don't have enough information to do this and will wait and procrastinate until I have enough information to form this system fully in my mind, then build or design or document a thing all at once.
I am perceived by my peers to be a, "slow" developer so I got "Peter Principle"'d into a Solution Architect and consultant.
My coping mechanism to handle this when I do agile development with peers is, when working with incomplete information, develop many versions of the same partial system in my head. A/B test them and extrapolate from incomplete information the most likely complete system.
Then build that version.
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.
poof what do you need?
poof what do you need?
poof what do you need?
Keep going until you end up with a manageable set of problems.
One of the VERY FEW Verbal classes was this. "Sometimes you dont know the weakness of your enemy and have not time to research. As A Rule of thumb, their biggest strngth, is thei great weakness".
Examples of the real life. 1 ) i was being filmed in the street with a Handcam from seven people of a destructive cult, i cited they call to their followers to do that in a forum. I was Filmed INSIDe the police station too. Losers. The principal proof to the fact they were a destructive cult ? The filmation
2 ) In my job in a public university some admin had the exclusibve right/permissions to put the SSL in the servers structure. We needdo a internal memorandum each three months and they took a whole week to do so. 50-60 people cant use the system. I got some interns and ask them to put an auto renewi SSL in a vultr instance, they can do in 15 minutes or less. Then, each blackout i only pass the info they are doing late a job than a simple intern/advanced student can automate in 15 minutes. They pedantic strength, was later the reason i get a promotion myself for report the solutions THREE years before.
3 ) In a divorce case, in mexico, a friend was asked as a part of that a 800 USD MONTHLY Bill for therapist of their exwife sons fo r a whole year. (stepsons of them),. The lawyer, exwife and therapist say that mutltiple times. Ok. Then we ask for the IRS equivalent invoice, and go for perjury by the lawyer, therapist and exwife for simulated operations (no irs invoice, all are lyieng and cometting fraud). The judge himself is currently near to be revoked for fraud in evidence. But was very STRONG the scandal they do when fake the therapist invoice ina onfficial document.
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.
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.
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'm probably the outlier who don't care too much about showing my value to my employer as long as they pay me. Somehow getting appreciation (whether true-hearted or not) is not a huge motivation to me. The reason I moved forward with this role was because miscommunication or zero-communication bogged down my work and created potential hazards in the maintenance phase. I'd like to remove those obstacles so I stepped forward to clean it up. I always protect myself by ccing everyone and try to reduce my responsibility in all of these -- because it is not clean cut who should do this communication type of work.
Maybe that's why I hate it.
Are you me? I'm a systems thinker and I, too, have to stop and analyze workflows and try to "fix" things. Probably why I ended up in process/management consulting.
Snap. How I've made this work in my career is being the guy who does the shit that nobody knows how to do
Great framing of an issue and it's something I'm going to be thinking about over the weekend. Thanks for sharing!
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.
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.
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.
Is there a 'right' answer to this question that's honest and isn't phony ?
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.
to shift the culture from “fast” to “safe” is mostly a team-based effort because not all teams need to shift. and even within a team you may have experimental and mature products.
i’ve seen this shift happen successfully multiple times. it must come from leadership. C-level and down. even if it’s just for one team. or one product. you need the buy in all the way up. and then your people in the chain will adapt to changing expectations
I've found this a lot in data systems where folks glue stuff together as fast as possible to "ship", while missing the huge glaring issues with the foundation that they've built on top of wet, sliding mud.
Every increase in your knowledge is a simultaneous decrease. You learn and you unlearn at the same time. A new certainty is a new doubt as well.
I pondered it a bit and arrived at "learning is losing innocence", from the point of view of somebody who mulls over Enos process. I think that sort of ties-in with this article.
You can code faster, but then you might overlook things. You can work a lot and earn a lot of money, but you might struggle with nurturing your friendships. You can have a partner but then you'll have arguments with them. You can remain single but then you'll have to deal with loneliness.
It helps me to know that the richest, most attractive or smartest person alive has the same amount of problems. It's just part of life and I am happy
There are plenty of slow coders who overlook more things than some fast coders. Plenty of people not working a lot who still struggle to nurture friendships, and so on.
My high-level view of backend development is to make functions that transform one persisted consistent state to another. Define the start/end states and all the code that's used to do that is implementation detail. The other part is fast reads of same.
Weakness in the inverse: not being ready to change to new code, because you have a clear and distinct understanding of the old, and an uncertain take on the new. In that case, even if the new were better objectively, it would be discounted for you by uncertainty.
Conversely, if you understand something complex deeply and newbies don't, to them something that's easy to understand (but defers problems your stack solves) is preferable, and you end up with culture and governance issues. Managers who are relatively ignorant then set up competitions to surface issues, validate claims, and develop alternatives to mitigate their reliance risks on employees.
So: move fast and forget things, and expect a fight :)
I don't understand your 2nd point. I also spend a fair amount of time educating others on the importance of knowing what's underneath.
It may cause you to favor complex solutions that are obvious to you, but inscrutable to people without your deep knowledge.
This is very common with people who are very skilled at a complex tool (such as C++ or Kubernetes).
This is a valid concern that I'm aware of and I try to make things as clear to others as possible. Often my PR descriptions are much longer than my code changes with tests that illustrate exactly what's being done and including links to reference documentation that spells out what's being used. Most often others immediately understand it and were merely only unaware of its existence.
It's not exactly that I lack experience elsewhere, only that I find understanding the base to be the biggest force multiplier when things get tough.
What are other dimensions along which there's this duality of strength/weakness in engineers (or even in the general workplace) that you've seen either in yourself or other coworkers?
and so on.
Try this https://www.gyfted.me/personality-quiz/strengthsfinder-test-... or this https://www.gyfted.me/quiz-landing/bfas-personality-test to learn more about your strengths/traits
- like in the example, fast people have trouble going slow.
- people who are exceptional at details might be poor at big-picture.
- super passionate people can take criticism of their ideas personally
- people who are slow might be steady
David Wallace: Okay. And your strengths?
Michael Scott: Well, my weaknesses are actually strengths.
David Wallace: Oh. Yes. Very good.
Imagine reporting to the real life Wallace as a fan of the show.
I look at our leaders today - our CEOS, elected officials, presidents and their lieutenants like Elon Musk - and I see a narrow sampling of humanity chosen for high executive function but little else. Who consider humanity's greatest virtues like empathy to be liabilities. Where is the self-awareness, the doubt, even the shame that brings wisdom?
I worry that this tireless race towards maximization of efficiency and reduction of cost above all else is driving the whole world towards ensh@ttification. When we could so easily take a step back, breathe, and find outside-the-box solutions beyond the zero-sum game of the status quo. If only they would let us..
There is a book Investing Between the Lines by Rittenhouse that argues that candor is a high predictor for company outperformance. Buffett for example has written on multiple occasions things like “this was fully my mistake” or “it turned out I was wrong”. With the book in the back of my mind, I set out to find annual reports were the letters showed candor instead of the typical “Among a greatly turbulent economy, we have maintained good revenue numbers and customer satisfaction” rhetoric.
I have read about 100 reports and found one or two satisfying this criterium. From the top of my head, only Berskhire, Amazon in the 2000s, and Ryanair conduct candor communication.
So yes I fully agree with your point on candor and self-awareness.
Last summer we sold the corporate jet that we purchased for $850,000 three years ago and bought another used jet for $6.7 million. Those of you who recall the mathematics of the multiplying bacteria on page 5 will understandably panic: If our net worth continues to increase at current rates, and the cost of replacing planes also continues to rise at the now-established rate of 100% compounded annually, it will not be long before Berkshire's entire net worth is consumed by its jet.
Charlie doesn't like it when I equate the jet with bacteria; he feels it's degrading to the bacteria. His idea of traveling in style is an air-conditioned bus, a luxury he steps up to only when bargain fares are in effect. My own attitude toward the jet can be summarized by the prayer attributed, apocryphally I'm sure, to St. Augustine as he contemplated leaving a life of secular pleasures to become a priest. Battling the conflict between intellect and glands, he pled: "Help me, Oh Lord, to become chaste - but not yet."
Naming the plane has not been easy. I initially suggested "The Charles T. Munger." Charlie countered with "The Aberration." We finally settled on "The Indefensible."
Outsized success a curse.