Software should be about the code, but not for every person on every project for all parts of that project.
It's great to "wake up" and realize that code doesn't have the intrinsic value you might have assumed, but you can also take that knowledge and go right back to writing beautiful code where it best serves the bigger mission.
Now, that is a letter to new developer that I wish I had read when I was a new developer:
Dear new developer,
Be careful when reading blogs. A lot of stuff you'll read online is insightful, informative, innovative, or inspiring. By all means, enrich your life with what you read, but be sure to also re-read "Wind in the Willows" from time to time and reflect on the character of Mr. Toad.
Regards,
Someone Who Made The Mistake of Putting Certain Bloggers on a Pedestal
When I was a developer I thought “without me all the people in the building have nothing to sell and they can all just go home”.
Then I spent a few years in sales (long story) and flipped 180 degrees. Without salespeople (and the customers they bring in) there would be nobody paying our salaries and we all could just go home.
Without salespeople you can't sell software. Without developers, you can't make software. Since we all have to pay bills, selling software is of crucial importance, but that doesn't make the developers less important. It just means that the society we live in makes those who sell as important as those who make. Just like we strive to evolve software development, we should also strive to evolve the society.
I've made software that people happily used without anyone selling it to them or me earning a single cent off of it. At my age, if I had the luxury of not having to worry about money, that's the kind of thing I would be doing all the time.
Sales is part of the capitalism layer that sits atop the actual work. Same as CEOs and finance. None of them do useful work, only decide what useful work gets done. In communism you couldn't sell software without a Party representative - that doesn't mean he's useful.
I think the development team's work in this scenario is more akin to basic research. There is still some chance they may discover something unexpected.
It’s not basic research in the vast, vast majority of business cases you’re describing. They aren’t Bell Labs doing novel work, they’re usually doing busy work on mundane apps. I’m not going to move our understanding of financial physics forward playing around with a social media or CRUD app. Hell, most work isn’t even testing a hypothesis other than “I hope this change doesn’t break shit”
It comes across as “everyone else’s work is trivial and low value but my, MY, work is difficult and important”. We shouldn’t be so precious.
I took “basic research” to mean “fundamental research”. Sqlite is not fundamental research. It’s an exception that proves the rule. It was literally designed for a solving a specific problem. Somewhat ironically, it also comes from the industry that originated the term “self-licking ice cream cone”. An occasional useful offshoot doesn’t justify massive amounts of otherwise less useful busywork
Basic research is research done without an obvious application. In the same way, development can be done without an obvious application. All those mathematicians studying prime numbers in the 1600s-1800s came in useful later when we invented good cryptography.
Raising the is–ought fallacy here i s a category mistake that weakens the author’s argument.
“Software is about people” argues:
> I used to think software was fundamentally about code. Experience taught me that I was mistaken. Software is fundamentally an artifact made by people, for people’s purposes, and its success depends on them.
“Software ought to be about people” says:
> Software isn’t necessarily about people, but I believe it should be.
You may argue the latter, but I think the OP believes software is already shaped by humans .
I think people are one factor. Source does, when done well, communicate intent and implementation precisely to other people. If the language has enough semantic information it can communicate some part of the specification as well. Knowing what to write and ensuring your software does what you think it does is an important part of a project. It takes working with people to build the correct understanding of the specification and requirements.
But to a degree it is also about the code. Sometimes your requirements are: be fast enough. In which case you need to think about code: instructions and data.
"Software is a just a tool to help accomplish something for people - many programmers never understood that. Keep your eyes on the delivered value, and don't over focus on the specifics of the tools"
That said, I don't think Carmack would ever say that software isn't about code. It's more that code should be written and evaluated based on how much net value it delivers to people, not on arbitrary technical metrics.
Close, but no. Software is about the mind, and its ability to shape (and be shaped by) its environment. Software was about "people" back when we had to pool our keystrokes together just to keep simple websites running - now we have the technical means to face the true nature of the problem, which is political: just like people have autonomy over their bodies, they deserve autonomy over their software, without having to rely on a corrupt and incompetent industry, addicted to ruining their own products for profit.
> just like people have autonomy over their bodies, they deserve autonomy over their software, without having to rely on a corrupt and incompetent industry
The technical means you mention won't give you that. The same people that make the industry "corrupt and incompetent" are leveraging those technical means to make it even more corrupt and less competent. Meanwhile, the rest of us who work in that industry are rapidly losing power to push back.
You can't rely solely on technology to solve problems rooted in human nature. I mean, we have better technology than at any point in human history, and somehow we're regressing on the issue of bodily autonomy.
This is why I'm so frustrated with people who are fanatical about AI adoption. It's not a panacea, it won't usher in some shiny utopia, it's just another technology that can be used both to improve lives and to oppress. If you take a careful look at our society, you can see which of those two uses is currently dominant.
When you're first starting out as a junior software developer, normally you do focus on just the job in front of you, i.e., the code, and the seniors have to deal with everything else. As you mature into your role, you gradually increase the scope of your work and start to take bigger and bigger views of the problem, which involves more communication and more people. That's just the natural progression of a software development career, not some big bombshell secret.
Software can be modeled as a social relation. Unless you're manufacturing your own chips from scratch, that is. Charging people for software never sat right with me.
Near everything is a social relation, if I'm understanding your point right. Why is charging for software different from charging for most any other thing?
they are not saying code is worthless. they are saying that code which serves nobody is worthless. if you think that website sucks, it probably means that whoever is behind it don't know (or care) that a user like you exist, which is a pity.
Not really, even with a venture backed company. The investors only care if they believe there will be paying customers, and at the end of the day those are people.
In many cases the customer and user are not the same (e.g. healthcare, Microsoft’s business, Google, et al)
More accurate to say restaurants are about people, not food. May be an apt analogy - chefs and cooks spend their time in the kitchen preparing food for a diner they don’t see.
Very weird title since it implies software is not about code which makes 0 sense. Yes, people skills are part of every profession but software jobs still hire based on how good your coding is primarily.
> software jobs still hire based on how good your coding is primarily
ehhh. In my experience, being able to code is a necessary but not sufficient skill for a software developer. The only exceptions I've seen is having some extremely deep expertise in a niche technical field (and even then I wouldn't call that being able to code well, so much as technical domain knowledge).
When I was hiring at AWS the view for my team (RDS) was that there wasn't much difference in expectations between algorithmic coding ability for juniors and seniors. The primary technical differentiator for seniors was architectural and operational. But even more important than those was the nontechnical stuff; mentorship, being able to communicate ideas clearly and succinctly (no point in being able to architect a system if you can't communicate it in a way people understand), interacting with other teams, demonstrating understanding customer and business value, etc.
Okay sure but would you say software is not about code? Yes of course people skills matter I get it but the baseline is still code, no? Isn't it then weird to say software is not about it but rather people?
Yes but also no I guess? Like would you say being a manager or in marketing is about writing, or that being in sales is about talking? Those are the main methods of accomplishing what those roles are meant to do, but it's not like they're about writing and talking.
What do you mean being a manager or in marketing is about writing? Like that statement makes no sense and is wildly vague. The main role of being a manager is to write? The main role of being "in marketing" is to write? I think you're doing a lot of reducing in that and framing the wrong abstract "write". Same mistake as the article.
In fact, my entire point of the critisim is that you can apply the concept to every profession and it will still be valid hence its a banal weird thing.
Saying being a manager or in marketing is about people makes 100x more sense than to say its about writing. Almost all jobs involve people so it applies universally.
But that doesn't mean software is not code. that is still a weird thing to say and wrong.
Yes, I mean you've basically explained it without realizing it; "being a manager is about writing" and "being a software developer is about coding" are equally overly reductive statements.
The code is the "how", the problems that people need solved are the "why". The code is merely an implementation detail.
For most problems solvable in code, there are literally infinite valid code representations of possible solutions (at least in higher-abstraction languages, the space is much more bounded at the assembly level). If you consider the subset of those representations that result in sufficiently performant execution, does it really matter which one is running? This is where most programmers will start mentioning clean abstractions and readability and maintainability, but those are concerns of making the code understandable for people reading and modifying that code. The people are still the driving force.
I'm not arguing for slop here - I definitely care about code quality - but it's important to stay grounded in the reason that it matters: people.
Tired of these absolutes.
Software should be about the code, but not for every person on every project for all parts of that project.
It's great to "wake up" and realize that code doesn't have the intrinsic value you might have assumed, but you can also take that knowledge and go right back to writing beautiful code where it best serves the bigger mission.
> Tired of these absolutes.
Now, that is a letter to new developer that I wish I had read when I was a new developer:
Dear new developer,
Be careful when reading blogs. A lot of stuff you'll read online is insightful, informative, innovative, or inspiring. By all means, enrich your life with what you read, but be sure to also re-read "Wind in the Willows" from time to time and reflect on the character of Mr. Toad.
Regards,
Someone Who Made The Mistake of Putting Certain Bloggers on a Pedestal
Software is about all the things
When I was a developer I thought “without me all the people in the building have nothing to sell and they can all just go home”.
Then I spent a few years in sales (long story) and flipped 180 degrees. Without salespeople (and the customers they bring in) there would be nobody paying our salaries and we all could just go home.
You should have stopped at 90 degrees ;)
Without salespeople you can't sell software. Without developers, you can't make software. Since we all have to pay bills, selling software is of crucial importance, but that doesn't make the developers less important. It just means that the society we live in makes those who sell as important as those who make. Just like we strive to evolve software development, we should also strive to evolve the society.
I've made software that people happily used without anyone selling it to them or me earning a single cent off of it. At my age, if I had the luxury of not having to worry about money, that's the kind of thing I would be doing all the time.
Sales is part of the capitalism layer that sits atop the actual work. Same as CEOs and finance. None of them do useful work, only decide what useful work gets done. In communism you couldn't sell software without a Party representative - that doesn't mean he's useful.
A less cynical take is that sales connects the people who need a problem solved to the people who can solve it.
Sales connects the pocket of the people who need a problem solved to the pocket of the people who invested on the company that promises to solve it.
Modern sales pipelines don't behave this way in my experience.
A very common approach to sales nowadays is to invent a problem that someone does not have and then try to sell them your tool that fixes the problem
Or they try to map the problem you have to the problem they solve, even if they are actually quite different problems
The biggest problem that sales is trying to solve is that you aren't buying anything from them
Yeah, I see this. I think in that case, both the sales and development team are deadweight (ie self licking ice cream cones)
I think the development team's work in this scenario is more akin to basic research. There is still some chance they may discover something unexpected.
It’s not basic research in the vast, vast majority of business cases you’re describing. They aren’t Bell Labs doing novel work, they’re usually doing busy work on mundane apps. I’m not going to move our understanding of financial physics forward playing around with a social media or CRUD app. Hell, most work isn’t even testing a hypothesis other than “I hope this change doesn’t break shit”
It comes across as “everyone else’s work is trivial and low value but my, MY, work is difficult and important”. We shouldn’t be so precious.
sqlite came out of a CRUD app developer being unsatisfied with his database options
I took “basic research” to mean “fundamental research”. Sqlite is not fundamental research. It’s an exception that proves the rule. It was literally designed for a solving a specific problem. Somewhat ironically, it also comes from the industry that originated the term “self-licking ice cream cone”. An occasional useful offshoot doesn’t justify massive amounts of otherwise less useful busywork
Basic research is research done without an obvious application. In the same way, development can be done without an obvious application. All those mathematicians studying prime numbers in the 1600s-1800s came in useful later when we invented good cryptography.
Two things can be true simultaneously. Neither function works without the other.
The conjoined triangles of success.
And without the farmers pulling the potatoes out of the ground, we would all starve and die. So who is necessary, really?
Anywhere we can read some of your story? I'm always curious about devs that went into sales, or sales from a dev perspective
"Software [ought to be] about people, not code"
Related but not quite the same as https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
Raising the is–ought fallacy here i s a category mistake that weakens the author’s argument.
“Software is about people” argues:
> I used to think software was fundamentally about code. Experience taught me that I was mistaken. Software is fundamentally an artifact made by people, for people’s purposes, and its success depends on them.
“Software ought to be about people” says:
> Software isn’t necessarily about people, but I believe it should be.
You may argue the latter, but I think the OP believes software is already shaped by humans .
I think people are one factor. Source does, when done well, communicate intent and implementation precisely to other people. If the language has enough semantic information it can communicate some part of the specification as well. Knowing what to write and ensuring your software does what you think it does is an important part of a project. It takes working with people to build the correct understanding of the specification and requirements.
But to a degree it is also about the code. Sometimes your requirements are: be fast enough. In which case you need to think about code: instructions and data.
John Carmack made a similar point:
"Software is a just a tool to help accomplish something for people - many programmers never understood that. Keep your eyes on the delivered value, and don't over focus on the specifics of the tools"
That said, I don't think Carmack would ever say that software isn't about code. It's more that code should be written and evaluated based on how much net value it delivers to people, not on arbitrary technical metrics.
Close, but no. Software is about the mind, and its ability to shape (and be shaped by) its environment. Software was about "people" back when we had to pool our keystrokes together just to keep simple websites running - now we have the technical means to face the true nature of the problem, which is political: just like people have autonomy over their bodies, they deserve autonomy over their software, without having to rely on a corrupt and incompetent industry, addicted to ruining their own products for profit.
> just like people have autonomy over their bodies, they deserve autonomy over their software, without having to rely on a corrupt and incompetent industry
The technical means you mention won't give you that. The same people that make the industry "corrupt and incompetent" are leveraging those technical means to make it even more corrupt and less competent. Meanwhile, the rest of us who work in that industry are rapidly losing power to push back.
You can't rely solely on technology to solve problems rooted in human nature. I mean, we have better technology than at any point in human history, and somehow we're regressing on the issue of bodily autonomy.
This is why I'm so frustrated with people who are fanatical about AI adoption. It's not a panacea, it won't usher in some shiny utopia, it's just another technology that can be used both to improve lives and to oppress. If you take a careful look at our society, you can see which of those two uses is currently dominant.
When you're first starting out as a junior software developer, normally you do focus on just the job in front of you, i.e., the code, and the seniors have to deal with everything else. As you mature into your role, you gradually increase the scope of your work and start to take bigger and bigger views of the problem, which involves more communication and more people. That's just the natural progression of a software development career, not some big bombshell secret.
Software can be modeled as a social relation. Unless you're manufacturing your own chips from scratch, that is. Charging people for software never sat right with me.
Near everything is a social relation, if I'm understanding your point right. Why is charging for software different from charging for most any other thing?
What about charging people for electronic books? From an IP perspective, code is just a really bad book.
Agreed—electronic books should be free.
I don’t agree, but understand the sentiment.
Great article, I will have more meetings and care less about the code quality. I am sure everything will work out fine.
The compiler doesn't care whether your code is elegant. Your coworkers do. That's literally why code quality exists.
Every single thing people care about is about people when discussed by people
It's really about neither.
It's about whether your code earns someone money.
Why does the https://fusionauth.io/ website suck then?
Enough of these code is worthless propaganda articles.
they are not saying code is worthless. they are saying that code which serves nobody is worthless. if you think that website sucks, it probably means that whoever is behind it don't know (or care) that a user like you exist, which is a pity.
(2020)
Some previous comments:
2024 https://news.ycombinator.com/item?id=41566097
a truism but also not that interesting. why is this getting upvoted?
Every product is about people.
For now. Will that remain true?
Every product is about investors.
Investors are people
[citation needed]
No u
Not really, even with a venture backed company. The investors only care if they believe there will be paying customers, and at the end of the day those are people.
In many cases the customer and user are not the same (e.g. healthcare, Microsoft’s business, Google, et al)
Exactly, so the most important thing is convincing investors there will be paying customers.
Not having paying customers.
“Eventually I realised restaurants are about diners, not knives.”
More accurate to say restaurants are about people, not food. May be an apt analogy - chefs and cooks spend their time in the kitchen preparing food for a diner they don’t see.
How to make a people problem worse:
- Umbrellas are about people, not rain.
- But your umbrella will keep me dry, right?
- The materials, the shape, none of it is really important.
- I'm not sure what you mean. Give me some hard numbers. How much rainfall the fabric can take? Was it built with quality?
- At the end of the day, an umbrella is just a tool.
Very weird title since it implies software is not about code which makes 0 sense. Yes, people skills are part of every profession but software jobs still hire based on how good your coding is primarily.
> software jobs still hire based on how good your coding is primarily
ehhh. In my experience, being able to code is a necessary but not sufficient skill for a software developer. The only exceptions I've seen is having some extremely deep expertise in a niche technical field (and even then I wouldn't call that being able to code well, so much as technical domain knowledge).
When I was hiring at AWS the view for my team (RDS) was that there wasn't much difference in expectations between algorithmic coding ability for juniors and seniors. The primary technical differentiator for seniors was architectural and operational. But even more important than those was the nontechnical stuff; mentorship, being able to communicate ideas clearly and succinctly (no point in being able to architect a system if you can't communicate it in a way people understand), interacting with other teams, demonstrating understanding customer and business value, etc.
Okay sure but would you say software is not about code? Yes of course people skills matter I get it but the baseline is still code, no? Isn't it then weird to say software is not about it but rather people?
Yes but also no I guess? Like would you say being a manager or in marketing is about writing, or that being in sales is about talking? Those are the main methods of accomplishing what those roles are meant to do, but it's not like they're about writing and talking.
What do you mean being a manager or in marketing is about writing? Like that statement makes no sense and is wildly vague. The main role of being a manager is to write? The main role of being "in marketing" is to write? I think you're doing a lot of reducing in that and framing the wrong abstract "write". Same mistake as the article.
In fact, my entire point of the critisim is that you can apply the concept to every profession and it will still be valid hence its a banal weird thing.
Saying being a manager or in marketing is about people makes 100x more sense than to say its about writing. Almost all jobs involve people so it applies universally.
But that doesn't mean software is not code. that is still a weird thing to say and wrong.
Yes, I mean you've basically explained it without realizing it; "being a manager is about writing" and "being a software developer is about coding" are equally overly reductive statements.
The code is the "how", the problems that people need solved are the "why". The code is merely an implementation detail.
For most problems solvable in code, there are literally infinite valid code representations of possible solutions (at least in higher-abstraction languages, the space is much more bounded at the assembly level). If you consider the subset of those representations that result in sufficiently performant execution, does it really matter which one is running? This is where most programmers will start mentioning clean abstractions and readability and maintainability, but those are concerns of making the code understandable for people reading and modifying that code. The people are still the driving force.
I'm not arguing for slop here - I definitely care about code quality - but it's important to stay grounded in the reason that it matters: people.
Don't they now hire based on AI token use?
touche