221–230 of 522 posts
Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.
It always gives me a pause, and then I would double the schedule.
Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.
I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
[1] Unless there are multiple skeezy companies in Menlo Park.
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…
The one that drives me up the wall is the schedule/cost anchoring question, "this should be easy to do, right?" every time they asking for a new feature. It's set to manipulate you to lower the schedule or the cost. If you say it's not easy, they would question your competency. If you say it's easy, they would say, well then you can get it done this week. It always gives me a pause, and then I would double the schedu…
The one that drives me up the wall is the schedule/cost anchoring question, "this should be easy to do, right?" every time they asking for a new feature. It's set to manipulate you to lower the schedule or the cost. If you say it's not easy, they would question your competency. If you say it's easy, they would say, well then you can get it done this week. It always gives me a pause, and then I would double the schedu…
In other words, if a project manager sets an expectation that a task is a “task that takes two weeks”, the developer will somehow manage to use about two weeks to make it, that is find the “best way” to do it given that timeframe, where “best” is probably evaluated under some kind of metric which has nothing to do with product or user value.
Sometimes the question “explain me why it should take more than two days, when i know it takes two days to do just that in the context of a minimal MVP” goes a long way in making programmers focusing on delivering the maximum value for the product.
So I think there is actually some value in having a technical person continuously challenging developers in shortening their path to implement a feature.
The one that drives me up the wall is the schedule/cost anchoring question, "this should be easy to do, right?" every time they asking for a new feature. It's set to manipulate you to lower the schedule or the cost. If you say it's not easy, they would question your competency. If you say it's easy, they would say, well then you can get it done this week. It always gives me a pause, and then I would double the schedu…
I do the opposite, I say well it's not entirely clear how much work this is going to take, I'll need to do some initial assessment to get a more accurate idea.
If they continue to pressure I ask them what changes they imagine need to be done since they're so assured of the scope and timeline of their request. I have not a care in the world of letting someone else be the "expert." If they are, I'm more than happy to go with their idea.
I've yet to get a response back outside of a collaboratige conversation with another developer working on the same codebase for similar efforts. This is usually where people realize just how much ignorance they have around their request and that they should leave it to the people more familiar with the work to make accurate assessments.
Earlier quoted context omitted.
It's an anti-pattern to simply not demo any progress until done. If you're doing agile right (loaded statement), the solution is to make sure everyone understands what's being done. If the audience is expecting all demos to show complete products, find a different audience to demo done-but-incomplete work. The idea is to get feedback before you've sunk six months into something that may not meet expectations.
Yeah, I could've been more precise about what I meant by "demo day." In my comment, I was thinking about the broader, often companywide demo days that many companies hold. I wasn't talking about intra-team demos to, say, product owners.
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…
Earlier quoted context omitted.
I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.
The defense I've seen is that it works reasonably well as a measure of productivity _if_ you're working in a similar team and in a stable codebase. From what I understand a lot of product teams at FB have nearly frictionless development tooling for their use cases so the pressure is to produce volume.