See, when I joined my current company, I was full of energy and I did BF. I fixed broken builds. I made our abandoned test suite green. I refactored our deployment pipeline. I hunted down the root cause of bugs and fixed them. But then I noticed several things.

First, rather than encourage people to behave like me by example, they did the opposite. Why fix a broken build when I would come along and do it? it turns out doing shit work just gives you more shit work.

Also the guy does hack jobs got promoted ahead of me because he is a master of optics and presents his work much better than it is. And look at how fast he delivers! it doesn't matter his code keeps causing problems in prod, by then he has moved on to another project and it's someone else's problem.

Oh, and that junior guy than I spend several hours a week helping makes more than me, because we hired him in 2022 when we were desperately throwing money at people, but I didn't get a raise in 2023 despite an "exceeds" rating because you know, it's tough times and we need to buckle up.

Listen, I love what I do and I want to excel at it, but is it any wonder and CBF? At the end of the day I work for a salary. If my efforts aren't rewarded, or sometimes actively punished, my motivation goes down the drain. Sure, part of it we do for ourselves, but at some point you have to question who is really benefiting from the situation.

Choosing an IT-career is just the least evil for me.

You aren’t forced too. You need to look up what ’forced’ really means. I’m not saying it isn’t hard though.

Yes we are forced to work. If I stop paying for stuff I'll starve, nevermind the fact that I'll have to live outside.

And yes we can live in the woods, theoretically. But we don't want to.

And no, before you say it, this being "the price to pay for living in civilization" is NOT a given. It's a local maxima that many people agreed to never revisit. Not very impressive, and not a good outlook for our race.

We do have choice and most do take the lesser evil of IT and but if you really want, you can go look to see what else is out there.

It is not without risk though.

That requires money, so you need a way to generate money. But you don't have to partake in society. If you want to I'm sure you can grab an axe and go build a log cabin in bumfuck nowhere.

And then you can work all day to make sure you have housing and food and firewood and whatever else you need.

Personally I'd rather sit on my ass in a comfortable office and get paid to think and press some buttons so that I can get electricity and food and all the shit I need. But nobody's forcing us.

I don't think you want what you think you want. You like modern society, certainly beats fighting mountain lions for days-old dead deer and dying of a treatable infection. If you want the benefits of society you have to contribute.

Me too, but I am arguing the degree of it here, and that nuance is sadly lost on many. They always jump on "go live in the woods then" which obviously is not what the argument is about.

If the costs of living drop a little and if housing becomes actually affordable then I'll very likely never open my mouth criticizing civilization again.

And I will not agree that the current world economical situation is inevitable. I think many of us are quite aware that the world elite is playing dangerous games at the expense of everyone else but themselves.

It does not have to be this way. It can be better. But that's a huge -- and different -- topic.

> But nobody's forcing us.

Hard disagree and I'll leave it at that, you are chasing a dictionary definition here much like my previous parent poster did, and that's not moving any discussion forward.

> I don't think you want what you think you want.

Disrespect will get you nowhere in any discussion.

> You like modern society, certainly beats fighting mountain lions for days-old dead deer and dying of a treatable infection. If you want the benefits of society you have to contribute.

Sure, and again -- degrees. It's not an all or nothing and it's very puzzling why you and many others are framing it that way.

It’s only in the last few decades for a small fraction of the world, and a few centuries for an even tinier fraction of the world, we’ve been able to “work for our salary” where salary even includes leisure.

In any event I'm not exactly nihilistic. I believe better places to work exist, but my visa prevents me from changing employers. When the time comes we'll see if the grass is greener.

I have a closet in the basement where when I did the vinyl plank floor, I ran out so the planks don't quite go to the back of the closet all the way. Problem? Yes? A bit ugly? Yes. But in reality the problem is 100% of the time covered by boxes and anyway I can live a happy life in this house for decades and not be affected. That's 0% tech debt.

On the other hand if my gutters are clogged, there's interest on that because the longer I wait the costlier it will be to deal with since clogged gutters can lead to basement leaks or gutters themselves detaching. Or, if my stoop is broken, that's not just an eye sore but I keep tripping on it, the faster I fix it the sooner I stop tripping. That's a high-interest debt that should be fixed asap.

In engineering, a high-rate debt could be some architectural thing that slows down the development of every single feature. You want to quickly pause features to pay this down so everything can move faster. On the other hand, some file that you never touch having some shitty code or lots of TODOs may be a very low interest debt since in practice you never touch it or are otherwise not bothered by it other than knowing that it's ugly - like my closet floor.

