5 ms·
The unfortunate thing is that this kind of stuff happens in our industry, regardless of architecture choices. Many developers are overworked through a combinati
by hluska 8y ago
The unfortunate thing is that this kind of stuff happens in our industry, regardless of architecture choices. Many developers are overworked through a combination of being short staffed and poorly managed.
The odds of being able to change this company are quite low. So, you'll need to make a choice. Do you want to stay until it starts to hurt your health, or do you want to leave and risk long term unemployment?
If you want to stick it out, you might need to take control of the team. In that case, I'd start by figuring out why the developer is having problems maintaining 10 microservices. Is it death by agile, is Go the wrong tool, or is it a case of massive technical debt? Or, was the whole project built by a burned out developer?
Once you figure out what's going on, you'll have to be open and honest with your CTO. Maybe your CTO needs to back off? Maybe your CTO needs to get more involved and start writing code? Maybe the other developer just isn't cut out for the company?
- throwaway3265 8y agoOh, I am great now. While it's not fulfilling, I have a fairly relaxed timeline (since it's the same deadline as the back-end) so I've done some learning, refactoring, cleanup, and extensive testing without any overwork. The project is new, so he has to create those 10 microservices from scratch. Someone is helping out managing the infra, but still there's quite a big burden on the dev. I think some optimal solutions might be to put a manager/dev lead in the middle to help out, let the team self-organize properly (cannot do that though since it's finance) or hire more devs. All of those would take months probably.
- hluska 8y agoFirst, I hope that you stay great. You've got compassion for the other developer, plus a good sense of what's wrong in an engineering culture. It would be upsetting for our industry to lose that to burnout or worse. In your CTO's defense, assuming we define microservices in roughly the same way, I think a single developer should be able to handle 10 microservices. If a developer couldn't, I'd want to look at contributing factors like death by agile, technical debt and a shitty stack. If none of those are the case, is the developer burned out? Or does she have the skill/demeanour to even do the work in that company? And sadly, you likely don't have time to ship the project and lobby for a major organizational change. I think you either need to be that manager in the middle (you're definitely capable, Manager), or alternately, how is your Go??? Good luck - I'll be thinking about you.