> developing software is not about writing code but communicating with people.

You often hear this from people who claim it's a revelation. I would say it's a bit overstating the case. Developing software is definitely still about writing code; you can't do it otherwise. But being able to communicate with people well makes your code maybe 100x more useful.

You usually hear it in the context of someone who's had a long enough career to forget how hard "just writing code" is when you're a noob ;)

I still find coding a mentally exhausting task and maybe even more now that I am getting older. I find it harder to concentrate and I am more easily distracted. It often takes me time to get in the right mood to code. I guess my memory skills are probably also getting worse.

I suffer a lot from procrastination and I think one of the reasons is that I find it still a hard to write code. Which most of the time is not coding but reading and trying to understand code. And thinking about all the alternative ways to solve a problem. I often find myself struggling to commit my changes doubting whether my changes are good.

I also still find myself looking up the order of the parameters of standard C library functions that I have used over 30 years. I am dyslectic and struggle to remember facts. I also still find myself making stupid Boolean logic coding errors and make one-off mistakes. I still find myself stepping through loops with the debugger just to see if I did not make a stupid mistake.

It still often takes me more time to solve an issue than I had thought it would take me. There are days when I leave the office feeling that I have accomplished nothing because I have not committed any working code.

> I still find coding a mentally exhausting task and maybe even more now that I am getting older

If it helps, we're at the dawn of AI assisted development. That will take a lot of the cognitive burden, allowing us to focus on the "what" more than the "how"

I doubt it, the design of the code is much more important and that hasn't been solved by AI yet.

Reducing cognative load is still entirely helpful

I predict AI assisted archicture design will come soon

Also, software is ultimately written by humans, for humans. A very overlooked thing in many circles. It seems so simple, but folks off in the deeply technical universe of engineering should remember it.

In short, writing code is communicating with people! Often, the listener is future you.

Maybe this is why infrastructure as code feels so obtuse to me, there isn't many opportunities to explain yourself in the code and so most of the communication is done in the docs.

Perhaps there is an opportunity for a more natural language approach to infrastructure as code, but I am not sure how far you can take that since the reality is still a lot of arbitrary delcarations.

Better answer, thanks to Hume:

“It is very difficult to talk of the operations of the mind with perfect propriety and exactness; because common language has seldom made any very nice distinctions among them, but has generally call’d by the same term all such as nearly resemble each other. And as this is a source almost inevitable of obscurity and confusion in the author; so it may frequently give rise to doubts and objections in the reader, which otherwise he wou’d never have dream’d of.”

––A Treatise of Human Nature, by David Hume, pg. 76

I doubt a "natural language" approach would work; the natural language for the domain has to be very precise. Just like the "natural language" for software has to be similar to either C or LISP. You are giving precise technical instructions which will be run by a machine.

"Hey, just spin up a server with enough capacity, alright?" Yes, sure. Please define capacity.

Those definitions are usually in the docs, which is why the code makes so many references to the docs.

Many infra-as-code systems allow you to add comments to the docs, which (if done well) can really help.

And infra-as-code is much superior to infra-as-let's-click-on-the-gui-until-it-works' Yes, it is hard to read (I know, I do it for a living). But at least you have a document which describes the infra!

I think a lot of the infrastructure-as-code motivation comes from struggling with documentation. At least it provides a unambiguous source of truth which is going to be correct. Understanding it and it’s quirks can be tedious but it’s better than port scanning and guessing hostnames to figure out what infrastructure exists.

> there isn't many opportunities to explain yourself in the code

Can't you include comments in your code?

I've never seen it done in infrastructure as code files, but I probably would if I were writing it. Or I'd at least include some explanation in the readme.

I do it all the time in YAML config and HCL, especially stuff which is not obvious. That's the main benefit of YAML over JSON, to be able to communicate to human readers through comments.

Some stuff, like which CIDRs are necessary for which connection, are only obvious in the moment you write it, not 1 or 2 years later or for another person who joins your project next week.