Engineers make two mistakes around this - fixing zero-interest debt when there's more important things to do on one hand. On the other hand, when they say "oh, product management/leadership didn't sponsor our tech debt fixing" - it's often because we fail to articulate the real cost of that problem - explaining that it's high rate and how it's costing you.

I disagree. they simply don't care because from the top down, new shiny stuff gets attention, not keeping the old stuff going.

edit: I also wanted to add this, if I do convince them of its importance, MAKE NO MISTAKE, management will agree that work must be done but it has absolutely NO BEARING on having a positive job performance. I just convinced management of something important that I have to do that I will receive no benefit from - unless it goes wrong then I'll get reprimanded.

Important, in the context of a hierarchy-driven development team or company, is defined first by the best way to let money flow towards the company, and second by the people who are enabled by the hierarchy to make decisions about where to allocate resources to improve that inflow of capital. While persuading someone it's momentarily important to shift from what was going to be done to what you think should be done can be one way to acquire "career capital" (Newport) and maybe move towards it being your job to do so, it doesn't change what your current job is which is basically to consistently show up and do whatever those others decide is important, and to be ok with that; slow, mediocre, gradual progress and existence, which is perfectly fine if you have other part s of your life, which you should be spending more time on anyway. If new shiny stuff gets attention, then that's part of the dysfunction of the overall system (Meadows - Thinking in Systems)

When I was early in my stupid career as an developer, I made the idiotic mistake of trying to influence decisions regarding things that didn't matter to anyone else, like accessibility, usability, and when I failed to do so put in a lot of my own personal energy to do it right anyway. That was worthless, and I got depressed, fired, and ended up homeless for a while. Do what you're paid to do, and be realistic about what that is, until you're literally swatting people away who want to pay you to do it, then you can do it the right way. Never trust companies for any reason, and don't invest too much of yourself in them unless you can guarantee positivity will come your way if you do things beyond your standard deliverables.

yeah, assuming you get to that point before burnout or CBF kicks in. Or maybe you never do and just retire off of corporate. I imagine that exact mentality is why so many game dev programmers burn out and chase the money they deserve in others parts of tech.

My point was that the burnout lies in mismatched expectations, as well as working excessively, and yes I'd agree that's probably why game devs do that. There are better avenues for "passion" than your career unless you can trade the skills you've built up in your career for whatever you want to do for work.

