To go along the same line of thought, too many think about the beatuy of the flower, instead of the whole florest.
The amount of hours occasionally wasted discussing this in PR, that add zero value to what the customer actually cares, e.g. does pressing the button print or not their monthly invoice.
Sure there is a balance to be had between completly unmaintainable code, and a piece of art to expose in the Louvre, however too many focus on the latter, instead of what is the customer getting out of their beautiful flower.
Cool, I'm glad you see my point :-) - it's just that there seems to be almost a meme going round, not just on hn, that 'hey this stuff just doesn't matter because the customer doesn't care' which seems fallacious to me (see other posts for why :-)
I think the term 'code beauty' is a poor choice though; that seems to me to implies something subjective, when in fact I fundamentally believe code quality dictacts product quality.
So you've listed houses, cars, watches, food. All these things indeed serve a purpose as well as allow for creativity and expression.
But the difference is, all those things have sale values that DIFFER based on that creativity and beauty. Code does not. My customer does not care if my backend code is beautiful, and neither does my CEO because it won't make more money.
> Is a dish or menu designed by a chef not art? Is a house designed by an architect not art?
Of course I see the art in those things, and in response i'll pay a lot more for a Frank Lloyd Wright than a mcmansion. But the customer of my B2B CRUD app does not care if my code looks like a FLW or a mcmansion. They care if it works.
In my experience, most of the corporate world seems to care more about their aesthetic notions of the Platonic ideal of what code should look like than whether or not it works or whether or not it is efficient. Certainly that's my experience from interviews.
Maybe the people who care about business value should be the engineering managers not the people who equate their personal aesthetic preferences with the only right way to write code?
Because our technical culture has been colonized by business interests to the point that people cannot tell the difference anymore.
Many comments on this thread show an unwillingness to even consider alternate technical aesthetics. Everything has to be about Creating Business Value, as if that's somehow the most important thing in life.
A rather silly post especially since it only talks about one side of the coin. Obviously customers don't care what your code looks like. That does not mean you shouldn't care about it - especially startups - since ugly, fragile code can completely change the rate of evolution of the product.
It's a great reminder that the customer doesn't care about the code. What matters is the experience and overall fidelity of the product shipped.
The language you pick, the quality of code you write, the comments and documentation, are all products (gifts) targeting your future self, future peers, and employer when it comes time to make changes to the software.
So many people focus on their "stack", and all these things that have little effect on the outcome. Customers don't know or care how something is built, they just want it to provide value and solve a problem.
> People can't all devote time and energy to everything that's important.
Well if the users can't spend any time on it, it isn't sufficiently important for the business to care about it as the users will be briefly miffed and then go on to what they consider important.
User unhappiness matters only so far as it changes behavior.
I believe the author's point is that you should care about the relation between your technical decisions and actual benefits for the user. It is true that many technical people develop an appreciation for tech choices that is driven by aesthetics more than by actual impact.
That being said, caring too much about customer success also has its pitfall, businesses can be driven by the present more than by the future, and by low-impact guaranteed results more than high-impact hypothetical risks.
Couple of interesting quotes that resonate with this.
1. "Company doesn't care about you (employee), and you shouldn't care about the company"
For few years this resonated in my head and I disbelieved it for obvious reasons. Its just demotivating. But after more than a decade I know this is completely true.
2. "Customers don't care how good the code is"
True. As far as the functionality is reliable and acceptable quality. Good code is only a value-enabler.
"Getting it" may be right for us (developers) but wrong for the company.
A florist that needs order tracking isn't trying to change the software world. That persuasive guy thats insists SmallTalk is gods gift to florists is NOT doing them a favor.
Totally, 100% agreed. Sure, there are a lot of developers who don't care about quality. Usually, they don't care because they're here to do their job and get paid, not to make an art piece. Which is to say, they would care if it was a part of their job, but it isn't, because of business-level decisions.
I agree, but a lot of it comes down to other peoples perception of you. Sometimes it is worth doing those dumb esoteric challenges that provide no business value whatsoever.
Example: The CTO really wants the table on the careers page to render the text color coded by the age of the job posting. Will it be easy to do this? No, our table text color is hard coded so we will have to rewrite the table module from scratch. Is this of any value to any paying customer or job applicant? No, no one cares about the text color.
But, after you have advised management it may not be valuable to your users and it will be very time consuming, you better hop on board the table text color train 100% and ship those stupid table colors.
Amen. It is the Jobs-Wozniak syndrome re-played again and again. We focus on technical issues and (mostly) ignore the business value we produce (aesthetics included). Guess what, the money is being made not because of code quality only, but from the business value it produces. So whoever presents him/herself neatly and can accentuate the awesomeness of the product (taking credit for your work), becomes the rainmaker and assumes power.
I am not really trying to dismiss people how care more about solving users problems. In that case, product is your thing, and I love love love to work with a product person who is passionate about solving user problems. But I doubt I would enjoy maintaining the code written by product person who doesn't care that much about "pretty code".
I don't get this - changing the code is not the problem - this is a political / marketing issue.
I have some news - passion is not enough, and there are more than 2% of people working on things they are passionate about - it only 2% get lucky.
I can think of a few instances in my recent career at large monorepo company where I have built something on the scale of "passionate, could improve our working lives"
One died because ... well I gave up, two are used locally by my team and those I could persuade, whilst other solutions built by others for the same fix have gone on to be blessed officially, (ie replaced by grassroots competition) and one was replaced by a fully mandated and funded project that spotted the need and just steamrollered over all the local fixes.
One is still outstanding and I think well worth pushing still.
But I don't dream of the big win where suddenly the Board says "why, without your glasses Miss Moneypenny you look ravishing".
I get paid, I work, and I try and make the world a bit better where I can. I am passionate about it. But i don't write blog posts about how passionate I am.
The amount of hours occasionally wasted discussing this in PR, that add zero value to what the customer actually cares, e.g. does pressing the button print or not their monthly invoice.
Sure there is a balance to be had between completly unmaintainable code, and a piece of art to expose in the Louvre, however too many focus on the latter, instead of what is the customer getting out of their beautiful flower.
reply