All the more reason not to make it any more complicated than necessary (even if it's in the expense of some code elegance). Not just for other people, but also for the future you, coming to maintain this. Going back to your code after three years, and someone else approaching the code for the first time are not that much different.

Also this is why I love automation, like scripts for everything. It's like a memo to your future self, with the side benefit of sparing you menial work. I keep even single one liner commands as their own shell scripts with a descriptive name.

Try to read and understand everything your write. If it doesn't click immediately or needs too much outside context or "working memory", make it simpler. Failing that, elaborate in comments.

Sometimes it has to be complicated. Complication in one area (usually infrastructure code) enables simplicity in other areas (usually application code). An OS memory manager deals with the complexity of page management, so as to present the nice abstraction of an orderly address space to applications. An SQL query optimiser is complex in order to allow dumb and "understandable" queries from applications.

It isn’t just about code. It’s about the software’s user. Humans and the programming is one part. But the software is for people. The problems being solved are for people. It is humans all the way down. In this way I view software as a very humanistic domain. That is why the theme of communication angle resonates with me so much. Agile is misused a lot but for goodness sake, talk to your users. Even if your user is just you.

This is exactly the thinking I see people trapped in and was pointing out. Focused on solving the engineering problems, not the humans that come before and after the problem (both end users and developers). We know there are hard things in engineering and problem solving ain’t easy. I think in an absolute sense you are right, but in a practical sense, it is more than a desirable side effect. Code once written and solving a problem can live on for a very ling time.

Yeah this is it -

Unconscious incompetent - you don’t even know how much you don’t know

Consciously incompetent - you have a rough idea of how much you still have to learn

Consciously competent - with willpower and effort you are competent at your job

Unconsciously competent - you are competent at writing code without effort or even thinking about it

Senior engineers (good ones) become unconsciously competent, and forget how difficult it is to write good code - because it’s now automatic!

The hardest thing these days is trying to think of names. Taking a concept and reducing it to one or two words that explain what it does, because to have a name that doesn't quite describe it, just, feels wrong.

I spend more time on thesaurus and dictionary sites than I did/do on places like planetsourcecode and stackoverflow.

There’s definitely a little truth to that, but the good ones are also more conscious over time of assumptions and dependencies and how to think about code and what to do and what not to do - and they will talk to you about it at length if you ask them. Half the problem is the young ones frequently don’t ask or listen. I was there once, young and full of pride and energy and not listening, and these days watch younger programmers nod their heads and then proceed to ignore any advice, even answers to their own questions. I don’t see unconscious competence causing many problems, aside from occasional impatience when working with someone who’s too green (or occasionally a bit stubborn about learning certain things.) Also the best older programmers will tell you to stop trying to be tricky & clever, they advocate learning how to write straightforward boring code, and it still takes programming for a couple decades yourself for that advice to sink in. Lawrence Kesteloot wrote a great piece about why this happens (also find other great programming advice sprinkled around his site): https://www.teamten.com/lawrence/writings/norris-numbers.htm...

The thing I see even more with seasoned programmers over time is conscious incompetence. We all start as unconscious incompetence, we all have no idea how much there is to learn, and people tend to assume that you can learn most of what is known in a career or lifetime. Then you learn a lot and grow older, and you find out that the visible bounds of what you don’t know grows much, much faster than the bounds of what you do know. The more you learn and the more you practice, the more you discover how very little you know. (BTW I first heard this from a retiring geophysicist, and have just noticed that it fits every great programmer I’ve worked with, as well as my own experience.)

I recommend any senior engineer look for opportunities to mentor, it keeps your awareness sharp and you may even encounter some unique perspectives that challenge your current model.

I have been surprised/hurt at the lack of these opportunities. I make myself very available to interns, sometimes, we stumble on great discussions, but they insist on doing it all on their own. People closer to my cohort often reach out for mentoring. I don’t know if it’s an ageism thing, or I’m just an asshole and I can’t see it, or what. I’ve decided to quit trying so hard to “give to the following generation”. I’m glad to share, but it’s not worth my own sense of “not mattering anymore.”

Other industries definitely have it better in regards to mentorship and passing the torch on so to speak. I've not once seen an apprenticeship style program for software developers, even though it's the perfect industry for it. There's not really a graceful ageing out process for the industry either. It seems the only pathways are moving up into management. At that point, often your software engineering knowledge gets put to the side, and new developers don't get access to it.

I've worked a few times with people I thought were just leadership jockeys their whole career, and then it turns out they were actually software developers for 20 years prior to that. They had all pretty much washed their hands of software, and their attitude was "Well, what would I know now. Not really my scene anymore.". That's a lot of experience thrown out the window.

Have a stroke. Then have to relearn programming again.

Bloody shocking just how many layers of concepts, frame works, Etc there is.

Or step away from JavaScript world for a couple of years. About the same sensation.

Or we realized that pretty code, or whatever is the current fad in how to write code, doesn't matter if it isn't actually solving the problem that the end users care about.

A problem that one will only properly learn about by communicating with other humans, understanding their expectations, skillset and most relevant, what their business domain is all about.

I really worry how out of touch I am on that front. It pains me but I offer such limited value to jrs as a result :(

All tech is magic until you pull the curtain...

I think our industry underemphasises soft skills because it tends to be a bigger weakness than usual in the general populace of practitioners, and people tend to minimize & avoid what they are weak at. We treat it as such to counteract the discounting tendency.

It was even more of the case in the first 10-20 years this person has been working in programming. Nowadays I've noticed people are getting more socially savvy in software in general, as the prestige of the field develops and more people enter who do it more as a career vs. something of a pure passion.

20/30 years ago you weren't making big bucks and being a programmer (it wasn't called software engineer back then) was associated with basically being on the spectrum, not showering and being a nerd who was low on the socio-sexual status hierarchy. You became a programmer because you liked computers. If you wanted money & prestige you did medicine, law or wall st.

I'm not so sure that's changed much. Aside from your odd finance unicorn or BigCo (Uber/Twitter), every VC startup's Engg department has at least 50% of people being on the spectrum. Maybe they dress better now and wear a nicer haircut, but autism is alive and well in the tech world, and I personally hope it stays.

For me, writing code is mostly about communicating with people and less about communicating with the computer. I try to structure my code in a way that my future self or any other colleague can understand what's going on. Of course the computer also has to understand what it needs to do, but programming languages have evolved further away from bare metal concepts to a more human friendly language.

Edit: to clarify, proper variable names, data structures that map onto the real world, function composition that minimizes future faults from developers, ... .

This is also why the most useful programs for a given domain are written by people who are from that domain and wrote the program for themselves. They may not be the best quality programs, as the person writing is typically does programming as a side item, but they almost defiantly cover the use cases they had in mind.

Learning to write code is “easy”. Learning how to communicate with people is hard.

The amount of broken code that exists in production seems to disagree with that first statement.

Why though? Most broken code I saw is due to not getting the requirements and edge cases right. Getting to know those is communkcation and wanting to know them is experience.

I have seen lots of code where the author did not understand DB transactions (at all!), without idempotency even if it was critical, test suites that call getters and setters for coverage stats but without any actual assertions; those kind of things.

I doubt anything someone writes here could change your mind. There are just so many things: knowing when to add tests, checking multiple places when fixing a bug, avoiding mutation, knowing when to do a rewrite, avoiding complexity… these are all things that are just knowing how to code that are difficult.

It was a valid question, no need to try to project hard-headedness. You probably won’t change any minds that way. So how do people come to know these things? Can you learn them in a vacuum sitting by yourself without communicating with anyone? Knowing when and how to add tests is a company-specific task, it’s different every place you’ll work, someone has to tell you. What if the primary reason code breaks really is because people weren’t communicating over the process, requirements, dependencies or design enough? All the things you mentioned are things a mentor and code reviews and documentation are meant to address, i.e., communication.

I think all these things can be learned even as a company of one, without ever speaking to your customers. It will take longer and the lessons will be harder to learn, but you will get all of it because it’s just problems with the programmer himself/herself, not problems with other people.

We can “what if” all day.. and yes, mentoring can improve these things but that can be said about lots of things that aren’t caused by poor communication. It just really sounds like you need the answer to be poor communication which is why I reacted that way.

> It just really sounds like you need the answer to be poor communication which is why I reacted that way.

Please. This is out of order. You didn’t react to me originally, and nobody here demanded that the answer is communication. You’re the only one insisting. You were asked a simple question, and the (as yet unanswered) question to you was why you attribute problems in production to coding and not communication, since there are plenty of examples of miscommunication leading to production bugs. This ad-hominem nonsense is you just making assumptions.

I can easily agree that you’re sometimes right, that there are some bugs caused by lack of knowledge or skill or schooling, and that there are bugs caused by individuals and that communication plays little to no role. I can also safely say, after a career that spans about the same length as the article author’s, and after doing decades of both programming and management, that the majority of problems that matter in production and the biggest and worst problems I’ve seen were caused by poor communication. One example would be that I’ve twice watched engineering departments decide to rewrite a large codebase from scratch, and it turned into a many year effort costing many millions of dollars, with thousands of production bugs and issues all resulting from the decision that wasn’t well planned. There are of course also bugs that are both, caused by individual knowledge or skill, but could have been saved with more oversight.

Feel free to share some concrete examples if you have some that you feel demonstrate production issues are cause more often by pure code and are not miscommunication. I’ve seen some and I have no doubt there are some. I’m open to hearing your answer and examples. Keep in mind this thread so far from my perspective is text-book miscommunication; the claim that production bugs means code is the cause and communication is not, is so broad and so vague and so ill-defined that of course I have no idea what you really mean. Feel free to elaborate and illustrate your point more clearly.

> I’ve twice watched engineering departments decide to rewrite a large codebase from scratch

This is the problem, not that they communicated about it wrong. If your rewrite fails, it's because you either didn't know what you were getting into (scoping issues, happens with a 1-person team too), didn't have enough follow through (again, not unique to teams), or didn't have a gradual transition plan to the new codebase and thus couldn't devote enough bandwidth to it while retaining customers. The failure of these are not related to communication, they're just execution problems. An executive somewhere failed at these companies, not a team.

> The failure of these are not related to communication, they're just execution problems. An executive somewhere failed at these companies, not a team.

Hard disagree, this is full of assumption. The teams were complicit in failing to plan well enough. I was there. Expecting an executive to handle this, or placing the blame, sounds like a very bad expectation. Execs can’t plan something like this on their own, they rely on the team to even know what needs rewriting and how to do it and how long it’ll take.

(You still haven’t answered the question.)

Executives are there to take the blame; that's their whole job. If a team can't do the project an executive decided they were going to do, it's the exec's fault for deciding that's what they should try to do. This is why executives are paid stock/bonuses (because their pay should depend on the company's performance) and it's also why execs are sometimes fired through no fault of their own.

