Strengths Are Your Weaknesses
terriblesoftware.org

・

346 points

・

kiyanwang

・

8 days ago

112 comments

w10-1 ・ 7 days 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.

  • lll-o-lll ・ 7 days 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.

  • msm_ ・ 6 days 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.

  • scott_w ・ 7 days 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.

    • makeitdouble ・ 7 days ago

      This could work fine if the pair is acknowledged as such. In most orgs one side of the pair will be just be seen as a replaceable counter-weight while the other side gets the praise and promotions.

      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.

    • maujun ・ 7 days 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 ・ 7 days ago
        ・ 8 more

        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 ・ 7 days ago
          ・ 6 more

          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.

          • dijit ・ 7 days ago
            ・ 2 more

            Sure it is, you explicitly want features and stability.

            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.

            • scott_w ・ 7 days ago

              > Having 10,000 production ready features with 97% uptime and no backups is not desirable

              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?

          • franktankbank ・ 6 days ago
            ・ 3 more

            I think it makes more sense to have someone specializing in OPs and someone specializing in feature delivery. They are totally different skillsets. If you have both great but just demanding regular feature devs to also figure out all the network plumbing and deployments is just regular old business folks squeezing blood out of rocks.

            • scott_w ・ 6 days ago
              ・ 2 more

              It's not about forcing every Dev to learn every aspect of Ops work. It's about ensuring the team that builds the feature manages its delivery end-to-end, including dev, test, deployment, failure response.

              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.

              • maujun ・ 6 days ago

                I believe we now have enough info to quantify the tradeoffs.

                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.

        • thaumasiotes ・ 7 days ago

          > With that mentality, why have lawyers for a prosecution and defence? Just have a judge decide.. right?

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

  • mfitton ・ 7 days 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 ・ 7 days 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 ・ 7 days 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.

  • orbisvicis ・ 7 days 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.

agentultra ・ 7 days ago

In my experience, people aren't so static as to have dualities. They don't fit so neatly into little descriptors.

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.

  • uoaei ・ 7 days ago

    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.

    • linguistbreaker ・ 7 days ago

      "all models are wrong, but some are useful"

      - George E Box

    • agentultra ・ 7 days ago

      Some heuristics are better than others.

      • towledev ・ 7 days ago

        You’re selling your point short.

        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.

hliyan ・ 7 days ago

Better formulated as: some weaknesses may be unintended consequences of your strengths under certain conditions. Rules of thumb like this are useful approximations of reality, but I wouldn't elevate them to the level of a principle that I would use in 1:1s. All the little phenomena that people like the author (myself included) in the tech/management world have observed and written about, would probably add up to several thousand. Human behaviour is complex. Sometimes you have no choice but to handle it on a case by case basis.

  • lolinder ・ 7 days ago

    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.

    • appleorchard46 ・ 7 days ago

      This is off-topic but I just wanted to say I appreciate your presence on HN. I see your name pop up often, and your comments are always insightful and clear. You consistently identify the root of complex topics (and disagreements/misapprehensions surrounding them) and are able to distill them in a non-argumentative way. Thanks for helping make this site a nicer place.

      • lolinder ・ 7 days ago

        Thanks for saying so!

    • patcon ・ 7 days ago

      This was the push back on parent comment that I was hoping to find, against the misguided qualifier. Thanks. Strongly agree.

      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" :)

    • jrowen ・ 7 days ago

      All they're really observing is that there are no such things as "strengths" and "weaknesses"

      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.

makeitdouble ・ 7 days ago

Yes.

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.

  • circlefavshape ・ 7 days ago

    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

  • m463 ・ 7 days ago

    lazy engineers automate stuff better :)

the_arun ・ 7 days ago

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

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.

  • hobofan ・ 7 days ago

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

  • crdrost ・ 7 days ago

    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_arun ・ 7 days ago

      We always need to think what is important - speed or zero incidents. I'm not saying what is right, but we have the decision to make. If your outcome is zero incidents - there is effort involved. If our goal is time to market/speed, we need to take the risk of incidents. There are always trade offs with every approach we take.

andai ・ 7 days ago

This is brilliant! It really is context dependent. There's probably exceptions to that though.

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.

  • mattw2121 ・ 7 days ago

    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.

    • ansisjdjsjs ・ 7 days ago

      Do these places ever discuss receiving feedback? Genuinely actioning feedback like this requires an extremely high level of trust, and expecting that level of trust in a short time window is borderline predatory.

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

      • mattw2121 ・ 3 days ago

        Sorry for the late reply. The Manager Tools podcast definitely talks about both sides of feedback. Everything they teach is predicated on building strong relationships, through weekly 1x1s, and starting off with positive feedback only after multiple months of conducting 1x1s.

      • andai ・ 6 days ago

        I don't get it. Don't you want to give as much feedback as possible in the beginning, before bad habits form and relationships are permanently soured?

  • ovalanche ・ 7 days ago

    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?