Edit: Additionally, if in retrospect I just said yes to the most viable incarnation of whatever the corporate overlords wanted, and stopped caring earlier about the hypothetical implications of poor technical decisions (which I should have accepted sooner weren't a significant part of my job), then the work would have just maybe got done and whether it worked or not wouldn't necessarily be my concern, and I'd have more fuel in the tank to just keep getting better and moving somewhere else.

- Engineering is very transparent about explaining when tech debt is slowing down development of new features

- We recognize that buggy/unreliable software hurts customer retention

- Engineering leadership has set the expectation that a significant portion of each team's time should be spent on maintenance and reliability.

[1] https://en.wikipedia.org/wiki/Broken_windows_theory

The metaphor of interest was the whole reason that Ward Cunningham initially coined the term "tech debt":

"Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt."

https://www.martinfowler.com/bliki/TechnicalDebt.html

what's amazing is that I'm apparently in debt while owing absolutely nothing to anyone.

When you say something like "0% tech debt" seriously, do you ever stop and wonder if maybe you're off-base?

Debt needs to be serviced, if you don't need to service it, it's not debt.

What next, that feature that hasn't been implemented yet is 0% tech debt?

The main point to take away is that much of what is colloquially called tech debt does not need to be dealt with on any time horizon, while some does - and being able to distinguish between the two types is key. Were you able to get that much out of this?

And then to make the analogy work for you again - my closet IS a form of tech debt and I insist that it's "0% debt". For example, if I am going to sell the house, it might be the case that having this flawed floor would cause me to get lower offers. So I might chose to deal with this issue at some point, but there's no reason to deal with it any sooner (analogous to not being in the rush to pay off a zero-interest loan)

If the porcelain top on my toilet breaks, I'm not in debt because I choose not to replace it.

now, I can run around and tell everyone my toilet is now causing me to have 0% debt because I have a right to say whatever I want, but words have meaning and me saying it doesn't make it so anymore than me claiming the earth is cheese has any effect on whether or not it is. Unless of course by cheese I really mean iron when I say cheese.

you do know what "tech debt" is, right? In your metaphor, your top may have 0% debt because only you use the bathroom and no one cares, or it has a potentially high debt in that you receive more germs from your bathroom and get more sick, costing you money to buy medicine to keep you not sick. The debt is objective but we live in a world where finding that objective measure is infeasible.

to use your cheese metaphor, it's more like boldly claiming the earth is 35% iron. it's something you can quickly google and is acceptable through decades of study, but it also wouldn't be surprising if better tooling and measurements later on specify "it's actually 33.42% iron". Important for a geologist, splitting hairs for a casual audience.

We are very much a casual audience, and splitting hairs over a metaphor isn't that productive.

There is no business leader on this earth that is going to agree with 0 debt is debt. Or that choosing not to do a thing or pay for a thing implies debt.

And it gets even worse when you take it to its logical conclusion. Choosing not to fix something is apparently debt. So then if you take out a loan to fix it it's also debt?

What the poster meant is it doesn't always harm anything to leave something unfinished or imperfect. Which is true, but then they tried to squeeze "technical debt" into that and went off the rails.

words have meanings for a reason.

Inaccurate or not, it's understood by people what "tech debt" means and the point of communication is to express ideas to others. Even if it spits on the queen's english, it furfills its goals. I lack the clout and energy to try and oppose and change such ideas (and to be frank, it wouldn't make the top 50 of things I would influence if given those factors).

We have 1 poster abusing it and getting called out for it.

I get to define my intent, not you. You cannot call someone out without disagreeing with the behavior or words that you're calling out. So congratulations on stating the obvious I suppose.

My thoughts are laid out above. I have nothing more to add on the subject. You win, and I apologize for failing to understand your point.

No no, seriously. You need a counter party to your debt. What about a divine figure?

Nobody gets in shit for telling their developers to code faster.

Lots of risk telling them to fix the underlying issues so they can ship faster in the future.

"Code hygiene" is not a goal but the means to a goal. The reason hygiene is good is that ideally should (1) enable you to ship faster and (2) have fewer bugs so you can focus on shipping the next thing instead.

So then there's two options - if your hygiene doesn't give you (1) and (2) then it's pointless. On the other hand, if you do have a velocity issue because of bad hygiene, then that sounds in line with your c-suite concern.

"hey boss, our code needs to be more hygienic" - nobody cares.

"hey boss, we are at 10% of possible velocity because of issues X,Y,Z, and we can be 10X faster if we take a month to fix those" - now they are listening.

So we offered a solution to our customers, and then we could customize this by offering our own "consultant" developers. In the end, each developer had a goal to be "80% of their time billable".

Now we sometimes had to write these things called "channels", which took about 2 weeks to write. If we would have rewritten the framework behind it (which would take about 2 weeks) we could have probably sped up writing channels to less than a week! The thing was, nobody really cared if it took 2 weeks or less than a week, since the customer paid for it. My statement of 'let the customer pay for the 2 weeks anyway' never got hold (that would have probably resulted in some accountant fraud I guess, the way they set up the contract). So anyway, nobody was willing to invest this 2 weeks refactoring that would almost instantly pay itself back.

We were writing channels all the time, and it always felt like such a waste.

Sometimes in corporations, you can end up in the most crazy situations. I've seen plenty.

Maybe it is like those restaurants with dirty bathrooms. Most customers don't care, and if you get some minimum customers management thinks a bathroom makeover won't matter.

You're making it sound like having someone quit is a blocker. Some managers see that as shedding the dead weight, and keeping in the guys who are the team players with endurance. The guy who complains about code quality suddenly leaves and all of a sudden there are no more complains about code quality, and worst case scenario you have new joiners trying to onboard and cause a good impression who don't care if code is shit because their goal is to shine.

How did you solved that problem?

If it's one of the few business that has an absolute monopoly over a certain sector in a country, then the country will gradually weaken over time, until eventually it won't be able to resist a foreign competitor.

Or at least that's what market theory suggests. Of course the period of 'self-correction' could take a few months to a few centuries to fully play out, and simultaneously overlaps with all other market participants.

“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...

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 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.

* 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.

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.

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.

Not if you make a habit of it. If you do, the right way feels like the only way and comes quite fluidly. Meanwhile, the lack of PR bickering and regressions that point back to you does actually become apparent to your colleagues. Your work is not only quick, but good, and people notice both.

This is something that’s not apparent early in one’s career and the temptation to take shortcuts does have short-term payoffs during that phase. But if you stick to doing good work, you come out way ahead later on.

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."

For so many reasons, from a mentor of mine:

Quality Is It's Own Excuse.

If you can do it better, do it better.

It’s a little absurd to state “uniquely” there, because obviously, “everyone” understands this except the people that need to understand it.

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.

[0]: https://youtu.be/ZcFrFjl-RQs

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.

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.

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.

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.

> 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.

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.

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.

>

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.

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)

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.

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.

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.

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.

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!

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.

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."

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.

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.

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.

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.

I get my craftsmanship fix writing code at home. Just couldn't bear doing it at work the way I had to.

> 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.

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.

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.

... 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.

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.

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.

Discretionary effort used to be the bread and butter of my career. Now the bureaucratic and social project management overhead required for any change makes things too annoying to be worth doing if I don't have to. I don't care if the product works long term, I don't care if the company succeeds long term, I just do my tickets until I find the next job.

“oh you can refactor! Just put together a refactoring design plan and present it at the next design meeting. Then after multiple rounds of reviews and feedback, we’ll divide the refactoring plan into a series of milestones that can be tracked and estimated. Then we can prioritize it during our next planning cycle among the other features that we want to accomplish.”

If you do try the whole “never ask permission to refactor,” you’re admonished for creating a PR that doesn’t adhere to the patterns in the repository. “I like this, but we need to discuss this with the whole team.”

So the tech debt spirals away until it takes months for anyone to merge a PR and tests are so flakey it feels more like playing casino slots hitting the restart button until it builds. Agile is great.

because they know deep down if their team is not happy or doesn't smile for the photos it looks bad on them.

or like "mental health and wellbeing" its a bunch of empty gestures that make no attempt at actually addressing the issues of your work (low pay, long hours, stress, pressure so on..)

same. being proactive in a reactive job is never rewarded in my exp.

you found an issue? now its your problem. that issue crops up again in the future? you must have fucked up.

its just not worth it. the pm's and other management are too small brained and they work on negative assumptions always.

I just wanted to chime in and say thanks for writing this, and I feel seen. It describes my daily feelings to a T. I see open source projects with their great test coverage and their principled refactors, and some days I am that person too! I’ll get a burst of Do It Right energy and just knock out a ton of nice well-built stuff. And then one day all of that energy vanishes and, like the author, I CBF. Tests get skipped, code gets bolted into places I know aren’t great, and I just overall start paving the way for something I know Future Dave won’t thank me for. And even though I’m seeing it happen in real time, I don’t have the energy/motivation/whatever-it-is to get back into an inspired Do It Right mode.

(And this is all for software that I write and sell on my own.)

It was inspiring to see that the author is the creator of Lazygit. If you’re reading this, dude I LOVE lazygit so much. I’ve turned friends onto it who love it too. In my mind you’re in the category of open source maintainers who somehow always manage to Do It Right.

I'm glad you like lazygit, hopefully I can continue to keep it in high esteem :)

This is 100% normal for individual programmers. Motivation, effort, energy, willpower, whatever you want to call it: it's finite.

The draw of an organization is that it gets more done than individual programmers. The catch is that in gluing things together, there are cracks, and things fall through them. It's the responsibility of the COO, HR, product managers, etc. -- anyone getting their salary from the organizational stuff and not the technical stuff -- to make sure there are processes in place to address those cracks. To make sure someone has to "BF."

Increasingly, at every place I've worked, they just offload those to individual engineers and designers. because they're hard to measure with respect to the bottom line or OKRs. The company suffers and engineers burn out because you can only "BF" on extra little tickets and tasks that fell through the cracks for so long without getting paid more.

That circuit could be right in that the payoff is often not actually worth the effort, when viewed objectively and holistically. For example, if you literally spend two months working on end-to-end tests and it in fact does save you three whole weeks of work in terms of debugging or whatever over the course of the next six months, that doesn't add up.

I think there are some common extremes. On one hand, the business side often forces engineers to take on tech debt that really is the wrong tradeoff. On the other hand, many engineers may spend time creating a sort of idealized factorization and large test suite that in the end really isn't going to pay off. And part of that is actually just because they are worried someone else will find a nicer code organization or another test to write and judge them for not doing it.

I would say this is actually the biggest problem with tech debt, the damage to morale that it causes.

Building end to end tests is hellishly annoying and a huge amount of work if the tooling to do it just isn't there. There needs to be better drop in default frameworks for building them.

when I am supposed to fix tech debt? if every week there is another functionality going out that needs to be done yesterday? Do you think that I have to do it in my free time? Why should I even bother existing

On a mature project in a small team, the only tickets left were hard bugs that nobody wanted. The kind of bugs where you can invest days and have nothing really to show for it except crossing out some suspicions. Or maybe incorrectly crossing one out and then going on a wild goose chase until you circle back to it in a week, flustered.

You're expected to commit all of your mental energy to these tickets day after day, and then once you finally triumph and solve the bug after coffee or amphetamine binges, you turn in the code, close the ticket, and you're expected to immediately work on the next ticket.

You don't get a real break. But you can mentally rest at the start of the next ticket since nobody expects instant results. But now it's been a couple days and people are asking you what you've been doing so far—you must be blocked, right?—but you've barely started and you're pressured to invent small lies and excuses about why you're behind, each one risking yet another slip of the mask.

And when you need some time off the most, it's when you're the most behind of all and people have begun to notice, so taking the time off doesn't even seem like an option.

Me, with zero C/C++ experience, being asked to figure out why the newer version of the Linux kernel is randomly crash-panicking after getting cross-compiled for a custom hardware box.

("He's familiar with the the build-system scripts, so he can see what changed.")

-----

I spent weeks of testing slightly different code-versions, different compile settings, different kconfig options, knocking out particular drivers, waiting for recompiles and walking back and forth to reboot the machine, and generally puzzling over extremely obscure and shifting error traces... And guess what? The new kernel was fine.

What was not fine were some long-standing hexadecimal arguments to the hypervisor, which had been memory-corrupting a spot in all kernels we'd ever loaded. It just happened to be that the newer compiles shifted bytes around so that something very important was in the blast zone.

Anyway, that's how 3 weeks of frustrating work can turn into a 2-character change.

The original stakeholders are long gone, the system is too valuable to be replaced and each quirk handles specific cases that are not documented anywhere. Bonus point if it's in a semi-dead language like VBScript. Please fix.

We found an issue in the kernel bug tracking that seems to explain it, but we never confirmed for sure. Fortunately updating either of those things fixed the issue. This was of course also hard because this was back in the golden days of vmware managed by client's IT team, so getting them to update things on a VM was hell as well.

The attitude I see most often is: "the worker is replaceable and therefore expendable, but the work will always be there until someone takes care of it so burn through as many workers as it takes to get it done"

As long as the business is making money, the prospect of it continuing to make money in the near and medium term future is not in jeopardy, and the actors involved are rational, capable and trustworthy, you should always favor the worker over the work.

IME, zero sum management is an emergent symptom of a poorly performing business (maybe if we make everybody work 150% harder we’ll hit our targets this quarter), insecure executives (who don’t understand the work they manage), or poor hiring/firing practices (the only way to let somebody go is by overloading them and rewarding it with a poor performance review, or you’re hiring people who aren’t capable or don’t care).

If you’re a manager forced to make zero sum decisions and don’t feel empowered to change the root of that problem, you should probably consider leaving — good environments grow people instead of expending people.

This breaks down when you have one player in the arena acting like a snake that tries to devour everyone else(eg. Elon Musk). He has the gift of attracting an endless horde of people to burn through and then tosses them aside once they are no longer useful to him(so many examples in his recent bio). The result is that they move faster than the competition and the others eventually get eaten alive. Normally word would get out that its not safe to work for such a character but SpaceX and Tesla are among the most desired employers that engineering graduates seek to work for. Tesla received 3.6 million job applications in 2022.

I think it’s worth pointing out that some projects are worth that level of devotion, and visibly so in real-time.

But we can’t make a project worth that level of enthusiasm and attention just by demanding people to act like it is (the siren song that leads to the earlier-discussed culture spirals). Often-well-meaning people will put the cart before the horse, but no amount of quacking will turn you into a duck, etc.

On balance, it’s healthy to be skeptical of people demanding devotion to some process or objective that’s not rooted in first principles you can agree with.

It wouldn’t surprise me too much if a meaningful proportion of the 3.6m applications per year are filed by people who find the first principles behind Tesla’s culture worthy of their devotion.

But yeah, the number of companies or projects that would benefit from that style of approach is quite small. 20% is the ceiling, 10% feels closer to the truth.

But what I'm describing there is an environment where:

1. Developers are treated with respect

2. Different skill sets and different motivations of those developers are recognized

Expectation management is a huge driver of quality of life.

Knowing how to carve out your niche and not be expected to delvier feature after feature without a break is part of "managing upwards", which is another important life skill to gain.

>> you turn in the code, close the ticket, and you're expected to immediately work on the next ticket.

Yes. That's me. And then I crash.

I used to call in sick when I go from heroically solving something unsolvable to start work on a new ticket. Then O thought, this is not sustainable. My boss is all over me for all of my sick time.

So then I started to just say to my manager, hey, Mgr, amma gonna flex this whole Monday. Don't call me. Don't frakkin even think about me. Back on Tuesday, we cool?

Turns out, we were cool.

Whenever someone requires from you to be a hero, don't. Or be that guy, then take a Monday off.

Recognizing that and accommodating it is a sign of maturity for both an engineer and a manager.

> [Audience reply: Sprinter]

> Right, only somebody who runs really short races, okay?

> [Audience laughter]

> But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint.

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

don't you just have normal time off on top of sick days?

But if you're in a flexible enough situation where you can just call up your boss like that, that's great. That's what "unlimited time off" should theoretically have been before the well was poisoned. Trust that workers can manage their own mental health but not abuse it to be gone 30% of the year.

The problem is often systemic and a symptom of an engineering team not really having control over their own roadmap. You see it when an engineering team isn't agreeing to take on work, but rather being told what to work on by people outside of the team. Sometimes it's isolated to a single team, but sometimes it can be a whole org or company. It's caused by bad expectations around the amount of work that can be done and unclear priorities. How many people it affects depends on what level the bad expectations are being set at.

In practice, this is how I've seen it play out. There are 10 developers worth of work that needs to be done by X date, but we only have a team of 8. No one has made it clear what the prioritization is or if they have, that priority isn't universally accepted or changes day to day. If everything is equally important, the tough work that may not have noticeable results is often what gets pushed into the backlog over and over. To people who see engineers as the "build new features" people, it's hard to regularly justify "I can't build feature X because I have to solve bug Y" and then a week later say "I still have no idea what's causing this issue".

It's easy to say, well just get everyone to agree on priority and what a reasonable amount of work is, but that's far, far easier said than done.

This is due to their lack of technical knowledge and they have accepted this reality because the outcomes that they want do end up happening so they dont rock the boat(or know how to since they can't discern technical stuff).

I know its a great spot to be in short term but Ive been scared because long term I will be in a big hole when the next role comes along and its more like what you describe and I haven't grown to match the role. I've considered leaving once the market improves but I don't think I can fathom giving up what I have either. Alternatively I have considered staying until I eventually get downsized but that could be years. I don't know.... :/

A good personal open source project is worth more when interviewing than anything else really. Can't fake that in an interview.

For example we compile locally, then manually move the compiled code over to the server instead of using something like docker. Part of this is the restrictions we have over our environment, part of this is inertia.

Fortunately I haven't given up trying to move to that paradigm but sometimes I actually dont want to be on a modern team. Its like I have plateaued to a comfortable state that I know wont always be there but I wish it did. I hope what I am explaining makes sense.

If you don’t know or can’t reach consensus what your goals and principles are, no process will make your org functional.

You don't get what you don't ask for. If you're asking and you feel like you're being overworked and reasonable requests for breaks are denied too much, work on finding somewhere more reasonable. Sure, easier said than done, but worth it to at least try in the long run.

What kind of runner can run as fast as they possibly can from the very start of a race?

[Audience reply: Sprinter]

Right, only somebody who runs really short races, okay?

[Audience laughter]

But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint.

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

And even within frameworks like Scrum, I don't think that "sprint" was ever intended to mean that programmers are supposed to be in permanent crunch mode.

Why call it a sprint if it's not supposed to be anything sprinting? We can literally call it anything we want, so why not pick a better metaphor?

I think that many developers who say they dislike Agile really mean they dislike Scrum. I mean, a rugby scrum is pretty violent, and sprinting non-stop is a good way of dying of exhaustion.

Come to think of it, some managers do seem to want the workplace to be a ruthless battleground with worker pitted against worker in a relentless flat-out sprint to seen as a "high performer".

In XP, there was very much the idea of spending time to prepare for a sprint. Get requirements and preconditions worked out, clear out possible distractions.. Then you'd use a 1 - 2 week long sprint (aka actual crunch time) to knock out 80 - 90% of a feature with everyone on the team under high pressure and positive, constructive stress. And then you'd have some time after the sprint to work with low pressure, clean up technical debt, consolidate and build up for the next sprint.

And honestly, that's a pretty effective way to work if you plan and gear up for it.

> I think that many developers who say they dislike Agile really mean they dislike Scrum.

True say.

https://scaledagileframework.com/iterations/

If you don't like SAFe then please be specific. Which parts of it don't work if actually followed as documented?