Teams are supposed to be complicit; that's why the company hired execs. If you want a company that has no hierarchy, you can always just not hire any executives. "Execs can’t plan something like this on their own" – well yeah, execs can't do anything substantial on their own. If they did, they would cease to be execs.

By question, I'll assume you mean your challenge to provide examples. Well, let's start with the CVEs. How many thousands of those are caused by poor hygiene in the form of buffer overflows? Then there are the crashes that aren't security bugs, like NullPointerExceptions. Actually, the most common security issue is misconfiguration, and there are a few examples here: https://www.insightsforprofessionals.com/it/leadership/famou.... Now, you can probably explain this away by saying any kind of organizational incompetence is a sign of poor communication. You can probably even argue with some validity that poor hygiene is also a result of poor communication, but this is why I am not really here to change minds.

Ok, fair. My understanding of "coding" is much narrower then, I sort those skills more under "sw engineering". But that is really just taste.

Idk, I think mutation can be pretty easily classified as a major source of errors in software. Avoiding it is as fundamental IMO as avoiding writing code that just behaves randomly depending on a call to a PRNG, even though many people don’t know this.

I think of SW engineering as taking some process that’s inherently broken and making it work more often than not. Coding seems more like doing the thing correctly in the first place.

Still you do have some requirements. Many legacy systems are 'as-is'. Just more or less working source code with huge label 'don't touch it'.