zemvpferreira ・ 7 days ago

I came across this idea after a dark period of meditation: creativity is the productive use of rumination, anxiety or mania. The best creators I know (offhand example, Heston Blumenthal) had rampant mental illness during their most creative periods. I myself suffer from clinical anxiety periodically, which I have to manage proactively.

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.

  • andai ・ 6 days ago

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

weard_beard ・ 7 days ago

My brain is waterfall in an agile world.

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.

  • whatnow37373 ・ 7 days ago

    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.

    • weard_beard ・ 7 days ago

      I've... had to adapt to similar circumstances. Separate data sanitization from other problems. Ignore "prioritization" as an activity you can control. Walk up to the first responsible party you can find, and do your best, "Robin Williams as the Genie in Alladin" impression.

      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.

  • apercu ・ 7 days ago

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

    • weard_beard ・ 7 days ago

      Perfectionism is just a nice way to say, “conflict avoidant” :-)

ddawson ・ 7 days ago

I'm so happy i work on a team. Early in my career I substituted my speed for what I saw as deep experience of others around me. I was the one willing to move fast and break things and I'm still doing that. Fortunately, I've learned to temper my eagerness by teaming up with others willing to probe my approach. I'm still impatience and eager but I'm much, much stronger in a team than as a lone cowboy.

inactiveseller ・ 7 days ago

Interest side of the story. I was trained in kung fu - wing chunwith a little group in Guadalajara, Mexico. Really good ideas , resistance and trainging.

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.

halgir ・ 7 days ago

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

  • jraby3 ・ 7 days ago

    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.

  • mathgeek ・ 7 days ago

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

  • smrxx ・ 7 days ago

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

    • apercu ・ 7 days ago

      Might be a tongue cheek comment, but I built my practice around this idea. If you're going to do deep thinking work 48 weeks a year, you simply can't do it effectively 40 hours a week. Even a machine needs maintenance down time.

  • npodbielski ・ 7 days ago

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

ferguess_k ・ 7 days ago

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.

  • apercu ・ 7 days ago

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

    • ferguess_k ・ 7 days ago

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

      • apercu ・ 7 days ago
        ・ 2 more

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

        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.

        • ferguess_k ・ 7 days ago

          We probably have the same mindset. Somehow I just want things to flow smoothly. I love and hate it though.

  • circlefavshape ・ 7 days ago

    > 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

sdjcse1 ・ 7 days ago

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

scott_w ・ 7 days ago

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!

gala8y ・ 7 days ago

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.

alganet ・ 7 days ago

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.

MetaMalone ・ 7 days ago

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.

tpoacher ・ 7 days ago

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.

  • devsda ・ 7 days ago

    > That dual interview question "what is your greatest strength? what is your greatest weakness" is a very bad question.

    Is there a 'right' answer to this question that's honest and isn't phony ?

    • tpoacher ・ 7 days ago

      Yes. Pointing out that strengths and weaknesses are the two sides of the same coin, as above. And then proceeding to talk about your strengths while identifying when they can turn into weaknesses, and how you mitigate those situations.

munificent ・ 7 days ago

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.

kwakubiney ・ 7 days ago

I think this goes in line with companies as a whole as well. I work at a place where features are pushed at a very very high speed and we have realized that the tradeoff is us missing pretty crucial edge cases in our development. Now i’m not sure if people have worked in a place where they shipped products fast but were able to minimize bugs but i’d love to hear how your company achieved that. Is it even possible? Does it all come down to hiring to suit your fast paced needs?

  • foolfoolz ・ 7 days ago

    it depends on the business and industry. at some phases in a business’s life you need to get features out more than stability. some industries are more sensitive to bugs than others. it’s not a one size fits all approach.

    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

  • calebio ・ 7 days ago

    Is it fair to say that also in your experience, those crucial edge cases/misses accumulate over time, making it even harder to ship things?

    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.

    • kwakubiney ・ 7 days ago

      Yeah pretty fair to say. The company is in a domain where accuracy is very important and crucial because we deal with people’s money, but most products are also in a market where competition is high so moves must be made quickly.I have not been there for long but it seems in the beginning, the foundation laid because of fast shipping culture has caused all these problems.

bch ・ 7 days ago

Just yesterday i saw this quote from Brian Eno -

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.

pentamassiv ・ 7 days ago

