I strongly agree with some of the interactions in this article.
Advice to Junior Programmers: Don't be 'that guy'. Don't be that guy that derails meeting and projects by trying to switch frameworks or languages or whatever. Writing code in your free time is different than writing code for a business on a team. Listen to your co-workers and go with the flow until you have a lot of experience under your belt.
Managers and Sr. Devs have a very keen awareness of when they run into 'that guy'. No one likes them and they are toxic to projects. Managers and Sr. Devs want to be completing projects and not defending why they are using XYZ technology.
'That guy' has a good technical ability but no business sense and usually ends up being let go. This leads to 'that guy' thinking they have been let go because no one can see their talent and adopting a victim mentality.
'That guy' has a good technical ability but no business sense and usually ends up being let go.
I don't think so. 'That guy' usually gets lower raises and eventually wises up to his own annoyingness and then leaves for your competitor where he's no longer 'that guy'. Then you lose what would be a great employee because one time in a meeting he annoyed you. Treating toxic interactions with more toxic interaction just leads to a dead organization. (Mmmm, toxicity...)
There's a reason why we pay younger people less money than older people. They're expected to get things wrong because they don't have experience yet. Don't make up snide labels for these people; give them tasks that will give them experience. Mentor, don't judge.
"Writing code in your free time is different than writing code for a business on a team.... Managers and Sr. Devs have a very keen awareness of when they run into 'that guy'. No one likes them and they are toxic to projects. Managers and Sr. Devs want to be completing projects and not defending why they are using XYZ technology.... 'That guy' has a good technical ability but no business sense and usually ends up being let go."
Sometimes 'that guy' is calling out the emperor has no clothes, and no one likes to hear that either. 'that guy' probably has business sense too, but perhaps not political savvy, which you're seeming to put above actual dollars and cents business sense.
'that guy' may in fact have come up with a way to get a 14 hour process down to 30 minutes, but it would offend people who spent 2 months building the 14 hour process. Or 'that guy' might suggest some technology that costs 20% of what's being paid now by using vendor Y, but then the manager who's getting some freebies from a friend for pushing the business to use vendor X instead of vendor Y.
No doubt, sometimes you get truly 'toxic' people. Sometimes you're getting people upsetting the apple cart, and the rest of the team is invested so much in the current apple cart that no amount of business-oriented justification will overcome NIH, and eventually 'that guy' will either get on board with 'the company line', or will leave, possibly to a competitor that's more open to continual improvement vs protecting the status quo from "that guy".
Actually this kinda makes sense. "That guy" usually preaches switching to what is latest buzzword. That doesn't lead to anywhere but if you have a person who consistently says "if we switch to whatever(whatever is a const variable here) our workload will be less", and if you don't listen to him and give a chance; you, sir, have made a huge mistake there. If you have that "that guy" in your business, give him a side project which will show whether his perspective is wrong. If not, and if that whatever is easy to learn, code and deploy... why not?
Sure, you should not, and honestly could not, switch frameworks and languages monthly but the coding field is not cast in stone, it evolves, continues to change and will continue to change (until we hit singularity and our a.i.s start to write code based on what we want).
Johnny Cochran called. He said he wanted his slogan back. Don't be 'that guy'.
For the record, I like getting things done too. That's exactly why I focus so much on having the right tool for the job at hand. And if it turns out that there's a better choice than the one that is being made, I will bring it to the attention of the people making the decision. Does it really matter in this situation who's more junior and who's more senior?
Advice to Junior Programmers: Don't be 'that guy'. Don't be that guy that derails meeting and projects by trying to switch frameworks or languages or whatever. Writing code in your free time is different than writing code for a business on a team. Listen to your co-workers and go with the flow until you have a lot of experience under your belt.
Managers and Sr. Devs have a very keen awareness of when they run into 'that guy'. No one likes them and they are toxic to projects. Managers and Sr. Devs want to be completing projects and not defending why they are using XYZ technology.
'That guy' has a good technical ability but no business sense and usually ends up being let go. This leads to 'that guy' thinking they have been let go because no one can see their talent and adopting a victim mentality.
Be a facilitator, not an irritator.