this post was submitted on 15 Oct 2024
311 points (99.7% liked)

Programming

17407 readers
75 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
(page 2) 38 comments
sorted by: hot top controversial new old
[–] [email protected] 16 points 1 month ago (3 children)

I feel blessed that I like my current job. Good manager, interesting work, limited amounts of bureaucracy. Most of this is a lucky coincidence but there are some things we can do. I had to explain many times to people which tasks I'm good at and which ones they should ask other people to do. I regularly defend this position. I set aside the morning for creative work only, no meetings, no admin, just thinking and solving. In the afternoon I down tools and do something physical, outside in daylight. A regular sleep cycle is absolutely critical for the maintenance of health and mood. Fresh food and companionship. Regular meditation. Do the basics well. These are the things that have made me happy.

load more comments (3 replies)
[–] [email protected] 21 points 1 month ago (3 children)

I’ve been programming for years, I’ve only happy when working on my own stuff. It’s like the difference between renting and owning

[–] [email protected] 4 points 1 month ago

Spot-on analogy.

load more comments (2 replies)
[–] [email protected] 16 points 1 month ago* (last edited 1 month ago) (3 children)

The thing that frustrates me about developers who feel powerless over technical debt is...who is actually stopping them from dealing with it? They way I see it, as a software engineer, your customer is sales/marketing/product/etc. They don't care about the details or maintenance, they just want the thing. And that's okay. But you have to include the cost of managing technical debt into the line items the customer wants. That is, estimate based on doing the right things, not taking shortcuts. Your customer isn't reading your commits. If they were, they wouldn't need you.

It would be bizarre if your quote for getting your house siding redone included line items for changing the oil on the work truck, organizing the shop, or training new crew members. But those costs of business are already factored into what you pay at the end of the day.

[–] [email protected] 19 points 1 month ago* (last edited 1 month ago) (1 children)

who is actually stopping them from dealing with it?

Management. Someone in management sets idiotic deadlines, then someone tells you “do X”, you estimate and come up with “it will take T amount of time” and production simply tells you “that’s too long, do it faster”

they don’t care about the details or maintenance

They don’t, they care about time. If there are 6 weeks to implement a feature that requires reworking half the product, they don’t care to know half the product needs to be reworked. They only care to hear you say that you’ll get it done in 6 weeks. And if you say that’s impossible, they tell you to do it anyway

you have to include the cost of managing technical debt

I do, and when I get asked why my time estimations are so long compared to those of other colleagues I say I include known costs that are required to develop the feature, as well as a buffer for known unknowns and unknown unknowns which, historically, has been necessary 100% of the time and never included causing us development difficulties and us running over cost and over time causing delays and quality issues that caused internal unhappiness, sometimes mandatory overtime, and usually a crappy product that the customers are unhappy with. That’s me doing a good job right? Except I got told to ignore all of that and only include the minimum time to get all of the dozens of tiny pieces working. We went over time, over cost, and each tiny piece “works” when taken in isolation but doesn’t really mix with everything else because there was no integration time and so each feature kinda just exists there on its own.

Then we do retrospectives in which we highlight all the process mistakes that we ran into only to do them all again next time. And I get blamed come performance review time because I was stressed and I wasn’t at the top of my game in the last year due to being chronically overburdened, overworked, and underpaid.

[–] [email protected] 10 points 1 month ago (1 children)

Yeah management is totally backwards there; it's like the building manager on a construction project going "all electrical needs to be done in X weeks", but realistically they have no direct control over that deadline being met by declaring an arbitrary deadline. The unfortunate difference is that if you do a shitty job wiring a building, you'll fail inspection and have to spend more time and money fixing it. Software can often hobble along; there aren't strict enforcements for quality that the business can legally ignore, so you'll always have sad defeated devs go "okay boss, we'll skip the things we need to get this done faster for you (I hate this job and don't care about the product's long term success)". Having a steady supply of those people will slowly kill a software company.

In the past, I've dealt with estimate pushback not by explaining what necessary work can be removed like tests, documentation, or refactoring, but by talking through ways to divide the project more effectively to get more people involved (up to a point, a la mythical man month). That seems to go more proactively. Then we look at nixing optional requirements. But, I've also usually dealt with mostly competent engineering management.

