Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
The same happened to me. In 3 or 4 companies. Man, update your CV and move, seriously, moving is ok. Now it is hard for me to get a job in cool places because they ask for stuff I was supposed to know as Senior, but never had the chance to work with, because it's been all shit project after shit project.
-
boubalo5888yWell I think it would be a good idea to think about moving tbh.
You could try having a word with management about the matter to give them a chance ( however unlikely) to change for the better -
@boubalo By my experience with similar situations, even if they change, won't be for good enough and/or not for long enough.
-
If your team feels like you feel then I'd personally set up a meeting with him and management and set things straight. If they have any idea on what's good for the future of said company (I'm assuming this project is important since it's been worked on for so long) they will listen to you and what you have to say as long as you have valid points and you believe in what you're saying.
Saying that if the company is mainly sales oriented then you might want to dust off your cv before making moves like that. -
@gosubinit Yeah that's a glaring theme... I've actually tried to move but I hit the same roadblock... Not enough relevant experience in areas that they want because it's just not in the cards where I'm at. I don't tend to interview well either it seems. I feel I can design and problem solve complex issues just fine at work, but for some reason with trite interview questions, my nerves cause me to flounder.
It also doesn't help the dude is my friend. He behaves totally different inside and outside of work. It really sucks.
Thanks for the advice everyone! -
cahva10158yOur team was in same position. We had semiworking product, we cut some corners just to meet our goals. Then we convinced higherups that we will need 3-4 weeks to refactor and we got back on the right track.
You have to convince them that your team needs some time to get the base better. Building a product is like building a house. If you build on rotten base, it will collapse sooner or later.
If you cant convince them, its better to leave. -
boubalo5888y@gosubinit
True, but it might makes things go better in the future , for example:
if you ever need a reference from them (even if improbable since you are a senior dev anyway)
Or ever have to work with one of those asshats or an acquaintance of theirs.
The world is a small place , it might happen, and in any case its better to and things on a nice note and "leave a door open" as my mum likes to say.
Tell em and wait a couple of months
Then leave
Related Rants
I need some advice here... This will be a long one, please bear with me.
First, some background:
I'm a senior level developer working in a company that primarily doesn't produce software like most fast paced companies. Lots of legacy code, old processes, etc. It's very slow and bureaucratic to say the least, and much of the management and lead engineering talent subscribes to the very old school way of managing projects (commit up front, fixed budget, deliver or else...), but they let us use agile to run our team, so long as we meet our commitments (!!). We are also largely populated by people who aren't really software engineers but who do software work, so being one myself I'm actually a fish out of water... Our lead engineer is one of these people who doesn't understand software engineering and is very types when it comes to managing a project.
That being said, we have this project we've been working for a while and we've been churning on it for the better part of two years - with multiple changes in mediocre contribution to development along the way (mainly due to development talent being hard to secure from other projects). The application hasn't really been given the chance to have its core architecture developed to be really robust and elegant, in favor of "just making things work" in order to satisfy fake deliverables to give the customer.
This has led us to have to settle for a rickety architecture and sloppy technical debt that we can't take the time to properly fix because it doesn't (in the mind of the lead engineer - who isn't a software engineer mind you) deliver visible value. He's constantly changing his mind on what he wants to see working and functional, he zones out during sprint planning, tries to work stories not on the sprint backlog on the side, and doesn't let our product owner do her job. He's holding us to commitments we made in January and he's not listening when the team says we don't think we can deliver on what's left by the end of the year. He thinks it's reasonable to expect us to deliver and he's brushing us off.
We have a functional product now, but it's not very useful yet and still has some usability issues. It's still missing features, which we're being put under pressure to get implemented (even half-assed) by the end of the year.
TL;DR
Should I stand up for what I know is the right way to write software and push for something more stable sometime next year or settle for a "patch job" that we *might* deliver that will most definitely be buggy and be harder to maintain going forward? I feel like I'm fighting an uphill battle in trying to write good quality code in lieu of faster results and I just can't get behind settling for crap just because.
undefined
software engineering
advice needed
shitty lead