[cabraca]

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time.

The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of code. Everything has to have some immediate business impact. I even see scrum teams measuring for team utilization now. target is 90% atm and they wonder why productivity is down.

[mattgreenrocks]

> If you remove people from the grind for 1-2 days a week

The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out.

I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels.

So I respond by easing up on advancing my career, because it gives back to me the least.

[Frost1x]

Pretty much. I often wonder where people find positions claimed on the internet where they're working 2-3 hours a day. I've increasingly throughout my career saw more and more slack evaporate to a point it's almost nonexistent.

I always wondered why people complained about how much time certain aspects took up they could automate away and my question was always: well, once you automate away that nice simple task, what do you do with the extra time? You created more slack and someone's going to come looking to fill that void the second they're aware. And the new task is going to be more difficult until you get to sets of tasks so cognitively intense and complex you can't simply automate them away. Then your day is filled with incredibly challenging stressful work.

I have no issue with doing complex work, I've spent my career doing it. What I have issue with is the amount of such work I can do in any given time span. At some point I need a break where I do something simple and mundane. Continous complex problem solving is the road to burnout. You'll be greeted by more and more failure and lack of visible progress combined with ever increasing stress levels.

If you're an entrepreneur, small business owner, or manager looking to optimize your labor force then you may want the opposite. You want more time to focus on the complex and the more simple you can automate, the better or if you have a workforce, you want your highest comped individuals focusing on the most optimally complex tasks they're capable of handling. You don't want your Fellow level engineer refilling the coffee maker because it's empty or implementing some basic features on some UI, go back to inventing new algorithms, math, or building new technology... but people need those nice relaxing breaks and slack, they can't run at their best constantly.

[shagie]

> The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out.

There's a book to hunt up...

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

It's written by Tom DeMarco of Peopleware fame.

[namaria]

>I have significant doubts that it is possible to continue to advance [as a worker under capitalism] (...), be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues.

It's heartbreaking how much human suffering is entirely avoidable in a post scarcity society where it is still artificially enforced to avoid the "moral hazard" of commoners daring not to toil or worry every waking hour

[dt3ft]

We can’t even push to a git repo unless it has a linked work item/story/task/bug.

So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO.

Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.

[rootusrootus]

That definitely sounds broken. I have a hard rule with my PO: 30% of the sprint is mine (read: the team's). He only gets to schedule 70% of the stories according to his priorities. I use that 30% for tech debt, primarily, but sometimes for spike projects and other things that interest us.

[onion2k]

Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots. People don't always understand code, but they do understand problems, and why those problems are important to keep on top of.

If your PO is sensible then a couple of paragraphs explaining why refactoring is important with a closing line that says spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time. People aren't stupid. Once they understand why something is necessary they've very receptive.

Also, add refactoring time in to your estimates in the future and you won't end up in this situation, plus the code that's committed will be better.

[fmakunbound]

> We can’t even push to a git repo unless it has a linked work item/story/task/bug

Exactly the same where I work. The pace of getting things done is absolutely glacial compared to what you know you could achieve if you had any agency. I think the only reason this organization I'm temporarily a part of can even compete is that all its competitors must be equally inefficient.

[Chio]

I don't believe this is how it is actually implemented in _most_ companies. Where I work every PR must have a linked story / bug / etc but anyone has the rights to create a story so it acts more as a way to track what changes actually goes into a release for x-teams to review and see if they need to document it, etc.

In regard to refactors, people tend to just squash them into another change they are making. This makes the git log a bit harder to follow at times, but people did this back when we just used to push to trunk too so I don't think the story is the deciding factor.

[sirsinsalot]

I get why bureaucracy is a total pain, getting work approved by stakeholders constantly ...

But the actual ticketing/PR system? Change requires control.

The actual issue is not _using_ that control tool to get the right things done. If basic technical debt issues are not an easy sell in your org, that's the real problem and one that should be handled by senior/dev manager.

A big red flag for me is any org that doesn't recognise and service technical debt and empower engineers to make a win.

I also wouldn't say tech debt pay-off should be without its justification in some cases. If an engineer can't measure the positive impact of doing something, it can make it a hard sell. Why should an engineer spend 2 weeks doing something if we can't describe the payoff?

[singlow]

Requiring it to be documented and approved is just responsible from a change-management perspective. At my company we have similar requirements and it is basically required to do that in order to meet security audit expecations. The problem is when they managers don't let you have a say in what gets done.

If a developer on our team things something should be done and can do it quickly, they are encouraged to create a ticket and do it. It gets code-reviewed and accepted. If it is not a quick change, they need to bring up the ticket at a planning meeting to make sure it is balanced against other priorities.

[dubswithus]

What happens if you do it anyway and don't put it on the board?

[commandlinefan]

> has to be planned and approved

It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this:

1. Management demands that every bit of work be associated with a ticket

2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system

3. management complains about devs opening "their own" tickets and prohibits self-opened tickets

4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board)