True. Question is, what makes you succeed in that situation? Try to elicit why it became what it is or just run? ;)

Understanding that you don't really need to understand it all and you need to understand only part of them. If you do try otherwise, you run into overhours :-)

Most popular technique to 'just do the thing' is using 'if my case do #1, else do #2'. Mostly because nobody really understand the business logic. Many reasons, no real one single document with spec, only wikipedia called confluence where you have half truths, barely truths and contradicting each other statements.

In such situation you almost never will understand the logic because there are even no use cases and thus all you can get are regression tests (because there are no use cases list). It gets accumulated over years, many externals / consultants with half-life time 1 year and so continues - chaos in specs (sometimes even transfering from one tool to another one with losing info) and big rotation in companies too dependent on externals.

So instead doing simple if-else, it's better to use wrapper / decorator or even better proxy of chain if more complicated.

It all depends and this textbox is too short to explain the fun facts :-)

The frequency of both skills in the general population would suggest otherwise.

Most people can't communicate effectively. They can write words and make sounds, but the amount of accurate information being transferred is minimal.

Programmers gets all the shit when others can't communicate, since it isn't until you actually try to write it down into a program that all the missing pieces people failed to communicate upstream start to show up. Programmers jobs wouldn't be hard if other people actually knew how to communicate properly.

