I was very surprised to learn that "focussed" seems to be a correct spelling/variation of "focused".
British English, innit. :)
Your job is not to tell us how to do our job
11–20 of 21 posts
Re: Your job is not to tell us how to do our job
#12Does 2% of our user base use IE8 on Windows XP and the expected revenue from those sources is less than the cost of supporting that platform? Then I’m sorry, but they can fuck right off. That’s not worth the time it takes to support. That decision is absolutely not the place of the developer. Failing to support a particularly market segment has implications far broader than simply the bottom line dollar value of each…
The view that developers are just coders to implement business requirements shall simply follow instructions/specifications is dangerous. The attitude of "my way or highway" is absurd if you really understand how organization/team works. It's your job, as a project manager, to not only provide material supports for your engineers to do their work, but also translate business logic into clear, acceptable, feasible and inspirational vision to your dev team. Engineers, on average, are smart and reasonable people. It's your personal failure being unable to convince engineers on "why" questions (e.g. why support IE8 on XP).
btw, 90% of business fail. it means 90%+ of the so called "business requirements" are just bs. it doesn't hurt to explain your business to your engineers. Can you sell your ideas to team? if you can't, it's a bigger problem than couple of naughty engineers.
Edit: delete the last line considered offensive.
Re: Your job is not to tell us how to do our job
#13Does 2% of our user base use IE8 on Windows XP and the expected revenue from those sources is less than the cost of supporting that platform? Then I’m sorry, but they can fuck right off. That’s not worth the time it takes to support. That decision is absolutely not the place of the developer. Failing to support a particularly market segment has implications far broader than simply the bottom line dollar value of each…
I didn't say I assume the right to drop support, I said I will fight tooth and nail to drop it, that does mean following necessary process to do so. If the specification doesn't change because the stakeholders don't go for it, then that's life. As much as the business doesn't want to be wasting money, I don't want to be wasting my time on something that has a detrimental effect on our ability to get the job done.
As much as the business doesn't want to be wasting money, I don't want to be wasting my time on something that has a detrimental effect on our ability to get the job done.
If supporting older browsers is part of the specification then it has no impact on your ability to "get the job done" - supporting older browsers becomes a part of the job.
Re: Your job is not to tell us how to do our job
#14The author of this article does himself a poor service by exposing the limits of his knowledge and his unwillingness to learn from others.
Being a good coder is really nice, and you earn loads of cookie points with your team members and even some of your managers, I'm sure, but a valuable engineer (the kind who is trusted to make decisions about products) is one who understands how the scope of his activities affects the product perception for the clients and, ultimately, the bottom line for the company.
Want an example or two? Sure. 1) If 2% of your users represent ~20% of your revenue their concerns and requirements will be prioritized accordingly.
2) If you need to know a specific set of information that you don't have access to at any time, ask for it. If such information is not available, raise that concern and work with your team and the product manager to make a judgment call.
Re: Your job is not to tell us how to do our job
#15Earlier quoted context omitted.
I didn't say I assume the right to drop support, I said I will fight tooth and nail to drop it, that does mean following necessary process to do so. If the specification doesn't change because the stakeholders don't go for it, then that's life. As much as the business doesn't want to be wasting money, I don't want to be wasting my time on something that has a detrimental effect on our ability to get the job done.
As much as the business doesn't want to be wasting money, I don't want to be wasting my time on something that has a detrimental effect on our ability to get the job done. If supporting older browsers is part of the specification then it has no impact on your ability to "get the job done" - supporting older browsers becomes a part of the job.
Which is very true, and as I stated if it's part of the spec, it's part of the spec, but I find it's a duty of the job to raise it as a concern and an area of risk for delivering the product on time, especially when starting out on a new product.
Re: Your job is not to tell us how to do our job
#16The author of this article does himself a poor service by exposing the limits of his knowledge and his unwillingness to learn from others. Being a good coder is really nice, and you earn loads of cookie points with your team members and even some of your managers, I'm sure, but a valuable engineer (the kind who is trusted to make decisions about products) is one who understands how the scope of his activities affects…
I'm not entirely sure what point you're trying to make here.
If you're insinuating that I don't think of the wider business value or the business as a whole then that is just false and what I have written is not meant to be interpreted as such.
Also your examples seem to be non-sequiturs, neither are relevant to the point I've made.
Re: Your job is not to tell us how to do our job
#17Does 2% of our user base use IE8 on Windows XP and the expected revenue from those sources is less than the cost of supporting that platform? Then I’m sorry, but they can fuck right off. That’s not worth the time it takes to support. That decision is absolutely not the place of the developer. Failing to support a particularly market segment has implications far broader than simply the bottom line dollar value of each…
The developer should absolutely be involved in that discussion, as the person with the best information on the cost of supporting that long tail. If complexity makes the system less reliable for the 98%, supporting the 2% may be a fool's bargain. (If, I say - your mileage depends on your tech and your team.)
Re: Your job is not to tell us how to do our job
#18The author of this article does himself a poor service by exposing the limits of his knowledge and his unwillingness to learn from others. Being a good coder is really nice, and you earn loads of cookie points with your team members and even some of your managers, I'm sure, but a valuable engineer (the kind who is trusted to make decisions about products) is one who understands how the scope of his activities affects…
I'm not entirely sure what point you're trying to make here. If you're insinuating that I don't think of the wider business value or the business as a whole then that is just false and what I have written is not meant to be interpreted as such. Also your examples seem to be non-sequiturs, neither are relevant to the point I've made.
There's always a rift between what one means for other people to understand and what they actually do. Case in point, I thought I had made a clear statement that I thought your post was disingenuous and immature and did you a disservice by casting you as more of a coder than a valuable engineer.
I'm not saying I'm right and you are wrong, I just made a reflection of how you came across. Was that clearer now?
As for my points being non-sequiturs, I'll admit that I fail to see _any_ point in your post other than you don't know what a product manager _is_ and you feel attacked somehow, so there's a fair chance you are right.
Re: Your job is not to tell us how to do our job
#19Earlier quoted context omitted.
I'm not entirely sure what point you're trying to make here. If you're insinuating that I don't think of the wider business value or the business as a whole then that is just false and what I have written is not meant to be interpreted as such. Also your examples seem to be non-sequiturs, neither are relevant to the point I've made.
There's always a rift between what one means for other people to understand and what they actually do. Case in point, I thought I had made a clear statement that I thought your post was disingenuous and immature and did you a disservice by casting you as more of a coder than a valuable engineer. I'm not saying I'm right and you are wrong, I just made a reflection of how you came across. Was that clearer now? As for m…
It's a direct response to the original post, visit the link at the start. The point is answering the points raised in that product owner's post.
My point is that product owners should stop telling developers how to do their job, especially when the "advice" they offer is without value at best, and at worst insulting.
Re: Your job is not to tell us how to do our job
#20Does 2% of our user base use IE8 on Windows XP and the expected revenue from those sources is less than the cost of supporting that platform? Then I’m sorry, but they can fuck right off. That’s not worth the time it takes to support. That decision is absolutely not the place of the developer. Failing to support a particularly market segment has implications far broader than simply the bottom line dollar value of each…
The view that developers are just coders to implement business requirements shall simply follow instructions/specifications is dangerous. The attitude of "my way or highway" is absurd if you really understand how organization/team works. It's your job, as a project manager, to not only provide material supports for your engineers to do their work, but also translate business logic into clear, acceptable, feasible and…
The parent poster said nothing deserving of this rebuttal.