tired of constant uncertainty
Posted by AQJK10@reddit | ExperiencedDevs | View on Reddit | 35 comments
i want to preface this by saying - i know what our industry is like and being comfortable in uncertainty is very much a pre-requisite for being successful in this job.
running after people for the spec. people dilly-dallying on details. people not being pro-active with information. X says talk to Y, Y says talk to Z and Z says go to X. Then bring X, Y, Z together. nearly everything i work on these days feels like just needing half the sprint to gather all the details and understand what the work is. i dont understand why this portion is so underestimated. this should be done before the sprint. not during the sprint. nobody seems to understand or care. they just want it done. somehow
it feels too tiring. my brain is in squirrel mode just trying not to waste time and understand everything. many people might say this is what i signed up for... i dont know. i like to code and i like to program. i like to learn but honestly 75% of the days i cant tell whether or not i do. it just feels like wanting to get it done and dusted off. does anyone have better experiences? Is this the way it'll always be? I keep saying that where I work is bad and toxic, but I wonder what other places are like
local_eclectic@reddit
This is a side effect of people not having agency
ieatdownvotes4food@reddit
That sounds like par for the course. The problem is mentally you think coding is the job, and all this is unreasonable bullshit that gets in the way..
shift your thinking to this Sherlock dance IS is the job, and pat yourself on the back when you can get spec nailed down to a T.
Not easy by any means but try to get systematic about it.
LowLifeDev@reddit
Then why do we need all those managers, product owners, scrum masters, analysts and rest of non technical people?
sol_in_vic_tus@reddit
So that there are people who can sit in the meetings with management and show them boxes on a list getting checked off.
CymruSober@reddit
So that people who are more clueless higher up in the chain and don’t even know enough to have any respect for people who know stuff are not shitting all over the place
Careful_Ad_9077@reddit
My eureka moment came when we had a complex system problem to solve, doing it with a mid programmer mind set meant doing a lot of code. Then our tech lead had an idea to fix it without doing any code.
danknadoflex@reddit
These are the words of an experienced dev right here. The sooner you understand this the better. The dance is not the distraction, the dance IS the performance and coding is not the star of the show.
GlassVase1@reddit
This helps, but when someone is asked to deliver something with a fixed date, but unfixed variables it's going to cause stress and anxiety.
ieatdownvotes4food@reddit
Yeah, it's the shit sandwich that can come with this gig at times for sure.. my default in these scenarios is to put in the hours, not more. Document everything along the way, don't be afraid to over-communicate during every standup, bring it up during retros, and if cards carry over to next sprint lean into a thick skin about it and let the cards fall where they may.
At that point the issue is really external to you, and likely affects most members on the team. If the company is good you should receive support and can impact change.. if it sucks you're vulnerable to all sorts of bad. But it's just a job, and there other fish in the sea.
AQJK10@reddit (OP)
u are right
Wooden-Contract-2760@reddit
Lacking Domain Awareness makes it hard to stay motivated, just like missing on imcentive to push more than just code into git.
Developers either surpass their roles (be it Engineer, Owner, or Officer role) or they are deemed to feel less valued over time.
AQJK10@reddit (OP)
what is Engineer, Owner or Officer?
Developers by virtue of their work are also part Eningeer and part Owner. You have to engineer the solution not just write code. and you have to own the feature / product better than the person who asked for it
Wooden-Contract-2760@reddit
does not suggest much ownership
no officer
and there goes the engineer perspective
apartment-seeker@reddit
This doesn't sound normal to me.
raven_raven@reddit
I’m OK with that as long as the management count all this alignment as me doing my job. But more often than not lately, I still have to clarify everything and somehow it doesn’t count when talking about my performance.
AQJK10@reddit (OP)
exactly, it's busy work that no one cares about. This is my biggest gripe. The devs are always on the hook to deliver
Redtitwhore@reddit
Fucking sprints.
peripateticman2026@reddit
They created a sweatshop industry - those fucking snake-oil merchants.
Traditional Waterfall is the best for almost all domains.
AQJK10@reddit (OP)
estimates, sprints, timelines these are all stupid. i want to shut the world out and write an operating system. no more crumbly disgusting enterprise code
ImSoCul@reddit
ah yes, your operating system will be flawless and have no tech debt or bugs.
Read this: it's old but it was accurate when I started my career, and it is only more accurate today. You basically teed it up perfectly https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Green0Photon@reddit
On the flipside, I feel like I constantly say how I want to just modify whatever existing software instead of rewriting stuff.
Meanwhile I had one manager talking about trying to tech bankruptcy on one app, and another backend system with four rewrites? Though tbh in trying to finally get to MVP of the recent rewrite, it almost feels like a rewrite of this rewrite, partially. And never fully migrating off of the old systems.
It's a stupid nightmare mess. And I don't have the authority to do any systems design -- it backfired on me trying to do so previously, though I did get some good stuff through.
AQJK10@reddit (OP)
i was only half joking abt the os. but atleast it'll be fun. and i've read that before and bookmarked it
ImSoCul@reddit
cool cool yeah, even if you're aware, it's good to have that reminder. This is probably one of my favorite pieces of writing related to software. Definitely a top 5
PoopsCodeAllTheTime@reddit
Become the boss, put everyone in line, enjoy nirvana.
Not sure how to get to the first step of the plan, but if you get there, it definitely works.
Huge-Leek844@reddit
I have no problem on running after people for requirements, tooling, check files, although is tiresome. I do have a problem with glue work. Running after people for technical stuff and i just check the box.
This is what i ve been doing for months and i hate it.
wutcnbrowndo4u@reddit
IMO the patterns you describe are not inherent to engineering. There exist communication & execution structures that allow information to show up where it should when it's needed, for the most part.
Obviously, no process or organization is perfect. But maybe you are a poor fit for a place with a poor culture of engineering execution.
10199@reddit
It can get worse. I found that our proprietary framework cant handle one type of messages, I asked what am I doing wrong and one dev confirmned "yes looks like we cant do it at the moment". To make story short now I am in limbo between dozens of devs, everybody needs something unique to be done so this feature can be included in framework but all of them are too busy (or have attention span of a hamster). In each conversation they ask "please remind me what this all is about". I am on 4th circle already (spent about 2 weeks on it), and it has not been moved anywhere.
Specialist_End407@reddit
Coding is barely 20% of the software dev. Sometimes you just have to admit that there's always this grueling groundworks before any paving can be done and it is just what it is. Take pride on these processes but don't take it too personally. Document it all, own it up, it's super hard to get everyone on the same page, what more to write a book with 10 different authors. To be so much coherent in the story, that's what most people don't just get.
poeir@reddit
It kind of feels like LLMs are subject to a form of Amdahl's law: Okay, writing the code is now infinitely faster. Thus, the project can be delivered 20% faster.
Specialist_End407@reddit
The fast food of software development is here and we've been led again and again to believe that delivery speed metric is all that matter. It's now a game of perception and better convincing your higher ups, the clients, the market. Coding is now barely 2% of software development.
ZergTerminaL@reddit
The work is in the ambiquity and the uncertainty - everything else seems to already be available commercially. Sprint or no sprint, I'd be doing the same things.
ImSoCul@reddit
>this should be done before the sprint. not during the sprint
wdym? like on Saturday? Defining the requirements is the work, and as AI starts to eat up the implementation portions, navigating through ambiguity is the key value-add engineers bring. I spend majority of my time writing docs and nailing down specs. Coding these days is pretty rare for me.
If you just want to write code, entry/junior level positions, especially within greenfield projects, may have more of this. However, cases like this especially where requirements are less ambiguous are ripe for competition, today from AI, but even before that from offshoring/nearshoring and in the future it may be some combination of the two. There's no reason to pay you a premium to do the easy part
throwaway_0x90@reddit
You're absolutely correct that it's not easy. Writing code is a walk in the park compared to dealing with humans and their ambiguous requirements that turn into emergencies at the 11th hour.
But that's what they pay the big bucks to Staff engineers to figure out.
aghost_7@reddit
Just ask your manager, it sounds like this isn't your problem unless you're in a startup.
filter-spam@reddit
Sadly I’ve never known it to be different