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
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. ..."
Laziness is not working hard.
What you're talking about is something else.
Sloppy or Careless work maybe?
But not lazy. If you're working 40+ hours a week you're definitely not lazy.
You can absolutely put in a lot of hours, but be putting in near-zero effort. This results in sloppy or careless work, but the root cause is the laziness of the person.
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?
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.
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".
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.
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
Let me tell you the tale of a man named Sisyphus...
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.
The point is that hard work doesn't imply excessive hours. If it did, that would mean anyone who doesn't put in excessive hours is lazy, which isn't true.
> I routinely come across developers who are the real deal: they’re conscientious and judicious in an unwavering way. They set a standard for themselves and do not compromise on it. Whether that’s a deliberate thing or whether they’re just built that way, it’s humbling to witness. If there’s a flaky test, they investigate it and fix it. If there’s a bug they spot in the wild, they make a ticket, and maybe even fix it then-and-there. If a new feature doesn’t gel well with the existing code, they refactor the code first rather than hacking the feature in. They’ll dive as far down the stack as necessary to get to the bottom of something. None of these things are necessary but great developers know that if they don’t address a problem early, and properly, it will only cost them more time in the long run. [... and more.]
This sounds like a great definition of not-lazy, and it does not mention long hours anywhere. My anecdotal experience is that I usually only have 20-35 not-lazy hours to give per week; any further hours per week are much less potent. Right now I'm working 24 hours per week and I think my employer is getting a great bargain: they don't have to pay me for hours that would likely be lazy.
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").
But humor me with an explanation, please...
There's a reason I don't work there anymore.
> 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.
I don't care what the theoretical outcome is when the practical one is always this.
What kind of runner can run as fast as they possibly can from the very start of a race?
[Audience reply: Sprinter]
Right, only somebody who runs really short races, okay?
[Audience laughter]
But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint.
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
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.
AFAIK, it does nothing to help here. But a solid leadership does help.
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.
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.
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.
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.
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.
> 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.
>> 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.
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.
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..."
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
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
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.
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.
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.
Recognizing that and accommodating it is a sign of maturity for both an engineer and a manager.
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).
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".
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.
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.
> I think that many developers who say they dislike Agile really mean they dislike Scrum.
True say.
The problem is often systemic and a symptom of an engineering team not really having control over their own roadmap. You see it when an engineering team isn't agreeing to take on work, but rather being told what to work on by people outside of the team. Sometimes it's isolated to a single team, but sometimes it can be a whole org or company. It's caused by bad expectations around the amount of work that can be done and unclear priorities. How many people it affects depends on what level the bad expectations are being set at.
In practice, this is how I've seen it play out. There are 10 developers worth of work that needs to be done by X date, but we only have a team of 8. No one has made it clear what the prioritization is or if they have, that priority isn't universally accepted or changes day to day. If everything is equally important, the tough work that may not have noticeable results is often what gets pushed into the backlog over and over. To people who see engineers as the "build new features" people, it's hard to regularly justify "I can't build feature X because I have to solve bug Y" and then a week later say "I still have no idea what's causing this issue".
It's easy to say, well just get everyone to agree on priority and what a reasonable amount of work is, but that's far, far easier said than done.
The 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.
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>
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.
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.
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.
If you've never watched Simple Made Easy I really recommend it: https://www.youtube.com/watch?v=LKtk3HCgTa8
> [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...
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.
Irrelevant, and reads as a non-sequitur. OP expressed his personal assertion on laziness, not productivity.
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.
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.
The attitude I see most often is: "the worker is replaceable and therefore expendable, but the work will always be there until someone takes care of it so burn through as many workers as it takes to get it done"
You are blaming the system S. However we have counter-examples where the problem P occurs outside of the system. If P occurs without S then possibly S is not the cause. Admittedly untangling causation, sufficient and necessary is difficult.
The article itself appears to be a counter-example that is non-commercial: where problem P occurs without system S.
I think it is worthwhile investing time to work out for yourself when to honestly blame commercial constraints, and when to recognise other root causes. Blaming the system by default is unhealthy IMHO.
As long as the business is making money, the prospect of it continuing to make money in the near and medium term future is not in jeopardy, and the actors involved are rational, capable and trustworthy, you should always favor the worker over the work.
IME, zero sum management is an emergent symptom of a poorly performing business (maybe if we make everybody work 150% harder we’ll hit our targets this quarter), insecure executives (who don’t understand the work they manage), or poor hiring/firing practices (the only way to let somebody go is by overloading them and rewarding it with a poor performance review, or you’re hiring people who aren’t capable or don’t care).
If you’re a manager forced to make zero sum decisions and don’t feel empowered to change the root of that problem, you should probably consider leaving — good environments grow people instead of expending people.
Your definition of "not-lazy" by it's very nature relies on systematically working overtime.
Investigating and fixing flaky tests is either explicitly covered by a ticket, and thus a part of run-of-the-mill tasks, or something a developer does in unscheduled tasks by going above-and-beyond including in work hours.
Finding a bug, creating a ticket, and working on it is not proof of non-laziness as that's a part of the basic job description.
Refactoring a feature is either tracked by a ticket and covered in normal ticket-assignment processes, thus not a demonstration of lack of laziness, or it's something you do in your own time.
You have to clarify where you find the time to do all that "above-and-beyond" stuff because it's either normal work done on normal company time, which surely doing the normal/bare minimum is not proof of not being lazy, or it's going the extra mile, which is certainly not done during normal office hours.
If you don’t know or can’t reach consensus what your goals and principles are, no process will make your org functional.
I think you didn't understood the problem. No one is talking about penalizing people for only doing 40hours. The problem is that code quality is never prioritized or allocated time, so you either live with it or you go above and beyond and you deal it yourself on your own time. If your team is bounded to KPIs which you don't build up by refactoring bad code or diving deep into code issues or tracking weird elusive bugs, either you are forced to pull extra hours to no fall behind your team or your performance will clearly be awful.
This is not an inevitability, though. It depends on the temperament of the company you work for. A slight majority of the companies I've worked for didn't mind allocating time for that sort of thing at all (but they did expect you to make a business case for it).
This is due to their lack of technical knowledge and they have accepted this reality because the outcomes that they want do end up happening so they dont rock the boat(or know how to since they can't discern technical stuff).
I know its a great spot to be in short term but Ive been scared because long term I will be in a big hole when the next role comes along and its more like what you describe and I haven't grown to match the role. I've considered leaving once the market improves but I don't think I can fathom giving up what I have either. Alternatively I have considered staying until I eventually get downsized but that could be years. I don't know.... :/
This breaks down when you have one player in the arena acting like a snake that tries to devour everyone else(eg. Elon Musk). He has the gift of attracting an endless horde of people to burn through and then tosses them aside once they are no longer useful to him(so many examples in his recent bio). The result is that they move faster than the competition and the others eventually get eaten alive. Normally word would get out that its not safe to work for such a character but SpaceX and Tesla are among the most desired employers that engineering graduates seek to work for. Tesla received 3.6 million job applications in 2022.
I think it’s worth pointing out that some projects are worth that level of devotion, and visibly so in real-time.
But we can’t make a project worth that level of enthusiasm and attention just by demanding people to act like it is (the siren song that leads to the earlier-discussed culture spirals). Often-well-meaning people will put the cart before the horse, but no amount of quacking will turn you into a duck, etc.
On balance, it’s healthy to be skeptical of people demanding devotion to some process or objective that’s not rooted in first principles you can agree with.
It wouldn’t surprise me too much if a meaningful proportion of the 3.6m applications per year are filed by people who find the first principles behind Tesla’s culture worthy of their devotion.
But yeah, the number of companies or projects that would benefit from that style of approach is quite small. 20% is the ceiling, 10% feels closer to the truth.
Of course, it sounds like you have buy-in from management for these quality standards. For people who don't have this kind of buy-in for the whole team, they'll have to work individually to maintain quality.
Agile lets you manage expectations and set boundaries by scheduling a finite amount of work into a bounded amount of time.
If you don't like SAFe then please be specific. Which parts of it don't work if actually followed as documented?
> You have to clarify where you find the time to do all that "above-and-beyond" stuff because it's either normal work done on normal company time, which surely doing the normal/bare minimum is not proof of not being lazy, or it's going the extra mile, which is certainly not done during normal office hours.
At every company I've worked for, I've had time for "above-and-beyond" stuff during normal office hours. That's just how low expectations are in my neck of the woods. Or maybe I'm outrageously talented and I would still excel working on some elite FAANG team... but I doubt it.
We found an issue in the kernel bug tracking that seems to explain it, but we never confirmed for sure. Fortunately updating either of those things fixed the issue. This was of course also hard because this was back in the golden days of vmware managed by client's IT team, so getting them to update things on a VM was hell as well.
A good personal open source project is worth more when interviewing than anything else really. Can't fake that in an interview.
don't you just have normal time off on top of sick days?
But if you're in a flexible enough situation where you can just call up your boss like that, that's great. That's what "unlimited time off" should theoretically have been before the well was poisoned. Trust that workers can manage their own mental health but not abuse it to be gone 30% of the year.
How do you find such places? I've been very curious about part time software work but knowledge online seems to suggest that freelancing is the only route there.
Funnily enough, I wanted to find such a job precisely so I could make my own stuff on the side, which will inevitably involve some signifigant open source contributions due to my tech stack. I've thought about simply being a paid member and essentially double dipping, but that route seems even rarer.
I think it's a notion worth considering in such a conversation.
So based on the table they are skilled, right? Are you suggesting that they are a savant in disguise and that they can produce high volumes of high effort work if they weren't "lazy"?
if the work is considered medium-to-high effort by the organization, your opinion on if it's avoiding "boring" work (which can still be low or high effort) is irrelevant.
>If someone is "undisciplined," more often they are just lazy and are engaging in avoidance behaviors.
IME it's because the employers don't trust nor want them to work on the high effort work. So either the business's most profitable software is the most boring, or the candidate is too junior (alternatively, the position and responsibility is simply filled or not valued)
>Humans with serious executive function issues are a tiny (super tiny) minority of the workforce.
Likewise, humans who can do "productive" creative work for 80 hours a week consistently, for years, is also a super tiny minority.
At the end of the day, "lazy" is relative and we haven't even established a baseline for what is/isn't lazy. So this conversation won't go anywhere. All we established in your lens is that taking breaks or doing non-technical work (meetings, even gossip depending on the line of work) is not productive in your eyes.
> Working on X but Y is a blocker
> Okay, I can do some work with Y to help get unblocked
> No we'll let A (on a different team, maybe a different contracted studio) deal with it, here's tiny widget Z to work on in the meantime
Sometimes it means well, sometimes it feels like they don't value your expertise nor care about fostering growth. And sometimes it's just politics (especially when working with multiple different companies and contractors and all that).
In my case I started writing stories of automated farming communes, compiled my writing in to a zine about a better world, had 260 copies printed and handed them all out, got my then dream job at Google X robotics, then ended up handing a copy of the zine to a robotics engineer and philanthropist who now funds my open source work as we push towards continuous crowd funding as our long term model.
Your story will go differently (lol) but what I can say is that defining your vision, building the appropriate skills, and telling everyone that you can what you’d like to do probably helps a lot. You may have to stick with the unfulfilling job for now, but you can try to build an exit strategy.
For example we compile locally, then manually move the compiled code over to the server instead of using something like docker. Part of this is the restrictions we have over our environment, part of this is inertia.
Fortunately I haven't given up trying to move to that paradigm but sometimes I actually dont want to be on a modern team. Its like I have plateaued to a comfortable state that I know wont always be there but I wish it did. I hope what I am explaining makes sense.
I have literally had (TWO SEPARATE!) people tell me, thinking it was perfectly acceptable, that they often put extra lines in their code so they can go back and clean it up instantly with auto-format while pretending they did real work.
What would you call someone who defaults to this type of behavior if not lazy? Work shy?