5 ms·

Yes, and more importantly... Strengths are weaknesses because they create a bias to use the strength rather than developing a weak alternate, and you only get

by w10-1 2y ago

Yes, and more importantly... 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.

mfitton 2y ago
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.
- hammock 2y ago
  >I'm not sure that follows from this article. 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
tomnipotent 2y ago
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.
scott_w 2y ago
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.
- maujun 2y ago
  This may be one reason employees have different titles. The other reason I can think of is why owners aren't usually called employees. 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.
  - dijit 2y ago
    Dev and Ops are natural enemies because they are focusing in pulling in opposite directions, a fact thats repeated ad infinitum in the course material surrounding devops - yet people still hold the belief that one person can fiercely hold two diametrically opposed positions at once and succeed. With that mentality, why have lawyers for a prosecution and defence? Just have a judge decide.. right?
    - scott_w 2y ago
      I find this current trend to hate DevOps to be childish. DevOps was a response to a very real problem of “throw it over the wall,” where the Dev team would build it and the Ops team had to figure out how to make it run, usually without any documentation. The change to having the Dev team responsible for deploying and running the product (and responding to the on-call they cause) creates a forcing function for the team itself to improve quality and deployment efficiency. 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.
lll-o-lll 2y ago
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.
orbisvicis 2y ago
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.
msm_ 2y ago
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.

by w10-1 2y ago

mfitton 2y ago

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.

hammock 2y ago
>I'm not sure that follows from this article. 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

tomnipotent 2y ago

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.

scott_w 2y ago

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.

maujun 2y ago
This may be one reason employees have different titles. The other reason I can think of is why owners aren't usually called employees. 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.
- dijit 2y ago
  Dev and Ops are natural enemies because they are focusing in pulling in opposite directions, a fact thats repeated ad infinitum in the course material surrounding devops - yet people still hold the belief that one person can fiercely hold two diametrically opposed positions at once and succeed. With that mentality, why have lawyers for a prosecution and defence? Just have a judge decide.. right?
  - scott_w 2y ago
    I find this current trend to hate DevOps to be childish. DevOps was a response to a very real problem of “throw it over the wall,” where the Dev team would build it and the Ops team had to figure out how to make it run, usually without any documentation. The change to having the Dev team responsible for deploying and running the product (and responding to the on-call they cause) creates a forcing function for the team itself to improve quality and deployment efficiency. 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.

lll-o-lll 2y ago

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.

orbisvicis 2y ago

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.

msm_ 2y ago

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.