Well at some point you expect some artifacts to show up, even if not just code, design docs, RFCs, code reviews, something. If there truly is nothing I don't think that's a viable way to contribute either. Sure one can "only help others" but all good engineers I've worked with can help others and still do their main tasks, and if they get to a point where they are a point of reference for everyone else and everyone else gets blocked without them this is a high priority thing to fix in the team, probably one of the highest priority things to fix.
I've seen management let bad engineers re-do projects from scratch 2 or 3 times. Because they blame bad requirements, poor choice of programming language, and whatever on all the issues that the project has.
They eventually acquire enough experience to be able to produce something that sort-of works around the 3rd attempt.
But thanks to how good they are at communicating, are considered by management to be good engineers.
While doing a working project at the 1st try, without using this week's new framework and so on isn't as valued.
I mean at some point we just get generic enough that we have to agree on the ultimate fact that at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles. I agree what you say happens but if good work isn't consistently recognized and you think you've worked on your comms, there's not much else to do really.
Well at some point you expect some artifacts to show up, even if not just code, design docs, RFCs, code reviews, something. If there truly is nothing I don't think that's a viable way to contribute either. Sure one can "only help others" but all good engineers I've worked with can help others and still do their main tasks, and if they get to a point where they are a point of reference for everyone else and everyone else gets blocked without them this is a high priority thing to fix in the team, probably one of the highest priority things to fix.
I've seen management let bad engineers re-do projects from scratch 2 or 3 times. Because they blame bad requirements, poor choice of programming language, and whatever on all the issues that the project has.
They eventually acquire enough experience to be able to produce something that sort-of works around the 3rd attempt.
But thanks to how good they are at communicating, are considered by management to be good engineers.
While doing a working project at the 1st try, without using this week's new framework and so on isn't as valued.
I mean at some point we just get generic enough that we have to agree on the ultimate fact that at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles. I agree what you say happens but if good work isn't consistently recognized and you think you've worked on your comms, there's not much else to do really.
2 replies →