[HN Gopher] Can't be fucked: Underrated cause of tech debt
___________________________________________________________________
Can't be fucked: Underrated cause of tech debt
Author : todsacerdoti
Score : 237 points
Date : 2023-10-12 16:21 UTC (4 hours ago)
(HTM) web link (jesseduffield.com)
(TXT) w3m dump (jesseduffield.com)
| lnxg33k1 wrote:
| I tend to consider bullshit any point that finds somehow
| acceptable thinking that people is lazy, in this society, in this
| world, on this planet, ffs we have to work 40 hrs per week per
| decades and rest after reincarnation, and you want to talk about
| laziness? Let's talk about how any bit of mental energy is
| extracted to built other's wealth and then when you are too old
| to do nothing other than watching work in progress they just spit
| you out
|
| 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
| qup wrote:
| Being not-lazy in your work is not the same as working lots of
| hours.
| bluefirebrand wrote:
| No, this is absolutely not true.
|
| 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.
| Proziam wrote:
| Most people consider low-effort to be 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.
| winwang wrote:
| I agree. I see it all the time. Huge amounts of hours
| being wasted "working hard", and running away from
| answering the real questions which would double the
| (positive) output in half the time.
|
| 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.
| ryandrake wrote:
| > I agree. I see it all the time. Huge amounts of hours
| being wasted "working hard", and running away from
| answering the real questions which would double the
| (positive) output in half the time.
|
| 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... "
| Proziam wrote:
| Lazy is a convenient catch all for "This person lacks the
| emotional fortitude to do the work when the option of not
| doing the work presents itself."
|
| 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).
| bluefirebrand wrote:
| > This results in sloppy or careless work, but the root
| cause is the laziness of the person.
|
| 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.
| Proziam wrote:
| You forgot the most common case:
|
| 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.
| ferbivore wrote:
| What's the difference between "lazy" and "serious
| executive function issues"?
| Proziam wrote:
| Emotional vs Medical.
|
| 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.
| hightrix wrote:
| Some people consider themselves to be "working" while
| browsing HN or reddit while they are "on the clock". That
| is being lazy while working.
| shaneoh wrote:
| I wonder how you measure balance between being lazy vs.
| not lazy by this definition? I agree with you, but it's
| not like it's feasible to remain full-on focused on
| coding or meetings or documenting for 8 hours straight
| each day.
| hightrix wrote:
| Really good point. There's a big difference in checking
| HN in the 10 minutes between meetings vs spending 4 hours
| after noon reading and replying to threads.
| rewmie wrote:
| > Being not-lazy in your work is not the same as working lots
| of hours.
|
| 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?
| adrianmonk wrote:
| Yes, work a normal, reasonable number of hours (let's say
| 40), but while you're there, give it your best.
|
| 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.
| default-kramer wrote:
| From the article
|
| > 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.
| lelanthran wrote:
| Yeah, but that diligence takes time, and now you have to
| work on extra hours to keep up performance metrics with
| the rest of the team.
| JohnFen wrote:
| If I worked at a place where I was penalized for "only"
| putting in 40 hours of solid work per week, I'd be
| energetically looking for a job elsewhere.
| MHard wrote:
| I can't speak for the original poster but one thing that I
| noticed is that from time to time it happens to me that
| despite not having a tight deadline I tend to not go all
| the way in avoiding tech debt. One example would be that I
| had a problem in one of the microservices with a version of
| a docker image that wouldn't run on an M1 mac. I fixed it
| in that repo but didn't do the same changes to other
| services with the same issue. Changing the other services
| would have taken me less than half an hour. This is the
| kind of laziness that the article and qup are referring to
| I believe.
| bakuninsbart wrote:
| Isn't it quite obvious that productivity does not scale
| linearly with time worked? Consistently, I can work 4-6
| hours a day at full productivity, and I have to choose less
| demanding tasks for the other 8-10 waking hours to maximise
| my productivity and well-being. This is also what I observe
| in my peers, and while there might be outliers to this, I
| think the stretch is far less extreme than propagated by
| some influencers.
| rewmie wrote:
| > Isn't it quite obvious that productivity does not scale
| linearly with time worked?
|
| Irrelevant, and reads as a non-sequitur. OP expressed his
| personal assertion on laziness, not productivity.
| yetihehe wrote:
| > when I am supposed to fix tech debt?
|
| 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. ..."
| Chabsff wrote:
| > But I've got chill PM ...
|
| 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".
| Jtsummers wrote:
| > 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").
| yetihehe wrote:
| Exactly, thanks for putting it so clearly.
| yetihehe wrote:
| I didn't call him a liar, I told him that he should lie
| about what he does. Sometimes you need a little lie about
| how long will it take and ship good code a little later
| than bad code on time.
|
| > 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.
| Chabsff wrote:
| Oh, my bad. Thanks for the clarification.
|
| 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.
| yetihehe wrote:
| Staying in a place where everything is stacked against
| your excellency will mean you will not gain excellency.
| Whether just bringing some money home is enough for you
| is only up to you, but then don't complain that you can't
| do anything nice, it's just whining at that point. Saying
| all that I don't condemn people for working in boring
| shitty places. At least typically they try their best
| anyway and make world a better place bit by bit.
| ryandrake wrote:
| I've seen these people called "shit umbrellas". If your
| life as a developer is relatively chill and drama-free,
| in all likelihood you have a hero PM, PjM and/or EngM
| using themselves as the shit umbrella to shield you from
| all the madness being spewed from up above. Those are the
| best teams to work on.
| HeyLaughingBoy wrote:
| I just replied to /u/yetihehe. That is a perfect
| description of the PM we had on the project I was talking
| about. She was amazing!
| robotnikman wrote:
| >Have you considered that perhaps your personal perspective
| is not exactly representative of large swathes of the
| industry
|
| 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.
| eschneider wrote:
| PM quality varies a lot and is hard to judge when
| interviewing for most IC roles. (As in, you often don't
| get to talk to those folks directly. You can ask probing
| questions of other folks, but feedback is a bit of a
| crapshoot.)
|
| 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.
| shaneoh wrote:
| Where is the lie exactly?
| afterburner wrote:
| I though he was suggesting OP should lie in order to look
| better?
| candiddevmike wrote:
| I rewrote something from scratch, now we can finally fix all
| of the old bugs.
|
| Let me tell you the tale of a man named Sisyphus...
| yetihehe wrote:
| Yeah, but that rewrite actually fixed a lot of other old
| bugs which we had to circumvent on server side. Before
| rewrite the code was just ugly spaghetti mess (interrupt
| routine of usart port was longer than main).
| candiddevmike wrote:
| The problem is you most likely introduced new bugs,
| created new build/test toolchains, and your team knew the
| previous codebase, probably quite well.
|
| 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.
| yetihehe wrote:
| I agree with all of your comment. This was indeed pretty
| unique case. No one in my small company (including me)
| actually knew that codebase, it was total mess written by
| original EE (who sayed himself he was not a programmer),
| it was pretty small (32kb of rom puts a limit on your
| codebase) by "team of programmers" standards and
| currently we have no one else who could actually do
| anything with that code, one coworker is learning to
| write firmware and new version is already much more
| readable and reasonable. It was TOTALLY in need of
| rewrite, but not all code is a good candidate for
| something like this.
|
| > 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.
| jacobyoder wrote:
| I saw this scenario happen. Startup, one person wrote an
| insanely complex engine that did a lot of stuff; allowed
| them to scale up, get funding, etc. But... it became a
| complexity nightmare. The answer was... hire a new single
| expert, and let them rebuild a bunch of stuff, and...
| there were now 2 insanely complex layers, one of which
| sort of knew how to interact with the other one. The
| first person had gone, and the second person ... just
| didn't come in the office much (2-3x/month), and... was
| 'above' all the 'day to day' needs.
|
| 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.
| justin_oaks wrote:
| In the same vein, don't tell your boss that you're going to
| refactor something, add tests, or write documentation. These
| are implementation details that you bake into your estimates
| and are part of doing software development. Your boss likely
| has no visibility into the tech debt in your codebase.
| Talking about refactoring, tests, and documentation gives the
| boss the opportunity to say "No, don't waste your time on
| that".
|
| 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.
| nradov wrote:
| What we did is to explicitly list bringing any touched
| modules up to current coding standards as an explicit item
| on the definition of done. That way team members were
| expected to include any necessary refactoring and test
| coverage expansion in their story point estimates.
| HeyLaughingBoy wrote:
| Read your comments later about the specifics of what you
| rewrote.
|
| 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.
| hombre_fatal wrote:
| That's how I burned out of software.
|
| 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.
| vegetablepotpie wrote:
| Agile solves a lot of these problems.
| reflectiv wrote:
| What kind of stupid statement is this...no it certainly
| does not.
|
| But humor me with an explanation, please...
| fnimick wrote:
| Does it? At one of my former jobs management would
| regularly pressure engineers into doing late nights at
| sprint end (every other week) if we were "behind". Then if
| we finished things a day into the next sprint, the PM would
| backdate the completion to make it look like we had hit the
| previous sprint, since sprint completion percentage was an
| OKR and people's bonuses and promotions depended on it.
| Then since we hit the sprint, obviously our velocity had to
| go up for the next one, even though we were starting a day
| late from scrambling to "finish" the last one.
|
| There's a reason I don't work there anymore.
| robbintt wrote:
| Name & shame
| HeyLaughingBoy wrote:
| Pretty much everywhere, unfortunately.
| zimzam wrote:
| The expectation that engineers work overtime to hit
| arbitrary metrics can't be fixed by a process like scrum
| or waterfall though. Process can't replace competent
| management.
| lowbloodsugar wrote:
| Agile done right solves these problems. I have yet to see
| Agile done right, even once. And I've done XP since ~2003
| and Scrum since 2006. It is now clear to me that Agile does
| not solve these problems: a solid leadership team solves
| these problems, and sometimes solid leadership teams use
| Agile (whether formally like Scrum, or informally, like
| just good communication). But Agile is the canary in the
| coal mine: it reveals very quickly if you have a solid
| leadership team or not.
| marcosdumay wrote:
| Agile done right is about some completely different
| problems.
|
| AFAIK, it does nothing to help here. But a solid
| leadership does help.
| tremon wrote:
| To me, "agile" in these discussions only apportions
| blame, it's orthogonal to the quality of software.
|
| 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.
| augustk wrote:
| > Agile done right solves these problems
|
| 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.
| bedobi wrote:
| no true scotsman is all agile advocates have
|
| 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
| sodapopcan wrote:
| I've worked in an "agile done right" situation. It
| certainly wasn't a utopia but the best experience of my
| professional career so far (14 years).
| edrxty wrote:
| %s/solves/creates/
|
| I don't care what the theoretical outcome is when the
| practical one is always this.
| liveoneggs wrote:
| Now, of course, everybody is going to start moaning, "But I
| have all this speed. I'm agile. I'm fast. You know, this
| easy stuff is making my life good because I have a lot of
| speed."
|
| 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...
| romanows wrote:
| Agile isn't meant to imply speed in the sense of LoC/s,
| though right? The speed in Agile is about getting
| customer feedback sooner rather than later (so maybe a
| kind of latency?). I don't think sprints are mentioned in
| the Agile manifesto or related materials.
|
| 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.
| rpeden wrote:
| Words matter, though.
|
| 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".
| nradov wrote:
| The Scaled Agile Framework (SAFe) simply calls it an
| iteration. This is a neutral term with no implications
| about the pace of work.
|
| https://scaledagileframework.com/iterations/
| sodapopcan wrote:
| Many people call it an "iteration".
|
| > I think that many developers who say they dislike Agile
| really mean they dislike Scrum.
|
| True say.
| lambersley wrote:
| Perception. Interpretation. Either way, "sprint" is
| intended to imply short burst, definite endpoint that can
| be seen. A Burndown is about measured capacity. The only
| actual speed that matters is time to failure, i.e. "fail
| fast".
| tetha wrote:
| If I recall right, Sprint originated from Extreme
| Programming, a predecessor to current agile methods.
|
| 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.
| dpe82 wrote:
| There's a theory of "Agile", and then there's the reality
| of how it ends up being practiced in almost every
| instance. The latter is what matters.
| liveoneggs wrote:
| take it up with Rich Hickey I suppose :)
|
| If you've never watched Simple Made Easy I really
| recommend it: https://www.youtube.com/watch?v=LKtk3HCgTa8
| marcosdumay wrote:
| How?
| mateo411 wrote:
| Agile can help, but I think a vacation/time off is better
| approach in this scenario.
| miroljub wrote:
| It's not that I don't believe you, I'd just enjoy reading
| an explanation how it solves the problems parent talks
| about.
| danwee wrote:
| How so? If there are boring bugs to be fixed, someone will
| need to fix them regardless of the methodology used.
| Humdeee wrote:
| Eureka! If only it was this easy...
| lelanthran wrote:
| > Agile solves a lot of these problems
|
| 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.
| bedobi wrote:
| no it doesn't lol it literally causes them? i'm no
| waterfall advocate but at least with waterfall there's a
| clear beginning, middle and end to a software project with
| intuitive places for work, rest and celebration
|
| 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
| nradov wrote:
| Scaled Agile Framework (SAFe) has a regular program
| increment cadence of every 8-12 weeks. This provides
| intuitive places for work, rest, and celebration.
|
| https://scaledagileframework.com/planning-interval/
| lowbloodsugar wrote:
| Some people really like killing those kind of bugs. I know
| people who would move from project to project, at the end of
| each, killing the show stoppers. I've done that myself.
|
| 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
| digging wrote:
| Actually what you're describing is completely different.
| Because if you're expected to only be working on those
| long, abstract, difficult tickets, none of the pressure to
| deliver features/bugfixes piles up as in the GP comment.
| But when you've got features on deadlines, there's not
| enough freedom to skip meetings and chug coffee all day
| without turning in any code.
| eterm wrote:
| So make that the expectation.
|
| 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.
| eschneider wrote:
| A lot of those long, abstract, difficult bugs become
| blocking/ship preventing issues, so...no pressure. And
| alas, many (most?) developers suck at debugging, so if
| you're any good at it, you get everyone else's broken
| code to fix. _sigh_
| Terr_ wrote:
| > The kind of bugs where you can invest days and have nothing
| really to show for it except crossing out some suspicions.
|
| 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.
| belval wrote:
| Personally these can be the best bugs though because you
| have an opportunity to learn something new (your work
| environment is everything though). Compare that to a ticket
| in an older codebase with hard multi-cause bugs that are
| just painful to debug and leave you with nothing but a
| deeper understanding of something that is slipping into
| irrelevance by the day.
| Terr_ wrote:
| "I found the bug, but it's because the business process
| you want to model is fundamentally insane and you're
| asking the computer to do magic."
| belval wrote:
| In my experience, administrative process that was
| previously done by a bunch of administrative assistants
| and then "computerized" around the year 2000.
|
| 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.
| verve_rat wrote:
| I'm going to frame this and put it on my wall.
| actionfromafar wrote:
| How _did_ your character change?
| Terr_ wrote:
| One evil-twin goatee, one villainous laugh.
| swatcoder wrote:
| Who left bugs like that on the board until so late in
| development? Unless they're just "tricky / nice to haves"
| that everybody knows might not be tractable (taking the
| pressure off you), that's some "odd" management. No wonder
| you burnt out.
| superfrank wrote:
| Working at a place like this now and I saw at least one
| previous workplace go from a healthy engineering org to
| something like this when they brought in new engineering
| leaders who all wanted to make their mark quickly.
|
| 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.
| stiiv wrote:
| I hope that people who suffer from exhaustion and a lack of
| breaks are setting realistic expectations for themselves, and
| not simply assuming that they need to push themselves to (or
| past) their limit. It is a rare manager who encourages you to
| work less, but it is (in my experience) a common manager who
| understands that breaks and self care are important. They
| just need to be reminded sometimes. You can push back, and a
| healthy organization will respect you for it.
| lambersley wrote:
| Crazy enough, I'm from the management school that believes
| the work is only the tool to develop the person and pay the
| bills. I will always sacrifice the work for the worker.
| It's sad that the majority of managers see this in reverse.
| kreeben wrote:
| Hombre, are you me?
|
| >> 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.
| dpe82 wrote:
| This. Software engineering can be a mentally draining task,
| and just like with physically draining tasks your body
| needs time to recover its strength. Nobody would expect an
| athlete to last very long doing back to back events without
| recovery time between them - they'd end up injured. Your
| brain is similar.
|
| Recognizing that and accommodating it is a sign of maturity
| for both an engineer and a manager.
| jdswain wrote:
| And that is why I dislike the label 'sprint'. A sprint is
| a short (unsustainable) extreme effort, not something
| that you do continuously.
| wetmore wrote:
| > 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...
| vjust wrote:
| Agile is evil
| mckn1ght wrote:
| > taking the time off doesn't even seem like an option
|
| 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.
| swatcoder wrote:
| Some of us really are lazy, though. But we set ourselves up in
| contracting or solodev where our time isn't being managed by a
| JIRA jockey between meetings.
|
| 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.
| sad_robot wrote:
| But what would the world be if you didn't produce more surplus
| value for the stakeholders and investors?! I would never
| understand people who go the extra mile like OPs heroes for
| some random corpo. You go the extra mile to develop your skills
| and leverage this new expertise into higher salaries or escape
| the rat race altogether.
| mvdtnz wrote:
| Developers are paid handsomely for those 40 hours. Much more
| than most other professions. I for one am tiring of the
| laziness of some developers I work with, and I don't even
| consider myself particularly diligent.
| Trasmatta wrote:
| The funny thing is that burnout can still happen regardless
| of how much compensation somebody gets.
| layer8 wrote:
| You seem to be working at the wrong company.
| TaylorAlexander wrote:
| I did a startup for five years that absolutely ruined me.
| Burnout on top of burnout for years on end. Now I work for an
| engineering non profit and I work 20-30 hours a week, sometimes
| less, and money is real tight but I'll tell you - there's just
| no way I can work more hours. I actually have a little time for
| side projects, and bike rides, and I never ever work weekends.
| Hell I don't work Tuesdays either except on rare occasions. I
| absolutely love my job. It's my dream job. But it's not worth
| killing myself over. We have one life to live and I'm going to
| fucking love it.
| sokka_h2otribe wrote:
| I think I might be a couple years behind you but I found your
| msg inspirational
| sokka_h2otribe wrote:
| That wakeup from 6 years of stress to <<one life, don't
| want to be driven this way [burnout way] anymore>>
| TaylorAlexander wrote:
| It takes time to find the right fit. Biggest thing is,
| when looking for a new job instead of negotiating the
| best salary, negotiate the right hours. 9/10 places will
| say "no thank you" if you say you must be allowed to
| typically work 25-30 hours a week. The place that says
| okay is a place that won't push you. Consider the open
| source world. They will appreciate paying a lower annual
| salary and still having a dev focused on their work, and
| they don't need all the extra overhead (meetings, etc) of
| a 40 hour week. Also working in open source (as I do)
| feels really good. You're not making some rich asshole
| richer, you're focused on helping the users.
| marmaduke wrote:
| I multiply every estimate by at least 3x and often add an order
| of magnitude, especially when I haven't done it before. when it
| takes less than I guessed, I use the time to resolve tech debt
| (or maybe leave early to enjoy the big blue room).
| marmaduke wrote:
| > Why should I even bother existing?
|
| 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>
| lr4444lr wrote:
| Have kids. It'll put things in a different perspective what it
| means to work 40 hrs./week.
| Jpoliachik wrote:
| We each have a limited number of fucks to give. It's more a
| decision of how to spend those - what is worth my mental energy.
| he0001 wrote:
| At any given point in time, there is always more work to do than
| time to do things. That's why there are managers.
| Trasmatta wrote:
| Except managers usually just make more useless work that you
| also don't have time to do
| justin_oaks wrote:
| Unfortunately many development managers have no visibility into
| technical debt and are more than happy to dig everyone down
| deeper in debt.
|
| 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.
| ipaddr wrote:
| If tech debt is important it will show up in a ticket. If not at
| some point a rewrite will happen. Prioritizing tech debt is
| something the ticket creators decide.
| happytoexplain wrote:
| >If tech debt is important it will show up in a ticket.
|
| That's like saying "everything is well-understood and well-
| planned".
| ipaddr wrote:
| You raise the issue with the decision makers but if they
| decide not to prioritize it I wouldn't personally take
| responsibility.
|
| Tech debt is project debt not developer debt
| peheje wrote:
| or a product with millions of users is scrapped, happened at my
| org.
| klysm wrote:
| This is how you get tech debt worded as users stories that
| don't make any sense, with confused PMs that don't know how to
| prioritize it vs features because the affect on the product is
| not clear.
| Guvante wrote:
| My viewpoint on tech debt as someone who does try to do it right
| is tracking is what is important.
|
| 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.
| oldpersonintx wrote:
| not sure what he's on about, 100% of the tech debt I have
| experienced is from people doing too much rather than too little
|
| 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
| digging wrote:
| > 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.
| augustk wrote:
| > 100% of the tech debt I have experienced is from people doing
| too much rather than too little
|
| "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
| ryandrake wrote:
| Not a huge Steve Jobs fanboy, but I always liked his quote[1]
| about craftsmanship, sweating the details, and giving a fuck:
|
| "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...
| quacked wrote:
| I appreciate this analogy, but Jobs made this work by creating
| a leadership culture that was obsessed with quality and
| craftsmanship. By all accounts he would regularly refuse to
| ship hardware and software that wasn't up to his standards and
| fired people for not building things to the right
| specifications. In contrast, most of us work in organizations
| with the exact opposite leadership mentality, namely "get your
| work done as quickly as possible so we can sell more product,
| and fudge whatever you have to to make it through quality
| testing unscathed".
| mattgreenrocks wrote:
| The best reason to do great work as much as you can is
| intrinsic satisfaction you get from that.
|
| 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.
| toss1 wrote:
| Yup.
|
| For so many reasons, from a mentor of mine:
|
| Quality Is It's Own Excuse.
|
| If you can do it better, do it better.
| bradlys wrote:
| Unfortunately we live in a stack ranked world and with
| incentives like not being deported - people will choose
| whatever pleases management over any idea of craftsmanship
| or quality.
| mrguyorama wrote:
| >if you can program well enough, then you can write great
| software quickly
|
| 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.
| munificent wrote:
| The correct career choice is to seek organizations whose
| values align with yours as much as possible.
|
| Life is too short to spend most of your waking hours
| surrounded by people whose beliefs go against yours.
| teaearlgraycold wrote:
| Jobs sounds like an asshole to work for and I wouldn't want
| to be held to his standard. That being said, I want to work
| with people that at least regularly _attempt_ to employ true
| craftsmanship. Your product can have its warts but it needs
| to fundamentally be built with love.
| yetihehe wrote:
| Typically this is because programmers are treated as workers on
| assembly line instead of carpenters making beatiful chest of
| drawers.
| ReactiveJelly wrote:
| One might also note, pound for pound, most chests of drawers
| are probably bought from Wal-Mart or Ikea.
| mikeyouse wrote:
| And unfortunately, since I enjoy woodworking, the Walmart
| chest of drawers is just as functional and often much
| better value than the finely crafted one. There's virtue in
| building something accessible that improves things even if
| it doesn't have "fine joinery" so to speak.
| c7DJTLrn wrote:
| There is also a huge portion of programmers who _want_ to be
| on an assembly line. They don 't care about their profession,
| they don't strive to improve at their craft, they don't read
| stuff on HN. They're simply there for the money. Since
| quality requires active effort in software, I think this
| group has an oversized responsibility for tech debt.
|
| Case in point: frontend and the shit show that's become.
| MattPalmer1086 wrote:
| It's not necessarily the developers fault here. One of the
| reasons I stopped being a professional developer is I like
| writing beautiful or well crafted code. Very few businesses
| will afford you that luxury. I enjoy the code I write in my own
| time.
| nullfield wrote:
| For my own curiosity, what did you move to that (as a person
| who cares about craftsmanship) is fulfilling enough, etc.?
| heisnotanalien wrote:
| Then the PM comes and asks you to change the wood used on the
| back of the chest of drawers because they have some brain fart.
| mschuster91 wrote:
| > 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.
|
| 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)
| digging wrote:
| Huh. I look behind me and the nice dresser I've been using
| since I was a child almost 30 years ago has a piece of plywood
| for the back. It actually could stand to be replaced by now,
| though.
|
| > 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.
| CharlieDigital wrote:
| It's a terrible analogy because most cabinet boxes are made
| out of plywood not because it's cheaper, but because it has
| better structural qualities versus -- what -- solid planks
| for the back of a dresser?
|
| 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.
| darzu wrote:
| Yeah, definitely a sloppy analogy ironically enough. But as
| a woodworker I've realize most people when they hear
| plywood they're really thinking OSB or cheap particle
| board. Quality high-ply with a hardwood outer layer isn't
| in their vocabulary. So the analogy sorta works.
| smolder wrote:
| I don't think Mr. Jobs actually knew carpentry and may have
| meant a different kind of material when he said plywood.
| Spooky23 wrote:
| The dresser matters as a craftsman producing a fine quality
| product. A good mass market product _should_ have a plywood
| back, because pushing up the cost takes away from it 's
| utility.
|
| 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.
| smolder wrote:
| Plywood is actually pretty nice. I'm confused. Are people
| talking about particle board?
| thrwy_918 wrote:
| I think an important difference, for me, is that at a certain
| point the chest of drawers is finished.
|
| 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.
| ryandrake wrote:
| > I think an important difference, for me, is that at a
| certain point the chest of drawers is finished.
|
| > 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.
| Mc91 wrote:
| > 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 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.
| Leherenn wrote:
| Have you tried taking the time instead of asking for it? It
| works surprisingly well in my experience, with very little
| pushback (and when there's pushback, it's important to
| understand why and address it). The first few months you
| focus on delivering value without rocking the boat. You
| probably don't have enough context to make any meaningful
| changes anyway. Then when it's time to groom stories, you
| select the time it takes to do a proper job, to make I
| improvements, and as long as it's not ridiculous, who's going
| to challenge you on it, and based on what?
|
| 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.
| ChrisMarshallNY wrote:
| I made this post[0], some time ago, and I think it dovetails
| nicely, here:
|
| >
|
| 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."
|
| [0] https://news.ycombinator.com/item?id=28086786
| TheIronMark wrote:
| This was the quote that came to mind. I read that book many
| times as a kid and that quote really stuck with me.
| inglor_cz wrote:
| Ah, Belgariad. I like David Eddings.
| cvoss wrote:
| Strongly object to the assessment that developers have this
| half checked-out mindset. Now, of course, this would differ
| from workplace to workplace, so YMMV, but at my workplace, so
| many developers have the craftsmanship attitude. They'd love to
| solve hard problems and solve them well, not because the
| solutions are worth money in a marketplace, but because they
| are intrinsically valuable, interesting, meaningful,
| delightful, etc. to the developers.
|
| 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.
| ryandrake wrote:
| You'll notice I never blamed developers in particular. This
| attitude is shared across "software as a whole" including
| developers, their managers, their PMs, their exec leadership.
| Everyone is part of the machine that is prioritizing money
| and a short-term horizon over craftsmanship and quality,
| including but not limited to the developers. We all have
| agency.
| theptip wrote:
| If that is you, then all good. I'm sure there are hobby
| carpenters getting joy from building wonky cabinets, and that
| is fine too.
| WJW wrote:
| I made a cabinet for my wife and it was both significantly
| more wonky AND more expensive than the IKEA equivalent, even
| if you counted my labor as being worth zero euro per hour. It
| also took several months instead of just ordering one. Still
| had fun though, which is what a hobby is all about.
| Xophmeister wrote:
| There are, of course, alternative metrics for "quality".
| Furniture with non-visible components made of plywood is more
| ecologically sustainable, for example (lighter and cheaper,
| too); one could even push this to using veneer everywhere. The
| furniture's beauty, form or utility is not affected, while
| being less of a burden on the world.
| barrysteve wrote:
| Jons also said you have to start with the customer experience
| and work from there.
|
| 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.
| shadowgovt wrote:
| I rarely meet a carpenter IRL who won't single-ply that
| backboard.
|
| 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.
| mvdtnz wrote:
| > I rarely meet a carpenter IRL who won't single-ply that
| backboard.
|
| 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?
| shadowgovt wrote:
| The point is when one sweats the details, one concludes
| that making the backboard full-thickness varnished board is
| an exercise in ego, not focusing on the user. It makes the
| user's experience worse for no other reason than some
| arbitrary artist's definition of simplified aesthetic.
|
| ... _definitely_ a lesson I think many software engineers
| should internalize.
| WJW wrote:
| That depends. What is the price of exceptionality?
|
| 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%?
| hvs wrote:
| You want craftsmanship? Pay for it and make time for it. Too
| many companies claim to want that but are both unwilling to pay
| top dollar and then don't provide enough time to actually do
| it.
| esafak wrote:
| It comes down to positioning and competition (profit margins).
| Apple notably sold upmarket consumer products; the segment best
| placed to pay for quality. If you are downmarket, or if you
| sell to businesses (where the buyer is not the user), you will
| find it harder to pull this off. It is the ideal, though!
| kypro wrote:
| > When you're a carpenter making a beautiful chest of drawers
| mattgreenrocks wrote:
| It's kind of sad Apple is still sort of the outlier in this
| multiple decades later.
|
| 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.
| j7ake wrote:
| I don't know what fictional carpenters Jobs was talking about.
| Real carpenters need to be pragmatic and cost effective to stay
| competitive in the market.
|
| 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.
| JohnFen wrote:
| It depends on the target market. If I were making furniture
| aimed at the wealthy, you better believe that every piece of
| wood in it will be high quality -- and the price I charge
| would reflect that. If I were making furniture for normal
| people, price is a greater concern and appropriate tradeoffs
| must be made.
|
| 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.
| j7ake wrote:
| I think every carpenter wishes they could make furniture
| exclusively for the wealthy and famous. But they have to
| compete with all the other carpenters at similar skill
| level for their business.
|
| 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).
| ryandrake wrote:
| > So Job's fictional carpenter would get outcompeted by the
| hypothetical free market where carpenters of equal skill are
| producing more at lower cost.
|
| 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.
| j7ake wrote:
| The point is that the world is large and there are many
| master carpenters.
|
| This hypothetical carpenter would be competing with other
| carpenters at the same skill level.
| kridsdale3 wrote:
| Thank god the world of Software and Hardware engineers
| competing with Apple is quite small.
| mattgreenrocks wrote:
| This is not wisdom, this is someone venting.
|
| The truth is way more nuanced than "the master carpenter
| would get outcompeted."
| j7ake wrote:
| The truth is also way more nuanced than what Jobs is
| describing. I was just showing how ridiculous his argument
| is.
| mattgreenrocks wrote:
| I advocate for a non-naive optimism here because one's
| views on this greatly influence one's mental climate.
|
| If you believe the race to the bottom prevents you from
| doing great work, then you will not do great work.
| j7ake wrote:
| If one takes a craft to be their profession, then one
| must be pragmatic because time and resources are finite.
| Otherwise one should take the craft as a hobby instead.
|
| 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.
| mattgreenrocks wrote:
| Absolutely. Tech as a whole has almost zero sense of collective
| aesthetic. And that harms the work we do, makes it harder for
| people to get into the field, and promotes very shallow,
| formulaic approaches.
|
| 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.
| yetihehe wrote:
| > My worst-rated comment on HN was when I suggested devs
| should spend 15m less on Twitter/HN
|
| 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."
| mattgreenrocks wrote:
| And people tune out even faster if you say to put more time
| in.
| hanspeter wrote:
| I've been giving a lot of thought to how engineers are
| different in this way. Assuming everyone has similar motivation
| and work ethic, I think it boils down to what satisfies you --
| or more precisely, what irks you the least.
|
| 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.
| d-lisp wrote:
| Well, if you are the type of carpenter that afford doing the
| _best_ drawers and dominate your market, you can probably work
| slower. e.g. Some luthiers sell their instruments 5 years
| before their completion.
|
| 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.
| thih9 wrote:
| It happens. E.g.:
|
| > 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.
| willsmith72 wrote:
| Eh there are certainly places for that mentality, but I prefer
| working with engineers and in places that do the opposite. Sure
| you can use the finest wood on the back, and polish the
| underside beautifully, but your beautiful chest is probably
| either never going to be bought or ripped apart and the wood
| reused for a chair. A lot of times, the fancy back of the chest
| is a complete and utter waste of time and effort.
|
| 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.
| MrPatan wrote:
| Precisely the exact opposite is true.
|
| 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?
| kunalgupta wrote:
| energy is finite
| MoreQARespect wrote:
| >Sometimes, I just CBF. I spent months (part time, of course)
| building out an end-to-end test system for my open source project
| Lazygit, and every day I think of all the regressions that system
| has prevented and how much harder it would be to add that system
| now given how many tests have been written since. I know for a
| fact it was worth the effort. So why haven't I added end-to-end
| tests to my other project, Lazydocker? Because I CBF.
|
| 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.
| FalconSensei wrote:
| I haven't yet seen this on my professional life (12+ years).
| There's always a few engineers that want to fix tech debt and
| improve code quality, but we have to fight with PMs to be able
| to, because is not new features, experiments, etc...
| rglover wrote:
| A guy in my co-working space had a good term for people who
| introduce technical debt out of laziness: "come on, man, you're
| being a buddy fucker."
| theptip wrote:
| Worth calling out that open source / hobby projects are very
| different from 9/5.
|
| 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.
| Helmut10001 wrote:
| I my perfect world of self-hosting, I take all the time I need to
| implement features and reduce tech dept over very long time
| spans. Sometimes, a migration from one service to another, or
| from one type of doing things to another, takes a year or more.
| During this time, both options run indefinitely alongside each
| other until I decide that it is time to deprecate something. This
| is very gratifying. I have reduced tech dept continuously and I
| see progress. Where I needed 2-4 days per months to manage
| things, I am down to 1 hour; and this hour is often adding and
| experimenting with new features.
|
| 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.
| shadowgovt wrote:
| Especially on hobby projects, sometimes you do something on one
| and not another because you really did it to learn, not to have
| the end result.
|
| If building a test framework was fun once and isn't fun again, I
| don't fault the builder.
| xwdv wrote:
| This isn't unique to tech debt. It's all debt.
|
| 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.
| esafak wrote:
| Sometimes the debt gets canceled with the project. Or the
| customer keeps using the product regardless of deficiencies.
| SillyUsername wrote:
| I'm in tears at that ironic FP on the link
| sbjs wrote:
| Hey Jesse, hope you're doing well man. You and I talked about
| this topic a bit in the past, and since then I've had a little
| more insight into these issues:
|
| 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.
| whb101 wrote:
| There are some misunderstandings in these comments.
|
| 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.
| add-sub-mul-div wrote:
| For most of my career I opportunistically cleaned up tech debt
| without being asked, because I wanted to. I felt ownership. Now
| that I'm in a Jira-based job with micromanagement and no autonomy
| I don't do a single thing I don't have to do.
|
| 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.
| clnq wrote:
| It's interesting how the companies creating this culture often
| pride themselves on culture and think they're doing it right.
| OJFord wrote:
| ' _Aussie_ slang '? Is the author Australian and assuming it's
| regional, or American say and it's not in the vernacular there
| and assuming it's specifically Australian?
|
| (It's attributed to Urban Dictionary, but not listed there; just
| with the addition of 'I' which has a different definition not
| mentioning Australia.)
| f33d5173 wrote:
| https://www.urbandictionary.com/define.php?term=cant+be+fuck...
| zubairq wrote:
| I think CBF may actually be a term for mental overload.
| renewiltord wrote:
| Funny. In many recreational sports at the low level, there's a
| similar sort of effect. You can just be better by always choosing
| to reach for the ball.
|
| 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.
| ike2792 wrote:
| This piece just seems like clickbait. In the real world of
| corporate software every decision involves triage. A sane
| developer asks themselves if the value added by doing it
| perfectly vs just good enough is worth the hassle and extra time,
| and often it isn't. Do those "CBF" decisions sometimes come back
| to haunt us? Of course, but the solution isn't to try to be a
| "perfect" developer that never releases anything to production
| b/c they're constantly optimizing.
| ilaksh wrote:
| Most if not all of our decisions are actually subconscious. When
| you just can't be f*****, it means that some circuit in your
| brain just doesn't think it's worthwhile to do the refactoring or
| tests or whatever it is.
|
| 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.
| T-zex wrote:
| The relationship between you and your job is very personal. What
| works in your situation does not necessarily apply to others.
|
| 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.
| wwarner wrote:
| In less colorful language, you might say that the result is not
| worth the effort. You can put it even more sharply -- you have an
| idea of what to do, but it's just not a very good idea. The right
| reaction (yeah you! in the mirror!) is to generate some more
| consequential ideas.
| dceddia wrote:
| Man, the negativity in here is unreal!
|
| 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.
| lambersley wrote:
| As a Dev Manager, please don't "fix it then-and-there." I've
| found that developers are great at fixing problems but terrible
| to prioritizing work. After all, its not their responsible to set
| priorities. The 'fix it then-and-there' on even a small issue has
| the potential to completely derail a project. Tech debt though,
| has to be treated with similar reverence to feature development.
| jquast wrote:
| I do like to call the large amount of TODO items i find in
| business codebases as "TO DIDNT", always some comments about what
| we know should have be done, but some alternative or smaller
| solution was done instead.
|
| Sometimes TODO comments describe a strict deadline, they read
| almost like apology letters!
| xtracto wrote:
| Aah the feeling of masd closing a HUGE list of tickets as
| ABANDONED in the jira board of a 6 year old startup.
|
| Most likely 70% of th e ticket owners don't even work here
| anymore
| tetha wrote:
| On the other hand, there is value in being lazy in the right
| places.
|
| 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.
| indigoabstract wrote:
| Maybe another way of putting it would be "the thrill is gone".
|
| 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.
| xyzelement wrote:
| Various debt has different "interest rates" and the skill is to
| pay off the high interest ones as the expense of 0-rate ones.
|
| 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.
| Bognar wrote:
| I love this analogy, interest rates on tech debt. It's such a
| natural extension of the phrase tech debt and succinctly gets a
| point across. I'm gonna have to steal that and start using it
| at work.
| munificent wrote:
| _> It 's such a natural extension of the phrase tech debt and
| succinctly gets a point across._
|
| The metaphor of interest was _the whole reason_ that Ward
| Cunningham initially coined the term "tech debt":
|
| "Technical Debt is a metaphor, coined by Ward Cunningham,
| that frames how to think about dealing with this cruft,
| thinking of it like a financial debt. The extra effort that
| it takes to add new features is the interest paid on the
| debt."
|
| https://www.martinfowler.com/bliki/TechnicalDebt.html
| hifycycyv wrote:
| That's a nice story but at my company management actively
| discourage all forms of code hygiene. The only thing they care
| about is code shipped. It comes down to a perverse set of
| incentives from the csuite but it 100% has zero to do with
| developer articulation.
|
| 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.
| Vinnl wrote:
| One thing that I've gotten better at, but still find hard, is
| tolerating CBF in others, when doing code reviews. I'll still
| call out that something would probably be a good idea (e.g.
| adding another unit test), but I'll coat that in layers of "but I
| also understand if that's too much of a hassle".
|
| 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.
| _gabe_ wrote:
| There are people that CBFed, and then there are people that DEGaF
| (Don't Even Give a Fuck). There's nothing more demoralizing then
| being thrown on a team of people that don't care about
| programming at all, don't even know what "cleaning up the code"
| looks like, and wouldn't care even if you told them. People that
| are content to hack the code to a mangled piece of crap just to
| knock out the ever-present Jira tickets and keep their job.
|
| I applaud the author. You may think that you're not one of the
| aspirational programmers, like a Carmack or a Knuth, but you most
| certainly are a different, better breed of programmer. Simply
| because you know that you can do better and strive for that when
| possible. I have a precious few teammates that have the same
| attitude as the author, and without them, I would probably go
| insane being surrounded by all the people that DEGaF.
___________________________________________________________________
(page generated 2023-10-12 21:00 UTC)