Rubber ducking isn't just for code. Plenty of ideas seem good until they become words.

Something I've seen many experienced programmers say is that one of the most important part of the job is to be able to quickly and accurately get requirements and feedback from the customer. Maybe studying interviewing techniques would be a good idea?

Programming is still hard when you’re a lone wolf operation. How many one-person startups have achieved unicorn status?

Soft skills are actually highly overrated.

The 10x developer is not a myth, it really exists.

What's better, someone who can write as much code as 10 people, or someone who can manage 10 people? Clearly the former.

Even better than both those is someone who can teach the team to be 10x better.

You can't teach that. The common trait of all 10x performers is that they're all self-taught.

Usefulness is one thing, communicating also reduces the number of breakages. There are multiple domains in a single software, and you can't possibly track all of them. Just ask people around, and they'll happily say some words on it.

> The longer I am a software engineer the longer I begin to understand that the soft skills are much more important than all the technical skills

believe it or not,this is not a revelation.

In our field survival bias is very strong and it's easy to draw conclusions from "these are the books that successful CEO read"

I have been programming since 35 years ago and professionally for 26 years, soft skills come up a lot when talking with people with a background similar to mine.

I have worked on the technical skills more than the soft skills at young age and once I've reached competence I realized that improving soft skills could be of some help, given I was confident enough with the core business of my job.

The reality is IMO that a lot of people lack both the competence and the soft skills, but those with the soft skills, being more likeable, are more easily remembered, also because they usually are able to understand on their own if they aren't proficient enough for the job and leave on good terms.

But you need those technical skills if you wanna climb up the ladder, even a little bit, because the more you learn, the more you understand how much you don't know and how much things are intertwined with each other and that there's no wall between a set of skills and another. Sometimes philosophy can help solve a software problem or applying rigorous logic can help with social issues.

