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