this post was submitted on 29 Feb 2024
41 points (95.6% liked)
Programming
17398 readers
242 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 !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Get used, it's normal in some cases - projects that are most likely failing and will never deliver anything productive.
Think about this way, that . While they're postponing you're making a couple of improvements you're getting payed for something that is now very in your comfort zone and you've to do a little to no effort to deliver some progress.
This is a management issue, may have come from poor requirements, high expectations, ineptitude in software dev. project management or all of the above combined.
Your best course of action is to realize that it's not worth for you to burn yourself trying to deliver more than expected or jump ship. Just do whatever you've to do at the pace you feel comfortable, wait for the project to fail and move on. Jumping ship won't help you much, it will essentially degrade your professional image and force you to learn an entire new architecture of another project that may end up just like that one. :)
Yes, considering it as a paid education always helps. I don't really think of anyone here as a mentor, so I usually have to study on my own to learn what I need, and I still tend to regret most design decisions I make. And there's just that looming feeling that everything I've worked on is ultimately worthless. But I guess all of this is just part of the software development job, ha.
Interesting that you say jumping damages the personal image, since it seems what most others here advocate. This job gives me good perspective, so I still wouldn't want to go elsewhere without convincing myself that it's a meaningful improvement.
As long as you're learning and getting payed it is worth it... in some cases it even goes further to "as long as it pays good".
Let me explain why, from the perspective of a developer who eventually transitioned into management: Occasionally, even seemingly futile projects yield results, and the company manages to ship something, albeit subpar. If you decide to abandon ship before the project's completion, you risk being branded as unreliable and weak minded.
Projects that linger are often sustained by middle management's relentless promotion of a particular narrative or by their skillful manipulation of senior management (bullshitting). This persistent advocacy creates a perception of the project being incredibly challenging, yet the "highly competent" middle manager successfully sees it through.
Once the project triumphs, any prior skepticism dissipates, but the narrative of its formidable nature remains, and the middle manager continues to champion their foresight, claiming, "As we can see now, I was right about this project. It was nearly impossible, but our exceptional team delivered, and here we are." All parties involved receive rewards, while those who departed before the launch are often perceived as weak by their peers.
The job market is small, and having a reputation for bailing when things get hard is bad. What we witness in software development mirrors broader societal dynamics—in the past, survival hinged on confronting danger and often dying, whereas today, it's more akin to a waiting game to see who commits suicide first. Exiting such projects is akin to playing "Russian roulette" with your IT career because regardless of the project's outcome, remaining loyal to the company and sticking with the project is typically a safer bet.
Side note: Occasionally, a middle manager may push everyone into quitting, thereby shifting the blame for the project's failure onto the workforce and paving the way for securing additional resources or personnel to then covertly overhaul the project and deliver something.
Thanks for the response. I agree that the project's big boss has an impressive ability to BS on the greatness of our project, and it may be enough to push the project past the finish line.
It seems you put a lot of weight on the project's "triumph." If the project fizzles out or fails spectacularly, does that not make you more of "the fool who couldn't do it and didn't know when to quit?" I don't think I'd hold it against my coworkers for leaving if they think it would improve their situation. (And doesn't a sound project plan account for the fact that you may lose people every so often?)
Interesting note about small job market though. I only have a ~20 person IT department without much churn so it feels quite small to me still. How do you see this reputation spreading? Just the diaspora of former coworkers is wide enough that most/many companies tend to have someone who knows / has heard of you?
I see your point however you'll be covered by the dynamics of the organizational hierarchy. When the mid manager's ability to bullshit senior management eventually runs out then the project will fail, not because of technical reasons, but because the senior management will terminate it. The mid manager will then get reassigned to somewhere very far away and you'll get a new project with a different manager.
In teams with three+ developers, the one who often bears the brunt of failure is the middle manager, not the workforce. Senior management typically holds the middle manager accountable for the project's shortcomings, rather than the individual contributors. As long as you fulfill your duties (do whatever is asked), your reputation will remain intact, portraying you as someone who consistently delivers without giving up.
At the end of the day it boils down to the waiting game: who will quit first or run out of bullshit. This is the dynamic within most organizations and ultimately, individuals who "do whatever is told" and never quit tend to emerge as unscathed heroes.
A guy knows a guy that know a guy... reputation plays a significant role and even seemingly innocuous comments "yes he was at my company for 1 year and he seemed like a nice guy but then he left before delivering his first project" can have far-reaching consequences.
Moreover, burning bridges by leaving a company before delivering a project can indeed makes it next to impossible to return in the future. Maintaining a good relationship with former employers is crucial, after all you never know when you may need to go back to some company.
In a smaller or medium-sized city where good IT job opportunities are limited, burning bridges will significantly impact your future prospects. Each negative remark or unfavorable departure from a company could potentially close doors to employment opportunities permanently.
Consider the following: 15 out of those 20 people, at some point, leave the company and while they "know you", they never worked on the same project. This may lead to those seemingly innocuous comments and burning job opportunities at 15 different companies - a considerable percentage of potential job sites in some places.
Also there's the issue of recruiters. They may look at your CV and if they see a bunch of companies in a short period of time they'll most likely favour other candidates.