The goal when developing software is to solve problems for people, so yes, being good at communicating with people is key. (You also have to know how to develop software, of course, but we usually take that as a given, since we're talking about software development, after all :) )

I would also say, that it's a special kind of communication. At least the part when someone talks to the users/clients/stakeholders. You have to be able to understand them and help them tell you what they need to tell, but what most of the time they wouldn't be able to tell by themselves. Because they don't have the analytical skills and, of course, also don't know what you need to know because they don't know the internals of the software being worked on. Besides this, it's also a bit of educating them about the software development process.

You can say that about almost any job but at the end of the day shit needs to get done right. Also, your specific role matters a lot when it comes to any skills including soft skills required from you.

100% - you also have the other group ( at least in my company ) that basically does not care about the user. That is a real problem, but hopefully, they see the light someday.

Having every engineering care about the user is inefficient. I don’t care about users, I care about inputs and outputs. By the time new stories reach me, the user should be entirely abstracted out.

It is more accurate to say every software engineer should care about interfaces. Not user interfaces, just interfaces. Code you write will be consumed by something or someone. That is who you care about, the end user is not always something within your horizon.

I work deep in the backend, the consumers of my work are other machines or developers. I don’t give a damn about the people at the very end clicking on pixels. My only interaction with them is when I look at their PII data in the database.

So you do care about your users. They are just not the "end" users, but I don't believe that you disagree with the parent post.

Yes, in a way we agree.

> The longer I am a software engineer, the more I understand that developing software is not about writing code but communicating with people.

I have experienced the same dawning of understanding. But I don't think it's because of how long I've been a SE; it's because the work has changed. Spotty kids just out of school pick up quickly that soft skills are important.

Writing code is the foundational layer. When I graduated, my soft skills were better than the average computer science grad. It helped me to get out gnarly situations, but the truth of the matter was, my code sucked and without mentorship, it would continue to suck.

You sound like you may have been a BOFH?

Or not?

I like you

Thanks for liking me. One thing that motivates me when developing software is helping other people. That is why I am quite happy with my current job at Bond3D.com where I contribute to a dedicated slicer in close cooperation with it users, my colleagues as Process development and Application. An important part of my work is understanding their problems and thinking about ways to solve them in cooperation with my other colleagues at software development.

WOW

Seriously, I need to speak with you.

How contact?

I am in love with what you are doing, and have a very specific thing I want to build with you.

yep. it’s sad that the interview process is so broken

But by outright saying the interview process is broken one sorta kinda fails the soft skill test, no?

not really? i feel like i'm misinterpreting your response, because it seems obvious to me.

the interview process (the standard one we are talking about by inference, ie DSA LC type interviews where the question isn't representative of OTJ actual skill required, or even a baseline for it, and where the interviewer themself are likely to fail if given a random selection) where, rather than interview for soft skills at all, the focus is on rather arcane "can you cram for an exam" knowledge.

so i'm not following how saying so, is failing any test of soft skills?

Complex interview questions do test technical know how but they also test for an emotional response. If one poses frustrated, defeated, angered, irritated, confrontational, arrogant, or even defiant, the interviewer will end the interview early. The problems are hard, but being able to walk through your thought process - even with feigned confidence - will make you pass the test. Yes, actually solving the problem will put the final nail in the future proverbial 9-5 coffin, but don't let emotion get the best of you. I agree the process is broken, but I'll game it to the end

> also test for an emotional response

depends on your definition of "test". i've yet to meet a trained interviewer, myself included. i've been doing this for ages, and in my own mind i do think i am better than average at interviews and assessments. (without a useful rubric to judge against, take that with a grain of salt.)

if i am to judge by only "vocal minority", ie negative feedback, services like triplebyte and Karat are the same. the interviewers are poorly trained. i would never do that kind of interview so i don't have firsthand knowledge in those cases.

emotional response to a problem beyond your capability (kobyashi maru) isn't what the interviewer is going for. i agree, there is a component. that isn't the same as actually evaluating soft skills.

to bring it back home, i remain unenlightened how my first comment demonstrates a failure of soft skills! thank you for the discussion.

Sometimes I wonder if soft skills are filtered out intentionally so as not to shake up the upper echelons of a company.

I won't say they are doing it maliciously but rather most interviews are for finding good workers.

Higher leadership positions rarely rely on interviews and those that have them tend to use them as a formality.

> Higher leadership positions rarely rely on interviews and those that have them tend to use them as a formality.

How high are you talking about? My employer definitely has real interviews for 7-figure total comp positions.

No, many interview loops have sections basically about 'how well do you work well with others / not a jerk'. Someone with social skills, leadership skills and software skills is definitely valued.