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
-
@atheist unfortunately I've found if I want to work on a good code base and do things right, I have to manage. Most devs ive worked with have never heard of design principles.
I never wanted to manage. -
Almost ever time I heard from my lead "let's do the basic quick fix as business need it now and we will refactor/improve later stage"; the later stage has never arrived. By the time the said "later stage" comes the business now need the second part quickly and then the third and so on. Or worse second feature gets put on back burner cause business now needs something completely different and refactoring is all forgotten.
Once in a while this happens it would probably be ok or especially for critical bugs. If this happens frequently then it means either you as a lead or product owner including the team are not doing good job of planning features to include proper implementation time.
Not sure how far I would go in arguing against it as I haven't come across such situations many times but I can see the other side of the argument. -
@teapot I'm not team lead. My role is to clean up tech debt and architecture. My next on my list is this area.
-
@craig939393 this is the dilemma.
Put up with working on shit code cos most majority of devs don’t educate themselves and improve once they think they’ve learnt how to code.
Or manage, but then you are doing more of what you don’t want to be doing and a lot less of coding.
Or you try to do both jobs and burn yourself out
I had a conversation that almost became an argument with a someone I manage the other day. It revolved around how we should do just the basic parts first as that's what the business needs quickly and the code base is in a bad state right now so I didn't want to build new features on a poor foundation, particularly as those new features might not be forwards compatible and might have no way of fixing.
Once basic is in, refactor and cleanup, add secondary features. Their point was to just do it all at once in a big bang. It devolved into them getting angry and telling me to leave them out of all future discussions because now we "aren't ever doing the secondary features", just give them the task and leave them alone.
I let this go, but now I've found out they went to another high up person on the team and presumably lied to them about what was said.
What to do?
question
managing