1. management demands that every bit of work be associated with a ticket...

[sobren]

It feels bad too have a ton of structure, but the opposite is worse IMO.

Single line tickets from the CEO that turn into months long projects with no guidance on the functionality. Engineers that burn down entire features because "it's bad code." Secret projects where you get berated for asking stakeholders to to clear up requirements because "you're scaring them."

It's easy to look at a rigid structure and assume it sprang wholecloth from Zeus's head - but most of the time it's an overcorrection. Being burned by a company where Freedom is just an excuse to make employees to work overtime will make anyone go a little overboard.

[Chris2048]

> after they "negotiate" your estimates down

I hate this. An estimate is an estimate, there is no negotiation, negotiation an estimate is simply interfering with it, making it less objective. It can also be a trick to put pressure on developers.

[lokar]

Wow. I have never seen anything close to that. Why would anyone put up with that?

[wes-k]

I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt.

I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase.

One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a proper refactor.

[xur17]

I've worked at companies that tried to have explicit 20% policies, and it worked okay for some period of time, but then became difficult to prioritize. That said, I've typically been pretty successful at casually using 10 - 20% of my time to work on random low hanging fruit (dev ergonomics, performance, etc). For some reason using a quiet Friday afternoon, or time between tickets seemed to work better than an explicit "work on whatever you want every Friday".

[onion2k]

I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt.

Where I work we have 1 'maintenance day' each sprint where the devs choose what to work on. That can be fixing annoying issues, improving the code, learning something, trying something out, etc. It works well when other things aren't taking priority (which is far too often tbh).

[dgb23]

How does a junior become a senior? By trying stuff that cannot do well yet and making mistakes.

[mysterydip]

> give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time.

This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.

[_yasmeen]

That reminds me of the time I was a junior dev, and the team lead told me verbatim: "I know you are too busy to write tickets, but can you take some time off [this urgent thing] to do that? Thanks!"

This was after they encouraged a certain "cool culture" for a couple of months due to the lack of direction. It was pretty funny that I did not only get micromanaged, but was told I did the wrong thing, and then asked to do a third job that was not my responsibility.

[heretogetout]

We have a lot of bugs everyone complains to me about and I have sufficient downtime to fix them* but I have to go through drawn out planning, UI, UX processes before I can even start. I just don't bother any more.

And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev.

* the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.

[politician]

I think that many companies don’t know or have forgotten that programming is a creative process more than a manufacturing process. You’re not pulling chicken breasts off an assembly line and wrapping them in plastic.

[adrianN]

Shit that bugged them for a long time might have a lot less value to the business than a tedious task that nobody wants.

[bruce343434]

So you'd rather have bugged out people which decreases morale which decreases productivity? See it as an investment. Yes, motor oil is more expensive than no motor oil, but it makes the engine run a lot better.

[jimbokun]

Shit that bugged them for a long time can multiply overall productivity going forward, and add far more value than slowly banging out the next user facing feature in a low productivity environment.

[Chris2048]

> Everything has to have some immediate business impact.

Or more specifically, explainable business impact.

But it's hard to explain how the code has become horrible and needs a refactor to makes it easier on devs, reducing stress, reducing likelihood of both bugs, and developers leaving.

[kilroy123]

I could not agree more. My current gig is the opposite and after a year I'm ready to leave.