Also, think longer-term: if you can program well enough, then you can write great software quickly which is a huge asset when making your own thing and selling it.
It is quite rational to optimize for your own wellbeing in these ways even in orgs that are not fully conducive to long term careers.
For so many reasons, from a mentor of mine:
Quality Is It's Own Excuse.
If you can do it better, do it better.
No? Doing things the right, robust way regularly takes more time and effort than doing it the quick and dirty way, which means your lazy coworker gets the management attention and raise instead of you.
For the vast majority of software developers, the correct career choice is just to always be making your manager's life easier, and they rarely care about "doing things the right way", especially when whatever you write will be replaced in five years because someone somewhere is too lazy to understand the current codebase.
Life is too short to spend most of your waking hours surrounded by people whose beliefs go against yours.
Be careful: it can be dangerous to tie your inner satisfaction with your work, which is not under your full control and also what you need to get paid. You can get burnt out.
Sometimes you have to take a step back and say "It is what it is, we all need money, fuck it and let's move ahead."
When I was in leadership and advocated for getting things done as quickly as possible, the principle reason is that it didn't matter: the company already failed by the time I had subordinates. My reward was that I got 4 extra years of my life back by leaving 1 year in rather than at the bitter end, compared to my colleagues.
It's my opinion that most companies are 90% operating failures / doing stuff that doesn't make sense, while there is 10% that does make sense and subsidizes all the failure. Some people call this taking risks, and indeed the worst places to work take the fewest risks, but I don't think the two are related.
Also the Lisa was a disaster. I don't think there is generalized advice here, even if you have all the conditions where craftsmanship and aesthetics are literally the #1 values your product has.
so, is the metaphor of drawer useless in software? Is there no point taking pride in the craft because it's all going to fail anyway?
I don't mean this rhetorically. I just genuinely wonder what and how different people's mindsets are with respect to work in the field. I work in games so success is rarely guaranteed, and shorcuts often taken. There's very few times I can say that better code would have saved a game financially.
It’s a little absurd to state “uniquely” there, because obviously, “everyone” understands this except the people that need to understand it.
* Sisu (Finnish): Though not a direct equivalent, "sisu" refers to a blend of determination, resilience, and courage in the face of adversity. It's doing something against the odds, putting extra effort, and not giving up.
* Gaman (Japanese): A term that loosely relates to enduring the seemingly unbearable with patience and dignity. It can apply to doing meticulous, quality work even when situations are challenging.
* Jugaad (Hindi): Jugaad speaks to a creative or innovative fix; essentially finding a low-cost solution to a problem in an intelligent way. It reflects a spirit of resourceful improvisation and can indicate a pride or savvy in being able to solve problems with limited resources.
* Arbejdsglæde (Danish): This word directly translates to "work happiness" and denotes finding joy and satisfaction in the work you do.
* Mānawa (Maori): This is used to describe patience and perseverance, particularly in working toward a goal or mastering a skill.
For me, meraki has kind of a "craftsmanship" meaning - you're building something carefully, like a sculptor. The result reflects your soul.
Jugaad is more of an ingenuity/re-purpose/get-it-working-fast kind of thing, kind of like a "hack" but with a more positive meaning.
It is a problem of being self taught on projects that only I would use, you would learn some very bad habits. Would also mean making code that you would look back on a few months later and have no idea what you were doing.
If it was for anything other than video games pre-online era, I fear the kind of damage it could have done. It was putting pixels on screen, not running online data bases or via monetary systems.
To that I say, I like the Ps2's/Gamecube memory systems that kind of didn't give a damn how many pointers you threw at it. I would also like to say I learned not to do this, I did not. I just don't code any more.
> I think software as a whole suffers greatly from this "well, I got it barely done, technically fulfilling the requirements, so my work is over" attitude.
I disagree. I think employees suffer from an incentive problem. I love doing good work and writing good software, but there's only so much time in the day and I don't love it so much that I'm going to give up my personal interests for business gains I'll never benefit from.
On top of that, mismanagement is the other biggest factor. Any time I start some refactoring, I can reasonably expect that I'll wake up one day to a brand new must-have feature that I need to complete by EOD if possible. No matter how much management agrees that tech debt needs to be addressed, it will only ever be addressed if I pad my estimates and do the refactoring instead of my assigned work.
The plywood starts flatter, is less resistant to warping, is just straight up more dimensionally stable, and as strong if not stronger than some species of wood that are used in carpentry.
Generally speaking, modern management doesn't respect the business, they look at maximizing current P&L before all else. I worked at a place where the entire business was dependent on a true legacy system where 75% of the staff responsible for this core system retired years ago, and the rest literally died at their desks. They considered it their life's work and documented everything and advocated for a variety of sane plans to migrate.
What was the result? They're all dead. The last one was 74. The system remains, and they are paying the legacy vendor 50x and getting minimum viable support and zero enhancement, further increasing complexity. It's a shitshow for the company, but they still haven't moved to fix it. The lesson is, don't get emotionally invested in the company. That dude should have been watching his grandkids grow instead of slinging COBOL and JCL and hoping that someone would wake up and give a shit.
All it takes is placing ethics (physical resource use, living standards of those who make your stuff) higher in your value approximation. I hate spending money on disposable goods with a passion, as a result I value the walmart chest of drawers negatively because owning and using it will make me unhappy.
If you hate globalisation, then maybe that can be tackled with better legislation, improvements in working conditions and standards of living, and other systematic changes. It's not going to be changed by lecturing poor people on the ethics of buying cheap stuff.
Weighing "Value" means you need to consider many dimensions and people have different weights, priorities and abilities to service those dimensions.
At some level, a dresser is just a box for my t-shirts and socks. Similarly a link-shortening website probably doesn't need a typesafe, fully commented code base.
Case in point: frontend and the shit show that's become.
I COULD use the online form if the fucking thing ever worked!
Most recently was unable to book service for my vehicle online cause the selection lists always cleared themselves the moment I selected something. I click the year of my vehicle. It populates for an instant. Then clears.
Then had a guy on the phone audibly upset at me for making him take the phone call to book service.
Every adjacent company ever: “we can beat Apple!!” then actively self-sabotages quality via processes, lax quality control, and a pervasive low level of CBF.
I get it barely done, technically fulfilling the requirements. How much more I clean up depends how much more time my PM has left me in the sprint. Since I'm constantly bombarded by questions, appeals for help, requests to approve pull requests, last minute changes, various meetings etc., that usually is not much, if any, time.
Of course, you need to pick the right battles. Sometimes that hack to fix a production issue will stay like that for ages, and the proper fix will never be done, and that's the way it is.
The problem is the business doesn't care about anything except how much money can be gotten out it, often with a short-term horizon.
So the developers and the business people walk shoulder to shoulder for a little ways, where the two interests are aligned, but then we part ways at the point of introducing technical debt. As a developer, I'm not free to take the time I need to pay down this debt, because of business constraints.
>
Exactly.
I read a book, where one of the characters is a smith. It has this exchange, between him, and another character:
"Always do the very best job you can," he said on another occasion as he put a last few finishing touches with a file on the metal parts of a wagon tongue he was repairing.
"But that piece goes underneath," Garion said. "No one will ever see it."
"But I know it's there," Durnik said, still smoothing the metal. "If it isn't done as well as I can do it, I'll be ashamed every time I see this wagon go by -and I'll see the wagon every day.”
I suggest avoiding The Elder Gods series.
Software - or at least, the kind of software I have worked on in my career - is never finished. It is a neverending ship of theseus.
I can muster motivation to try really hard on something that has an end point. But the idea of maintaining that kind of motivation and focus on a project that just goes on and on and on is, for me, near-unimaginable. You could pay me a million dollars a year and I think I would still really struggle with it. It's something I think about a lot and struggle with, because I have certainly had colleagues who seem to be able to maintain that level of craft on software projects.
> Software - or at least, the kind of software I have worked on in my career - is never finished. It is a neverending ship of theseus.
Totally agree. I've done several rants on HN about the software industry's inability to declare their products "done" and moving on. Every product that we complain about becoming "enshittified" should have been declared "done" and developers pencils-down years ago.
I get my craftsmanship fix writing code at home. Just couldn't bear doing it at work the way I had to.
The core issue is that going above and beyond that isn't rewarded in most cases - to the contrary: if you take the time to do it right (write proper unit/integration/end-to-end tests, refactor when you see a steaming pile of poo instead of just taking another dump straight on the pile), you'll end up "less" productive on paper than your colleagues "solving" ticket after ticket - and most organizations run that way, particularly those where the business model doesn't allow for good code. The worst cases tend to be "fully agile" shops that don't account for refactoring / code quality cleanups at all.
Apple is the unicorn in that regard (or at least it was up until the last years, their software quality definitely declined...): their products cost a ton of money for the customers, so the customers expect good quality, Apple as a company has the profit margin to actually make that happen, and most importantly: at the helm they had Steve Jobs who actually "had an eye" for experience instead of some run-off-the-mill MBA beancounter.
(Do note that there is also the other extreme: just look at Juicero. A machine built to squeeze out juice packs, with engineering practices like it would be used in spaceflight)
It's a feature, not a bug; the chest of drawers is heavy enough already and someone's gonna have to move it someday. Making the back as thin as possible is doing a kindness to a future owner when they have to relocate the damn thing.
Yeah, that's the point. Do you want to be one of the millions of craftspeople who doesn't sweat the details? Or do you want to be exceptional?
... definitely a lesson I think many software engineers should internalize.
sure, no other reason than "less stability". You may or may not need the stability, but sacrificing it so that is 2% easier to carry into a house (which happens maybe, once per 2 years for an especially nomadic person) seems to be the exact kinds of corners management likes to take.
A toast to the hardware manufacturer that considers the fact that tangible objects get moved.
In other words, which percentage of your lifetime earnings would you be willing to give up to not add a plywood backboard (or the software equivalent)? 10%? 50%?
I'd happily give up 50% to not encourage that. But I am also fortunate in that 50% of a very senior SWE is still a very liveable wage.
He said that trying to build the best tech ever and trying to market it, does not work, and he had the scar tissue to prove it. His NEXT experience echoes the truth.
Making a high-quality product requires an Entire Agreement, you cant buy from a supplier who only sells plywood for your chest of drawers.
Apple controls it's tech from top to bottom and that's the only way to effect serious change and uphold quality standards.
It is spirit-draining to pick up some off the shelf tech and find a million things with it that should be structured differently..... but we all do it and that's how it is.
We don't have top-to-bottom control and easy ways to change product designs, that Apple has, until we all get that ability, high quality is a failable target.
Using expensive wood or spending time doing things nobody will see will lower your throughout and raise your costs unnecessarily for the customer.
Even a master carpenter has finite time and money. Every morcel of time spent doing things nobody can see is time not spent doing other things with more visibility. The masters are still competing with other masters in a globally competitive market.
So Job’s fictional carpenter would get outcompeted by the hypothetical free market where carpenters of equal skill are producing more at lower cost.
Apple, during the Jobs days anyway, produced luxury goods for a luxury price. Given the market they were addressing, Job's comments make complete sense.
Making furniture with features that no one can see except the carpenter is a disadvantage compared to the same carpenter who focuses their time making more their furniture more visually appealing to their customers.
Everyone seems to forget that Apple was nearly bankrupt in the 90s because no one was willing to pay so much for their product when Microsoft did it cheaper and similar quality (from the users perspective).
Sure. It's a rather tiny market that can't support a lot of furniture makers. But it can support at least a couple, and I'll bet you that those ones aren't going cheap on materials.
> Everyone seems to forget that Apple was nearly bankrupt in the 90s
I certainly haven't forgotten, but that's orthogonal to my point. My point is that in many industries, there are high-quality, very expensive versions of the products. One of the things that makes them high quality and expensive is that they don't cut corners. In electronics, I've seen the same effect, where extra care and expense was placed into things that technically don't need it and are unlikely to ever be seen by the customer. That extra care and expense matters to that demographic, though.
While Apple is certainly not on the same level as that, the point is true craftsmanship and meticulous attention to detail does still exist in consumer goods, and can be handsomely profitable.
I guess the metaphor applies here too. Some will take that pride and rise up. Some will take that pride and fall behind despite being equally qualified as the ones who rose. Others will coast along and make stable business.
I think where the metaphor breaks down is visibility. Sure, that cheap plywood isn't normally visible, but a customer who looks will find it. very few iphone consumers have the skills to find bad code and fewer care as long as it does what it is intended. It's probably more akin to selling hot dogs than selling a chair.
I think the point of the story is that Jobs's carpenter is not even trying to compete with Walmart trash products. He is deliberately avoiding the market that is sensitive to higher costs.
This hypothetical carpenter would be competing with other carpenters at the same skill level.
The truth is way more nuanced than “the master carpenter would get outcompeted.”
If you believe the race to the bottom prevents you from doing great work, then you will not do great work.
Spending all your time polishing details that nobody cares about is not doing great work, it is wasting time. Time that could have been spent experimenting on new techniques, trying new ideas, taking on new projects.
this mindset seems to be the exact ones that coporate companies sinking in tech debt has. The absurd extreme of this is that carpentry is a waste of time when you could be making more money as a doctor.
Fact is you don't need to be 100% optimal on time and resources and you don't need infinite money to live. I'm sure carpenters work on thin margins but a few pieces of plywood won't bankrupt them and leave theif families on the streets.
If someone sacrifices a little time and money for personal satisfaction and pride, that's fine. If they want to maximize profits that's also fine (as long as they aren't abusing their labor to do so). C'est la vie.
Maybe someone should have explained to Jobs how to compete in the marketplace. Another approach is to try to understand why Jobs said those things given the obvious economic costs that you mention, and how it led to the most valuable company in the history of the world.
You just got it barely working? Great, now make it beautiful while you have the context. It’s done when it is tight, fielded, and you can forget about it.
On tech “culture”: My worst-rated comment on HN was when I suggested devs should spend 15m less on Twitter/HN and put them toward writing more unit tests so they’d understand and enjoy their work more.
To me, that sums up where we are now.
Because everybody knows that spending 15m less on HN will not give you better anything. It's like saying "working more hours a day you will have more code". It just leads to burn-out. Most programmers need some idle time between thinking. Or like saying "Want to have house? Eat less avocado toast and skip that starbucks coffee."
For some engineers, the thought of leaving some things undone gives them the icky feeeling, while the thought of not completing a challenge in an expected timeline doesn't bother them. For others, it's the opposite.
I think this holds true even for personal projects, where there's no manager or sprint to impose a time constraint.
But it's a spectrum where most people are somewhere between the extremes.
If you're the middle-end drawer maker, then you probably will put plywood on the back so that you can build more in less time and call it a day.
And in the end no one will ever see it.
> In a way I would have loved to ship with that hack in there, but once we found the cause of the error message I couldn't in good conscience leave the hack in there. Besides which hand editing it added time to completing the build, which was inefficient.
Source: https://www.wcnews.com/news/2023/09/18/mythbusters-wing-comm...
The link is about investigating the origin of the “thank you for playing wing commander” error message, which seems fitting too.
Good engineers have to know when they're building a beautiful chest for public display for 20 years, and when their customer doesn't even know if they want a chest yet. It's a matter of context and being aware enough of the business circumstances to make the right decision.
There are countless software projects that have never seen the light of day because the developers spent all the time polishing the back of the cabinet (and the product managers designing the door handles), and nobody did anything about the actual drawers.
You've seen the survivors of the process which have ugly backs of the cabinets because the developers started on the actual drawers and, because more likely than not it was somebody elses money paying for back-of-the-cabinet-polishing, and they got stopped at the end.
Also, if I have to delay the building of my kitchen because the cabinets are late, and I call the shop and they cheerfully tell me that they were ready yesterday but they haven't finished polishing the backs, oh man, I don't know how happy am I going to be about their excellent craftsmanship, you know?
maybe some hobby projects. I can't name a product that failed due to too much polishing. It's almost always due to overscoping or underfunding or political reasons. Sometimes first to market is important, but it's not the difference between success or failure simply due to timing.
>you've seen the survivors of the process which have ugly backs of the cabinets because the developers started on the actual drawers
And I've also seen "survivors" that died because the drawers weren't actually bolted on but got plenty of funding on the show floor with "no touching allowed" signs. Absolutes, sith, etc.
> if I have to delay the building of my kitchen because the cabinets are late, and I call the shop and they cheerfully tell me that they were ready yesterday but they haven't finished polishing the backs, oh man
And that's a classic miscommunication. Some managers see unnecesary polish when in reality they were still bolting the drawer in but they think "it's good enough".
Some people see all those (planes) software projects (coming back from war) being live ridden with (bullet holes) technical debt, and the first thing that comes to their mind is ("better reinforce the places with most bullet holes!") "Better make sure to deal with that technical debt!"
Fascinating!
Lord of the Rings didn't fail to ship or lose money because of this. They made money, but more than that, they created something that will be remembered forever for quality and craftsmanship. Not every carpenter has to care that much and the same is certainly true of people shipping computing equipment. Just like Peter Jackson, Steve Jobs got rich, but he won't be remembered for being rich. He's remembered for quality and craftsmanship. I can't sit here and say everyone who builds anything should build for maximum quality, but I have trouble believing we'd be worse off as a world if we had more Notre Dames and Parthenons and fewer pothole-riddled main streets with falling apart boarded up storefronts.
I get it but as an aspiring artisan it also makes me question how I even can get to that point. Your environment determines a lot of your growth and COVID has thrown a tempest into that equation.
All the respect to Steve Jobs, but I know I'm not him, someone who is probably top 0.1% in intelligence and luck. I'll put customers' requirements before mine.
The first thing a good carpenter will do is make sure the house they're about to renovate is square and true. If it's not, they will have tricks to make the walls square and true, they're not just going to polish the turd or put glitter on it.
Jobs at Apple probably had a lot of opportunity to work on a lot of greenfield things, which I'd say 99% of people don't have the luxury or doing.
I also like his quote and attitude btw, just realistically, most of us won't ever get live in that world.
“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
I think software as a whole suffers greatly from this "well, I got it barely done, technically fulfilling the requirements, so my work is over" attitude.
1: https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...