3 ms·

this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. Be constructive and civil. Instead of congratu

this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. Be constructive and civil. Instead of congratulating yourself for the transitory sadistic, self-righteous pleasure you obviously derive from making the developers you hired "deeply uncomfortable," try working with them. Teach them exception handling if you know this. That would demonstrate a collaborative team spirit. Update: I was downvoted, as expected. In that case, I neglected to add "offensively smug." The humorless business attitude of dog-eat-dog with a facade of righteousness is here to stay.

unethical_ban 13y ago
Your comment was akin to "Fix your attitude, you asshole". Let me rephrase your comment to something you would approve of: --- >this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. It's not fun to be berated at work in front of colleagues, and the purpose it supposedly serves can be accomplished by taking the role of mentor, not drill instructor. Don't you think that's a bit harsh? It's a bad mistake for a coding expert to make, but perhaps coding wasn't their first skill, or they had a bad teacher. Call them out legitimately with their faults, let them know that certain best practices are required, and move on. Or even better: If the organization is large enough, have a coding standards document in place, like the Linux kernel and other large software projects do.
shubb 13y ago
Working with a technically competent people manager can be awkward, but I think it's over all a positive. The fact is, only the people actually implementing a project can know what the reality is. There are times when a technical tradeoff gets made (for specific example, turning exceptions off entirely in C++ is actually pretty widespread for various reasons, good and bad). Sometimes, that tradeoff may even be wrong in hindsight - a legacy of an earlier iteration that there was never budget to correct. In that sort of situation, a technical person on the outside of the project trying to be helpful can come across as annoying. They are likely telling you what you already know. However, many of these problems actually originate in people management land, and need a people management solution. For instance, I think a lot of projects mess up because they are trying to achieve too much with too little budget, or because no one with the right skills for a particular task is on the project. The people manager needs to solve those problems. It takes an unusually humble programmer to say 'Hey, I've mostly worked in python, and now I'm needing to write all these C++ modules for optimization, I'm in over my head'. If the people manager can understand his skill gaps and hire to fill them, that's really valuable. Similarly, if you need to explain to your boss that 'In hindsight, the way we are doing this won't scale. I need a whole lot of money to rewrite, and you won't see a single new feature for a month', it's going to be a much better conversation if he has understood how and why things got that way, rather than feeling a betrayal of his trust in the guy who's job it is to understand tech stuff. So, being able to say 'we should be handling exceptions' is important, but as a people manager, it is actually probably your fault. They are probably not doing it because you insisted they implement 'that important feature absolutely by next week'. If you are in charge, it's worth remembering that at some level, it's usually your fault.

unethical_ban 13y ago

Your comment was akin to "Fix your attitude, you asshole". Let me rephrase your comment to something you would approve of: --- >this particular MBA actually knows what exception handling is and wants to know why the fuck we're not doing it. It's not fun to be berated at work in front of colleagues, and the purpose it supposedly serves can be accomplished by taking the role of mentor, not drill instructor. Don't you think that's a bit harsh? It's a bad mistake for a coding expert to make, but perhaps coding wasn't their first skill, or they had a bad teacher. Call them out legitimately with their faults, let them know that certain best practices are required, and move on. Or even better: If the organization is large enough, have a coding standards document in place, like the Linux kernel and other large software projects do.

shubb 13y ago

Working with a technically competent people manager can be awkward, but I think it's over all a positive. The fact is, only the people actually implementing a project can know what the reality is. There are times when a technical tradeoff gets made (for specific example, turning exceptions off entirely in C++ is actually pretty widespread for various reasons, good and bad). Sometimes, that tradeoff may even be wrong in hindsight - a legacy of an earlier iteration that there was never budget to correct. In that sort of situation, a technical person on the outside of the project trying to be helpful can come across as annoying. They are likely telling you what you already know. However, many of these problems actually originate in people management land, and need a people management solution. For instance, I think a lot of projects mess up because they are trying to achieve too much with too little budget, or because no one with the right skills for a particular task is on the project. The people manager needs to solve those problems. It takes an unusually humble programmer to say 'Hey, I've mostly worked in python, and now I'm needing to write all these C++ modules for optimization, I'm in over my head'. If the people manager can understand his skill gaps and hire to fill them, that's really valuable. Similarly, if you need to explain to your boss that 'In hindsight, the way we are doing this won't scale. I need a whole lot of money to rewrite, and you won't see a single new feature for a month', it's going to be a much better conversation if he has understood how and why things got that way, rather than feeling a betrayal of his trust in the guy who's job it is to understand tech stuff. So, being able to say 'we should be handling exceptions' is important, but as a people manager, it is actually probably your fault. They are probably not doing it because you insisted they implement 'that important feature absolutely by next week'. If you are in charge, it's worth remembering that at some level, it's usually your fault.