My professor always said: "The sum of the problems is constant"

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.

  • procaryote ・ 7 days ago

    It's pretty obviously wrong though. People aren't zero-sum creatures of perfect balance.

    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.

  • trash_cat ・ 7 days ago

    Isn't that quite a pessimistic view though? Of course there will always be something that irks you, but that does not mean you can't be fulfilled at some point in life and be aware that you are really happy and there is nothing you would change.

    • pentamassiv ・ 7 days ago

      I think it depends on your perspective. You can think of it as pessimistic or optimistic. An optimistic view would be: There will always be problems, but I can deal with them. Everyone else also has problems. No matter the decisions I made, there is no reason to have regrets.

      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

karmakaze ・ 7 days ago

How can having a comprehensive understanding of your infrastructure/stack be a weakness exactly?

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.

  • w10-1 ・ 7 days ago

    > How can having a comprehensive understanding of your infrastructure/stack be a weakness exactly?

    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 :)

    • karmakaze ・ 7 days ago

      Any code runs on the infrastructure/stack, so old or new it's the same underlying foundation. If there's a change or proposed change to the infrastructure/stack the first thing I'd do is become very familiar with it.

      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.

  • lawn ・ 7 days ago

    > How can having a comprehensive understanding of your infrastructure/stack be a weakness exactly?

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

    • karmakaze ・ 7 days ago

      > It may cause you to favor complex solutions that are obvious to you, but inscrutable to people without your deep knowledge.

      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.

lanfeust6 ・ 7 days ago

The only context for my weakness being a strength is running operations or my own business, or high-level architecture. My preference is for not being detail-oriented, but I rally to do that when I have to, which is often when troubleshooting code. I have to break down the problem and simplify it, not just to be effective but to keep motivated.

iamwil ・ 7 days ago

The article mentioned speed of dev as a trait that's both a strength and a weakness. I suppose the opposite of that is quality orientated, but not very fast.

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?

bsenftner ・ 7 days ago

This is a good, astute essay providing a useful mental framework that can undermine many a developer's innate imposter syndrome. The concept of duality is a great discriminator, it is just subtle enough that focusing on one's strength as a duality is a mind game that distracts from what normally spirals into negative self suspicion.

gnuser ・ 7 days ago

Wow, I hadn’t thought of it like that before. I’ve recently been finding real insights in such reframing.

rkowal ・ 7 days ago

100% true and research backs this up: strengths are also risks (or weaknesses). - If you're very disagreeable you will offend people, but at the same time hold your ground (important in high impact roles). - If you're very driven, you might tend to dominate people. - If you're very flexible, you might be impulsive.

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

pandatigox ・ 7 days ago

Sorry, on a side note, I've been noticing the artwork for each blog post. It looks very aesthetic - is this AI generated? or actual artwork? I don't seem to find a source...

m463 ・ 7 days ago

This is true.

- 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

Uzmanali ・ 7 days ago

Wow, this really spoke to me. I’ve always been proud of how fast I work, but yeah... that speed has backfired more than once. I used to feel bad about it, but now I get it

reverendsteveii ・ 7 days ago

there should be a word for that horrible feeling when you realize that the things you love about yourself and the things you can't stand about yourself are all just yourself

wutwutwat ・ 7 days ago

Michael Scott: Why don’t I tell you what my greatest weaknesses are? I work too hard, I care too much and sometimes I can be too invested in my job.

David Wallace: Okay. And your strengths?

Michael Scott: Well, my weaknesses are actually strengths.

David Wallace: Oh. Yes. Very good.

  • kylecazar ・ 7 days ago

    Fun fact, Wallace was a business person they cast. He was a VP at Merrill Lynch, and remained so during the course of the show.

    Imagine reporting to the real life Wallace as a fan of the show.

begueradj ・ 7 days ago

It's like saying strength and weakness are relative concepts: strength has its side effects just as weakness can be beneficial in certain circumstances.

cjcenizal ・ 7 days ago

If you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.

tonijn ・ 7 days ago

Welk tbh there’s no need to quote Steve Jobs to get that insight

zackmorris ・ 7 days ago

If we're comparing prolific programmers with pragmatic programmers, I wonder if there's an analog on the management side?

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

  • huijzer ・ 7 days ago

    > Where is the self-awareness, the doubt, even the shame that brings wisdom?

    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.

    • huijzer ・ 7 days ago

      For example, Buffett in the 1989 letter:

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

spitfire ・ 7 days ago

Success is a cruel mistress.

Outsized success a curse.

  • hinkley ・ 7 days ago

    Layoffs caused by companies fishtailing because they don’t know when to stop hiring people as fast as they can place them. Always a bad time.