5 ms·
If this happens once or twice and gets resolved quickly, then sure it's OK. It can happen, and even if "team player" is often misused as a politicized HR code w
by p4wnc6 11y ago
If this happens once or twice and gets resolved quickly, then sure it's OK. It can happen, and even if "team player" is often misused as a politicized HR code word, most of us developers still do want to be team players in the real sense, and so helping out is not a problem.
But if the issue lingers over time, either because the small company doesn't want to foot the bill to hire an appropriate specialist, or because the company tries to paper over the wrongness of the on-going situation by acting like this sort of "team player" working-outside-my-speciality-because-someone-claims-it's-urgent status is just "how start-ups work" or "that's just start-ups" or "everyone's got to wear many hats" or whatever other bullshit, then that's a huge red flag.
It means that not only did the company fail to plan for its needs (which should be some cause for concern, but not catastrophic since start-ups are hard), but even more, after learning that they didn't plan staffing correctly, instead of considering the deleterious burnout effects it might have on a specialist to force them to work way outside their area for prolonged times, the company just doubles down on it and even tries to build their company culture around it, as if "just do what you're told, no matter how hilariously far off it is from what we said you'd be doing" is a centerpiece of company culture, and indeed that somehow that's "just how it is" at any start-up.
So, even if there is no intentional deceit or planned bait-and-switch, it's still a big red flag if this happens a lot and/or doesn't get resolved quickly.
If you are a specialist, any employer who doesn't care enough about your specialty to be sensitive to the request to make you work way outside of it is really bad news for your career, unless you have other reasons for wanting to work there that, for you personally, supersede however much you value career progress in your chosen specialty.
At the very least, companies should be apologetic about this when it happens, and should really work to find a compromise that doesn't cause burnout or create big gaps of time on an employee's work history during which the employee is not gaining experience related to their actual career specialty. If managers can admit the situation is not ideal, and level with you about the business emergency causing it, that's somewhat better (though still not an excuse for it to linger on for a long time). But if the business can't be bothered to admit they are doing something really suboptimal, something specifically fucking with your career progress and ability to gain experience, then it's probably time to just move on to another job. The company's not showing you any loyalty at that point, but they are expecting a pretty extreme form of loyalty and trust on the engineer's part.
- danieltillett 11y agoIt is defiantly a problem if a company does not learn and adapt to changing needs. It is an inefficient use of resources and ultimately will lead to developer churn if allowed to continue. Companies do have problem recruiting people to do the work that needs to get done verses the work developers want to do. Maintaining old code is not popular and getting good people to do this is hard. This is no excuse for engaging in bait-and-switch tactics though.
- vonmoltke 11y agoI think a lot of companies are shooting themselves in the foot in this respect. They bias themselves towards people with visible portfolios of greenfield work, then hire them to do maintenance. Not only does this select negatively for the type of person who would be good at maintenance, it also sends the signal that maintenance is a career dead-end.
- danieltillett 11y agoDoes anyone want to maintain old code as a job? I agree that there is a major issue between what companies say they want and what they actually reward people for. Be a team player and work on code maintenance, but when we promote or recruit we want a “rock star” who has 100 projects on GitHub.
- vonmoltke 11y ago> Does anyone want to maintain old code as a job? I actually think it's really fun. Of course, my attraction to engineering has always been to figuring out how things work and making them better. Unfortunately, most maintenance is just ticket-punching. I love the kind of maintenance that is "find a way to speed up the critical path in X" or "find the source of the intermittent crash in Y" rather than "change every occurrence of FONT_COLOR='#239a11' to '#239a33'".
- p4wnc6 11y ago