Posted by kiyanwang 1 day ago
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.
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.
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.
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?".
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
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.
- George E Box
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.
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.
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).
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.
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.
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).
Using the post’s framework, I wonder whether his “assholery” had any positive flipsides— maybe something like speaking openly when others (politely) wouldn’t?
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.
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.