[–] [email protected] 5 points 1 month ago

Yeah that’s what we did last time. I implemented a basic framework on top of a very widespread system in our codebase, which would allow a number of requested minor features to be implemented similarly, with the minimal amount of required boilerplate, and leaving the bulk of the work to implementing the actual meat of the requests.

These requests were completely independent and so could be parallelized easily. The “framework” I implemented was also incredibly thin (basically just a helper function and an human instruction in the shape of “do this for this usecase”) over a system that is preexisting knowledge. My expectation was to have to bring someone up to speed on certain things and then let them loose on this collection of tasks, maybe having to answer some question a couple times a day.

Instead, since the assigned colleague is basically just a copilot frontend, I had to spend 80% or more of my days explaining exactly what needed to be done (I would always start with the whys od things since the whats are derived from them, but this particular colleague seems uninterested in that).

So I was basically spending my time programming a set of features by proxy, while I was ostensibly working on a different set of features.

So yeah, splitting work only works if you also have people capable of doing it in the first place. Of course I couldn’t not help this colleague either, that’s a bad mark on performance review you know. Even when the colleagues have no intention of learning or being productive in any way (I live in a country with strong employee regulations so almost nobody can be fired for anything concerning actual work performance, and this particular colleague doesn’t hide that they don’t care about actually doing a good job, except to managers so they still get pay raises for “improving”).

Yeah, you can tell I’m unhappy

[–] [email protected] 6 points 1 month ago (1 children)

I believe for many companies, developers work on giant codebases with many hundred thousands or even millions of lines of code.

With such large codebase you have no control over any system. Because control is split between groups of devs.

If you want to refactor a single subsystem it would take coordination of all groups working on that part and will halt development, probably for months. But first you have to convince all the management people, that refactor is needed, that on itself could take eternity.

So instead you patch it on your end and call it a day.

load more comments (1 replies)
[–] [email protected] 14 points 1 month ago (1 children)

Yes, this. Refactor first to make the upcoming change easier and cleaner, not after. Don’t ask for permission, don’t even call it refactoring or cleanup. Just call it working on the feature, because that’s what it is. Don’t let non-engineers tell you how to engineer.

[–] [email protected] 6 points 1 month ago (2 children)

Yes, this! I rarely ask for permission on that sort of thing. I’ll just do it as part of my work and see if anyone calls me out on it.

[–] [email protected] 3 points 1 month ago (1 children)

I do this too, but I realize I'm privileged to be able to. In past jobs people actually would get pissed at me for doing it. I had a manager have a really shitty talk with me about it once. I'd guess a lot of people have bad experiences like that

[–] [email protected] 103 points 1 month ago (7 children)

I would say 80% of employees are unhappy, but I don't have any data to back this up.

[–] [email protected] 44 points 1 month ago (6 children)

Can confirm. Was quite unhappy in my mechanical engineering job, had an opportunity to develop something nice in python, was told we'd do it in excel/vba instead, still unhappy.

[–] [email protected] 4 points 1 month ago (1 children)

excel has python support now! you may still get away with it

[–] [email protected] 5 points 1 month ago (1 children)

It's cloud based though... Not ideal. I get why they had to do that (they didn't want to expose people to the Python infra shit show) but it's still kind of a shame.

Would be better if they added Typescript support IMO.

[–] [email protected] 5 points 1 month ago (1 children)

...like the js infra stuff isn't it's own special nightmare?

load more comments (1 replies)
[–] [email protected] 6 points 1 month ago
load more comments (4 replies)
[–] [email protected] 14 points 1 month ago (2 children)

Or maybe 80% of people are unhappy. No data here either

[–] [email protected] 1 points 1 month ago

80% of beings in the multiverse

[–] [email protected] 15 points 1 month ago (2 children)

80% seems too high, but the US Surgeon General declared a loneliness epidemic https://www.hhs.gov/sites/default/files/surgeon-general-social-connection-advisory.pdf

And Gallup claims that 29% of Americans have been diagnosed with depression at one point: https://news.gallup.com/poll/505745/depression-rates-reach-new-highs.aspx

So... That is not good. It is almost like humans evolved to live in tight knit, walkable communities.

