Can't be fucked: Underrated cause of tech debt
jesseduffield.com
jesseduffield.com
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.
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.
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.
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.
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."
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.
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.
"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.
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.
- 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.
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.
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.
No no, seriously. You need a counter party to your debt. What about a divine figure?
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.
“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...
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.
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."
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.
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.
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)
> 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.
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 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.
>
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 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.
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.
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.
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.
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.
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.
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..)
“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.
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.
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.
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 :)
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
Laziness is not working hard.
What you're talking about is something else.
Sloppy or Careless work maybe?
But not lazy. If you're working 40+ hours a week you're definitely not lazy.
You can absolutely put in a lot of hours, but be putting in near-zero effort. This results in sloppy or careless work, but the root cause is the laziness of the person.
That said, I think "laziness" is only a small part of the answer. It seems to me that it's usually about an emotional response. Kind of like procrastination. The hard questions hit hard. There's a real good-feeling self-satisfaction from putting in hours of sweat.
I think a lot of times we are put in boxes, and our roles are pretty heavily constrained, such that we do not have the power to "answer the real questions." Raise your hand anyone who's had this conversation with their manager:
Manager: "Dev, I'd like you to take more responsibility, be transformational, be a 'force multiplier' for the team!"
Dev: "OK, let me make major architectural decisions without having to get approval from three levels of managers."
Manager: "Uh, wait..."
Dev: "Let me hire and fire, and build up a team of direct reports."
Manager: "Hold up..."
Dev: "Give me a budget to spend on tools, training, contractors, and so on."
Manager: "Whoa, whoa, whoa.. I didn't mean that transformational..."
> Working on X but Y is a blocker
> Okay, I can do some work with Y to help get unblocked
> No we'll let A (on a different team, maybe a different contracted studio) deal with it, here's tiny widget Z to work on in the meantime
Sometimes it means well, sometimes it feels like they don't value your expertise nor care about fostering growth. And sometimes it's just politics (especially when working with multiple different companies and contractors and all that).
There are a million reasons/excuses for people to be lazy depending on perspective.
Personally, I view people with this trait to be productivity vampires that I avoid like the plague regardless of their reasons (which in my experience are 99% excuses and 1% genuine hardships).
If someone is producing a high volume of low effort work, they are not lazy. What they are is not disciplined, or not skilled.
If someone is producing low volumes of high effort work, they are similarly not lazy, they are highly skilled and maybe a perfectionist
If someone is producing high volumes of high effort work they are a either a one of a kind savant or they are lying about the volume or effort.
If someone is producing low volumes of low effort work, then maybe we can call them lazy.
Someone skilled produces low volumes of medium-to-high effort work because they are the sort of person who would rather browse social media, or engage in office gossip, or play "call a meeting to discuss" games to avoid having to do the boring work.
If someone is "undisciplined," more often they are just lazy and are engaging in avoidance behaviors. Humans with serious executive function issues are a tiny (super tiny) minority of the workforce.
A person struggling with narcolepsy doesn't fall into the same bucket as the person who just wastes time at work so they don't have to do work.
So based on the table they are skilled, right? Are you suggesting that they are a savant in disguise and that they can produce high volumes of high effort work if they weren't "lazy"?
if the work is considered medium-to-high effort by the organization, your opinion on if it's avoiding "boring" work (which can still be low or high effort) is irrelevant.
>If someone is "undisciplined," more often they are just lazy and are engaging in avoidance behaviors.
IME it's because the employers don't trust nor want them to work on the high effort work. So either the business's most profitable software is the most boring, or the candidate is too junior (alternatively, the position and responsibility is simply filled or not valued)
>Humans with serious executive function issues are a tiny (super tiny) minority of the workforce.
Likewise, humans who can do "productive" creative work for 80 hours a week consistently, for years, is also a super tiny minority.
At the end of the day, "lazy" is relative and we haven't even established a baseline for what is/isn't lazy. So this conversation won't go anywhere. All we established in your lens is that taking breaks or doing non-technical work (meetings, even gossip depending on the line of work) is not productive in your eyes.
I have literally had (TWO SEPARATE!) people tell me, thinking it was perfectly acceptable, that they often put extra lines in their code so they can go back and clean it up instantly with auto-format while pretending they did real work.
What would you call someone who defaults to this type of behavior if not lazy? Work shy?
You've just provides your personal assertion on a non-definition. Do you actually have an alternative definition that does not imply working lots of hours?
The point is that hard work doesn't imply excessive hours. If it did, that would mean anyone who doesn't put in excessive hours is lazy, which isn't true.
> I routinely come across developers who are the real deal: they’re conscientious and judicious in an unwavering way. They set a standard for themselves and do not compromise on it. Whether that’s a deliberate thing or whether they’re just built that way, it’s humbling to witness. If there’s a flaky test, they investigate it and fix it. If there’s a bug they spot in the wild, they make a ticket, and maybe even fix it then-and-there. If a new feature doesn’t gel well with the existing code, they refactor the code first rather than hacking the feature in. They’ll dive as far down the stack as necessary to get to the bottom of something. None of these things are necessary but great developers know that if they don’t address a problem early, and properly, it will only cost them more time in the long run. [... and more.]
This sounds like a great definition of not-lazy, and it does not mention long hours anywhere. My anecdotal experience is that I usually only have 20-35 not-lazy hours to give per week; any further hours per week are much less potent. Right now I'm working 24 hours per week and I think my employer is getting a great bargain: they don't have to pay me for hours that would likely be lazy.
I think you didn't understood the problem. No one is talking about penalizing people for only doing 40hours. The problem is that code quality is never prioritized or allocated time, so you either live with it or you go above and beyond and you deal it yourself on your own time. If your team is bounded to KPIs which you don't build up by refactoring bad code or diving deep into code issues or tracking weird elusive bugs, either you are forced to pull extra hours to no fall behind your team or your performance will clearly be awful.
This is not an inevitability, though. It depends on the temperament of the company you work for. A slight majority of the companies I've worked for didn't mind allocating time for that sort of thing at all (but they did expect you to make a business case for it).
Your definition of "not-lazy" by it's very nature relies on systematically working overtime.
Investigating and fixing flaky tests is either explicitly covered by a ticket, and thus a part of run-of-the-mill tasks, or something a developer does in unscheduled tasks by going above-and-beyond including in work hours.
Finding a bug, creating a ticket, and working on it is not proof of non-laziness as that's a part of the basic job description.
Refactoring a feature is either tracked by a ticket and covered in normal ticket-assignment processes, thus not a demonstration of lack of laziness, or it's something you do in your own time.
You have to clarify where you find the time to do all that "above-and-beyond" stuff because it's either normal work done on normal company time, which surely doing the normal/bare minimum is not proof of not being lazy, or it's going the extra mile, which is certainly not done during normal office hours.
> You have to clarify where you find the time to do all that "above-and-beyond" stuff because it's either normal work done on normal company time, which surely doing the normal/bare minimum is not proof of not being lazy, or it's going the extra mile, which is certainly not done during normal office hours.
At every company I've worked for, I've had time for "above-and-beyond" stuff during normal office hours. That's just how low expectations are in my neck of the woods. Or maybe I'm outrageously talented and I would still excel working on some elite FAANG team... but I doubt it.
Irrelevant, and reads as a non-sequitur. OP expressed his personal assertion on laziness, not productivity.
I think it's a notion worth considering in such a conversation.
Try to lie about how long will it take. Just today I finished* 1-month almost total rewrite of firmware for one of devices at my work. It started as a 1-week small rewrite of part of communication module for a small bug and was scheduled as that. But I've got chill PM and coworkers who will appreciate that now we can actually fix some 8yr old bugs in legacy parts of that code.
* well, now some testing of edge cases and another round of fixes but at least remote code updating works so we can ship those devices...
Edit: "Lie" is call to action here, there were some misunderstanding in comments. Previous start of my comment was "Lie. ..."
Have you considered that perhaps your personal perspective is not exactly representative of large swathes of the industry and that many (if not most) workers do not have the agency and/or leeway to place place themselves in a comparable situation?
I wouldn't be so cut-and-dry with your assertion that the parent post is "lying".
yetihehe is not accusing the parent poster of lying, they're telling them to lie. To claim the work will be X (just the feature, perhaps), and then slip in the extra work (tackling tech debt and other issues), and letting the work schedule "slip" (which they can do because they have a "chill PM").
> Have you considered that perhaps your personal perspective is not exactly representative of large swathes of the industry
Yes. HN is place for ALL kinds of people, sometimes they are not even programmers. Many tips are not applicable to everyone here.
In that case, I would heavily disagree with your suggestion. Your "chill" PM is likely actively running interference on your behalf in order to allow you to spend time on such endeavors. It's a great thing when you can have such a partner, but most PMs (in my experience) are not willing to put themselves on the line like that.
Do most software engineering jobs not have good PM's? Asking since I started my first real software engineering job last year, it doesn't pay the best but the PM is great and very hands off. I wonder if that itself is worth holding onto the job a while.
If you have management that you like working with, and the work is pretty good, yes, that in and of itself is a pretty good reason to stay for a while.
Let me tell you the tale of a man named Sisyphus...
I have never in my professional career seen a solo developer rewrite something from scratch successfully in isolation. It almost always turns into the developer leaving, either because they became burnt out being the sole SME, or it fluffed their resume enough for them to find a new job. Everyone else on the team is left holding the bag.
I'm actually more surprised your manager/PM let you do this. Most of the time this happens as a skunkworks thing.
Rewrites should always be incremental, never big bang, and never in isolation.
> I'm actually more surprised your manager/PM let you do this. Most of the time this happens as a skunkworks thing.
I didn't know it will take so long, delving into this was like a frctal of bad code. When I've tried to fix something, it required fixes in other places which required fixes in another places. I could make several TDWTF posts from that code.
> Rewrites should always be incremental, never big bang, and never in isolation.
Yeah, but that codebase was not that big, so it was medium size bang. Never in isolation - there was no one other at my company who could actually do it and it was tested functionally by others once it was stable enough.
First phase was about 4 years. Second phase started, and I was there in year 2 of that. 6 month contract on my part. Took me months just to figure everything out.
Background - the core engine was PHP. The 'rewrite' was also PHP.
I left, and got some updates from a few folks later. They hired some python and JS people ("we can't find/hire any PHP people!"). And... they gave the python and JS people greenfield "rebuild chunks of this system". And months later, this was all spun as "PHP sucks, node rocks". Because.. well... look what was getting done. They couldn't hire many PHP folks because... they weren't paying terribly well compared to the level of skill required to deal with the core engine.
This was far less about tech as it was management. Giving a team of JS people who are all colocated, have a working system to inspect and emulate, can choose their own tools, and are given a long time frame... it's not all that surprising they had some success compared to "let one guy go off on his own and don't talk to him for weeks at a time".
Looking back, the second guy was trying to recreate much of the flexibility of the first system, but in a 'modern' way, which was very much not a great idea (the complexity and flexibility were the core problems, from what I could tell). The node and python teams avoided implementing much of the flexibility, and they could get away with it a bit more because by that time the business was more established, and had a better understanding of what they needed and what was not.
Part of how I viewed it was "it took 12 people 8 months to recreate 20% of what one person did in PHP in a couple of years". But that's certainly putting an overly pro-PHP spin on it. ;). By all means, though, having just one person be the sole person who knows 90% of the system, with no time given to train others... huge red flag. Took me a few months to suss out just how precarious that was, and I understand the business need to spread out the risk. Was just very annoyed that the "rebuild" decision was spun as "php sucks" instead of "solo-expert-working-in-isolation" sucks.
It's not lying to your boss, it's part of doing quality work.
Of course you shouldn't let perfect be the enemy of the good. You do still need to ship. I'm just suggesting that you don't let your boss know the ways in which you can increase your tech debt by cutting corners.
Of course, it sounds like you have buy-in from management for these quality standards. For people who don't have this kind of buy-in for the whole team, they'll have to work individually to maintain quality.
I've been in a similar situation and our approach was to make a business case for the rewrite.
* Original programmer who was the team lead was gone and had no interest in consulting for us
* Code was thousands of lines of completely uncommented 8051 assembly language
* Code had known bugs
* Bug fixing and documenting/understanding would likely go on for months
* We could not integrate the rest of the system functionality without a complete understanding of that undocumented code
* We were confident that one person could rewrite it in less than six weeks since we had complete knowledge of what it needed to do.
And then left it up to management as to what was the best approach. They were making a completely informed decision, but phrased the way we did, no reasonable person would have told us to continue with buggy, undocumented code that was at the heart of the system we were building.
I'm often on the receiving end of completely unrealistic estimates. It would piss me off to no end to find out that someone lied about how long they expected something to take.
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.
But humor me with an explanation, please...
Agile lets you manage expectations and set boundaries by scheduling a finite amount of work into a bounded amount of time.
There's a reason I don't work there anymore.
AFAIK, it does nothing to help here. But a solid leadership does help.
When it's an agile project, either devs will choose to do the right thing, or too many developers will work on new features, whether because it gives them more visibility or because they like working on features more. And when it's not agile, either you have a product/team manager that understands the importance of not drowning in tech debt, or you have a manager that constantly prioritizes features over quality.
Neither approach guarantees that the right choices will be made, just that in Agile, the developers mostly have themselves to blame.
It's funny that Agile is always something else. It cannot be criticized because then your are doing it wrong. It's like a theory which is not falsifiable.
don't get me wrong agile is an improvement in the sense that iterating on small deliverables is better than a single giant waterfall process, no disagreement there
but yeah if your tool never delivers in the alleged benefits, ever, anywhere, then it's not good enough to say the problem is the people
tools are welded by people
if your tool doesn't take that into account and assumes and requires its users to be perfect, well, then it's not a very good tool
I don't care what the theoretical outcome is when the practical one is always this.
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".
If you don't like SAFe then please be specific. Which parts of it don't work if actually followed as documented?
> I think that many developers who say they dislike Agile really mean they dislike Scrum.
True say.
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.
If you've never watched Simple Made Easy I really recommend it: https://www.youtube.com/watch?v=LKtk3HCgTa8
Agile causes a lot of those problems. GP just described all the elements of agile, "pick up next ticket as a on as one is closed", "blockers", daily status updates, etc.
meanwhile doing maintenance on an existing system in an agile environment, esp with kanban, is very often literally what the poster is describing, an endless slog through tickets that aren't particularly noteworthy and thus don't really merit much consideration or celebration when done etc
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.
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 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.
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.
>> 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.
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.
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.
Clients and customers see us as efficient, but it's really just a matter of being so lazy that we don't let technical debt pile up on us and make us have to actually work hard later on.
You can get away with it in corpo-coding too, but you need to earn some freedom and have the right team members around you.
How do you find such places? I've been very curious about part time software work but knowledge online seems to suggest that freelancing is the only route there.
Funnily enough, I wanted to find such a job precisely so I could make my own stuff on the side, which will inevitably involve some signifigant open source contributions due to my tech stack. I've thought about simply being a paid member and essentially double dipping, but that route seems even rarer.
In my case I started writing stories of automated farming communes, compiled my writing in to a zine about a better world, had 260 copies printed and handed them all out, got my then dream job at Google X robotics, then ended up handing a copy of the zine to a robotics engineer and philanthropist who now funds my open source work as we push towards continuous crowd funding as our long term model.
Your story will go differently (lol) but what I can say is that defining your vision, building the appropriate skills, and telling everyone that you can what you’d like to do probably helps a lot. You may have to stick with the unfulfilling job for now, but you can try to build an exit strategy.
you should bother existing to push back against economic forces that push us to work too much and feel bad that we aren't working more. you should exist to teach your colleagues that taking the time to consider the broader implications of your work is important. you should exist to contribute your opinions to communities like this one. you should exist to eat chocolate and walk your dog (if applicable). you should exist to listen to Alan Watts lectures on YouTube. You should </ran out of tokens>
You are blaming the system S. However we have counter-examples where the problem P occurs outside of the system. If P occurs without S then possibly S is not the cause. Admittedly untangling causation, sufficient and necessary is difficult.
The article itself appears to be a counter-example that is non-commercial: where problem P occurs without system S.
I think it is worthwhile investing time to work out for yourself when to honestly blame commercial constraints, and when to recognise other root causes. Blaming the system by default is unhealthy IMHO.
It doesn't take more than a couple minutes to throw up a task about an issue you see. That issue then becomes the tech debt.
Leadership is responsible for prioritizing tech debt and ensuring a certain burn down of that debt.
Note that sometimes you burn down tech debt by deciding you won't do a thing, that is perfectly fine as well.
The point of the tech debt song and dance of log, verify, handle is to give a second pass at "not right now issues". Sometimes your instinct was wrong, there wasn't a need for X, othertimes it was right for reasons that weren't in your headspace.
Most importantly some amount of "I can't do this now" work is actually important. But if you don't take the time to look at it you won't find it.
It takes little effort. Writing things down helps you reassess your choice. And it serves a good starting point for future revisiting. It also keeps you honest (certain culture promotes a pretence of perfection). Even if it becomes someone else's problem later, they'll be grateful for the explicitly.
The tech debt will occur anyway, so you might as well make it visible rather than invisible. Knowing what you owe is the first step of repayment.
And those that do know about the technical debt will often say "We'll fix these issues after the release" which is either a bold-faced lie or they believe it even though it never happens.
If you are writing code for fun, then avoiding the “ugh field” is perfectly fine.
If you are being paid, then “can’t be fucked” is not, in general, an acceptable excuse. (At very least, not in any teams I have run.)
I think people often feel pressure to “do it right” when building hobby projects, which can lead to maintainer burnout; unless you are being paid there is no obligation to engineer with safety tolerances. Artisanal hand-crafted code is fine in that case.
Like, in our first configuration management, we were strict and anal about testing everything. Add a new property for a config file? Needs a unit test for the default value, needs a unit test for overriding the value. This resulted in so many dang tests, so it was great, wasn't it? Eh. You kinda change one default value and 32 tests across multiple cookbooks fail and it's a big hassle. So you stop changing and improving things.
In our new configuration management, we're much more coarse about testing. Setup a consul server, setup a patroni cluster, see if the patroni cluster elects a leader and ships archives to pgbackrest. If it does, the important 90% of the system is probably setup right. Maybe check that a few important metrics are shipped via telegraf and filebeat looks at the right logs, too, that'll be 95% - 99%. The other 90% going wrong after that won't be caught in tests anyway because they tend to be based on business needs in prod.
Once that works, why bother testing that ansible can write a variable into a file if the template is changed? Maybe if there is some computation in there, but more often than not, these computations are hard to setup correctly in a test environment, so eh.
This is similar to how someone gave me shit years ago about not writing tests for the initial configuration loading and dynamic module loading of a custom application server. The thing is, if I break this in a way I didn't catch, it will break QA and every single local test as soon as I push that and many people will yell at me.
Half the time folks will still make (something close to) the requested change. The other half they indeed CBF and just merge it as-is. In those latter cases, I'll be slightly disappointed, but I'm also consciously telling myself that honestly, it's often a fine reason, and if it's really important, I can still consider doing the work myself.
I believe this is the key insight here, and behind every rockstar developer there's just a person that probably has a lull from time to time as well.
I find it similar to having kids. Most of adults have them, but the impact they have on their lives is so different. It all depends on financial situation, support from the rest of the family, friends, health situation..
In many cases this is not a different league, but an entirely different game with different rules and goals.
The article calls the lack of pro-activeness a CBF, but that is a symptom and not a cause. The fact that you CBF might not necessarily be a problem with you. It could be that you are in a different frame of reference compared to some other people who "do things perfectly".
Maybe moving maximum amount of Jiras into a done state is valued more than delivering this excellent refactoring. Maybe skipping unit tests and dropping feature branch to testers is perceived as a more pragmatic approach. Maybe your perfect commit will be unrecognizable a couple months later, because company is "moving fast".
People with great jobs in great companies will not understand this and call it laziness, procrastination or any other thing that will put you at blame. Just like people with great families will not understand what it means to have abusive parents.
Software development is about processes, but often developers have no say in setting up those processes, there is no feedback loop. Some naive manager will push to maximize some theoretical metric. In some cases you can adapt, circumvent certain obstacles, but sometimes you just CBF.
Many people can’t be fucked to pay certain debts. Medical bills? I don’t give a fuck, if my insurance didn’t cover it you’re shit out of luck. No I’m not logging into some website and putting in a credit card to pay. I don’t got time, and I don’t give a fuck.
And some go further. Student loans? Can’t be fucked to pay. The interest keeps growing and wipes out any progress you make on payments. So fuck it, don’t pay.
There’s even exercise debt. People let fat build up in their bodies to unhealthy levels, and they know they should pay down this debt to themselves before it kills them, but they just can’t be fucked. They stay fat.
The best way to deal with debt, is to never take the debt in the first place.
In all my years, I rarely see tech debt get paid off. What is more common is the team declares bankruptcy and builds up an entire new project to replace the one that was indebted.
Worse, if you do pay tech debt off, it encourages taking on more debt in the future since there is a precedent for it getting paid off. It makes your tech credit score go up.
I say "perfect world" because:
- everything is under my control, I worked hard to reduce my dependencies
- I have only about 10 people to care for, and they largely stay the same
- I have no other goals than time reduction and liberty; both go hand in hand
I am not sure this is possible in companies.
Sometimes TODO comments describe a strict deadline, they read almost like apology letters!
Most likely 70% of th e ticket owners don't even work here anymore
If someone else does it yeah cool, nice. Otherwise it's too much work.
* The DIR (do it right) tooling, which always is in limited supply, is best for building things that have a high lifetime impact. It could have direct impact; it could be a gear in the foundation of many future products.
* The CBF tooling is for low lifetime impact work. Inevitably, because you are human, you'll use your CBF tooling at times. Know when that is happening and apply it to the right project: For example, the quick script to clean and transform some unique data.
In other words, the advice in life is always the same: Know thyself.
Most us started out with a lot of enthusiasm for programming, but for some it slowly eroded along the way or the novelty wore off. To me, it's a mystery why some people can maintain their passion in the long run, for some it's on and off while for others it completely dies at some point.
I also find it funny that Australians felt the need to turn the "can't be bothered" expression into something slightly stronger, if the author is right about this.
I’ve also 100% had lulls where I just hate it and cannot be bothered to do my job or do it well, I think it ebbs and flows with what you’re being asked or required to do.
But I feel fortunate that I still enjoy programming for the most part (though not as much as 20 years ago) and haven't had too many situations where I had to force myself to do something that I would rather not.
The first relates to feedback clarity.
For someone at 98% in a class or life, the few next things are easy to see and focus on, and are typically small delta's from the global maximum.
But at 60%, there are many things to fix and many directions to local maxima.
Someone who can make headway from 60% is far more skilled than someone who makes improvements from 98%. Their adaptive function is much more complex and comprehensive. (I would also argue they create more social value to go from 60-75%, but that depends on output utilization.)
It's roughly same with the range of early-late stage companies, with 40%-95% clarity.
The second aspect is, well, dependent co-arising: you're adapted to the difficulties you've had, so you can tolerate or solve them better than most -- leading you to prefer those situations over new ones, even though the new ones are objectively better. In a sense, you're maximizing your activation rather than benefit. It's a bit of a trap since any detachment requires de-activation, which is (a) opposite of what you previously valued and not exciting, and (b) typically confronts one with the exported costs of one's prior focus.
A benefit of recognizing misperception is to counter it where it reduces value.
CBF is essentially the saturation state for incentive vs difficulty, where no additional incentive or ease will induce further activation. This is actually the goal state of bureaucratic organizations working via validated processes or people minimizing cost/maximizing slack at work. So: not always bad, but certainly not exciting.
The answer is to step out of the equation. Have other engaging activities (or businesses) such that time/resources wasted in one is quickly pruned to shift time/resources to others. Do this enough and you can't be trapped, because you're familiar with the hype/deflate cycle of coming and going. You might also be less daunted when struggling at 60%, and less full of yourself when sailing at 98%. Because these switches entail incommensurable decisions, they exercise what might called be your moral core, you identify a bit less with your roles, you can approach new tasks and new people with openness, and you might spend more time just being.
I've noticed something a lot of successful people do is they always operate at that level. I only do when I'm feeling good: well-rested, ate recently, stress levels moderate.
But I've practised at it and I'm getting better. For things you care about, it's always worth taking the shot.
Computers were always sold to me as assistance and aids in order to automate tasks so I can enjoy my life more. I think this not giving a fuck attitude is directly part of this. If the thing works, it'll probably do and I can go back to enjoying the sunshine rather than sitting in some dank cubicle trying to be awesome.
There are really just three things: 1) existing code that does not need to change, 2) existing code that should change and 3) non-existent code that should exist. Yay for 1 and are we working on 2 or 3 today?
(It's attributed to Urban Dictionary, but not listed there; just with the addition of 'I' which has a different definition not mentioning Australia.)
Pouring tons of effort into personal projects doing things that you CBA to do for anything else? not being able to prepare minimum repros because reporting the bug itself was the most that you could manage? eh. My case of ADHD in a nutshell.
I didn't have medication for the majority of my life and I got plenty done. I just had a certain degree of executive dysfunction that's hard to describe, but manifested itself as basically losing every hobby whenever I got bored (which is not supposed to happen nearly as much).
I didn't even know it was a thing that just happened to people (and had a name like ADHD) until about a year ago. I seriously just thought I was lazy or "couldn't be fucked".
So it could totally be ADHD, speaking as someone with severe ADHD who also did not know it was ADHD for quite a while.
If building a test framework was fun once and isn't fun again, I don't fault the builder.
1. Burnout happens when we don't believe in a cause or our belief in it is unjustified, whether we realize it eventually or intuitively understand it without it being conscious yet. In all three of these cases, the reality is just that it's not worth doing in the bigger picture.
Obviously, the question of why something is worth doing is complex. I'll admit that there's plenty of reasons for doing things that we ourselves aren't aware of for a long time.
I had a passion and almost obsession for solving software problems for decades, and I didn't know why, but I just followed the flow throughout it all. Eventually it led to a short-lived career, and the only concrete result of it so far is immaculatalibrary.com, but there's also the extremely in-depth knowledge and understanding of logic that I gained from it all.
Honestly I'm able to continue to work very steadily on immaculatalibrary.com, making incredible progress in the past month alone, without any burnout, because I fully know that it's worthwhile, even without explicitly being able to describe why.
Countless reasons for writing software are purely insufficient. Money, fame, solving problems we think are huge, inflating our egos, etc. Fortunately I have no following for my pet software project, so none of these things cloud my vision, and I'm able to focus on it for what it is, and for its only clear and immediate end: publishing and digitizing certain public domain books I find useful and think other people should also.
2. Burnout also happens when we realize that we're building a mansion on top of a pile of garbage. When my site was written in Jekyll or Node.js + Express.js + Postgres + Pug or any other technology I experienced with, it was incredibly hard to move forward and make real progress. I had already resolved to maintain the website indefinitely, but I gave up on it intermittently when I made it too difficult for myself to make literally any changes to the website, sometimes for months on end.
The solution for me was to start from absolute scratch, examine the principles of how I wanted to write the site, build it slowly according to that, re-examine these principles regularly in light of what I had already made and how it was working out, and evolve and update my method accordingly.
And honestly, during most of the past 2 years, I had a website building app that I am not proud of at any of those iterations. But I am proud of what I have now. And it's very possible that I won't be proud of it in the future for what it is now, in the same way. But that doesn't quite matter. As long as I'm proud of it in the moment, and happy with it, while admitting to myself that it's an evolving WIP, and knowing full well that this is always going to be a dynamic process for myself, then it's good enough for the purpose it has.
But that's just the nature of software. It's never finished, but it can be finished in the moment for the job you need at that moment, as long as you examine what the job is and what it should be. The only way I've solved burnout for myself is making sure that the source and destination are satisfactory to me and that I'm fully honest with myself and open to the facts.
Some of us are apparently built to be fixers, solvers, and supporters. We are the elves at night that are not seen, but problems that would have happened without us now don't happen. And a problem that doesn't happen is a problem that's not noticed.
However, that drive to make things better eventually gets bogged down by the apparent lack of care or concern by many other people which leads to more new problems that often shouldn't exist. At some point, you step back and say, "Perhaps if I stop making things better, collapse will come sooner and then people will wake up and decide to pay more attention to their actions and outcomes."
Technical debt is sometimes an intentional trade-off between short term and long term goals. There are times when we would agree that we can cut some corners or not plan for certain expected futures because our time is precious and limited.
When such decisions are weighed before taking action, technical debt is acceptable. But when people are either too inexperienced or simply don't care, the tech debt is just wrong.
What's even more demotivating is watching inferior tools become the most successful, especially as those tools seem to attract the kind of developers who don't see or don't care about software and system quality. These are the people who, when you show them an alternative approach (which has less risk or long term cost - and even without much additional upfront cost), they inevitably say, "Why would you do that? This works fine." And so you end up with 200 line functions, horribly tight coupling everywhere, copy/pasted blocks of code everywhere, etc.
Another demotivator is when key decision makers are too comfortable with "how it has always been done" and are unwilling to grow to the new challenges and company size. You could hustle and deliver proof of concepts which show how company wide shared architectures would reduce effort across most teams (silos) while increasing reliability of systems... and ease of employee migration from one team to another. But after doing things like this and making traction perhaps 1 in 10 times, you eventually decide it's not worth trying. CBF. Meanwhile, the same tech leader is constantly harping about our need to hire more engineers. So clearly, the answer is not work smarter, but throw more people at it and build more variations of tech debt. (When a new engineer is faced with maintaining a debt-ridden legacy project, they don't stick around long.)
I'm sure every profession has some version of all of this, but our seems especially nasty in this regard. I used to balk at the idea of professional certifications before one could be a software engineer, but now I think it would be worth it. Everyone should have to understand and demonstrate more than just passing Leetcode challenges to work in this field.
my advice to future coders is to try to put your entire project into a single file...you'll have to drop every bright idea, abstraction, layer, etc just to make it palatable...and the world will thank you
My advice to future coders is to never do this. Clearly we don't work in projects or IDEs that are in any way similar.
“The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future”
A Philosophy of Software Design. John Ousterhout
That's like saying "everything is well-understood and well-planned".
Tech debt is project debt not developer debt