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 things and not spend any time figuring out the context they are working in, and behaving accordingly.
My first day of work, this is what my boss said to me: "Look at this trading floor. There's screens everywhere, everything is numbers. Deltas, gammas, vegas. Everything is calculated by computers. But don't forget, every business is a people business!"
The jargon is getting more & more obtuse every year...
Also, a major feature of "vibe coding" now is the rough edges on UI design that don't make sense at all... It's pretty obvious that code bases aren't evolving because these systems can't handle complex prompts while retaining features from prior releases, and it seems like functional testing for releases has now become the kid who can't speak that fell down a well... Oh well.
Vibe coders are the new circa-2000 cross-trained front end web developers.
Without industry experience and/or software engineering education, they zoom past a lot of hard-won lessons.
E.g. the node.js packaging ecosystem wouldn't have committed so many own-goals if it'd been designed by people with more historical awareness
In time, vibe coders will rediscover test driven development, but until then you'll have to deal with watching monkeys try to construct buildings by stomping hard and frequently enough that the atoms self-assemble.
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.
The joke about vibe coding replacing junior devs is apt, because it has the same failure mode -- it can build something that works, but completely incompetently and with unmaintainable design choices.
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.
> make a valuable process accessible to themselves
I am directly calling into question the "value" of that process. It's also becoming increasingly clear that these tools just whitewash away the copyrights of the materials they were trained on and still mostly reproduce when asked. This would then actually be the destruction of value.
> invoking a a no-true-Scotsman
I did not. This is in response to an article. It demonstrates a clear lack of understanding of professional software engineering and instead imagines that writing a good spec is all there is to actually do. It displays a definite lack of understanding of the fundamentals of engineering or of profitable business.
> is a good example of a lack of soft skills.
You seek appeasement instead of understanding and you call into question my skills? I see now what you think this forum is for.
Calling you out for being overly critical is not 'seeking appeasement'. I am calling your skills into question -- why shouldn't I? Your soft skills seem to consist of attacking people when you don't like what they have to say.
> But it's never been the case that a dev could just focus on technical things and not spend any time figuring out the context they are working in, and behaving accordingly.
This is factually wrong. Until a few decades ago in tech, and it's still like that in most economic sectors and I dare say most countries, it's the managers that take the role of figuring out the organization and interfacing with other teams. An engineer being only in charge of technical issues but nothing business-related was the norm; that would yield no promotion into management, of course, but still the norm.
Yes, but it goes more far than that:
You will have to participate in meetings, you will be asked to joing for a lunch, you will be asked to contact a customer/devcontact there, you will be asked to attend some events, you will be asked to communicate with others etc.
You are not existing as isolated particle in vacuum behind your screen :-)
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.
Both, actually, but in the case I'm thinking of the devs with the strongest leadership skills in terms of organizing their peers to make things happen were completely invisible to management who were playing a different game. Just like their game was invisible to the devs shipping product, who didn't understand the implications on their careers. Saw a couple of great unofficial leaders get fired and a bunch more leave due to the disconnect. It caught up to the managers later, turned out their people skills weren't good enough after execution ground to a halt.
(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 was trying to subtly point out that the information asymmetry goes both ways: most devs aren't aware of what their managers are doing for the team either. More transparency in both directions is healthy (and skip-level meetings, for god's sake).
Yeah, I hear you and I also added a parenthetical that the incentives aren't always the same.
In an organization of high-minded individuals, the information asymmetry goes both ways, I've been a manager and a dev and I tried to be high-minded and do my best to smooth that assymetry for the greater good in both roles.
But sometimes, especially the last 3-4 years since it got tough, there's a lot of people trying to hold on by any means necessary. Information asymmetry isn't the problem there, it's incentive assymetry. What if you're just not that good at tech and got promoted to 1st, maybe 2nd level manager in the good years? What's your incentive?
Absolutely! The "How does a bad manager with a good team ever get identified/fired?" problem is something more companies should have an answer to.
That's why I think skip-levels check-ins and direct reports regularly anonymously rating their manager (via HR) should be the starting place at all companies.
Otherwise, toxic (or just underperforming) managers stay in their positions longer than is good for the company.
Most employees are incapable of rating their manager. They can complain or praise, but they're not competent to judge whether the manager is competent.
There's an interesting parallel to the advice often given for "lean" startups, of never taking seriously the customers' feature requests, only their complaints. Most customers know their own pain points but aren't capable of suggesting good general solutions that can be incorporated into a product.
I have seen a number of organizations throughout my 20 ish year career that have a policy of “developers don’t meet with customers”.
I am not endorsing it and I think it’s poor form, but it absolutely exists. You are in a weird bubble if you think there haven’t been engineering jobs where a dev could only care about code.
I neglected soft skills and I survived so far. I'm bad at soft skills and I probably have some sort of mental disorder like autism or something. I don't really care, I don't enjoy interacting with people and I prefer interacting with machines as much as possible. I've found a place that pays me for my technical skills and does not bother me with human interactions, I think there are more places like that in the world.
> I think there are more places like that in the world.
There are but not as many as we might like.
I’d say I’ve learned to be decent on the soft skills side but it comes at a cost and the need to overutilise them can be incredibly draining.
So many places run Agile so it feels like software engineering for noisy extroverts but, to me, it just makes it so hard to get anything done, and I see others struggling the same way.
One of my pet peeves is how bad people are at, or perhaps how unwilling they are to embrace, asynchronous communication. Again, this favours the extroverts.
And then one key advantage of written communication nowadays is I can ask an LLM to help me with it so my message lands better. More than once, when dealing with particularly frustrating situations, I’ve asked ChatGPT to rewrite an email for me “so that I come across as a reasonable human being rather than a deranged psychopath”. It works.
>So many places run Agile so it feels like software engineering for noisy extroverts but, to me, it just makes it so hard to get anything done, and I see others struggling the same way.
Interesting. I'm very introverted too, but I worked at one Agile place, and it was like a dream for me. Maybe it was just the way they implemented it. What I liked was that I didn't need to talk to people much, outside of the bi-weekly planning meetings (which were large enough that I didn't have to actually speak up much). Instead, we used Jira to track everything: tasks were broken down into tickets, and I could see at a glance what everyone on the team was working on at the time, what work remained to be done, etc. When I finished a task and put it up for review, I could just go find another unassigned ticket and grab that and start working on it, instead of having to talk to anyone (like the boss). We did a lot of code review too, but here again, it was all through Jira/Gitlab/etc., not in person. So I could spend time reviewing other people's merge requests, writing my comments, etc.
The only time I really needed to talk to team members was 1) during the morning stand-up, which was quick, 2) during the bi-weekly sprint review and sprint planning meetings, and 3) if someone was stuck and wanted to work together in-person on a problem (not often).
By contrast, I'm now stuck in a poorly-run place doing waterfall development, and it's awful. I don't know what anyone is working on usually, because everything is verbal (we do use Jira, but I can only see my own pre-assigned tasks), I don't have a good idea of what the group is doing, the timeline for anything, how anything is progressing, if there's other things I could help with or add input to before someone goes the wrong direction, etc. The manager just runs thing in a completely authoritarian manner. I wish I could just go back to my old Agile workplace.
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?
It depends on what you want to achieve as a developer, I think. Having some soft skills makes a lot of things easier, but if you don't have the hard skills to back it up, you'll plateau unless you switch to management before you reach your limit.
At the same time, if you're very good at what you do, soft skills are a lot less important. Most of my peers would rather work with brilliant jerk than a friendly average person.
But most people are not brilliant, and then you can't afford to not have soft skills.
> Most of my peers would rather work with brilliant jerk than a friendly average person
I worked with one of these. Every interaction was miserable and stomach-turning. He slowed the project down in a number of ways. A friendly average person would have been a net gain.
>A friendly average person would have been a net gain.
I'm perfectly happy to have a friendly, average person as my boss, as long as he has good people skills and is pretty good at managing a team. He doesn't need to be technically brilliant at all.
By contrast, working with a boss who's a technically brilliant jerk is an absolutely miserable experience. Companies that make a habit of promoting brilliant jerks into management positions should be avoided.
What was his role? How did he slow the project down? I ask because quite often, the value of "soft skills" is exaggerated. In almost 20 years of software engineering I have met some of the worst personalities imaginable. Yet, I cannot think of a single time somebody's personality got in the way to such an extent it slowed the project down. Some problems can't be solved by average people. In such cases, bad social skills with above average intellect will go farther than average intellect with good soft skills.
I know an example. A tech lead who would demand every single task to be done in certain ways and go through a certain processes. Invading other team's PRs and slack channels in order to pick fights because they weren't using his microservice or his libraries. Claiming "if you're not working like us, then you're wrong". Asking people to make PRs but then not approving. Before being demoted, his team had ZERO new features delivered for about a quarter. To me that's an example of slowing down teams.
But if you mean you want someone "brilliant, but an asshole", then I agree with you. I find that the common examples are more about incompetent managers who can't make the best of an IC who can work well in isolation.
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.
Not OP, but I did work for a boss once that was technically very strong, but not as strong in terms of planning and scheduling work. It was a very difficult process, because I couldn't deliver what they wanted, as what they wanted changed both during and after delivery. Most things I delivered, which were what we agreed upon before delivery, were rewritten as they did not envision or plan work in advance. Technical skills are not a panacea; professionalism is a multidimensional skill matrix.
Exactly: being able to quote esoteric facts and trivia about CPU instruction sets or compiler features and use those while working doesn't automatically make someone adept at planning and leading a team of developers. However, some companies think the opposite, and the end result is not good.
The logic, the method names, the test names, code in the log messages.
Does not matter what the output or complexity is, does not matter how the previous state of the code in the area looks like, it. Must. Look. And. Read. Their. Way.
A 3 file PR review can take weeks. There was once a PR for a new feature that took 1.5 years and 2 developers (the og op left the company 3 months into having opened this PR) to eventually merge.
People want results. Brilliant assholes produce those, so you tolerate the annoying parts. Would be great if they were also kind, but I'll take a house built by an asshole over a tent erected by a friendly person.
It's not a dichotomy, obviously. There are plenty of very smart people who are also pleasant to be around. But if they're either strong in soft skills _or_ in hard skills, I prefer them being asshole over them not contributing but being nice.
Very often in my experience, people with too many soft skills and too little hard skills are at best dead weights, at worst con men, which are a special kind of asshole you REALLY don't want to deal with.
Of course the best is to have both hard/soft skills, which is not as rare as people assume.
>Very often in my experience, people with too many soft skills and too little hard skills are at best dead weights, at worst con men
No, these are the people who should be moved into management positions. They can spend time on all the soft-skill stuff that ICs don't want to spend time on, like dealing with upper management, leading meetings, etc. They don't need to have the best hard skills, just enough to understand at a higher level and communicate with others in and out of the organization, and they can refer to the experts in their teams when they need more detail.
Hard disagree. I've yet to see a "brilliant asshole" with anywhere near the kind results I expect from my teams. The usual pattern is your typical asshole will ship broken stuff and then blame everyone else for the breakages.
Now, average assholes who self-promote as brilliant and hope no one will see through their crap, sure, plenty of those. I'd recommend against failing to see through their crap, though. They'll make your actually good engineers leave.
Maybe you had those average assholes masquerading as brilliant? I don't know that of course, but "ships broken stuff" doesn't sound particularly brilliant to me.
I'm thinking of the type that builds things that you can stack up against the output of others and comes out miles ahead. I have one of those in my team, and it feels like a force of nature: he independently does in a month what a team of five did in three, and his work is of better quality. Of course I'll cut him a lot more slack.
I have no experience with the military and very little with working in academia, but a lot with commercial work, and I've seen it work many times. Clearly those people wouldn't be the ones talking to customers or leading teams, but it's worth a lot to have someone that can tackle hard problems.
I'm not at all saying that you can only have one or the other, or that soft skills don't matter at all. It's just my experience that output matters a lot more than people say in these types of conversations.
To me looks a lot more like the cliche Diva in music - are you really going to not work with someone extremely talented just because they're difficult to work with and you wouldn't want to hang out with them?
> it's worth a lot to have someone that can tackle hard problems
Oh, absolutely. My point is those personalities are almost common in the military and academia. They’re rarer in commerce because there aren’t that many niches where hard problems exist independent of peoples’ preferences. (As in, choosing how to scope the hard problem is part of what makes it hard. And the scoping that works best isn’t going to be found in isolation from customers and others working on the problem.)
> Most of my peers would rather work with brilliant jerk than a friendly average person.
I think you need to be more specific than just "avert" the trope without elaborating. Others have commented how a brilliant jerk can slow a project down, but I get the impression that you are thinking of someone who is not sociable, not interested in business goals, very direct and perhaps even pessimistic about others' ability, but hand them a technical task and they can deliver exceptional results. This is opposed to, say, someone who is sociable but can't deliver anything without constant attention or handholding.
Yes, absolutely. I'm not talking about people who are not sociable _and_ can't produce, but people who don't care about your feelings, but are very strong in their work.
In other comments, it felt like they focused very much on the "low in soft skills" part without looking at the other skills being extended. Of course, someone who is unpleasant to work with and only writes buggy software will not help a project progress. But someone you don't want to spend time with but who carries your team through the project with his skill and productivity is a very different story.
Also the vast majority of sw engineers just have average soft skills. There is still a difference to sales and we certainly do not need any more pretentious behaviour in technical discussions. Yes, VCs will require you to advertise yourself, but I think many also just want a realistic approach about a potential business ventures.
The most practical problem sw engineers have here that they waste hours on some frivolous technical solution that could have been cleared up with a pragmatic approach through a three minute call.
That engineers aren't people persons is a stereotype. There are as many "autists" in the social sciences. Yes, I know I shouldn't use that word for anything that is not a pathological diagnosis.
Soft skills, in the context it's used here, include communication skills.
A key part of communication is being able to communicate ideas with someone not like you (different expertise, background, touchpoints).
Imho, a lot of software developers suck at that. (Obligatory: 'I talk to the customers so the engineers don't have to')
To the article's point, this becomes an increasingly valuable and critical skill the closer software development moves to the original requesting users. Or the closer the ability to code moves to people who were already talking to users.
Personally? I view myself as a problem solver: whether I solve a problem with code, a new technology, a conversation with a colleague, a deep dive discovery session with a SME, or a month-long series of political meetings with conflicting stakeholders, I don't care.
>>But it's never been the case that a dev could just focus on technical things and not spend any time figuring out the context they are working in, and behaving accordingly.
I've worked with plenty of programmers who were absolutely insufferable human beings but were some kind of supernatural coders who were doing the work of 20 people or were literally the only people who could understand the maths or physics or rendering in our products - so everyone kinda put up with it. I used to know someone who had dozens of HR complaints about them every year and nothing was done because the company didn't think they could risk firing them.
So yeah. They exist. And I don't think AI is going to do much about them, but I'd love to be proven wrong.
There are lots of developers who are able to lean into their inclination to be non-communicative. In many cases I think this inclination is at least partly due to neuro diversity; but I've met some who are simply genuinely unpleasant.
To the outside, the difference is hard to tell, isn't it? Between neuro-diversity and genuine unpleasantness -- isn't it mostly that one has a diagnosis (that you know of) and the other does not?
You might change your moral judgement of someone's behavior if you find out they have this or that condition (at least I do), but it doesn't change how their behavior impacts you, does it? If it did, I think the best you could do is to assume that everyone has some sort of condition that makes them act the way they do, and it'll be less of a problem.
As someone who's neurodiverse myself, I do want to agree with this. Having said that, I do think it's possible for someone to choose to be an asshole and be neurodiverse at the same time. I wouldn't ever want my neurodiversity to be a free pass for any type of behaviour myself.
I generally struggle with the idea of someone actually choosing to be an asshole, I assume there's usually an unseen cause.
E.g. I work with someone who seems very normal, is very professional, and I have no reason to believe that they area neurodiverse in any way. They once were very direct in a ticket towards a different team. Did they choose to be an asshole, or were they losing their last ounce of patience and politeness because they've been carrying a mountain of responsibility and stress? I think it's very difficult to tell that apart, or to judge based on "well, they could have not taken on that responsibility so they're liable for anything that is a consequence of it".
I don't consider it a free pass, but there's a lot more understanding for things that are outside your control. Where we see that line of control probably determines whether we judge someone harshly or not.
>I used to know someone who had dozens of HR complaints about them every year and nothing was done because the company didn't think they could risk firing them.
But did the company make them a team lead and put him in charge of other people?
No, luckily. But they were the kind of person who you could casually ask "hey John, what have you been working on" and they would reply with "you're too stupid to understand so I won't bother explaining".
>>>absolutely insufferable human beings but were some kind of supernatural coders who were doing the work of 20 people
I don’t at all condone being that guy. However….
It’s pretty amazing what an engineer can accomplish if you can actually get into a flow state because people are too afraid/intimidated to interrupt you every 10 minutes and you aren’t being invited to endless (and mostly useless) meetings all day.
You’re right but i have always preferred people who can do a little more. Nothing against the socially awkward and conflict avoidant nature in many of these friends, but people who push back and fight to communicate their views and passions often got our team better outcomes than someone who just turns up and does the work they’re asked to do.
As long as it is not opposite set of skills (talks a lot without knowledge to back it up so essentially using charisma to convince people to do the wrong thing most of the time) then yes, a lil bit of negotiation can save you a whole lot of work in the long run (XY problems being one example)
For sure, I’ve been tricked into hiring those people before too. It’s good that there’s still something hard in running an organization, the whole “what is value?” question feels like it’ll be one of the few things we have to maintain work for humans over the next little while.
That is likely referring to what has become known as the standup, where developers read off the commit log for the "manager" who hasn't yet figured out how to use a computer.
It definitely happens at bloated organizations that aren’t really good at software development. I think it is especially more common in organizations where software is a cost center and business rules involve a specialized discipline that software developers wouldn’t typically have expertise in.
I have 13 years of professional experience, and I work in a small company (15 people). Apart from one or two weekly meetings, I mostly just work on stuff independently. I'm the solo developer for a number of projects ranging from embedded microcontrollers to distributed backend systems. There's very little handholding; it's more like requirements come in, and results come out.
I have been part of some social circles before but they were always centered around a common activity like a game, and once that activity went away, so did those connections.
As I started working on side hustles, it occurred to me that not having any kind of social network (not even social media accounts) may have added an additional level of difficulty.
It's not so hard if you're an expert in the field or concept they're asking the solution for, especially if you've already implemented it in the past, in some way, so know all the hidden requirements that they aren't even aware of. If you're in a senior position, in a small group, it's very possible you're the only one that can even reason about the solution, beyond some high level desires. I've worked in several teams with non-technical people/managers, where a good portion of the requirements must be ignored, with the biggest soft skill requirement being pretending they're ideas are reasonable.
It's also true if it's more technical than product based. I work in manufacturing R&D where a task might be "we need this robot, with this camera, to align to align to and touch this thing with this other thing within some um of error."
Software touches every industry of man. Your results may vary.
I've seen that plenty of times. I suspect that you haven't seen it because you live in a place with high cost of living, which induces a high turnover in personnel, or perhaps you've been working in very dynamic markets such as SaaS.
When I was starting my career in Europe as freelance sysadmin, I worked several times for small companies that were definitely not at the forefront of technology, were specialised in some small niche and pretty small (10-15 engineers), but all its engineers had been there for 10-20 years. They pretty well paid compared to the rest of the country, and within their niche (in one case microcontroller programming for industrial robots) they were world experts. They had no intention of moving to another city or another company, nor getting a promotion or learning a new trade. They were simply extremely good at what they were doing (which in the grand scheme of things was probably pretty obsolete technology), and whenever a new project came they could figure out the requirements and implement the product without much external input. The first time I met a "project manager" was when I started working for a US company.
>I worked several times for small companies that were definitely not at the forefront of technology, were specialised in some small niche and pretty small (10-15 engineers), but all its engineers had been there for 10-20 years. They pretty well paid compared to the rest of the country
This isn't possible in the USA. Companies like this (small, and not in tech hub cities) always try to take advantage of their location and pay peanuts, with the excuse "the cost of living is lower here!", even though it's not that much lower (and not as low as they think), and everything besides houses costs the same nationwide.
I agree that something like that is very unlikely in the US, which is why so many people in this thread (I presume Americans) were incredulous as to whether that was even possible, but elsewhere in Europe good software and electronic/electrical engineers can be making very good money for the local standards in stable jobs, while at the same time being paid a lot less than they would be in a similar job in one of the US major tech hubs.
I've heard this, and I've even seen it in plenty of poorly performing businesses, but I've never actually seen it in a highly performing, profitable tech company. Other than at the new grad level but it's treated as net-negative training while they learn how to build consensus and scope out work.
Not coincidentally, the places I've seen this approach to work are the same places that have hired me as a consultant to bring an effective team to build something high priority or fix a dumpster fire.
A fly-by-night charlatan successfully pushed ticking into our organization in the past year and I would say it was a disaster. I only have the experience of one, but from that experience I am now not sure you can even build good software that way.
I originally hoped it was growing pains, but I see more and more fundamental flaws.
I’ve worked at one, but it required a PM who was ruthless about cutting scope and we focused on user stories after establishing a strong feedback pipeline, both technically through CI/CD/tests and with stakeholders. Looking back, that was the best team I’ve ever worked in. We split up to separate corners of the company once the project was delivered (12 month buildout of an alpha that was internally tested and then fleshed out).
Maybe I had greenfield glasses but I came in for the last 3 months and it was still humming.
Previously? There was an understanding of the problem trying to be solved. The gaps left the pangs of "this isn't right".
Now I have no way to know where things stand. It's all disconnected and abstracted. The ticket may suggest that something is done, but if the customer isn't happy, it isn't actually. Worse, now we have people adding tickets without any intent to do the work themselves and there isn't a great way to determine if they're just making up random work, which is something that definitely happens sometimes, or if it truly reflects on what the customer needs.
You might say that isn't technically a problem with ticketing itself, and I would agree. The problems are really with what came with the ticketing. But what would you need tickets for other than to try and eliminate the customer from the picture? If you understand the problem alongside the customer, you know what needs to be done just as you know when you need to eat lunch. Do you create 'lunchtime' tickets for yourself? I've personally never found the need.
You must be working in projects with a relatively small number of “problems to be solved” at any given time, and with the problems having relatively low complexity. In general there’s no way to keep everything in your head and not organize and track things across the team. That doesn’t mean that a lot of communication doesn’t still have to happen within the team and with the customers. Tickets don’t replace communication. But you have to write down the results of the communication, and the progress on tasks and issues that may span weeks or months.
> In general there’s no way to keep everything in your head
I imagine everyone's capacity is different, but you wouldn't want anyone with a low capacity on your team, so that's moot. Frankly, there is no need to go beyond what you can keep in your head, unless your personal capacity is naturally limited I guess, because as soon as you progress in some way the world has changed and you have to reevaluate everything anyway, so there was no reason to worry about the stuff you can't focus on to begin with.
I find that the current way we do Scrum is way more waterfall-ish than what we had before. Managers just walked around and talked, and knew what each person was doing.
We traded properly working on problems for the Kafkaesque nightmare of modern development.
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 the real world, one day up and deciding no more managers on a whim would lead to chaos, so Scrum offered a "training wheels" method to facilitate the transition, defining practices that push developers into doing things they normally wouldn't have to do with a manager behind them. Once developers are comfortable and into a routine with the new normal Scrum intends for you to move away from it.
The problem: What manager wants to give up their job? So there has always been an ongoing battle to try and bastardize it such that the manager retains relevance. The good news, if you can call it that, is that we as a community have finally wisened up to it and now most pretty well recognize it for what it is instead of allowing misappropriation of the "Agile" label. The bad news is that, while we're getting better at naming it, we're not getting better at dealing with it.
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”.
> I don’t think people invested in Scrum believe it’s “temporary” or ever marketed it as such.
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.
I've realized it's a different paradigm in (very loosely) the Kuhn sense. You wouldn't track tasks if you're fundamentally not even thinking of the work in terms of tasks! (You might still want a bug tracker to track reported bugs, but it's a bug tracker, not a work tracker.)
What you actually do is going to depend on the kind of project you're working on and the people you're working with. But it mostly boils down to just talking to people. You can get a lot done even at scale just by talking to people.
People gotta remember its a job just like anything else. I dont see any other profession going above and beyond so why should that be levied upon on programmers, I don't see PMs trying to understand code, CEOs trying to understand the customer more than the investor.
McDonalds and Taco Bell tried to get rid of their "soft skills" (AKA customer service} and look how they're doing right now... Endless stores that all look & feel the same -- uncomfortable seats, no happy families around for longer than 10 minutes, longer drive-thru lines, and impersonal & impatient staff that avoids customers like the plague.
Evangelists will preach Ai because it's good for corporations that don't care about customer needs, but in the same sense, it may well be the catalyst for many to move out of cities to more human areas as it grows.
Businesses dictate the spread of Ai, and then foist it on customers because they think monopolies are sustainable, but the foundational rules always ring true -- Customer service & commitment are essential to the survival of a business. This tone deaf approach will eventually alienate many from companies that adopt it, and there aren't enough tech-inclined introverts to sustain profit in a world where Ai takes everyone's jobs. We don't ALWAYS want to talk to vending machines, human interaction is a need for many that Ai evangelists seem to think will simply go away.
I hope there are still some reasonable minded business leaders out there to swoop in and fix things after the ashes this era leaves along with all the VC carnage & political damage rendered on our economy.
Ai is great for math though... Maybe that should be the less-destructive focus.
>uncomfortable seats, no happy families around for longer than 10 minutes
Which is probably also net positive for business - similar to loud music in the pubs is a deliberate choice so people could focus on drinking rather than talking?
>McDonalds and Taco Bell tried to get rid of their "soft skills" (AKA customer service} and look how they're doing right now... Endless stores that all look & feel the same -- uncomfortable seats, no happy families around for longer than 10 minutes, longer drive-thru lines, and impersonal & impatient staff that avoids customers like the plague.
How's their profitability? Long drive-thru lines sounds like business is doing well.
This reminds me of people complaining about Windows, with its ads and AI and tracking and such. They don't like it as users, but the company is making plenty of money, so of course it's the right thing to do.
Very often some tech lead or head of could spot them and put them on tasks where they could be autonomous (generally technical but important aspects that bogs down several teams or products: pipelines, tooling, api design, performance, etc).
Some could also be involved in features involving business logic but the lead/PM would make sure to put more details or streamline any feedback/questions through jira.
Also, there's even more developers out there that get complacent on the business aspect after some time of seeing how poor product and business development is, and just phase out of it completely and try to find solace in the technicalities.
If feels sometimes like many on HN live in ultra competitive bubbles with managers pushing people to grow and promote them like it works in Meta and similar, but that's really not the norm, it's the exception.
Many of us work in companies where software is an expense, not an asset, mentality is different, there are no such structures, management and product are crap and you find a wide variety of situations and devs.
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 treacherous and uncertain. There's too many unknown unknowns, it's like not knowing if the dice you're playing is loaded against you. You don't know how many cultural land mines you might step on when interacting with your superior, or if there's a glass ceiling enforced by a group who will nitpick on minor irrelevant 'faults'.
Whereas compare soft skills to hard skills, you have a major advantage in certainty. There is a dice loaded in your favor. You know you can get much of the stuff done, and once you've reached the desired results, that's all there is to it.
I also could go on on how soft skills erodes human's capacity for judging what is value, instead basing their opinions on the majority source of opinions... It'll definitely be a much more irrational world to live in.
I'm sorry, but that's nonsense. Soft skills are mostly definitely not about sucking up.
At a previous job, the PM for another team often asked me to join some of their meetings — her engineers were shit at talking to non-technical people, so, for critical meetings, she asked me to join to serve as an interpreter of sorts. That's soft skills at work.
Talking to stakeholders and understanding what they need? Soft skills. Understanding the different between important and urgent? Soft skills. Being able to assess a candidate during an interview? Soft skills. Navigating cultural differences when you have offices or suppliers abroad? Soft skills.
I'd go as far as to say that the single biggest difference between a junior and a senior engineer is how well developed their soft skills are.
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 preferences, and that sucks, because as I said the game of soft skills can be a cultural landmine equivalent to rolling a dice with unknown odds.
If that is the only game in town, the result could turn out to be like the USA's politics of today, with no way to deviate/defect if you disagree.
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 neurotypical, it's a limitation about yourself that you need to acknowledge)
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. Would you rather have those two people have the mindset that "other engineers have their own preferences and that sucks", or that they have the mindset that "other engineers have their own preferences as a result of their own experience, and I welcome navigating those differences as part of the job"? Which of those two conversations ends with the two engineers understanding why the other person has a different opinion, and reaching a reasonable compromise? Which conversation ends with everybody involved learning something new, making the team technically stronger?
Because soft skills is also dealing with politics, you can't separate the 2.
> 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.
But most of the things you're describing as bad can also be described as a lack of soft skills. The person who can't take care of themselves and rolls over under pressure definitely has poor soft skills.
I've heard this "soft skills are the only skills that matter" thing throughout my entire career but these days this is indeed greatly amplified.
Our CEO started sharing screenshots of his xitter/linkedin feeds and most of them contain wisdoms like "Opus 4.5 is better than 90% of talent". There is also longer form business fan fiction. It usually follows this template: there is a hero - a humble manager/sales person, and a villain - a cocky, nerdy software developer. The villain claims that some task is impossible or takes months to complete. Then the humble hero (equipped with Opus 4.5) completes the task in 2 hours. The villain is then humiliated/fired and everyone lives happily ever after.
These posts definitely contribute to the declining morale among employees. Nobody goes "above and beyond" anymore - we just strictly doing the tickets and nothing more.
Even before AI, there was tremendous pressure on developers for NOT going above and beyond.
I have been in far too many situations where a developer had an idea or a prototype it was blocked by a product manager on the grounds of it not being their idea. As a technical manager you then have to burn political capital just to get people to fucking collaborate.
I've also seen way too many situations where developers must do the actual PM gruntwork where the PM wants to pretend they are some kind of svengali tastemaker figure.
Have this for a few years and the psychological safety of any developer is in shambles.
Those environments need to be fucking burned to the ground.
One just needs to survive one layoff round to learn that going above and beyond is useless, everyone gets shown the door regardless of the performance.
That is one reason why companies don't like seniors, we know their tricks.
Companies have forgotten the value of morale. In this particular sense, AI hype has been very successful in demolishing morale, creating burnouts and overall decreasing value of everyone. Now everyone at the company can build everything in 2 hours, or so I am told.
> everyone at the company can build everything in 2 hours
The business teams can build it in two hours, but those lazy developers spend weeks finishing off the so called last 2% that's somehow always left over after a vibe session.
Once upon a time a clever software engineer realized that engineering talent is the fuel which the business relies on to support its revenue growth, and management is for facilitating this process, while the CEO’s purpose is to be blamed when it doesn’t work out. He wrote a small bash script which replaced corporate leadership with a “quote of the day” generator and everyone lived happily ever after.
- You can have a horrible CEO that doesn't value their employees and is trying to devalue labor.
- AI coding tools can be incredible exoskeletons in the hands of skilled engineers and enable them to get much more work done.
Perhaps the real "SaaS-killer" is innovation capital [1] realizing it can take advantage of the various forms of arbitrage and changing of the guards happening now, raise venture capital, and take on the old and slow management-driven businesses.
If you've ever had the itch to fire your boss, now's the time. It's a hard path, there are way more hats to wear, but the dry powder is out there waiting to be deployed.
It's also the fun path! Although I think we should acknowledge that most don't have the means to do this. For engineers with a high salary I would advise saving as much as possible so you have more agency.
> There is also longer form business fan fiction. It usually follows this template: there is a hero - a humble manager/sales person, and a villain - a cocky, nerdy software developer. The villain claims that some task is impossible or takes months to complete. Then the humble hero (equipped with Opus 4.5) completes the task in 2 hours. The villain is then humiliated/fired and everyone lives happily ever after.
Can you share examples? I've never seen something like that.
> Our CEO started sharing screenshots of his xitter/linkedin feeds and most of them contain wisdoms like "Opus 4.5 is better than 90% of talent". There is also longer form business fan fiction. It usually follows this template: there is a hero - a humble manager/sales person, and a villain - a cocky, nerdy software developer. The villain claims that some task is impossible or takes months to complete. Then the humble hero (equipped with Opus 4.5) completes the task in 2 hours. The villain is then humiliated/fired and everyone lives happily ever after.
I do have the impression that many programmers are much more resistant to bullshitting, and love to call out the mistakes when confronted with bullshit. Getting into management, on the other hand, means believing in instead of fighting lots bullshit.
So, of course the mentioned CEO gets lots of such stories in his xitter/linkedin feeds; CEOs are not insanely eager to comment on such stories why the premises are wrong, and by which dirty tricks this manipulates people. Rather, by climbing up the company ranks, they actively had to believe in more and more fairy tables (or bullshit); if they are too resistant to the brainwashing that they have to believe in, they will stop climbing ranks.
> These posts definitely contribute to the declining morale among employees. Nobody goes "above and beyond" anymore - we just strictly doing the tickets and nothing more.
I think those posts exist in a bubble. They only escaped the bubble because someone wanted to use them once over to unite a different group of people against a different set of bad guys, ironically continuing the cycle. This time it’s devs loathing management instead of management loathing devs.
All of the great people I’ve worked with don’t play any of these games at all. They know it’s a sideshow of engagement bait and content generated with a goal of being controversial, not truthful.
Going above and beyond is hardly ever rewarded in my experience, except when it happens in the stupidest way, like producing more technical debt faster.
> Today, I use Claude Code for almost all non-trivial programming tasks and have spent $500+ on it just last December.
Truthfully, I don't want to get advice from people who become addicted to AI, sorry. The money investment that person did, already leaves me with tons of questions.
I think this tongue in cheek comparison would make more sense if it were possible to spend more than 50 cents on an LSP or debugger over the course of a lifetime.
Visual Studio Professional did cost about $500 back in the day, although you ended up getting a perpetual licence for the software and some updates. These days they expect you to have a subscription as with all other business software.
> Truthfully, I don't want to get advice from people who become addicted to AI, sorry.
If you sleep on this, these people are going to take your job.
I've been writing serious systems code for 15 years. Systems that handled billions of dollars of transaction volume a day and whose hourly outages cost billions of dollars. These are systems you have to design carefully. Active-active, beyond five nines reliable.
I'm telling you AI is extremely beneficial even in this segment of the market. The value prop is undeniable.
I'm easily getting twice my workload done with AI, and I'm not even leveraging the full extent of the tools. I've only just started to do more than fancy tab-autocomplete.
This is going to be a huge shift in our industry, and I would brace for impact.
I dont want to take responsibility for 10 features at the same time because one guy on the internet is able to bullshit the execs.
> I'm easily getting twice my workload done with AI, and I'm not even leveraging the full extent of the tools. I've only just started to do more than fancy tab-autocomplete.
Companies won't even pay for IntellJ, why would they pay for the top tier Claude plan so you can run the 10 agents you need? (and yes it needs to be multiple agents according to their founder [1])
>I'm easily getting twice my workload done with AI, and I'm not even leveraging the full extent of the tools.
It seems that every person who says this never elaborates on the nature of their work. What exactly are you writing? What languages? Technologies? What does the LLM assist with? In what ways does it hamper more than help?
I ask these questions because I have yet to see any meaningful, real world application of AI at my job. There's definitely interest, but every exploratory effort seems to fall flat, sometimes comedically so e.g. recently we had Sonnet 4.5 recommend some JavaScript for a UI hang we were looking into. It also recommended we use WebWorkers to improve perf. Sounds great. Looks great, with nice markdown and whatnot. Too bad it was a legacy MFC application written in C and C++.
I don’t want to do twice my workload. I’m old enough to have learned that the faster and more efficient you are, the more demands they pile on you, and the net result is more stress, more expectations for the same pay. AI doesn’t solve unreasonable demands, shifting requirements and looming deadlines, does it?
And still, writing code is not even the bottleneck, the thinking, meeting stakeholders, figuring out technical problems is. What would I do with a machine that spits out bad code.
I guess I’m not cut out for a field where the only metric that counts is how many tickets and lines of code one can churn out in an hour any more.
In my 20+ years in the tech industry, the most important thing I have learned is that writing code is the least significant part of being a software engineer.
You write code once, but then it's modified endlessly. Supporting and using and improving the code is the majority of the work. LLMs are terrible for that. They tend to write code that isnt easy to read and modify. They don't plan for future use cases. They often paint themselves into a corner with successive modifications, and lose context as the project grows.
Don't worry about your job just yet. We are a long long way from replacing people.
Personally I get a +5% productivity in a good day with AI.
I do double my productivity on personal projects but they aren't entreprise style jobs.
I really hope for those AI companies that my situation isn't too common because burning billions to make dev hobbies more productive doesn't sound too good of a business plan.
In my (not systems engineering) opinion, most time spent writing code is boilerplate and rituals; unit tests are pretty repetitive, creating a React component is a lot of repetition, etc. A LLM code assistant can do these boring things faster.
Yeah I agree with you on that, I'm just curious about the systems programming use case as in my experience you have to think deep about interactions and working with an agent blunts that
These people are not going to take your job, the people who uses tools smartly while having the knowledge and experience in highly reliable distributed systems are. If human in the loop is not required any more, nobody is going to keep their job.
The uncomfortable truth is that the skill of _writing_ code is becoming commoditized.
Reading, understanding, designing efficient systems, and planning changes based on that, at least for now, will still be for human experts (and AI already a great assist here).
But churn out yet another webpage/website? People doing this will need to move on from this as their primary job.
People exaggerate how many people work on just simple websites / webpages. Anyone needing a website has been able to get it for very cheap for a long time.
Yep. It has been the case forever. The reason we keep/kept getting new tools is because laymen would exhaust their capabilities in the old tools and started requiring a developer once they need THAT ONE feature.
Be careful, engineers, when interacting with soft skill experts not to join their reality distortion field where it’s all about coordination, alignment, bizness strategy, clever planning. Whereas the real stuffs are just implémentation details, quickly solved.
This is actually a soft skill deficiency of not being able to appreciate importance of other people's fields of expertise. Not unlike a hard skill expert's failure to appreciate the importance of soft skills.
People with truly good soft skills are a pleasure to work with even if your soft skills are not that great.
The trouble isn't that they would convince me with their reality distortion (they don't), the issue is that they are satisfied with their "progress" while I'm still asking crucial questions (which they ignore, b/c they don't see the importance).
Part of the soft skills that are useful for a developer is being able to frame your crucial questions in a way that makes their importance relevant to their world.
Perhaps soft skills are too squishy and/or broad of a term to be useful then. It seems like these discussions always go "maybe you, as the developer, just need to learn how to do soft skills properly?" in response to business types exhibiting an undesirable behavior. Sure, smooth talking and playing into someones personality might be more successful (albeit with a lot more hot air), but all of you are supposed to be working towards a goal. If someone gets hung up because you weren't smooth enough, I would think they're a bad faith actor who doesn't actually want to get something done.
But I’m not talking about “smooth talking” here; in response to the above example —- where engineering is asking questions that that the business things had not answered because they are presumably “unimportant” —- there is almost certainly a communication breakdown happening.
Likely, one of the following is happening:
* The questions are important to the business but engineering has failed to articulate why getting the answers are critical to the business. (Some engineers have a tendency to describe problems in the scope of how it affects their own job or task, but neglect the larger picture or fail to articulate any consequences)
* The questions actually aren’t important for the business to answer and the engineer fails to understand how their task supports the goals of the business
* The questions are important but they cannot be answered by the business. The engineer might need to gather more information before to generate actionable questions, or maybe the questions should be answered by engineering themselves.
Remember, technical workers, you must grind all you soft skills in addition to the technical ones, so that you can successfully interact with those people hired exclusively to use their soft skills.
Engineers just need to have good enough soft skills to effectively communicate.
Engineers who struggle to do that are just as bad at their job as business managers who aren’t technical enough to operate Microsoft Office. There’s a minimum of both hard and soft skills that anyone in a professional environment should have.
Again, by communicating. If someone doesn't know what they are building, who they are building it for, and why -- then they do not have a solid grasp of the requirements.
Its never about the soft skill experts being able to convince the engineers, the challenge if any, is always about them being able to convince the "leadership"
Wait until you try to explain basic concepts to such people! What's annoying is HR employing more of these people and not understanding why the dial does not move.
What is baffling and infuriating is when such people are put in management. MBAs will destroy Western business eventually(those who tag an MBA onto a STEM qualification are not as bad but still infected.)
The sort of people who have been able to neglect their soft skills are probably still going to be able to do so in the future. But those were always the extreme intelligence outliers, generational talent type figures.
For most software engineers, neglect of soft skills have always been a career tarpit that leads nowhere you want to end up. Being able to navigate social settings and to communicate well is a force multiplier. For most people, it really doesn't matter how good you are if nobody understands what you are saying and you can't convince other people to buy into your ideas. You far more often see moderately successful charlatans that are all talk than successful people with awful communication skills. Of course if you're able to walk the talk, that's when you can really go places.
> [people without soft skills] were always the extreme intelligence outliers
This is a B-player myth.
High intelligence makes you better at soft skills. People are complex, and being good at soft skills takes intelligence, intelligence to intuit the importance and see the patterns of soft skills.
It is true that if you have high skills that a business needs, you can choose to ignore many internal norms of dress or etiquette.
Unfortunately it is also true that some people think that acting badly will give them cred (reversing the causality that having cred permits bad behaviour). Was Sam-Bankman-Fried acting that cryptic appearance? Do executives also model their behaviour by rewatching The Apprentice or Gordon Ramsay?
Disclaimer: That's mostly my personal opinion, from watching people smarter than I. Then again I'm no genius, nor do I win status games, so perhaps I'm just ignorant. I've definitely seen some less talented try and put on an act leading to a pratfall. Also many of the smartest people I know left school at 15.
To add - their comment about socially prickly smart devs (my paraphrase) makes me think they are referencing the mad genius stereotype (crazy artist, Aspie developer, etcetera).
> The sort of people who have been able to neglect their soft skills are probably still going to be able to do so in the future. But those were always the extreme intelligence outliers, generational talent type figures.
This is just not true. Lack of soft skill never implied high intelligence, it was always and is just lack of soft skills. Some people without them are otherwise highly intelligent, others are just normal or even weaker then average.
> You far more often see moderately successful charlatans that are all talk than successful people with awful communication skills. Of course if you're able to walk the talk, that's when you can really go places.
I would argue that this is consequence of management that does NOT have soft skills. People write a lot about soft skills of engineers and simply assume management has them. They do not always, yes they then end up being bad managers ... and charlatans doing good is usually consequence of bad management without those actual people skills. Soft skills are not just about coming across nice, they are also about being able to be assertive, being able to recognize charlatans or toxic personalities and being able to deal with them (which is not the same as enabling them).
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 more due to Mr Musk's eccentricities and political ventures than the engineering team.
The reason this hasn't happened to any wider degree is quarterly capitalism and institutional inertia. Looks weird to the investors if the organization claims to be doing well but is also slashing its employee count by 90%. Even if you bring a new CEO in that has these ideas, the org chart will fight it with tooth and nail as managers would lose reportees and clout.
Consultancies in particular are incredibly inefficient by design since they make more money if they take more time and bring a larger headcount to the task: They don't sell productivity, but man hours. Hence horrors like SAFe.
At the same time, that quest for the next big thing is performative, it's theater for the investors, and exactly what I'm talking about.
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.
I think the author would say that the developer who is without soft skills won't merely be prevented from gaining desirable work. They'll be unable to keep a job, period.
Seems a pretty sketchy assertion, but regardless whether these people burn out in career purgatory at a java 8 feature factory moving jira tickets around for all of eternity, or they move on to something else entirely, it's probably not what they had in mind.
So I opened this article to find out at the very beginning, that author put's a lot of money to AI providers... So probably also used it to write this article. So, according to the rule "text which is not worth of spending time on writing is also no worth of reading" I closed it.
I found out that the author of a blog post paid a maid to clean their house, and sends their laundry out. Therefore, the blog post was written by the maid, or one of the laundromat employees. So I closed it.
That's a false equivalence. You might read a blog post about engineering from someone who paid a maid to clean their house, and sends their laundry out.
But would you read their blog post on laundry tips?
No - it's just as easy for you to send out your own laundry.
Err, no, the equivalent would be if the author had written an article about laundry, and how important it is to pay attention to all the details... then you realize the photo of his laundry still has a tag on it from the laundromat.
I would submit that this could be based on a stereotype that “coder = antisocial.”
Why are we assuming that people who write code don’t have soft skills?
The youngest generation who joined the profession are probably in it for the the salary versus the older generations who came from computer clubs and dungeons and dragons groups of the 1970s/1980s along with a culture where having a niche interest was socially ostracizing and uncool.
I wonder if the youngest generation entering the profession is much more of a cross section of regular people?
I've had a long career in software and my conclusions is that if soft skills are valued over hard skills, the organization is already captured by talentless engineers and leaders. There are holdouts in the world, where execution is king, find those places and run away from soft skill fortresses. This is more true than even with LLM-amplified productivity.
> There are holdouts in the world, where execution is king, find those places and run away from soft skill fortresses.
And guess what do you need to execute? Both soft and hard skills. You'll not live long without both of them and this is even more true today.
It's useless estimating the ratio between soft and hard skills without context, sometimes projects fail for one, sometimes for the other.
The big truth is that as the markets get more competitive, the employee pool follows the same trend: it's not 2021 anymore, world has changed, great developers that have both hard and soft skills can be found in the market and it's up to a competent hiring team to find them.
This feels like a false dichotomy. You can be superior to those conceptual camps by building an array of skills.
This is even obvious to heavily technically minded people, who lament how one kind of engineer would benefit from stronger grasp of other domains. Communication skills, understanding of how to exist within social structures, and all those “soft skills” have the power to multiply the value of the technical skills.
My sense is that the loudest proponents for devaluing soft skills are those who are bad at them and want a moat rather than having to work at them to compete.
Like most of these binary statements, the truth is indeed somewhere in the middle. Software engineers don't require focus on getting beyond acceptable with soft skills. Software engineers who want to move into staff/managements/product/etc. need to focus on them.
> The whole corporate world has been overtaken by feminism
Please don't post hyperbole or engage in political/ideological battle on HN. The guidelines make it clear we're trying for something better here. https://news.ycombinator.com/newsguidelines.html
I thought this article was going to be about something else ...
It is really about prompting and writing specs - the "soft" (but really "hard") skill of giving detailed specs to an LLM so it does what you want.
I think the more important, truly soft, skill in the age of AI is going to be communicating with humans and demonstrating your value in communicating both vertically up and down and horizontally within your team. LLMs are becoming quite capable at the "autistic" skill of coding, but they are still horrible communicators, and don't communicate at all unless spoken to. This is where humans are currently, and maybe for a long time, irreplaceable - using our soft skills to interact with other humans and as always translate and refine fuzzy business requirements into the unforgiving language of the machine, whether that is carefully engineered LLM contexts, or machine code.
As far as communication goes, I have to say that Gemini 3.0, great as it is, is starting to grate on me with it's sycophantic style and failure to just respond as requested rather than to blabber on about "next steps" that it is constantly trying to second guess from it's history. You can tell it to focus and just answer the question, but that only lasts for one or two conversational turns.
One of Gemini's most annoying traits is to cheerfully and authoritatively give design advice, then when questioned admit (or rather tell, as if it were it's own insight) that this advice is catastrophically bad and will lead to a bad outcome, and without pause then tell you what you really should do, as if this is going to be any better.
"You're absolutely right! You've just realized the inevitable hard truth that all designers come to! If you do [what I just told you to do], program performance will be terrible! Here is how you avoid that ... (gives more advice pulled out of ass, without any analysis of consequences)"
I consider "understanding what people want when they well you" part of soft skills, and LLMs are good at that.
I've know a few non-developers who use AI to solve the things they need. Nothing huge, it's not anything amazing, but what impressed me is how well the process works for them. They describe what they want in very vague terms with a lot of contradictions and in convoluted stream-of-thought paragraphs. But it mostly works, and LLMs produce something that's very close to what they want, and they get to their desired result with a few iterations.
> girlfriends you can get in this society are even worse
Skill issue.
Also, unrealistic expectations. People are both afraid of doing the hard work to have meaningful relations and filtering out duds and also want the world from another human.
I'm just going to sharpen up my hard skills so that I don't have to suck up on my soft skills. If that doesn't work out as I wish, well, since I already have a job, and I'm already 40+, and it looks like my company doesn't go away in a few years and we are so short-handed, I think I'm fine.
Just to clarify that I'm not a jackass in real-life. In fact, I'm perfectly OK with all sorts of soft skills -- after all, my current position requires me to do so. But I just try to maintain a minimum level of soft skills to navigate the shoreline -- not interested to move up anyway.
"I'm already 40+, and it looks like my company doesn't go away in a few years and we are so short-handed"
FANG employee for over a decade quit her job, opened a consultancy, and sold back what she was doing to former clients of her company(and their clients). She sold back what she was having to do to make up for this short-handedness, and the incompetence of many of her former colleagues.
She did it at 3-400 times the markup she was being paid while employed :) because they were time critical.
> we won't be able to AI our way into better communication skills
Why not?
I always find these articles funny. There's someone almost triumphantly declaring that AI is able to take over the hard skills tasks from oh so dreaded engineers, but the authors can somehow not imagine that their soft skills - which are often they only ones they have - could be done by AI as well.
DjangoCon has a policy to not use the term "soft skills" and instead classify them as "professional skills" - communication and collaboration and management and leadership.
I think they're 100% right about that. There's nothing easy or soft about what gets classified as "soft skills".
I mentor CS students at two local universities. The best students are using gen ai to enhance their learning and understanding (i.e. they use it as a tool instead of a crutch). The worst students are using it in attempt to “level the playing field” and are failing miserably.
It is easy to determine if someone solved a problem using AI because they can’t explain or recreate “their” solution. Detecting cheating in essays is still far more difficult.
You could probably detect essay cheating (AI written) in the exact same way by questioning the student about it - why did they organize the essay in this way, what was their motivation for focusing on X, or expressing something as Y... Of course anyone can concoct an explanation on the fly, but it should be obvious if they are speaking from the experience of having authored it or just coming up with a post-hoc rationalization.
If they had AI write the essay, yet can still explain it as well as if they had written it themselves (ditto for code), then it would tend to indicate that they at least read it and thought about it, which I think should be more acceptable in a learning environment.
> You could probably detect essay cheating (AI written) in the exact same way by questioning the student about it - why did they organize the essay in this way, what was their motivation for focusing on X, or expressing something as Y... Of course anyone can concoct an explanation on the fly, but it should be obvious if they are speaking from the experience of having authored it or just coming up with a post-hoc rationalization.
I wouldn't claim that I am bad at writing (at least in my native language, which is not English) - at least many colleagues say so. But I do insist that when writing I don't think that way. If I were to answer these question, my honest answers would be:
"why did they organize the essay in this way": I just wrote down the thoughts that came to my mind, and then gave them some structure that seemed right.
"what was their motivation for focusing on X": Either "because it felt right" or "I had to write at most x pages, and indeed it would have made sense to focus on more topics, so I focused on this arbitrary thing"
So indeed I would claim that a lot of sensible reasons why things are this way actually are post-hoc rationalizations. :-)
> So indeed I would claim that a lot of sensible reasons why things are this way actually are post-hoc rationalizations.
Perhaps, but still I think that responses to questioning about an essay that the student did actually write will come a lot more quickly and naturally, even if they indicate that not much thought was put into it, than if they realize they are being called out for cheating and and have to make something up on the spot, since they didn't at least read it carefully!
This couldn't ring more true to me - I think one of the consequences of the rapid change in the profession we are seeing is that skills that typically were required only at more senior levels become required further down the stack.
If I was a junior today, I'd be studying business impact, effective communication, project management, skills that were previously something you could get away with under-indexing on until senior+.
I remember a day at the office of a former job; there was one guy, the "chief developer", technically solid, but he was a pure a**** when interacting with others; it was quite known that he was a "difficult person".
One day, I opened the door to another floor and he approached the opened door: I saw him with two things in his hands: the one was a Leitz folder, and in the other hand he had a cup of coffee - so full that the coffee was kept in the cup already only because of the surface tension of the liquid.
I held the door opened, looked at him, a small smile and noded - he didnt show any reaction (not even think of a "thank you" or similar)
So, there is professional skills and then there is "soft skills" which at many places is a euphemism for political theatre. Nearly everyone I've ever met has professional skills; few can stomach "soft skills"
Feels like soft skills are peddled as if developers don't have "enough" and it is a common assumption by nearly everyone that this is the case.
I think of it in a similar way: the magnitude of soft skills you put on display is positively correlated to the difficulty of social interactions at that workplace. Navigating all the nuances, implies how complicated and maybe loaded that environment is. Do one "mistake" regarding social skills and you will face "consequences"?
Businesses have valued "cohesion" over "correctness" for some time (at least the last 10 years of my career) with the thinking that they can always eventually get to a correct solution, but teams that aren't cohesive do not work toward the goal they fight amongst themselves until they tear themselves apart (as a former Python dev I have seen teams that have one or two members fight for MONTHS over which set of linters to use)
I also want to say that the only source of "bugs" is misunderstandings - of what the technology does, what the business wants, or what the customer wants (two thirds of that is "soft skills"). We've created DDD to try and address one third of those potential issues, but we're not there yet.
Do we accuse AI of having poor soft skills when it doesn't do what we want?
I think the problem is knowing how to bridge knowledge gaps. That just comes from experience and there are no shortcuts on either end of the gap.
Empathy does matter a little bit, but to focus so much on it is plain neurotic. Consider how much less friction there is when the interactions can be kept brief. Everyone is already familiar with the various situations and problems that can arise (like on a sports team). That's pure hard skills, not soft skills.
Posts like this are flamebait for the extreme ends of these gaps: stubborn mediocre programmers and arrogant dumb management.
I have always said this: life is other people. Jobs and employment are necessarily a reflection of the fact that we need each other to survive. We do not hunt the meat we consume, we did not deliver ourselves, and the vast majority of us won’t build the bed we die in.
I used to work with a brilliant asshole - he had this babyface but would constantly belittle his fellow engineers.
Everyone hated him but the CEO loved him since he thought he was their golden ticket to the promised land.
At some point he went with us to a shooting range for target practice, immediately after he developed a fascination for guns, he never threatened anyone, but one day he buys a Kevlar vest and tells all his fellow devs.
Has this ever been something you can ignore? You need to be able to interact with customers, communicate with other team members, mentor junior engineers, etc. I know there is the trope of the abrasive but technically genius engineer but no one wants to work with that person irl.
Unless you're buried deep in an organization, the main value that programmers provide is to help translate the needs of a business into a program that, when compiled, creates a reliable artifact that, when executed, works reliably and is easy to use.
Writing code is just how that happens, sometimes. Soft skills are essential to communication with the users and product managers.
Counter point - If one person can now do the work of an entire team the level of communication skills required will actually be simplified.
So now instead of needing to manage multiple stakeholders and expectations of 10 different middle managers you'll probably just have a 1:1 with a single person.
What about those professional software developers still refusing to use AI / LLMs? I know a couple and they're still churning out code completely 100% manually.
Heck, I even know a guy who refuses to use an IDE with Java and the indenting is a mess, but he gets there.
Not necessarily faster, but more easy for sure. There's plenty of stories of proficient abacus using accountants being faster than those using calculators. Those days are gone now though because a calculator is just so much easier to pick up.
Software 'engineers' are going to have learn the hard skills that they have gotten by without thus far. The ones who were never engineers in the first place will have to learn 'soft skills' because they are incapable. I believe @ Tsoding put it best: The only thing AI will do, in so far as coding goes, is to remove a lot of people who should never have been in it in the first place.
I think this is kinda sad. I always thought coding was so beautiful for creating a (good paying) job for socially awkward people on the spectrum who pre-coding was considered dorks and went into idk what but probably some unsatisfying job. It seems like we're heading back to that which makes me sad and worried about the highly functioning autistic population.
I am sorry but is being employed a job or a daycare?
Not only this is extremely patronizing towards all people on spectrum, but at the same time extremely hurtful statement for people who are treating employment as a job(ie - most of population).
And what are you going to say to people who are stuck in low-end jobs?
"Conflict is essential to human life, whether between different aspects of oneself, between oneself and the environment, between different individuals or between different groups."
The obvious default interpretation of your comment is that the other person is using something as an excuse. If you say you did not intend it as a personal putdown, I believe you, but the rest of us don't have direct access to your intent, so you'd need to include enough information in your comments to disambiguate it.
As for Marion Milner's classic paragraph, I'm delighted that you found it worthwhile enough to quote! But you have to read the entire paragraph to understand it, and you can't leave out the word "toleration". That's the most important word there, both in the text and in the title.
Sorry but did we read the same comment? It's not patronising. The people who are stuck in low end jobs were not in the scope of this comment (there are also people in war zones or very sick, also out of scope). And how did you manage to find this extremely hurtful to any group...?
My rule of thumb is that if you’re not measuring anything you’re not engineering. It’s not the whole picture, but to me the engineering part sometimes means being able to explain (and even quantify) why one solution is better than another.
I've found coding assistants to be a huge boon for this. All of the thorough analysis that previously would've taken a bunch of tedious extra thought work to do for marginal benefit (with a well-calibrated intuition) becomes 5 seconds of thought to the the computer to build a harness and then letting it chew on that for 15 minutes. It now also takes me one command and less than a minute to get pprof captures from all the production services my team owns (thanks to some scripts I had it write), which is just something I never would've bothered to automate otherwise, so we never really looked much at it. Codex is also very good at analyzing the results, and finding easy wins vs. knowing what would be invasive to improve, and then just doing it.
Thinking of seeing if I can get mutation testing set up next, and expanding our use of fuzzing. All of these techniques that I know about but haven't had the time to do are suddenly more feasible to invest into.
Not the original author, but I would guess that understanding the domain problem and interpreting it correctly in a software solution (not code, but a product with workflows, UX, etc.), which in turn requires ability to listen and understand and ask right questions on one hand (what a user wants to achieve), and a good understanding of the technical limitations as well as human habits on the other hand (what is possible and makes sense). One can argue that AI lacks what we'd call intuition and interpersonal qualities which are still necessary, as before AI.
Your $300k+ TC job is going away. The only way you'll make the same take home is if you provide more value.
You can be a robotic IC, but you won't be any better than a beginner with Claude Code. You have to level up your communication and organizational value to stay at the top.
Everyone has to wear the cloth of a senior engineer now to simply stay in place. If you can't write well, communicate well, plan and organize, you're not providing more value than a Claude-enhanced junior.
"If you can't write well, communicate well, plan and organize"
Straw man. Pretty sure, this is the dilbert equivalent of "I can problem solve". If you are an engineer, we are making boatloads being brought in to fix the incompetence of this level of thinking. INFOSEC alone is having a field day.
Would you like to buy a bridge? Coded by Claude. One previous owner. An owner who used said bridge to go to church once a week, and vibe code in Starbucks afterwoods.
How about the skill of saving hard disk space, memory, and CPU cycles, for a start? The skill of designing simple, reliable, fast, and efficient things, instead of giant complex bloated unreliable pieces of shit? How about a simple, usable web page that doesn't drag my machine to a crawl, despite its supercomputer-like ability to process billions of instructions per second and hold billions of bytes of data in working memory?
Remember when BIOS computers used to boot in seconds, reliably? When chat clients didn't require an embedded copy of Chromium? When appliances and automobiles didn't fall apart in 6 months, costing thousands to "repair" or just needing to be thrown away and bought again?
Remember when there used to be these things called "machine shops" and "Radio Shacks" and "parts stores" that people who built things frequented? Now most people have to call AAA if they get a flat tire. Changing their own oil is out of the question. "Eww, dirty oil, on my clean fingernails?" Many couldn't tell you which end is which on a screwdriver if their life depended on it.
I'd say these concepts are pretty essential, especially for any nation entertaining delusions of waging Total War against other big and powerful nations. Wasteful and foolish nations lose wars.
Beyond engineering itself, strictly computer engineering?
How many coders have no idea what goes on behind an IDE. Have not even the slightest notion how a computer works. Who thinks building a computer means watching a Youtube video and buying ready made parts, putting them together, and then think they should be employed by NASA.
To begin: Math, Linux, Devops, C, and Assembly.
Not a youtube video. Not arithmetic. Learn to the point that you could be employed by any of the above as a senior. And don't fear failure. Keep doing it until you understand it.
I agree with your original post that the need for hard skills will persist, but I see it in the other direction: software engineers are going to have to get better at thinking in larger abstractions, not deeper understanding of the stack. Those who can only solve problems locally and repeat the patterns they've seen before rather than create new patterns from building blocks are the ones who are going to struggle.
"software engineers are going to have to get better at thinking in larger abstractions"
........Math was first on my list.
I don't know how else to say that.
Computer science is indistinguishable from sufficiently advanced maths.
The AI can already do that part.
The abstraction that matters going forward, is understanding why the abstraction chosen by the AI does or doesn't match the one needed by the customer's "big picture".
The AI is a bit too self-congratulatory in that regard, even if it can sometimes spot its own mistakes.
A lot of studying math is just learning jargon and applications for what are actually pretty straightforward concepts, which lets you better communicate with the computer. You get higher bandwidth communication and better ability to know all of the nuances in things it might propose. You can propose things and understand when it replies with nuances you missed.
Like intro differential geometry is basically a deep dive into what one actually does when reading a paper map. Something everyone (over 30?) is familiar with. But it turns out there's plenty to fill a graduate level tome on that topic.
Linear algebra is basically studying easy problems: y=ax. Plenty to write about how to make your problem (or at least parts of it) fit that mould.
I suspect and think I've seen others say that you get better outputs from LLMs when using jargon. Essentialy, its pattern matching tells it to say what an expert would say when using the terminology experts use.
Yep, exactly. The failure to realize that you mean different things when talking about "larger abstractions" is exactly the kind of miscommunication that software people will need to navigate better in the future.
Ah, I think “Math” as a single word on its means many different things to many different people, I didn’t interpret in quite the same way. But I see what you mean.
I’m not sure that my colleagues who I think of as “good at math” and “good at thinking in larger abstractions” are necessarily the same ones, but there’s definitely a lot of overlap.
I hope this too but it's not a given, IMO. Previously people without technical chops failed quickly by being unable to deliver working code, now they can deliver mediocre code with the damage only becoming clear years later. It breaks the "can deliver code --> good technical ability" proxy and even after the initial damage wave, it's unclear if we will find a better proxy.
I think AI coding agents will quickly pick all the low hanging fruits and plateau.
Everything can be vibed will be vibed until everyone hits a wall, where no docs to form corpus nor instructions for prompts exist. There are problems that are yet to be named, but how can you name things when humans aren't the one to experience patterns of a thought process?
And naming things is one of the only two hard things in computer science
In a team environment, half of the job is communication.
That LLMs do a better job if you know what you are asking for is old news.
But to be honest, I usually don't care to write properly into an LLM prompt. An LLM will ignore grammar and form and just extract the essence. If I make an actual mistake I will notice quickly and fix it.
If I'd send slack messages like that to an peer, they'd either mock me or simply think I am dumb.
We also know the stories about people that use LLMs for any communication or anything they write. Probably for the exact reason that being lazy with writing is acceptable now. My call is that writing skill will decline, not improve. This could probably be the case for anything that people use LLMs as a proxy for.
Broadly agree, but one point I think is (sadly) relevant:
> That LLMs do a better job if you know what you are asking for is old news.
Even a decade after Word Lens had demonstrated augmented reality live translation through a smartphone camera, I was amazing people by showing them the same feature in Google Translate.
Similar anecdotes about Shakuntala Devi, even in 2018 I was seeing claims about her mental arithmetic beating a supercomputer (claims that ignored that this happened in 1977 and the computer was already obsolete at the time), even though my mid-2013 MacBook Air could not only beat her by a factor of 150 million, it could also train an AI to read handwritten numbers from scratch in 0.225 seconds, and then perform inference (read numbers) at just over 6,629 digits per second*.
You say "old news", I say this discussion will be on repeat even in the early 2030s. And possibly even the 2060s.
"I deal with the goddamn customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!"
Look, I personally am taking full advantage of exactly the skills described. I was the one who posted the above thing on HN showing how I am 20-50x more productive now, complete with a 4 hour speedrun video. I usually try not to just talk and point out current problems, but build solutions AND show (github, youtube) with specific details so you can watch it and apply it for yourself. But I am telling you:
1) most people will not adapt, so we will need UBI for those who don’t
2) eventually even those who adapt will be replaced too, so we will need UBI for everybody
It is after all a thin layer that remains. I remember Kasparov proudly talked about how “centaurs” (human + machine working together) in chess were better than machines alone… until they weren’t, and human in the loop became a liability.
But the problem is more widespread in the last 70 years. Just look around. Industry always tells the individual they can do some individual action downstream to clean up the mess they create upstream, and it is leading the entire planet into ruin:
In fact, the human population in modern environments has been living large on an ecological credit card and the bill is coming due for our children, because all the “individual responsibility” stuff — where you can somehow diet, exercise and recycle your way out of things corporations do upstream — is all a gient lie and always has been. So the negative externalities just build up until the next generation won’t be able to ignore them anymore, but it could be too late. Whether that’als day zero for water in cities, or factory farms for meat with antiobiotic resistance, or fossil fuels and greenhouse gases to subsidize the car industry, or ubiqitous microplastic plastic pollution around thr world (yes, personal plastic recycling was just another such scam designed to keep you docile and not organize to force corporations to switch to biodegradeable materials.) The “anthoposcene” is seeing a decline in insects and all species of animal except humans and farm animals. Coral reefs are bleached, kelp forests and rainforests are decimated, and governments work with industry to eg allow Patagonian forests to be burned for new developments and then smokey the bear says “only YOU can prevent forest fires”. Think about it.
I may have misread your comment, but I don't think soft skills are a 'narrow thing' at all. Effective communication, building trust, bringing people along with you - these are fundamental to being an effective human, not some niche pivot.
Not fair on you. I did not mean to have a dig. I get where you are coming from, and should have elaborated. I've worked with those one or two engineers who were rude by default. Who had an extraordinary knack of vaguely describing the problem set, and then having a full on meltdown, always in front of other people, when the solutions did not match the problem in their head.*
*Goldman Sachs(sorry for invoking that name here) did a report on their high turnover, and the above framing was why many quit.
Look, if we zoom in, then "learning to code" is also quite a broad range of skills that someone needs to master before they can meaningfully carve out a career in a competitive marketplace.
The point is that if you zoom out, it's just a thin slice that can be automated by machines. People keep saying "I'll tell you in my experience, no UAV will ever trump a pilot's instinct, his insight, the ability to look into a situation beyond the obvious and discern the outcome, or a pilot's judgment"... https://www.youtube.com/watch?v=ZygApeuBZdk
But as you can see, they're all wrong. By narrow here I meant a thin layer that thinks it's indispensable as they remove all the other layers. Until the system comes for this layer too.
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 things and not spend any time figuring out the context they are working in, and behaving accordingly.
My first day of work, this is what my boss said to me: "Look at this trading floor. There's screens everywhere, everything is numbers. Deltas, gammas, vegas. Everything is calculated by computers. But don't forget, every business is a people business!"
It's the vibe coders who would love to pretend that the opposite end of the spectrum from them is "artisinal coding."
They honestly have no idea what "software engineering" in a professional context even looks like. So they come up with this prattle.
The jargon is getting more & more obtuse every year...
Also, a major feature of "vibe coding" now is the rough edges on UI design that don't make sense at all... It's pretty obvious that code bases aren't evolving because these systems can't handle complex prompts while retaining features from prior releases, and it seems like functional testing for releases has now become the kid who can't speak that fell down a well... Oh well.
Vibe coders are the new circa-2000 cross-trained front end web developers.
Without industry experience and/or software engineering education, they zoom past a lot of hard-won lessons.
E.g. the node.js packaging ecosystem wouldn't have committed so many own-goals if it'd been designed by people with more historical awareness
In time, vibe coders will rediscover test driven development, but until then you'll have to deal with watching monkeys try to construct buildings by stomping hard and frequently enough that the atoms self-assemble.
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.
The joke about vibe coding replacing junior devs is apt, because it has the same failure mode -- it can build something that works, but completely incompetently and with unmaintainable design choices.
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.
> make a valuable process accessible to themselves
I am directly calling into question the "value" of that process. It's also becoming increasingly clear that these tools just whitewash away the copyrights of the materials they were trained on and still mostly reproduce when asked. This would then actually be the destruction of value.
> invoking a a no-true-Scotsman
I did not. This is in response to an article. It demonstrates a clear lack of understanding of professional software engineering and instead imagines that writing a good spec is all there is to actually do. It displays a definite lack of understanding of the fundamentals of engineering or of profitable business.
> is a good example of a lack of soft skills.
You seek appeasement instead of understanding and you call into question my skills? I see now what you think this forum is for.
> I see now what you think this forum is for.
Calling you out for being overly critical is not 'seeking appeasement'. I am calling your skills into question -- why shouldn't I? Your soft skills seem to consist of attacking people when you don't like what they have to say.
Trotting out fallacy names on regular basis isn't going to win you any points.
> But it's never been the case that a dev could just focus on technical things and not spend any time figuring out the context they are working in, and behaving accordingly.
This is factually wrong. Until a few decades ago in tech, and it's still like that in most economic sectors and I dare say most countries, it's the managers that take the role of figuring out the organization and interfacing with other teams. An engineer being only in charge of technical issues but nothing business-related was the norm; that would yield no promotion into management, of course, but still the norm.
Yes, but it goes more far than that: You will have to participate in meetings, you will be asked to joing for a lunch, you will be asked to contact a customer/devcontact there, you will be asked to attend some events, you will be asked to communicate with others etc.
You are not existing as isolated particle in vacuum behind your screen :-)
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.
> 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?
Both, actually, but in the case I'm thinking of the devs with the strongest leadership skills in terms of organizing their peers to make things happen were completely invisible to management who were playing a different game. Just like their game was invisible to the devs shipping product, who didn't understand the implications on their careers. Saw a couple of great unofficial leaders get fired and a bunch more leave due to the disconnect. It caught up to the managers later, turned out their people skills weren't good enough after execution ground to a halt.
(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 was trying to subtly point out that the information asymmetry goes both ways: most devs aren't aware of what their managers are doing for the team either. More transparency in both directions is healthy (and skip-level meetings, for god's sake).
Yeah, I hear you and I also added a parenthetical that the incentives aren't always the same.
In an organization of high-minded individuals, the information asymmetry goes both ways, I've been a manager and a dev and I tried to be high-minded and do my best to smooth that assymetry for the greater good in both roles.
But sometimes, especially the last 3-4 years since it got tough, there's a lot of people trying to hold on by any means necessary. Information asymmetry isn't the problem there, it's incentive assymetry. What if you're just not that good at tech and got promoted to 1st, maybe 2nd level manager in the good years? What's your incentive?
Absolutely! The "How does a bad manager with a good team ever get identified/fired?" problem is something more companies should have an answer to.
That's why I think skip-levels check-ins and direct reports regularly anonymously rating their manager (via HR) should be the starting place at all companies.
Otherwise, toxic (or just underperforming) managers stay in their positions longer than is good for the company.
Most employees are incapable of rating their manager. They can complain or praise, but they're not competent to judge whether the manager is competent.
There's an interesting parallel to the advice often given for "lean" startups, of never taking seriously the customers' feature requests, only their complaints. Most customers know their own pain points but aren't capable of suggesting good general solutions that can be incorporated into a product.
I have seen a number of organizations throughout my 20 ish year career that have a policy of “developers don’t meet with customers”.
I am not endorsing it and I think it’s poor form, but it absolutely exists. You are in a weird bubble if you think there haven’t been engineering jobs where a dev could only care about code.
I neglected soft skills and I survived so far. I'm bad at soft skills and I probably have some sort of mental disorder like autism or something. I don't really care, I don't enjoy interacting with people and I prefer interacting with machines as much as possible. I've found a place that pays me for my technical skills and does not bother me with human interactions, I think there are more places like that in the world.
> I think there are more places like that in the world.
There are but not as many as we might like.
I’d say I’ve learned to be decent on the soft skills side but it comes at a cost and the need to overutilise them can be incredibly draining.
So many places run Agile so it feels like software engineering for noisy extroverts but, to me, it just makes it so hard to get anything done, and I see others struggling the same way.
One of my pet peeves is how bad people are at, or perhaps how unwilling they are to embrace, asynchronous communication. Again, this favours the extroverts.
And then one key advantage of written communication nowadays is I can ask an LLM to help me with it so my message lands better. More than once, when dealing with particularly frustrating situations, I’ve asked ChatGPT to rewrite an email for me “so that I come across as a reasonable human being rather than a deranged psychopath”. It works.
>So many places run Agile so it feels like software engineering for noisy extroverts but, to me, it just makes it so hard to get anything done, and I see others struggling the same way.
Interesting. I'm very introverted too, but I worked at one Agile place, and it was like a dream for me. Maybe it was just the way they implemented it. What I liked was that I didn't need to talk to people much, outside of the bi-weekly planning meetings (which were large enough that I didn't have to actually speak up much). Instead, we used Jira to track everything: tasks were broken down into tickets, and I could see at a glance what everyone on the team was working on at the time, what work remained to be done, etc. When I finished a task and put it up for review, I could just go find another unassigned ticket and grab that and start working on it, instead of having to talk to anyone (like the boss). We did a lot of code review too, but here again, it was all through Jira/Gitlab/etc., not in person. So I could spend time reviewing other people's merge requests, writing my comments, etc.
The only time I really needed to talk to team members was 1) during the morning stand-up, which was quick, 2) during the bi-weekly sprint review and sprint planning meetings, and 3) if someone was stuck and wanted to work together in-person on a problem (not often).
By contrast, I'm now stuck in a poorly-run place doing waterfall development, and it's awful. I don't know what anyone is working on usually, because everything is verbal (we do use Jira, but I can only see my own pre-assigned tasks), I don't have a good idea of what the group is doing, the timeline for anything, how anything is progressing, if there's other things I could help with or add input to before someone goes the wrong direction, etc. The manager just runs thing in a completely authoritarian manner. I wish I could just go back to my old Agile workplace.
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?
Very likely way more than 2 of them
It depends on what you want to achieve as a developer, I think. Having some soft skills makes a lot of things easier, but if you don't have the hard skills to back it up, you'll plateau unless you switch to management before you reach your limit.
At the same time, if you're very good at what you do, soft skills are a lot less important. Most of my peers would rather work with brilliant jerk than a friendly average person.
But most people are not brilliant, and then you can't afford to not have soft skills.
> Most of my peers would rather work with brilliant jerk than a friendly average person
I worked with one of these. Every interaction was miserable and stomach-turning. He slowed the project down in a number of ways. A friendly average person would have been a net gain.
>A friendly average person would have been a net gain.
I'm perfectly happy to have a friendly, average person as my boss, as long as he has good people skills and is pretty good at managing a team. He doesn't need to be technically brilliant at all.
By contrast, working with a boss who's a technically brilliant jerk is an absolutely miserable experience. Companies that make a habit of promoting brilliant jerks into management positions should be avoided.
What was his role? How did he slow the project down? I ask because quite often, the value of "soft skills" is exaggerated. In almost 20 years of software engineering I have met some of the worst personalities imaginable. Yet, I cannot think of a single time somebody's personality got in the way to such an extent it slowed the project down. Some problems can't be solved by average people. In such cases, bad social skills with above average intellect will go farther than average intellect with good soft skills.
I know an example. A tech lead who would demand every single task to be done in certain ways and go through a certain processes. Invading other team's PRs and slack channels in order to pick fights because they weren't using his microservice or his libraries. Claiming "if you're not working like us, then you're wrong". Asking people to make PRs but then not approving. Before being demoted, his team had ZERO new features delivered for about a quarter. To me that's an example of slowing down teams.
But if you mean you want someone "brilliant, but an asshole", then I agree with you. I find that the common examples are more about incompetent managers who can't make the best of an IC who can work well in isolation.
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.
Not OP, but I did work for a boss once that was technically very strong, but not as strong in terms of planning and scheduling work. It was a very difficult process, because I couldn't deliver what they wanted, as what they wanted changed both during and after delivery. Most things I delivered, which were what we agreed upon before delivery, were rewritten as they did not envision or plan work in advance. Technical skills are not a panacea; professionalism is a multidimensional skill matrix.
Exactly: being able to quote esoteric facts and trivia about CPU instruction sets or compiler features and use those while working doesn't automatically make someone adept at planning and leading a team of developers. However, some companies think the opposite, and the end result is not good.
Every PR has to match their way exactly.
The logic, the method names, the test names, code in the log messages.
Does not matter what the output or complexity is, does not matter how the previous state of the code in the area looks like, it. Must. Look. And. Read. Their. Way.
A 3 file PR review can take weeks. There was once a PR for a new feature that took 1.5 years and 2 developers (the og op left the company 3 months into having opened this PR) to eventually merge.
>Most of my peers would rather work with brilliant jerk than a friendly average person.
If that’s true, you work somewhere very strange. Almost everyone hates dealing with assholes.
People want results. Brilliant assholes produce those, so you tolerate the annoying parts. Would be great if they were also kind, but I'll take a house built by an asshole over a tent erected by a friendly person.
It's not a dichotomy, obviously. There are plenty of very smart people who are also pleasant to be around. But if they're either strong in soft skills _or_ in hard skills, I prefer them being asshole over them not contributing but being nice.
Very often in my experience, people with too many soft skills and too little hard skills are at best dead weights, at worst con men, which are a special kind of asshole you REALLY don't want to deal with.
Of course the best is to have both hard/soft skills, which is not as rare as people assume.
>Very often in my experience, people with too many soft skills and too little hard skills are at best dead weights, at worst con men
No, these are the people who should be moved into management positions. They can spend time on all the soft-skill stuff that ICs don't want to spend time on, like dealing with upper management, leading meetings, etc. They don't need to have the best hard skills, just enough to understand at a higher level and communicate with others in and out of the organization, and they can refer to the experts in their teams when they need more detail.
I completely disagree. Managers who don't have knowledge can do way too much damage.
Hard disagree. I've yet to see a "brilliant asshole" with anywhere near the kind results I expect from my teams. The usual pattern is your typical asshole will ship broken stuff and then blame everyone else for the breakages.
Now, average assholes who self-promote as brilliant and hope no one will see through their crap, sure, plenty of those. I'd recommend against failing to see through their crap, though. They'll make your actually good engineers leave.
Maybe you had those average assholes masquerading as brilliant? I don't know that of course, but "ships broken stuff" doesn't sound particularly brilliant to me.
I'm thinking of the type that builds things that you can stack up against the output of others and comes out miles ahead. I have one of those in my team, and it feels like a force of nature: he independently does in a month what a team of five did in three, and his work is of better quality. Of course I'll cut him a lot more slack.
> if you're very good at what you do, soft skills are a lot less important
Empathy is more than butter. It also lets you uncover why the requirements should be what they are.
There are roles where buried brilliance works. But it’s usually in academia or the military. Not commercial work.
I have no experience with the military and very little with working in academia, but a lot with commercial work, and I've seen it work many times. Clearly those people wouldn't be the ones talking to customers or leading teams, but it's worth a lot to have someone that can tackle hard problems.
I'm not at all saying that you can only have one or the other, or that soft skills don't matter at all. It's just my experience that output matters a lot more than people say in these types of conversations.
To me looks a lot more like the cliche Diva in music - are you really going to not work with someone extremely talented just because they're difficult to work with and you wouldn't want to hang out with them?
> it's worth a lot to have someone that can tackle hard problems
Oh, absolutely. My point is those personalities are almost common in the military and academia. They’re rarer in commerce because there aren’t that many niches where hard problems exist independent of peoples’ preferences. (As in, choosing how to scope the hard problem is part of what makes it hard. And the scoping that works best isn’t going to be found in isolation from customers and others working on the problem.)
> Most of my peers would rather work with brilliant jerk than a friendly average person.
I think you need to be more specific than just "avert" the trope without elaborating. Others have commented how a brilliant jerk can slow a project down, but I get the impression that you are thinking of someone who is not sociable, not interested in business goals, very direct and perhaps even pessimistic about others' ability, but hand them a technical task and they can deliver exceptional results. This is opposed to, say, someone who is sociable but can't deliver anything without constant attention or handholding.
Yes, absolutely. I'm not talking about people who are not sociable _and_ can't produce, but people who don't care about your feelings, but are very strong in their work.
In other comments, it felt like they focused very much on the "low in soft skills" part without looking at the other skills being extended. Of course, someone who is unpleasant to work with and only writes buggy software will not help a project progress. But someone you don't want to spend time with but who carries your team through the project with his skill and productivity is a very different story.
If you can isolate the brilliant jerk to do something that needs very little coordination with others, that can work.
But at least where I've worked, there wasn't much standalone work like that.
Also the vast majority of sw engineers just have average soft skills. There is still a difference to sales and we certainly do not need any more pretentious behaviour in technical discussions. Yes, VCs will require you to advertise yourself, but I think many also just want a realistic approach about a potential business ventures.
The most practical problem sw engineers have here that they waste hours on some frivolous technical solution that could have been cleared up with a pragmatic approach through a three minute call.
That engineers aren't people persons is a stereotype. There are as many "autists" in the social sciences. Yes, I know I shouldn't use that word for anything that is not a pathological diagnosis.
Soft skills, in the context it's used here, include communication skills.
A key part of communication is being able to communicate ideas with someone not like you (different expertise, background, touchpoints).
Imho, a lot of software developers suck at that. (Obligatory: 'I talk to the customers so the engineers don't have to')
To the article's point, this becomes an increasingly valuable and critical skill the closer software development moves to the original requesting users. Or the closer the ability to code moves to people who were already talking to users.
Personally? I view myself as a problem solver: whether I solve a problem with code, a new technology, a conversation with a colleague, a deep dive discovery session with a SME, or a month-long series of political meetings with conflicting stakeholders, I don't care.
>>But it's never been the case that a dev could just focus on technical things and not spend any time figuring out the context they are working in, and behaving accordingly.
I've worked with plenty of programmers who were absolutely insufferable human beings but were some kind of supernatural coders who were doing the work of 20 people or were literally the only people who could understand the maths or physics or rendering in our products - so everyone kinda put up with it. I used to know someone who had dozens of HR complaints about them every year and nothing was done because the company didn't think they could risk firing them.
So yeah. They exist. And I don't think AI is going to do much about them, but I'd love to be proven wrong.
There are lots of developers who are able to lean into their inclination to be non-communicative. In many cases I think this inclination is at least partly due to neuro diversity; but I've met some who are simply genuinely unpleasant.
To the outside, the difference is hard to tell, isn't it? Between neuro-diversity and genuine unpleasantness -- isn't it mostly that one has a diagnosis (that you know of) and the other does not?
You might change your moral judgement of someone's behavior if you find out they have this or that condition (at least I do), but it doesn't change how their behavior impacts you, does it? If it did, I think the best you could do is to assume that everyone has some sort of condition that makes them act the way they do, and it'll be less of a problem.
As someone who's neurodiverse myself, I do want to agree with this. Having said that, I do think it's possible for someone to choose to be an asshole and be neurodiverse at the same time. I wouldn't ever want my neurodiversity to be a free pass for any type of behaviour myself.
I generally struggle with the idea of someone actually choosing to be an asshole, I assume there's usually an unseen cause.
E.g. I work with someone who seems very normal, is very professional, and I have no reason to believe that they area neurodiverse in any way. They once were very direct in a ticket towards a different team. Did they choose to be an asshole, or were they losing their last ounce of patience and politeness because they've been carrying a mountain of responsibility and stress? I think it's very difficult to tell that apart, or to judge based on "well, they could have not taken on that responsibility so they're liable for anything that is a consequence of it".
I don't consider it a free pass, but there's a lot more understanding for things that are outside your control. Where we see that line of control probably determines whether we judge someone harshly or not.
>I used to know someone who had dozens of HR complaints about them every year and nothing was done because the company didn't think they could risk firing them.
But did the company make them a team lead and put him in charge of other people?
No, luckily. But they were the kind of person who you could casually ask "hey John, what have you been working on" and they would reply with "you're too stupid to understand so I won't bother explaining".
>>>absolutely insufferable human beings but were some kind of supernatural coders who were doing the work of 20 people
I don’t at all condone being that guy. However….
It’s pretty amazing what an engineer can accomplish if you can actually get into a flow state because people are too afraid/intimidated to interrupt you every 10 minutes and you aren’t being invited to endless (and mostly useless) meetings all day.
¯\_(ツ)_/¯
There are plenty of devs who do nothing beyond taking a Jira ticket scoped by others, implementing it, and then grabbing the next ticket.
While they may not have been very successful, they did have a place.
You’re right but i have always preferred people who can do a little more. Nothing against the socially awkward and conflict avoidant nature in many of these friends, but people who push back and fight to communicate their views and passions often got our team better outcomes than someone who just turns up and does the work they’re asked to do.
As long as it is not opposite set of skills (talks a lot without knowledge to back it up so essentially using charisma to convince people to do the wrong thing most of the time) then yes, a lil bit of negotiation can save you a whole lot of work in the long run (XY problems being one example)
For sure, I’ve been tricked into hiring those people before too. It’s good that there’s still something hard in running an organization, the whole “what is value?” question feels like it’ll be one of the few things we have to maintain work for humans over the next little while.
Looks very robotic to me, never worked on a place where meetings and dealing with other humans wasn't part of the job.
I’ve been on plenty of teams where meetings didn’t actually require any meaningful participation from most people.
Meetings without any meaningful participation from most people? I guess too many people in the meetings?
That is likely referring to what has become known as the standup, where developers read off the commit log for the "manager" who hasn't yet figured out how to use a computer.
Or for the product manager too lazy to check Jira.
Never been the case for me, additionally I have always worked in shared desks or offices.
Is this genuinely common? I’ve only ever seen that level of hand holding extended to new grad hires.
It definitely happens at bloated organizations that aren’t really good at software development. I think it is especially more common in organizations where software is a cost center and business rules involve a specialized discipline that software developers wouldn’t typically have expertise in.
I have 13 years of professional experience, and I work in a small company (15 people). Apart from one or two weekly meetings, I mostly just work on stuff independently. I'm the solo developer for a number of projects ranging from embedded microcontrollers to distributed backend systems. There's very little handholding; it's more like requirements come in, and results come out.
I have been part of some social circles before but they were always centered around a common activity like a game, and once that activity went away, so did those connections.
As I started working on side hustles, it occurred to me that not having any kind of social network (not even social media accounts) may have added an additional level of difficulty.
I am still working on the side hustles, though.
> it's more like requirements come in, and results come out.
Wow someone is very good at setting requirements. I have never seen that in 25 years of dev life.
I've seen it many many times, a few from myself.
It's not so hard if you're an expert in the field or concept they're asking the solution for, especially if you've already implemented it in the past, in some way, so know all the hidden requirements that they aren't even aware of. If you're in a senior position, in a small group, it's very possible you're the only one that can even reason about the solution, beyond some high level desires. I've worked in several teams with non-technical people/managers, where a good portion of the requirements must be ignored, with the biggest soft skill requirement being pretending they're ideas are reasonable.
It's also true if it's more technical than product based. I work in manufacturing R&D where a task might be "we need this robot, with this camera, to align to align to and touch this thing with this other thing within some um of error."
Software touches every industry of man. Your results may vary.
I've seen that plenty of times. I suspect that you haven't seen it because you live in a place with high cost of living, which induces a high turnover in personnel, or perhaps you've been working in very dynamic markets such as SaaS.
When I was starting my career in Europe as freelance sysadmin, I worked several times for small companies that were definitely not at the forefront of technology, were specialised in some small niche and pretty small (10-15 engineers), but all its engineers had been there for 10-20 years. They pretty well paid compared to the rest of the country, and within their niche (in one case microcontroller programming for industrial robots) they were world experts. They had no intention of moving to another city or another company, nor getting a promotion or learning a new trade. They were simply extremely good at what they were doing (which in the grand scheme of things was probably pretty obsolete technology), and whenever a new project came they could figure out the requirements and implement the product without much external input. The first time I met a "project manager" was when I started working for a US company.
>I worked several times for small companies that were definitely not at the forefront of technology, were specialised in some small niche and pretty small (10-15 engineers), but all its engineers had been there for 10-20 years. They pretty well paid compared to the rest of the country
This isn't possible in the USA. Companies like this (small, and not in tech hub cities) always try to take advantage of their location and pay peanuts, with the excuse "the cost of living is lower here!", even though it's not that much lower (and not as low as they think), and everything besides houses costs the same nationwide.
I agree that something like that is very unlikely in the US, which is why so many people in this thread (I presume Americans) were incredulous as to whether that was even possible, but elsewhere in Europe good software and electronic/electrical engineers can be making very good money for the local standards in stable jobs, while at the same time being paid a lot less than they would be in a similar job in one of the US major tech hubs.
Of course, sometimes people realize that what they asked for wasn't actually what was needed.
I mean... This "realization" is what triggered the advent of agile, 2 decades ago, right?
People almost never know what they want, so put SOMETHING in front of them, fast, and let's go from there
I've heard this, and I've even seen it in plenty of poorly performing businesses, but I've never actually seen it in a highly performing, profitable tech company. Other than at the new grad level but it's treated as net-negative training while they learn how to build consensus and scope out work.
Not coincidentally, the places I've seen this approach to work are the same places that have hired me as a consultant to bring an effective team to build something high priority or fix a dumpster fire.
A lot of highly performing teams don't even use tickets.
Do any highly performing teams use tickets?
A fly-by-night charlatan successfully pushed ticking into our organization in the past year and I would say it was a disaster. I only have the experience of one, but from that experience I am now not sure you can even build good software that way.
I originally hoped it was growing pains, but I see more and more fundamental flaws.
I’ve worked at one, but it required a PM who was ruthless about cutting scope and we focused on user stories after establishing a strong feedback pipeline, both technically through CI/CD/tests and with stakeholders. Looking back, that was the best team I’ve ever worked in. We split up to separate corners of the company once the project was delivered (12 month buildout of an alpha that was internally tested and then fleshed out).
Maybe I had greenfield glasses but I came in for the last 3 months and it was still humming.
How do you keep track of tasks that need to be done, of reported bugs and feature requests?
Previously? There was an understanding of the problem trying to be solved. The gaps left the pangs of "this isn't right".
Now I have no way to know where things stand. It's all disconnected and abstracted. The ticket may suggest that something is done, but if the customer isn't happy, it isn't actually. Worse, now we have people adding tickets without any intent to do the work themselves and there isn't a great way to determine if they're just making up random work, which is something that definitely happens sometimes, or if it truly reflects on what the customer needs.
You might say that isn't technically a problem with ticketing itself, and I would agree. The problems are really with what came with the ticketing. But what would you need tickets for other than to try and eliminate the customer from the picture? If you understand the problem alongside the customer, you know what needs to be done just as you know when you need to eat lunch. Do you create 'lunchtime' tickets for yourself? I've personally never found the need.
You must be working in projects with a relatively small number of “problems to be solved” at any given time, and with the problems having relatively low complexity. In general there’s no way to keep everything in your head and not organize and track things across the team. That doesn’t mean that a lot of communication doesn’t still have to happen within the team and with the customers. Tickets don’t replace communication. But you have to write down the results of the communication, and the progress on tasks and issues that may span weeks or months.
> In general there’s no way to keep everything in your head
I imagine everyone's capacity is different, but you wouldn't want anyone with a low capacity on your team, so that's moot. Frankly, there is no need to go beyond what you can keep in your head, unless your personal capacity is naturally limited I guess, because as soon as you progress in some way the world has changed and you have to reevaluate everything anyway, so there was no reason to worry about the stuff you can't focus on to begin with.
I find that the current way we do Scrum is way more waterfall-ish than what we had before. Managers just walked around and talked, and knew what each person was doing.
We traded properly working on problems for the Kafkaesque nightmare of modern development.
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 the real world, one day up and deciding no more managers on a whim would lead to chaos, so Scrum offered a "training wheels" method to facilitate the transition, defining practices that push developers into doing things they normally wouldn't have to do with a manager behind them. Once developers are comfortable and into a routine with the new normal Scrum intends for you to move away from it.
The problem: What manager wants to give up their job? So there has always been an ongoing battle to try and bastardize it such that the manager retains relevance. The good news, if you can call it that, is that we as a community have finally wisened up to it and now most pretty well recognize it for what it is instead of allowing misappropriation of the "Agile" label. The bad news is that, while we're getting better at naming it, we're not getting better at dealing with it.
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”.
> I don’t think people invested in Scrum believe it’s “temporary” or ever marketed it as such.
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.
I've realized it's a different paradigm in (very loosely) the Kuhn sense. You wouldn't track tasks if you're fundamentally not even thinking of the work in terms of tasks! (You might still want a bug tracker to track reported bugs, but it's a bug tracker, not a work tracker.)
What you actually do is going to depend on the kind of project you're working on and the people you're working with. But it mostly boils down to just talking to people. You can get a lot done even at scale just by talking to people.
People gotta remember its a job just like anything else. I dont see any other profession going above and beyond so why should that be levied upon on programmers, I don't see PMs trying to understand code, CEOs trying to understand the customer more than the investor.
McDonalds and Taco Bell tried to get rid of their "soft skills" (AKA customer service} and look how they're doing right now... Endless stores that all look & feel the same -- uncomfortable seats, no happy families around for longer than 10 minutes, longer drive-thru lines, and impersonal & impatient staff that avoids customers like the plague.
Evangelists will preach Ai because it's good for corporations that don't care about customer needs, but in the same sense, it may well be the catalyst for many to move out of cities to more human areas as it grows.
Businesses dictate the spread of Ai, and then foist it on customers because they think monopolies are sustainable, but the foundational rules always ring true -- Customer service & commitment are essential to the survival of a business. This tone deaf approach will eventually alienate many from companies that adopt it, and there aren't enough tech-inclined introverts to sustain profit in a world where Ai takes everyone's jobs. We don't ALWAYS want to talk to vending machines, human interaction is a need for many that Ai evangelists seem to think will simply go away.
I hope there are still some reasonable minded business leaders out there to swoop in and fix things after the ashes this era leaves along with all the VC carnage & political damage rendered on our economy.
Ai is great for math though... Maybe that should be the less-destructive focus.
>uncomfortable seats, no happy families around for longer than 10 minutes
Which is probably also net positive for business - similar to loud music in the pubs is a deliberate choice so people could focus on drinking rather than talking?
>McDonalds and Taco Bell tried to get rid of their "soft skills" (AKA customer service} and look how they're doing right now... Endless stores that all look & feel the same -- uncomfortable seats, no happy families around for longer than 10 minutes, longer drive-thru lines, and impersonal & impatient staff that avoids customers like the plague.
How's their profitability? Long drive-thru lines sounds like business is doing well.
This reminds me of people complaining about Windows, with its ads and AI and tracking and such. They don't like it as users, but the company is making plenty of money, so of course it's the right thing to do.
Often it means being a sociopath
There are HOSTS of dogshit devs that operated that way, trust me. Half the job of a PM has been to work with these types of people.
I too met many such developers.
Very often some tech lead or head of could spot them and put them on tasks where they could be autonomous (generally technical but important aspects that bogs down several teams or products: pipelines, tooling, api design, performance, etc).
Some could also be involved in features involving business logic but the lead/PM would make sure to put more details or streamline any feedback/questions through jira.
Also, there's even more developers out there that get complacent on the business aspect after some time of seeing how poor product and business development is, and just phase out of it completely and try to find solace in the technicalities.
If feels sometimes like many on HN live in ultra competitive bubbles with managers pushing people to grow and promote them like it works in Meta and similar, but that's really not the norm, it's the exception.
Many of us work in companies where software is an expense, not an asset, mentality is different, there are no such structures, management and product are crap and you find a wide variety of situations and devs.
That really sounds like a PM complaining that "I have to do my actual job of being the bridge between the business and the engineering team"
ALL PMs are expected to be doing some translation, otherwise what's the point of their job?
> otherwise what's the point of their job?
Who else is going to move a box from one column to another?
Claude?
It could be Claude. Or Sally, Joe, or Sue. Whatever name the PM goes by is immaterial.
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 treacherous and uncertain. There's too many unknown unknowns, it's like not knowing if the dice you're playing is loaded against you. You don't know how many cultural land mines you might step on when interacting with your superior, or if there's a glass ceiling enforced by a group who will nitpick on minor irrelevant 'faults'.
Whereas compare soft skills to hard skills, you have a major advantage in certainty. There is a dice loaded in your favor. You know you can get much of the stuff done, and once you've reached the desired results, that's all there is to it.
I also could go on on how soft skills erodes human's capacity for judging what is value, instead basing their opinions on the majority source of opinions... It'll definitely be a much more irrational world to live in.
I'm sorry, but that's nonsense. Soft skills are mostly definitely not about sucking up.
At a previous job, the PM for another team often asked me to join some of their meetings — her engineers were shit at talking to non-technical people, so, for critical meetings, she asked me to join to serve as an interpreter of sorts. That's soft skills at work.
Talking to stakeholders and understanding what they need? Soft skills. Understanding the different between important and urgent? Soft skills. Being able to assess a candidate during an interview? Soft skills. Navigating cultural differences when you have offices or suppliers abroad? Soft skills.
I'd go as far as to say that the single biggest difference between a junior and a senior engineer is how well developed their soft skills are.
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 preferences, and that sucks, because as I said the game of soft skills can be a cultural landmine equivalent to rolling a dice with unknown odds.
If that is the only game in town, the result could turn out to be like the USA's politics of today, with no way to deviate/defect if you disagree.
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 neurotypical, it's a limitation about yourself that you need to acknowledge)
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. Would you rather have those two people have the mindset that "other engineers have their own preferences and that sucks", or that they have the mindset that "other engineers have their own preferences as a result of their own experience, and I welcome navigating those differences as part of the job"? Which of those two conversations ends with the two engineers understanding why the other person has a different opinion, and reaching a reasonable compromise? Which conversation ends with everybody involved learning something new, making the team technically stronger?
Because soft skills is also dealing with politics, you can't separate the 2.
> 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.
But most of the things you're describing as bad can also be described as a lack of soft skills. The person who can't take care of themselves and rolls over under pressure definitely has poor soft skills.
The System rewards yes-men and bullshit-artists and LLMs have come to replace them.
> ifonlyyouknew.jpg
I've heard this "soft skills are the only skills that matter" thing throughout my entire career but these days this is indeed greatly amplified.
Our CEO started sharing screenshots of his xitter/linkedin feeds and most of them contain wisdoms like "Opus 4.5 is better than 90% of talent". There is also longer form business fan fiction. It usually follows this template: there is a hero - a humble manager/sales person, and a villain - a cocky, nerdy software developer. The villain claims that some task is impossible or takes months to complete. Then the humble hero (equipped with Opus 4.5) completes the task in 2 hours. The villain is then humiliated/fired and everyone lives happily ever after.
These posts definitely contribute to the declining morale among employees. Nobody goes "above and beyond" anymore - we just strictly doing the tickets and nothing more.
Even before AI, there was tremendous pressure on developers for NOT going above and beyond.
I have been in far too many situations where a developer had an idea or a prototype it was blocked by a product manager on the grounds of it not being their idea. As a technical manager you then have to burn political capital just to get people to fucking collaborate.
I've also seen way too many situations where developers must do the actual PM gruntwork where the PM wants to pretend they are some kind of svengali tastemaker figure.
Have this for a few years and the psychological safety of any developer is in shambles.
Those environments need to be fucking burned to the ground.
One just needs to survive one layoff round to learn that going above and beyond is useless, everyone gets shown the door regardless of the performance.
That is one reason why companies don't like seniors, we know their tricks.
Companies have forgotten the value of morale. In this particular sense, AI hype has been very successful in demolishing morale, creating burnouts and overall decreasing value of everyone. Now everyone at the company can build everything in 2 hours, or so I am told.
> everyone at the company can build everything in 2 hours
The business teams can build it in two hours, but those lazy developers spend weeks finishing off the so called last 2% that's somehow always left over after a vibe session.
Once upon a time a clever software engineer realized that engineering talent is the fuel which the business relies on to support its revenue growth, and management is for facilitating this process, while the CEO’s purpose is to be blamed when it doesn’t work out. He wrote a small bash script which replaced corporate leadership with a “quote of the day” generator and everyone lived happily ever after.
Two things can be true:
- You can have a horrible CEO that doesn't value their employees and is trying to devalue labor.
- AI coding tools can be incredible exoskeletons in the hands of skilled engineers and enable them to get much more work done.
Perhaps the real "SaaS-killer" is innovation capital [1] realizing it can take advantage of the various forms of arbitrage and changing of the guards happening now, raise venture capital, and take on the old and slow management-driven businesses.
If you've ever had the itch to fire your boss, now's the time. It's a hard path, there are way more hats to wear, but the dry powder is out there waiting to be deployed.
[1] ICs in both senses of the acronym.
It's also the fun path! Although I think we should acknowledge that most don't have the means to do this. For engineers with a high salary I would advise saving as much as possible so you have more agency.
> There is also longer form business fan fiction. It usually follows this template: there is a hero - a humble manager/sales person, and a villain - a cocky, nerdy software developer. The villain claims that some task is impossible or takes months to complete. Then the humble hero (equipped with Opus 4.5) completes the task in 2 hours. The villain is then humiliated/fired and everyone lives happily ever after.
Can you share examples? I've never seen something like that.
> Our CEO started sharing screenshots of his xitter/linkedin feeds and most of them contain wisdoms like "Opus 4.5 is better than 90% of talent". There is also longer form business fan fiction. It usually follows this template: there is a hero - a humble manager/sales person, and a villain - a cocky, nerdy software developer. The villain claims that some task is impossible or takes months to complete. Then the humble hero (equipped with Opus 4.5) completes the task in 2 hours. The villain is then humiliated/fired and everyone lives happily ever after.
I do have the impression that many programmers are much more resistant to bullshitting, and love to call out the mistakes when confronted with bullshit. Getting into management, on the other hand, means believing in instead of fighting lots bullshit.
So, of course the mentioned CEO gets lots of such stories in his xitter/linkedin feeds; CEOs are not insanely eager to comment on such stories why the premises are wrong, and by which dirty tricks this manipulates people. Rather, by climbing up the company ranks, they actively had to believe in more and more fairy tables (or bullshit); if they are too resistant to the brainwashing that they have to believe in, they will stop climbing ranks.
> These posts definitely contribute to the declining morale among employees. Nobody goes "above and beyond" anymore - we just strictly doing the tickets and nothing more.
I think those posts exist in a bubble. They only escaped the bubble because someone wanted to use them once over to unite a different group of people against a different set of bad guys, ironically continuing the cycle. This time it’s devs loathing management instead of management loathing devs.
All of the great people I’ve worked with don’t play any of these games at all. They know it’s a sideshow of engagement bait and content generated with a goal of being controversial, not truthful.
I would not go as far to say that they exist in a bubble. I quit my job as an engineer because this exact sentiment from my boss was ruining my life.
Going above and beyond is hardly ever rewarded in my experience, except when it happens in the stupidest way, like producing more technical debt faster.
> Today, I use Claude Code for almost all non-trivial programming tasks and have spent $500+ on it just last December.
Truthfully, I don't want to get advice from people who become addicted to AI, sorry. The money investment that person did, already leaves me with tons of questions.
Sensible. This article is another AI hype angle. The author works on an AI agent platform for marketing, of course he wants to hype it.
Best to also avoid people with LSP and debugger addiction.
I think this tongue in cheek comparison would make more sense if it were possible to spend more than 50 cents on an LSP or debugger over the course of a lifetime.
Many people who get into software development before 2010 or so have easily spent hundreds of dollars on dev tools of a similar nature.
Surely, they don't spend $500 per month, though, as the quote implies.
Visual Studio Professional did cost about $500 back in the day, although you ended up getting a perpetual licence for the software and some updates. These days they expect you to have a subscription as with all other business software.
> Truthfully, I don't want to get advice from people who become addicted to AI, sorry.
If you sleep on this, these people are going to take your job.
I've been writing serious systems code for 15 years. Systems that handled billions of dollars of transaction volume a day and whose hourly outages cost billions of dollars. These are systems you have to design carefully. Active-active, beyond five nines reliable.
I'm telling you AI is extremely beneficial even in this segment of the market. The value prop is undeniable.
I'm easily getting twice my workload done with AI, and I'm not even leveraging the full extent of the tools. I've only just started to do more than fancy tab-autocomplete.
This is going to be a huge shift in our industry, and I would brace for impact.
I dont want to take responsibility for 10 features at the same time because one guy on the internet is able to bullshit the execs.
> I'm easily getting twice my workload done with AI, and I'm not even leveraging the full extent of the tools. I've only just started to do more than fancy tab-autocomplete.
Are you getting 2x the money?
> Are you getting 2x the money?
Probably no and additionally paying $200/mo out of pocket for the pleasure of doing twice the work.
Why would it be out of pocket?
Companies won't even pay for IntellJ, why would they pay for the top tier Claude plan so you can run the 10 agents you need? (and yes it needs to be multiple agents according to their founder [1])
[1]: https://news.ycombinator.com/item?id=46470017
>I'm easily getting twice my workload done with AI, and I'm not even leveraging the full extent of the tools.
It seems that every person who says this never elaborates on the nature of their work. What exactly are you writing? What languages? Technologies? What does the LLM assist with? In what ways does it hamper more than help?
I ask these questions because I have yet to see any meaningful, real world application of AI at my job. There's definitely interest, but every exploratory effort seems to fall flat, sometimes comedically so e.g. recently we had Sonnet 4.5 recommend some JavaScript for a UI hang we were looking into. It also recommended we use WebWorkers to improve perf. Sounds great. Looks great, with nice markdown and whatnot. Too bad it was a legacy MFC application written in C and C++.
I don’t want to do twice my workload. I’m old enough to have learned that the faster and more efficient you are, the more demands they pile on you, and the net result is more stress, more expectations for the same pay. AI doesn’t solve unreasonable demands, shifting requirements and looming deadlines, does it?
And still, writing code is not even the bottleneck, the thinking, meeting stakeholders, figuring out technical problems is. What would I do with a machine that spits out bad code.
I guess I’m not cut out for a field where the only metric that counts is how many tickets and lines of code one can churn out in an hour any more.
In my 20+ years in the tech industry, the most important thing I have learned is that writing code is the least significant part of being a software engineer.
You write code once, but then it's modified endlessly. Supporting and using and improving the code is the majority of the work. LLMs are terrible for that. They tend to write code that isnt easy to read and modify. They don't plan for future use cases. They often paint themselves into a corner with successive modifications, and lose context as the project grows.
Don't worry about your job just yet. We are a long long way from replacing people.
Personally I get a +5% productivity in a good day with AI.
I do double my productivity on personal projects but they aren't entreprise style jobs.
I really hope for those AI companies that my situation isn't too common because burning billions to make dev hobbies more productive doesn't sound too good of a business plan.
Curious, could you give examples of how you've been able to double your productivity with AI?
In my (not systems engineering) opinion, most time spent writing code is boilerplate and rituals; unit tests are pretty repetitive, creating a React component is a lot of repetition, etc. A LLM code assistant can do these boring things faster.
Yeah I agree with you on that, I'm just curious about the systems programming use case as in my experience you have to think deep about interactions and working with an agent blunts that
These people are not going to take your job, the people who uses tools smartly while having the knowledge and experience in highly reliable distributed systems are. If human in the loop is not required any more, nobody is going to keep their job.
Totally agree.
The uncomfortable truth is that the skill of _writing_ code is becoming commoditized.
Reading, understanding, designing efficient systems, and planning changes based on that, at least for now, will still be for human experts (and AI already a great assist here).
But churn out yet another webpage/website? People doing this will need to move on from this as their primary job.
>But churn out yet another webpage/website?
People exaggerate how many people work on just simple websites / webpages. Anyone needing a website has been able to get it for very cheap for a long time.
Yep. It has been the case forever. The reason we keep/kept getting new tools is because laymen would exhaust their capabilities in the old tools and started requiring a developer once they need THAT ONE feature.
Be careful, engineers, when interacting with soft skill experts not to join their reality distortion field where it’s all about coordination, alignment, bizness strategy, clever planning. Whereas the real stuffs are just implémentation details, quickly solved.
In the end, they might convince you that 2+2=5.
This is actually a soft skill deficiency of not being able to appreciate importance of other people's fields of expertise. Not unlike a hard skill expert's failure to appreciate the importance of soft skills.
People with truly good soft skills are a pleasure to work with even if your soft skills are not that great.
The trouble isn't that they would convince me with their reality distortion (they don't), the issue is that they are satisfied with their "progress" while I'm still asking crucial questions (which they ignore, b/c they don't see the importance).
Part of the soft skills that are useful for a developer is being able to frame your crucial questions in a way that makes their importance relevant to their world.
Perhaps soft skills are too squishy and/or broad of a term to be useful then. It seems like these discussions always go "maybe you, as the developer, just need to learn how to do soft skills properly?" in response to business types exhibiting an undesirable behavior. Sure, smooth talking and playing into someones personality might be more successful (albeit with a lot more hot air), but all of you are supposed to be working towards a goal. If someone gets hung up because you weren't smooth enough, I would think they're a bad faith actor who doesn't actually want to get something done.
Soft skills are broad in scope, for sure.
But I’m not talking about “smooth talking” here; in response to the above example —- where engineering is asking questions that that the business things had not answered because they are presumably “unimportant” —- there is almost certainly a communication breakdown happening.
Likely, one of the following is happening:
* The questions are important to the business but engineering has failed to articulate why getting the answers are critical to the business. (Some engineers have a tendency to describe problems in the scope of how it affects their own job or task, but neglect the larger picture or fail to articulate any consequences)
* The questions actually aren’t important for the business to answer and the engineer fails to understand how their task supports the goals of the business
* The questions are important but they cannot be answered by the business. The engineer might need to gather more information before to generate actionable questions, or maybe the questions should be answered by engineering themselves.
Remember, technical workers, you must grind all you soft skills in addition to the technical ones, so that you can successfully interact with those people hired exclusively to use their soft skills.
Engineers just need to have good enough soft skills to effectively communicate.
Engineers who struggle to do that are just as bad at their job as business managers who aren’t technical enough to operate Microsoft Office. There’s a minimum of both hard and soft skills that anyone in a professional environment should have.
Bizness needs to understand that scalable reliable durable solutions take time to craft properly. https://www.youtube.com/watch?v=x9wn633vl_c
Engineers need to understand that those requirements don’t apply to every project.
https://res.cloudinary.com/monday-blogs/w_1000,h_561,c_fit/f...
How does an engineer know that he is involved in a bozo-driven PoC or in a technical deathtrap that will end up as the core business of the company?
Again, by communicating. If someone doesn't know what they are building, who they are building it for, and why -- then they do not have a solid grasp of the requirements.
Never saw a subcontracting requirement document, stating "the solution is for a bozo-project. so don't spend ages making it robust for the future"
Effectively communicating as an engineer is not “reading a requirements document”.
If you’re just blindly implementing someone else tech spec, you’re not doing any engineering, you’re just programming.
Oh, that's easy. Can you point any real person waiting to use the thing?
In fact, that's probably the easiest question to answer on this entire discussion.
Live version of this comment:
The Expert https://youtu.be/BKorP55Aqvg?si=n3apbzYNDb4U0hmD
Its never about the soft skill experts being able to convince the engineers, the challenge if any, is always about them being able to convince the "leadership"
Wait until you try to explain basic concepts to such people! What's annoying is HR employing more of these people and not understanding why the dial does not move. What is baffling and infuriating is when such people are put in management. MBAs will destroy Western business eventually(those who tag an MBA onto a STEM qualification are not as bad but still infected.)
The sort of people who have been able to neglect their soft skills are probably still going to be able to do so in the future. But those were always the extreme intelligence outliers, generational talent type figures.
For most software engineers, neglect of soft skills have always been a career tarpit that leads nowhere you want to end up. Being able to navigate social settings and to communicate well is a force multiplier. For most people, it really doesn't matter how good you are if nobody understands what you are saying and you can't convince other people to buy into your ideas. You far more often see moderately successful charlatans that are all talk than successful people with awful communication skills. Of course if you're able to walk the talk, that's when you can really go places.
> [people without soft skills] were always the extreme intelligence outliers
This is a B-player myth.
High intelligence makes you better at soft skills. People are complex, and being good at soft skills takes intelligence, intelligence to intuit the importance and see the patterns of soft skills.
It is true that if you have high skills that a business needs, you can choose to ignore many internal norms of dress or etiquette.
And also as your status goes up, the more you don't need to care about signaling, and some people do counter-signalling. I always think of this: https://www.dailymail.co.uk/lifestyle/article-9233455/Prince...
Unfortunately it is also true that some people think that acting badly will give them cred (reversing the causality that having cred permits bad behaviour). Was Sam-Bankman-Fried acting that cryptic appearance? Do executives also model their behaviour by rewatching The Apprentice or Gordon Ramsay?
Disclaimer: That's mostly my personal opinion, from watching people smarter than I. Then again I'm no genius, nor do I win status games, so perhaps I'm just ignorant. I've definitely seen some less talented try and put on an act leading to a pratfall. Also many of the smartest people I know left school at 15.
Intelligence scales with social skills.
Unless you have a condition like autism which allows skewed development, which a lot software engineers do have.
To add - their comment about socially prickly smart devs (my paraphrase) makes me think they are referencing the mad genius stereotype (crazy artist, Aspie developer, etcetera).
Are rudeness and crazyness markers of intelligence? is Terry Davis a good or bad example https://news.ycombinator.com/item?id=16105215
you can be better and decide not to do it because you dgaf
> The sort of people who have been able to neglect their soft skills are probably still going to be able to do so in the future. But those were always the extreme intelligence outliers, generational talent type figures.
This is just not true. Lack of soft skill never implied high intelligence, it was always and is just lack of soft skills. Some people without them are otherwise highly intelligent, others are just normal or even weaker then average.
> You far more often see moderately successful charlatans that are all talk than successful people with awful communication skills. Of course if you're able to walk the talk, that's when you can really go places.
I would argue that this is consequence of management that does NOT have soft skills. People write a lot about soft skills of engineers and simply assume management has them. They do not always, yes they then end up being bad managers ... and charlatans doing good is usually consequence of bad management without those actual people skills. Soft skills are not just about coming across nice, they are also about being able to be assertive, being able to recognize charlatans or toxic personalities and being able to deal with them (which is not the same as enabling them).
Where did I claim one implied the other?
The shift is from tarpit to unemployment. A Jira ticket processing dev still has use. Probably not for much longer.
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 more due to Mr Musk's eccentricities and political ventures than the engineering team.
The reason this hasn't happened to any wider degree is quarterly capitalism and institutional inertia. Looks weird to the investors if the organization claims to be doing well but is also slashing its employee count by 90%. Even if you bring a new CEO in that has these ideas, the org chart will fight it with tooth and nail as managers would lose reportees and clout.
Consultancies in particular are incredibly inefficient by design since they make more money if they take more time and bring a larger headcount to the task: They don't sell productivity, but man hours. Hence horrors like SAFe.
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.
At the same time, that quest for the next big thing is performative, it's theater for the investors, and exactly what I'm talking about.
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.
> Twitter had a lot of engineers on its payroll to look for the next big thing.
What was the "next big thing" before acquisition? There seems to be more features added after the acquisition than before it.
I think the author would say that the developer who is without soft skills won't merely be prevented from gaining desirable work. They'll be unable to keep a job, period.
Seems a pretty sketchy assertion, but regardless whether these people burn out in career purgatory at a java 8 feature factory moving jira tickets around for all of eternity, or they move on to something else entirely, it's probably not what they had in mind.
So I opened this article to find out at the very beginning, that author put's a lot of money to AI providers... So probably also used it to write this article. So, according to the rule "text which is not worth of spending time on writing is also no worth of reading" I closed it.
The author works on AI-powered Brand Agents built for marketers & publishers. That should be enough to tell you it’s not worth reading.
I found out that the author of a blog post paid a maid to clean their house, and sends their laundry out. Therefore, the blog post was written by the maid, or one of the laundromat employees. So I closed it.
That's a false equivalence. You might read a blog post about engineering from someone who paid a maid to clean their house, and sends their laundry out.
But would you read their blog post on laundry tips?
No - it's just as easy for you to send out your own laundry.
Err, no, the equivalent would be if the author had written an article about laundry, and how important it is to pay attention to all the details... then you realize the photo of his laundry still has a tag on it from the laundromat.
false equivalence
I would submit that this could be based on a stereotype that “coder = antisocial.”
Why are we assuming that people who write code don’t have soft skills?
The youngest generation who joined the profession are probably in it for the the salary versus the older generations who came from computer clubs and dungeons and dragons groups of the 1970s/1980s along with a culture where having a niche interest was socially ostracizing and uncool.
I wonder if the youngest generation entering the profession is much more of a cross section of regular people?
I've had a long career in software and my conclusions is that if soft skills are valued over hard skills, the organization is already captured by talentless engineers and leaders. There are holdouts in the world, where execution is king, find those places and run away from soft skill fortresses. This is more true than even with LLM-amplified productivity.
> There are holdouts in the world, where execution is king, find those places and run away from soft skill fortresses.
And guess what do you need to execute? Both soft and hard skills. You'll not live long without both of them and this is even more true today.
It's useless estimating the ratio between soft and hard skills without context, sometimes projects fail for one, sometimes for the other.
The big truth is that as the markets get more competitive, the employee pool follows the same trend: it's not 2021 anymore, world has changed, great developers that have both hard and soft skills can be found in the market and it's up to a competent hiring team to find them.
+1 - I think this really needs to be emphasized more. Just like any relevant skills, soft skills are useful. It is great to build strength here.
It is never a sign of health when they become the main thing.
This is a bit confusing. Execution requires both soft and hard skills.
I think you're conflating "soft skills have value" with an org run by bullshitters.
Not conflating, the parent is saying it's correlated.
This feels like a false dichotomy. You can be superior to those conceptual camps by building an array of skills.
This is even obvious to heavily technically minded people, who lament how one kind of engineer would benefit from stronger grasp of other domains. Communication skills, understanding of how to exist within social structures, and all those “soft skills” have the power to multiply the value of the technical skills.
My sense is that the loudest proponents for devaluing soft skills are those who are bad at them and want a moat rather than having to work at them to compete.
> There are holdouts in the world, where execution is king
Could you name a few with salaries at least somewhat near FAANG’s?
Like most of these binary statements, the truth is indeed somewhere in the middle. Software engineers don't require focus on getting beyond acceptable with soft skills. Software engineers who want to move into staff/managements/product/etc. need to focus on them.
In most cases, the hard part is getting a bunch of people to work together on a problem and not have it turn out complete shit.
It's never easy for a bunch of people, each with differing and partially-overlapping conceptualisations of some domain, to coordinate correctly.
The human problems don't really go away. It requires an insane amount of "context" that would overwhelm any current AI.
[flagged]
> The whole corporate world has been overtaken by feminism
Please don't post hyperbole or engage in political/ideological battle on HN. The guidelines make it clear we're trying for something better here. https://news.ycombinator.com/newsguidelines.html
I thought this article was going to be about something else ...
It is really about prompting and writing specs - the "soft" (but really "hard") skill of giving detailed specs to an LLM so it does what you want.
I think the more important, truly soft, skill in the age of AI is going to be communicating with humans and demonstrating your value in communicating both vertically up and down and horizontally within your team. LLMs are becoming quite capable at the "autistic" skill of coding, but they are still horrible communicators, and don't communicate at all unless spoken to. This is where humans are currently, and maybe for a long time, irreplaceable - using our soft skills to interact with other humans and as always translate and refine fuzzy business requirements into the unforgiving language of the machine, whether that is carefully engineered LLM contexts, or machine code.
As far as communication goes, I have to say that Gemini 3.0, great as it is, is starting to grate on me with it's sycophantic style and failure to just respond as requested rather than to blabber on about "next steps" that it is constantly trying to second guess from it's history. You can tell it to focus and just answer the question, but that only lasts for one or two conversational turns.
One of Gemini's most annoying traits is to cheerfully and authoritatively give design advice, then when questioned admit (or rather tell, as if it were it's own insight) that this advice is catastrophically bad and will lead to a bad outcome, and without pause then tell you what you really should do, as if this is going to be any better.
"You're absolutely right! You've just realized the inevitable hard truth that all designers come to! If you do [what I just told you to do], program performance will be terrible! Here is how you avoid that ... (gives more advice pulled out of ass, without any analysis of consequences)"
It's getting old.
It won't help. LLMs are good at soft skills, too. There's a whole "AI girlfriend" industry, and it's quite successful.
Confidently stating incorrect information and unilaterally agreeing with someone until they develop psychosis are not, in fact, desirable soft skills.
LLMs are not good at soft skills, just the girlfriends you can get in this society are even worse.
I consider "understanding what people want when they well you" part of soft skills, and LLMs are good at that.
I've know a few non-developers who use AI to solve the things they need. Nothing huge, it's not anything amazing, but what impressed me is how well the process works for them. They describe what they want in very vague terms with a lot of contradictions and in convoluted stream-of-thought paragraphs. But it mostly works, and LLMs produce something that's very close to what they want, and they get to their desired result with a few iterations.
Speaking of skills:
> girlfriends you can get in this society are even worse
Skill issue.
Also, unrealistic expectations. People are both afraid of doing the hard work to have meaningful relations and filtering out duds and also want the world from another human.
So pretty similar to product owners or project managers in your average enterprise
> the girlfriends you can get in this society are even worse
WTF?
Dehumanizing people into a collective, way to go. Do you expect to assimilate them, Borg style?
I'm just going to sharpen up my hard skills so that I don't have to suck up on my soft skills. If that doesn't work out as I wish, well, since I already have a job, and I'm already 40+, and it looks like my company doesn't go away in a few years and we are so short-handed, I think I'm fine.
Just to clarify that I'm not a jackass in real-life. In fact, I'm perfectly OK with all sorts of soft skills -- after all, my current position requires me to do so. But I just try to maintain a minimum level of soft skills to navigate the shoreline -- not interested to move up anyway.
"I'm already 40+, and it looks like my company doesn't go away in a few years and we are so short-handed" FANG employee for over a decade quit her job, opened a consultancy, and sold back what she was doing to former clients of her company(and their clients). She sold back what she was having to do to make up for this short-handedness, and the incompetence of many of her former colleagues.
She did it at 3-400 times the markup she was being paid while employed :) because they were time critical.
I’m not in FAANG and mine is just a small one which may not afford a lot, but yeah I totally agree it’s a good idea for a FAANG person.
> we won't be able to AI our way into better communication skills
Why not?
I always find these articles funny. There's someone almost triumphantly declaring that AI is able to take over the hard skills tasks from oh so dreaded engineers, but the authors can somehow not imagine that their soft skills - which are often they only ones they have - could be done by AI as well.
DjangoCon has a policy to not use the term "soft skills" and instead classify them as "professional skills" - communication and collaboration and management and leadership.
I think they're 100% right about that. There's nothing easy or soft about what gets classified as "soft skills".
The irony here is that universities are struggling to teach writing skills, due to massive cheating with AI.
I mentor CS students at two local universities. The best students are using gen ai to enhance their learning and understanding (i.e. they use it as a tool instead of a crutch). The worst students are using it in attempt to “level the playing field” and are failing miserably.
It is easy to determine if someone solved a problem using AI because they can’t explain or recreate “their” solution. Detecting cheating in essays is still far more difficult.
You could probably detect essay cheating (AI written) in the exact same way by questioning the student about it - why did they organize the essay in this way, what was their motivation for focusing on X, or expressing something as Y... Of course anyone can concoct an explanation on the fly, but it should be obvious if they are speaking from the experience of having authored it or just coming up with a post-hoc rationalization.
If they had AI write the essay, yet can still explain it as well as if they had written it themselves (ditto for code), then it would tend to indicate that they at least read it and thought about it, which I think should be more acceptable in a learning environment.
> You could probably detect essay cheating (AI written) in the exact same way by questioning the student about it - why did they organize the essay in this way, what was their motivation for focusing on X, or expressing something as Y... Of course anyone can concoct an explanation on the fly, but it should be obvious if they are speaking from the experience of having authored it or just coming up with a post-hoc rationalization.
I wouldn't claim that I am bad at writing (at least in my native language, which is not English) - at least many colleagues say so. But I do insist that when writing I don't think that way. If I were to answer these question, my honest answers would be:
"why did they organize the essay in this way": I just wrote down the thoughts that came to my mind, and then gave them some structure that seemed right.
"what was their motivation for focusing on X": Either "because it felt right" or "I had to write at most x pages, and indeed it would have made sense to focus on more topics, so I focused on this arbitrary thing"
So indeed I would claim that a lot of sensible reasons why things are this way actually are post-hoc rationalizations. :-)
> So indeed I would claim that a lot of sensible reasons why things are this way actually are post-hoc rationalizations.
Perhaps, but still I think that responses to questioning about an essay that the student did actually write will come a lot more quickly and naturally, even if they indicate that not much thought was put into it, than if they realize they are being called out for cheating and and have to make something up on the spot, since they didn't at least read it carefully!
This couldn't ring more true to me - I think one of the consequences of the rapid change in the profession we are seeing is that skills that typically were required only at more senior levels become required further down the stack.
If I was a junior today, I'd be studying business impact, effective communication, project management, skills that were previously something you could get away with under-indexing on until senior+.
I remember a day at the office of a former job; there was one guy, the "chief developer", technically solid, but he was a pure a**** when interacting with others; it was quite known that he was a "difficult person".
One day, I opened the door to another floor and he approached the opened door: I saw him with two things in his hands: the one was a Leitz folder, and in the other hand he had a cup of coffee - so full that the coffee was kept in the cup already only because of the surface tension of the liquid.
I held the door opened, looked at him, a small smile and noded - he didnt show any reaction (not even think of a "thank you" or similar)
You never really could. If you hear of a (very) succesful software engineer with horrid soft skills they’re a 1%er chance wise
I’ve been hearing this since the 90’s.
I feel like it's a myth promoted by engineers with poor soft skills to justify themselves never learning said skills.
How do you learn soft skills? Maybe you have a point there
Watching other people do it better than you, or reading about it and trying things yourself would be two ways I can think of.
So, there is professional skills and then there is "soft skills" which at many places is a euphemism for political theatre. Nearly everyone I've ever met has professional skills; few can stomach "soft skills"
Feels like soft skills are peddled as if developers don't have "enough" and it is a common assumption by nearly everyone that this is the case. I think of it in a similar way: the magnitude of soft skills you put on display is positively correlated to the difficulty of social interactions at that workplace. Navigating all the nuances, implies how complicated and maybe loaded that environment is. Do one "mistake" regarding social skills and you will face "consequences"?
My take:
Businesses have valued "cohesion" over "correctness" for some time (at least the last 10 years of my career) with the thinking that they can always eventually get to a correct solution, but teams that aren't cohesive do not work toward the goal they fight amongst themselves until they tear themselves apart (as a former Python dev I have seen teams that have one or two members fight for MONTHS over which set of linters to use)
I also want to say that the only source of "bugs" is misunderstandings - of what the technology does, what the business wants, or what the customer wants (two thirds of that is "soft skills"). We've created DDD to try and address one third of those potential issues, but we're not there yet.
Do we accuse AI of having poor soft skills when it doesn't do what we want?
I think the problem is knowing how to bridge knowledge gaps. That just comes from experience and there are no shortcuts on either end of the gap.
Empathy does matter a little bit, but to focus so much on it is plain neurotic. Consider how much less friction there is when the interactions can be kept brief. Everyone is already familiar with the various situations and problems that can arise (like on a sports team). That's pure hard skills, not soft skills.
Posts like this are flamebait for the extreme ends of these gaps: stubborn mediocre programmers and arrogant dumb management.
I have always said this: life is other people. Jobs and employment are necessarily a reflection of the fact that we need each other to survive. We do not hunt the meat we consume, we did not deliver ourselves, and the vast majority of us won’t build the bed we die in.
Soft skills were never optional.
I used to work with a brilliant asshole - he had this babyface but would constantly belittle his fellow engineers.
Everyone hated him but the CEO loved him since he thought he was their golden ticket to the promised land.
At some point he went with us to a shooting range for target practice, immediately after he developed a fascination for guns, he never threatened anyone, but one day he buys a Kevlar vest and tells all his fellow devs.
The following Monday was his last day..
Has this ever been something you can ignore? You need to be able to interact with customers, communicate with other team members, mentor junior engineers, etc. I know there is the trope of the abrasive but technically genius engineer but no one wants to work with that person irl.
Unless you're buried deep in an organization, the main value that programmers provide is to help translate the needs of a business into a program that, when compiled, creates a reliable artifact that, when executed, works reliably and is easy to use.
Writing code is just how that happens, sometimes. Soft skills are essential to communication with the users and product managers.
The classic "technically strong but lacking soft skills" unheard story about you through the office after your results.
Thank Open Source and Free Software which commodified hard skills and pushed business to value them as zero.
Counter point - If one person can now do the work of an entire team the level of communication skills required will actually be simplified.
So now instead of needing to manage multiple stakeholders and expectations of 10 different middle managers you'll probably just have a 1:1 with a single person.
A quote from one of my best managers "I don't think your biggest challenges on this project will be technical."
This definitely helped me to have better perspective.
What about those professional software developers still refusing to use AI / LLMs? I know a couple and they're still churning out code completely 100% manually.
Heck, I even know a guy who refuses to use an IDE with Java and the indenting is a mess, but he gets there.
Refusing to use them or trying them and not getting value? Honestly I’ve tried them all and they’re all shit unless you’re doing trivial stuff.
Some of them don’t even do trivial stuff very well.
How do you try them without paying?
calculators doing a perfect job did not end accountants' jobs, it made it faster.
I don’t think that’s as good of an example as you think it is.
“Computer” used to be a job title. It was entirely replaced by … drumroll … electronic computers, i.e. calculators.
Technology doesn’t usually eliminate the need for a job output in general but it can sometimes shift the skills needed wildly.
Not necessarily faster, but more easy for sure. There's plenty of stories of proficient abacus using accountants being faster than those using calculators. Those days are gone now though because a calculator is just so much easier to pick up.
Your sort of paying them to understand the tax code that changes year to year tho
Me! me! I have people skills :)
https://youtu.be/hNuu9CpdjIo?si=FkbWtFMKunwjxcen
(Office Space)
This has never been the case for those of us doing consulting, soft skills are a must have requirement when dealing with customers on regular basis.
Many of us became software engineers precisely to neglect our soft skills (or lack thereof)
What about: tech managers can no longer hide their poor or nonexistent management skills.
The claim in the article that AI is good at writing code, is that claude code is written by claude code.
Counter-point, a three person dev team displaces a multi million revenue company.
Why have a slow human CEO when machines are faster..
Software 'engineers' are going to have learn the hard skills that they have gotten by without thus far. The ones who were never engineers in the first place will have to learn 'soft skills' because they are incapable. I believe @ Tsoding put it best: The only thing AI will do, in so far as coding goes, is to remove a lot of people who should never have been in it in the first place.
I think this is kinda sad. I always thought coding was so beautiful for creating a (good paying) job for socially awkward people on the spectrum who pre-coding was considered dorks and went into idk what but probably some unsatisfying job. It seems like we're heading back to that which makes me sad and worried about the highly functioning autistic population.
On the other hand, the increase in remote roles has made this a bit easier for some.
I am sorry but is being employed a job or a daycare?
Not only this is extremely patronizing towards all people on spectrum, but at the same time extremely hurtful statement for people who are treating employment as a job(ie - most of population).
And what are you going to say to people who are stuck in low-end jobs?
I'm on the spectrum to be clear
[flagged]
Please don't cross into personal attack.
It wasn't a directed statement but a general one.
"Conflict is essential to human life, whether between different aspects of oneself, between oneself and the environment, between different individuals or between different groups."
The obvious default interpretation of your comment is that the other person is using something as an excuse. If you say you did not intend it as a personal putdown, I believe you, but the rest of us don't have direct access to your intent, so you'd need to include enough information in your comments to disambiguate it.
More information here in case helpful: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
As for Marion Milner's classic paragraph, I'm delighted that you found it worthwhile enough to quote! But you have to read the entire paragraph to understand it, and you can't leave out the word "toleration". That's the most important word there, both in the text and in the title.
Sorry but did we read the same comment? It's not patronising. The people who are stuck in low end jobs were not in the scope of this comment (there are also people in war zones or very sick, also out of scope). And how did you manage to find this extremely hurtful to any group...?
Can you elaborate on this?
What are some examples of skills you think are now essential, that prior have been taken for granted or obviated in some way?
My rule of thumb is that if you’re not measuring anything you’re not engineering. It’s not the whole picture, but to me the engineering part sometimes means being able to explain (and even quantify) why one solution is better than another.
I've found coding assistants to be a huge boon for this. All of the thorough analysis that previously would've taken a bunch of tedious extra thought work to do for marginal benefit (with a well-calibrated intuition) becomes 5 seconds of thought to the the computer to build a harness and then letting it chew on that for 15 minutes. It now also takes me one command and less than a minute to get pprof captures from all the production services my team owns (thanks to some scripts I had it write), which is just something I never would've bothered to automate otherwise, so we never really looked much at it. Codex is also very good at analyzing the results, and finding easy wins vs. knowing what would be invasive to improve, and then just doing it.
Thinking of seeing if I can get mutation testing set up next, and expanding our use of fuzzing. All of these techniques that I know about but haven't had the time to do are suddenly more feasible to invest into.
Not the original author, but I would guess that understanding the domain problem and interpreting it correctly in a software solution (not code, but a product with workflows, UX, etc.), which in turn requires ability to listen and understand and ask right questions on one hand (what a user wants to achieve), and a good understanding of the technical limitations as well as human habits on the other hand (what is possible and makes sense). One can argue that AI lacks what we'd call intuition and interpersonal qualities which are still necessary, as before AI.
Read further into the comment.
Your $300k+ TC job is going away. The only way you'll make the same take home is if you provide more value.
You can be a robotic IC, but you won't be any better than a beginner with Claude Code. You have to level up your communication and organizational value to stay at the top.
Everyone has to wear the cloth of a senior engineer now to simply stay in place. If you can't write well, communicate well, plan and organize, you're not providing more value than a Claude-enhanced junior.
> If you can't write well, communicate well, plan and organize,
Why not ask the LLM to write for you? Same for planning, organization and written communication.
Seems like robotic ICs can "robotize" most of the work stack.
"If you can't write well, communicate well, plan and organize" Straw man. Pretty sure, this is the dilbert equivalent of "I can problem solve". If you are an engineer, we are making boatloads being brought in to fix the incompetence of this level of thinking. INFOSEC alone is having a field day.
Would you like to buy a bridge? Coded by Claude. One previous owner. An owner who used said bridge to go to church once a week, and vibe code in Starbucks afterwoods.
How about the skill of saving hard disk space, memory, and CPU cycles, for a start? The skill of designing simple, reliable, fast, and efficient things, instead of giant complex bloated unreliable pieces of shit? How about a simple, usable web page that doesn't drag my machine to a crawl, despite its supercomputer-like ability to process billions of instructions per second and hold billions of bytes of data in working memory?
Remember when BIOS computers used to boot in seconds, reliably? When chat clients didn't require an embedded copy of Chromium? When appliances and automobiles didn't fall apart in 6 months, costing thousands to "repair" or just needing to be thrown away and bought again?
Remember when there used to be these things called "machine shops" and "Radio Shacks" and "parts stores" that people who built things frequented? Now most people have to call AAA if they get a flat tire. Changing their own oil is out of the question. "Eww, dirty oil, on my clean fingernails?" Many couldn't tell you which end is which on a screwdriver if their life depended on it.
I'd say these concepts are pretty essential, especially for any nation entertaining delusions of waging Total War against other big and powerful nations. Wasteful and foolish nations lose wars.
Beyond engineering itself, strictly computer engineering? How many coders have no idea what goes on behind an IDE. Have not even the slightest notion how a computer works. Who thinks building a computer means watching a Youtube video and buying ready made parts, putting them together, and then think they should be employed by NASA.
To begin: Math, Linux, Devops, C, and Assembly. Not a youtube video. Not arithmetic. Learn to the point that you could be employed by any of the above as a senior. And don't fear failure. Keep doing it until you understand it.
I agree with your original post that the need for hard skills will persist, but I see it in the other direction: software engineers are going to have to get better at thinking in larger abstractions, not deeper understanding of the stack. Those who can only solve problems locally and repeat the patterns they've seen before rather than create new patterns from building blocks are the ones who are going to struggle.
"software engineers are going to have to get better at thinking in larger abstractions" ........Math was first on my list. I don't know how else to say that.
Computer science is indistinguishable from sufficiently advanced maths.
The AI can already do that part.
The abstraction that matters going forward, is understanding why the abstraction chosen by the AI does or doesn't match the one needed by the customer's "big picture".
The AI is a bit too self-congratulatory in that regard, even if it can sometimes spot its own mistakes.
A lot of studying math is just learning jargon and applications for what are actually pretty straightforward concepts, which lets you better communicate with the computer. You get higher bandwidth communication and better ability to know all of the nuances in things it might propose. You can propose things and understand when it replies with nuances you missed.
Like intro differential geometry is basically a deep dive into what one actually does when reading a paper map. Something everyone (over 30?) is familiar with. But it turns out there's plenty to fill a graduate level tome on that topic.
Linear algebra is basically studying easy problems: y=ax. Plenty to write about how to make your problem (or at least parts of it) fit that mould.
I suspect and think I've seen others say that you get better outputs from LLMs when using jargon. Essentialy, its pattern matching tells it to say what an expert would say when using the terminology experts use.
> I don't know how else to say that.
Yep, exactly. The failure to realize that you mean different things when talking about "larger abstractions" is exactly the kind of miscommunication that software people will need to navigate better in the future.
If you need to have that explained to you, you are the problem.
Ah, I think “Math” as a single word on its means many different things to many different people, I didn’t interpret in quite the same way. But I see what you mean.
I’m not sure that my colleagues who I think of as “good at math” and “good at thinking in larger abstractions” are necessarily the same ones, but there’s definitely a lot of overlap.
[dead]
I hope this too but it's not a given, IMO. Previously people without technical chops failed quickly by being unable to deliver working code, now they can deliver mediocre code with the damage only becoming clear years later. It breaks the "can deliver code --> good technical ability" proxy and even after the initial damage wave, it's unclear if we will find a better proxy.
I think AI coding agents will quickly pick all the low hanging fruits and plateau.
Everything can be vibed will be vibed until everyone hits a wall, where no docs to form corpus nor instructions for prompts exist. There are problems that are yet to be named, but how can you name things when humans aren't the one to experience patterns of a thought process?
And naming things is one of the only two hard things in computer science
In education, I view them as life skills, durable skills.
Poppycock. If a software engineer truly solved a hard problem they they would be a billionaire overnight.
Now that everyone has a assistant that can work 24/7, talk to customers, get requirements There is no excuse for neglecting hard skills.
What this article calls "soft skills" is largely just experience which is often wrong in tech.
In a team environment, half of the job is communication.
That LLMs do a better job if you know what you are asking for is old news.
But to be honest, I usually don't care to write properly into an LLM prompt. An LLM will ignore grammar and form and just extract the essence. If I make an actual mistake I will notice quickly and fix it. If I'd send slack messages like that to an peer, they'd either mock me or simply think I am dumb. We also know the stories about people that use LLMs for any communication or anything they write. Probably for the exact reason that being lazy with writing is acceptable now. My call is that writing skill will decline, not improve. This could probably be the case for anything that people use LLMs as a proxy for.
Broadly agree, but one point I think is (sadly) relevant:
> That LLMs do a better job if you know what you are asking for is old news.
Even a decade after Word Lens had demonstrated augmented reality live translation through a smartphone camera, I was amazing people by showing them the same feature in Google Translate.
Similar anecdotes about Shakuntala Devi, even in 2018 I was seeing claims about her mental arithmetic beating a supercomputer (claims that ignored that this happened in 1977 and the computer was already obsolete at the time), even though my mid-2013 MacBook Air could not only beat her by a factor of 150 million, it could also train an AI to read handwritten numbers from scratch in 0.225 seconds, and then perform inference (read numbers) at just over 6,629 digits per second*.
You say "old news", I say this discussion will be on repeat even in the early 2030s. And possibly even the 2060s.
* Uses an old version of python, you'll need to fix it up accordingly: https://benwheatley.github.io/blog/2018/03/16-10.44.18.html
"I deal with the goddamn customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!"
Watch them
when could we?
As usual - the advice is essenially rats from a sinking ship all the way. “You all need to do this narrow thing to survive now”.
2016 to truckers: “Learn to code LOL”
2026 to coders: “Learn soft skills”
https://news.ycombinator.com/item?id=46436872
Look, I personally am taking full advantage of exactly the skills described. I was the one who posted the above thing on HN showing how I am 20-50x more productive now, complete with a 4 hour speedrun video. I usually try not to just talk and point out current problems, but build solutions AND show (github, youtube) with specific details so you can watch it and apply it for yourself. But I am telling you:
1) most people will not adapt, so we will need UBI for those who don’t
2) eventually even those who adapt will be replaced too, so we will need UBI for everybody
It is after all a thin layer that remains. I remember Kasparov proudly talked about how “centaurs” (human + machine working together) in chess were better than machines alone… until they weren’t, and human in the loop became a liability.
But the problem is more widespread in the last 70 years. Just look around. Industry always tells the individual they can do some individual action downstream to clean up the mess they create upstream, and it is leading the entire planet into ruin:
https://magarshak.com/blog/government-and-industry-distract-...
In fact, the human population in modern environments has been living large on an ecological credit card and the bill is coming due for our children, because all the “individual responsibility” stuff — where you can somehow diet, exercise and recycle your way out of things corporations do upstream — is all a gient lie and always has been. So the negative externalities just build up until the next generation won’t be able to ignore them anymore, but it could be too late. Whether that’als day zero for water in cities, or factory farms for meat with antiobiotic resistance, or fossil fuels and greenhouse gases to subsidize the car industry, or ubiqitous microplastic plastic pollution around thr world (yes, personal plastic recycling was just another such scam designed to keep you docile and not organize to force corporations to switch to biodegradeable materials.) The “anthoposcene” is seeing a decline in insects and all species of animal except humans and farm animals. Coral reefs are bleached, kelp forests and rainforests are decimated, and governments work with industry to eg allow Patagonian forests to be burned for new developments and then smokey the bear says “only YOU can prevent forest fires”. Think about it.
I may have misread your comment, but I don't think soft skills are a 'narrow thing' at all. Effective communication, building trust, bringing people along with you - these are fundamental to being an effective human, not some niche pivot.
"Effective communication, building trust, bringing people along with you" That's a David Brent powerpoint presentation.
Fair. I'll retire 'bringing people along with you' before it ends up on a motivational poster with a stock photo of a rowing team.
Though you're right that there's no I in team. There is one in AI though, which probably tells us something.
Not fair on you. I did not mean to have a dig. I get where you are coming from, and should have elaborated. I've worked with those one or two engineers who were rude by default. Who had an extraordinary knack of vaguely describing the problem set, and then having a full on meltdown, always in front of other people, when the solutions did not match the problem in their head.*
*Goldman Sachs(sorry for invoking that name here) did a report on their high turnover, and the above framing was why many quit.
Look, if we zoom in, then "learning to code" is also quite a broad range of skills that someone needs to master before they can meaningfully carve out a career in a competitive marketplace.
The point is that if you zoom out, it's just a thin slice that can be automated by machines. People keep saying "I'll tell you in my experience, no UAV will ever trump a pilot's instinct, his insight, the ability to look into a situation beyond the obvious and discern the outcome, or a pilot's judgment"... https://www.youtube.com/watch?v=ZygApeuBZdk
But as you can see, they're all wrong. By narrow here I meant a thin layer that thinks it's indispensable as they remove all the other layers. Until the system comes for this layer too.
[dead]
[dead]
[dead]