load more comments (2 replies)
load more comments (5 replies)
[–] [email protected] 75 points 1 month ago (3 children)

Will AI steal their jobs? 70% of professional programmers don’t see artificial intelligence as a threat to their work.

If your job can be replaced with GPT, you had a bullshit job to begin with.

What so many people don't understand is that writing code is only a small part of the job. Figuring out what code to write is where most of the effort goes. That, and massaging the egos of management/the C-suite if you're a senior.

[–] [email protected] 4 points 1 month ago

If all you bring to the job is looking shit up and telling me yes or no instead of actually trying to help me find solutions, or explaining me what I did wrong, you're just a glorified robot. You're in line for replacement and you'll fucking deserve it. At least that's what I wanna say to "the computer said" people.

[–] [email protected] 20 points 1 month ago (3 children)

Automation is always incremental.

I'm an accountant. Components of the job have been being automated or systemised for many decades. Most of the tasks that occupied a graduate when I was one 20 years ago don't exist anymore.

Not because AI is doing those tasks but just because everything became more integrated, we configure and manage the flow of data rather than making the data, you might say.

If you had to hire 100 professional programmers in the past, but then AI makes programmers 10% more efficient than previously, then you can do the same work with 91 programmers.

That doesn't mean that 9 people were doing something that an LLM can do, it just means that more work is being completed with fewer programmers.

[–] [email protected] 6 points 1 month ago

To add on this, this doesn't necessarily mean that there are fewer programing jobs in total. If people work 10% more efficently, that means that the cost of labor is only 91% of what it was before meaning that people might be able to afford to finance more programing projects. One thing that does matter is for example things like entry level jobs disappearing or the nature of the work changing. Doing less boring gruntwork can make the job more fun, but otoh digitization sometimes results in the worker having less agency in what they do since they have to fit everything into a possibly inflexible digital system.

load more comments (2 replies)
[–] [email protected] 34 points 1 month ago (4 children)

If your job can be replaced with GPT, you had a bullshit job to begin with.

This one's funny to me, because the people who WILL try to replace you with GPT don't care if they CAN replace you with GPT. They just will.

Look at how it's haphazardly shoved into everything for no reason whatsoever already.

load more comments (4 replies)
[–] [email protected] 32 points 1 month ago

So, roughly 20% of developers have found the right mix of self-medication?

[–] [email protected] 66 points 1 month ago (1 children)

There's a lot of like management being like "we gotta hit this deadline (that we made up)" combined with "if I hit all my targets and put in some overtime, the boss can buy another sports car this year"

I don't want to work extra to make someone else richer. Maybe if I had a shit load of shares. Maybe. But I don't. So I do my job with professional standards, but I'm not doing 12 hour days

load more comments (1 replies)
[–] [email protected] 157 points 1 month ago (14 children)

Technical debt is the number one cause of developer frustration. Working with imperfect systems demoralizes programmers, making it difficult to do quality work.

I'd wager not being given time to tackle technical debt is indeed frustating...

[–] [email protected] 15 points 1 month ago (2 children)

The secret is just to do it anyway. I have yet to work in a job where anyone actively stopped me fixing technical debt, even if they never asked me to do it.

[–] [email protected] 9 points 1 month ago

Use overestimation padding, eh?

[–] [email protected] 13 points 1 month ago

Depends on the work load. The company should make time for that and you should get paid for it.

[–] [email protected] 11 points 1 month ago

It is. Source: We've had the same issues for years, but never get any time allotted to fix them.

[–] [email protected] 24 points 1 month ago

Yeah, that's probably more the issue. We've seen too many times throwaway code become production code because "it works already, we need to move forward".

[–] [email protected] 44 points 1 month ago (1 children)

It’s hilarious when the identified problems come back around to bite the organization, when the priorities have been to work on poorly specc’d features instead.

[–] [email protected] 19 points 1 month ago (1 children)

But then it is the developers fault, never management

load more comments (1 replies)
[–] [email protected] 39 points 1 month ago

I don't care what your fancy RAMrod doohickeys say Johnson! We need that system up tomorrow so we can reach our quarterly earning projections for the shareholder's meeting!

load more comments (9 replies)
load more comments
view more: ‹ prev next ›