251–260 of 316 posts
Earlier quoted context omitted.
I was waiting for a /s at the end of this comment, but now I can't tell if you're kidding.
If MBAs weren't economically efficient, the market wouldn't make so many of them and companies wouldn't pay them so much.
Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company's hiring and resource management, and a perfect understanding of the software's requirements. These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but a…
I deeply disagree with this argument of "empathizing": it is very often the case that if I tend to disagree with another side and nevertheless attempt to "empathize" with it, my disagreement turns into furious hate for the other side.
It is in my opinion often better for the peace not to think too much about the perspective of another side that you disagree with.
"What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch." If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and…
I disagreed with this point in the article. I do not need a manager that has done my job before or spends a week a quarter doing my job. I need a manager that knows how to get my team the resources it needs and knows how to to deliver a product. Most importantly, I need a manager that trusts the team. I've had great managers that couldn't code their way out of a paper bag.
I use to also think being technical was a part of that but now i think being a good manager is worth much more on its own.
Earlier quoted context omitted.
> Sending out company newsletters seems like a nice way to let everyone know what the company is up to. Not sure how you go from that to reminding lowly engineers of their "insignificance". I agree with both you and parent. I've enjoyed getting a monthly newsletter by email in past jobs, letting me know "hey so we just signed a contract with a client that is twice as big as the biggest one we've had so far". Makes se…
I hope the filter rule auto-replied "Congrats!" and archived the thread :)
But looking back (I have left this company since then), I believe your strategy would have genuinely had a positive effect on any employee's career path.
Too much time is spent generating metrics for non-technical managers to evaluate the productivity of engineers.
The best way to evaluate the productivity of engineers would be to determine if their peers see them as a top performer, a net positive or a net negative. If somebody is a net negative, get rid of them. If somebody is a top performer, make sure they're compensated accordingly and kept happy so they don't leave. If somebody is a net positive then you should be satisfied that you aren't stuck with a net negative. Any a…
Earlier quoted context omitted.
Hah if only managers were that grown up too. I’ve tried those conversations. Firstly, that Friday deadline likely would have been fine, it was just a power play. Secondly, when the manager said “yep” to dropping the feature, you’ll still be expected to make progress. (Of course most of the time they try to make you do double the work. A quick “yep” wouldn’t happen IRL)
Get a new manager. Seriously.
Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decis…
Manager (or possibly his boss) needs a leaving present of the mythical man month
Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decis…
As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.
Earlier quoted context omitted.
> Regarding estimates, it really is frustrating when a non-engineering manager cannot understand the inability to state any reasonable time estimation. On the flipside, it can be frustrating for managers that engineers sometimes can’t understand that they have to manage deadlines. If the engineer doesn’t make an educated guess at the time it will take then the manager is put in the position of making a non-educated g…
>The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation. It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Time is almost always more flexible than the people imposing the deadlines thi…
Making decisions on the basis of an estimate which could be plus or minus 50% is fine.
It’s better than making a decision on the basis of nothing at all, and then managing the project with no clue about how long it should be taking or costing.
> If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time.
This isn’t the idea of estimates - the main idea is so you can effectively allocate resource and understand cost/benefit. All companies have limited resources and must decide if they want to focus on feature A or feature B, and part of that decision will be the likely cost, risk, and timeline to deliver.
You aren’t going to cancel a project when it goes (a bit) over budget because the development costs to date are already sunk (ie you only now need to consider remaining development effort in the cost/benefits calc) and the benefits are probably still the same.