261–270 of 304 posts
Earlier quoted context omitted.
What you describe is definitely not a person with hard skills, so it's not relevant to the current discussion.
I was answering to a specific post that doesn’t mention or imply it, plus I mention exactly what you say in my second paragraph which you most certainly missed.
Earlier quoted context omitted.
Blaming people who use technology to make a valuable process accessible to themselves and then invoking a a no-true-Scotsman in order to defend the status quo is a good example of a lack of soft skills.
But the process is still inaccessible to them, provided we consider achieving reliability and security goals of said process. And no, this is not "no true Scotsman;" "vibe coded" software is demonstrably inferior in numerous ways, and outright dangerous in some contexts. No number of carefully scripted demos or PR campaigns is going to change this reality.
Consequently, this was the reason businesses had junior devs partnered with senior devs! It's not surprising that when you pair junior devs (human) with junior devs (gen ai coding) you still get junior dev issues.
Personally, I think AI coding tools being able to translate incomplete junior dev thinking into senior dev work is an impossible task. There's just not enough initial intent signal in the novel task use case (read non-'CRUD LOB app').
I do think eventually we'll have complementary expert tools that perform a senior dev-alike function (arch and security review), but that's a harder problem that likely isn't going to be economically viable as a product until/unless AI coding tools achieve substantial penetration.
Earlier quoted context omitted.
IDK, at many large orgs...there are developers that essentially communicate through "tickets" and "their lead"... and Def never talk to "business" people or customers. It's not very rare if you get a large enough org.
In other large orgs, the managers are in a parallel universe playing status games while the devs self-organize to get anything done. The soft skills involved in doing that wind up being completely invisible to the status universe.
Are you referring to the work the managers are doing or the devs are doing as being invisible?
Earlier quoted context omitted.
Doubt we'll see that in the short term. Long term, possibly, especially if you add a financial crisis. Truth is most larger software development organizations could have even before LLMs downsized significantly and not lost much productivity. The X formerly known as Twitter did this and has been chugging along on a fraction on its original staff count. It's had some brand problems since its acquisition, but those are…
The thing is, Twitter is stuck. It's not growing, most likely it's shrinking. We also have no idea if it's profitable or not. Twitter had a lot of engineers on its payroll to look for the next big thing. If you give that up and keep a skeleton crew, sure, that works. Most businesses don't want to become husks of their former selves.
It was objectively bad for facebook's net profits to pour over $10 billion into the metaverse, what they gambled would be the next big thing, but the perception that they were cooking up something new, even if that was a massive waste of money, was better for their valuation than the sense that they were just resting on their laurels.
Earlier quoted context omitted.
In other large orgs, the managers are in a parallel universe playing status games while the devs self-organize to get anything done. The soft skills involved in doing that wind up being completely invisible to the status universe.
> The soft skills involved in doing that wind up being completely invisible to the status universe. Are you referring to the work the managers are doing or the devs are doing as being invisible?
(Not all managers, this was a special degenerate case, but it's worth considering that different people have different goals/incentives/values. It's not always a straight line to "delivering customer value" that is only held up by a lack of people skills.)
I don't think it has ever been the case that you could neglect soft skills. You will hear this over and over, in every area of every business: people become successful by adjusting their behaviour to what works for the business. Sometimes this is called being a slick politician, sometimes it is called avoiding getting bogged down in politics. But it's never been the case that a dev could just focus on technical thing…
Overall, it'll be a worse world if you can't make a living purely on hard skills. If soft skills is mostly about sucking up, and there is no demand for any hard skill, you'll find society less able to stand up to the pressures of a majority group, because guess what, they're all too scared to stand up as an individual for fear of dropping the ball on the soft skill. Moreover, the game theory of the soft skill is trea…
I don't think it has ever been the case that you could neglect soft skills. You will hear this over and over, in every area of every business: people become successful by adjusting their behaviour to what works for the business. Sometimes this is called being a slick politician, sometimes it is called avoiding getting bogged down in politics. But it's never been the case that a dev could just focus on technical thing…
I respectfully disagree. Over 3 decades as SWEs I have seen many devs who did absolutely nothing but hack - two of them were autistic too. The “everything is numbers” is small fraction of the industry but perhaps since this is HN maybe resonates more with people?
Earlier quoted context omitted.
Thing is, Scrum isn't supposed to be something you do for long. As you no doubt know, Agile is ultimately about eliminating managers from the picture, thinking that software is better developed when developers work with each other and the customer themselves without middlemen. Which, in hindsight, sounds a lot like my previous comment, funnily enough, although I didn't have Agile in mind when I wrote it. Except in th…
I don’t think people invested in Scrum believe it’s “temporary” or ever marketed it as such. And agile teams are supposed to be self-managed but there’s nothing saying there should be no engineering managers. It sounds counter intuitive, but agile is about autonomy and lack of micro-management, not lack of leadership. If anything, the one thing those two things reject are “product managers” in lieu of “product owners…
It is officially marketed as such, but in the real world it is always the managers who introduce it into an organization to get ahead of the curve, allowing them to sour everyone on it before there is a natural movement to push managers out, so everyone's exposure to it is always in the bastardized form. Developers and reading the documentation don't exactly mix, so nobody ever goes back to read what it really says.
> And agile teams are supposed to be self-managed but there’s nothing saying there should be no engineering managers.
The Agile Manifesto is quite vague, I'll give you that, but the 12 Principles makes it quite clear that they were thinking about partnerships. Management, of any kind, is at odds with that. It does not explicitly say "no engineering managers", but having engineering managers would violate the spirit of it.
> not lack of leadership.
Leadership and management are not the same thing. The nature of social dynamic does mean that leadership will emerge, but that does not imply some kind of defined role. The leader is not necessarily even the same person from one day to the next.
But that is the problem. One even recognized by the 12 Principles. Which is that you have to hire motivated developers to make that work. Many, perhaps even most, developers are not motivated. This is what that misguided ticketing scheme we spoke of earlier is trying to solve for, thinking that you can get away with hiring only one or two motivated people if they shove tickets down all the other unmotivated developers' throats, keeping on them until they are complete.
It is an interesting theory, but one I maintain is fundamentally flawed.
Earlier quoted context omitted.
Perhaps it's a poor choice of words, what I mean by 'sucking up' refers to understanding the counterparty's mind (and making decisions to close the deal), and it is definitely a part of the game. Every single thing that you listed requires a understanding of the opposing party that you just talked about in order to make the deal work out. A boss has his/her temper to deal with, her engineers have their own preference…
Honestly, the way you conflate soft skills with randomness and capital-P Politics is worrisome. > Every single thing that you listed requires a understanding of the opposing party that you just talked about in order to make the deal work out. Yes, that's the whole point! Understanding other people is an important life skill, and something that every neurotypical person should be able to do. (And, if you're not neurot…
> See it this way: You have two people in your team who disagree on a technical issue. You need to help them come to a decision.
You lay out a very hopeful scenario. Sometimes there are some issues where there are no clear cut answers (ie. you cannot apply a objective value judgement) and it's a purely political play. If you are asked to solve the issue, you have to take a side either way, and whichever side you take you will piss off the other, possibly for good. If the side you judged in favor of fails, you might end up being on the chopping block, or be 'marked' by the organisation with a 'never-do-well' label. This is -the- landmine I'm talking about.
You had better hope there are support in the org that can still support you, because depending on the severity of the fallout, you might be starting from 0. You'd better hope hard skills are still valuable by then.