The Power of No
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
-
For a moment there I thought I was the 'C' in this tale of woe! I have had almost identical experiences over the last few weeks, so I feel your pain. However
Quote:
(aside - everyone is Agile nowadays, right?)
No. One size does not fit all.
CHill60 wrote:
One size does not fit all.
Tell that to the airplane sits ;P :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
The best project manager I worked with used to take my estimates and treble them - the estimates were then generally accurate. A decent project manager will ask for an estimate knowing that it's really a bit of a guess and communicate that when asking the question.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
CHill60 wrote:
One size does not fit all.
Tell that to the airplane sits ;P :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
I love that word. We live and work in a transient resort town. Yesterday a fresh (they get off the greyhound daily) 1/2 wit was rolling a trash bin from the local thrift store past our shop. On the way back it stopped rolling right in front of our screen door. (ruh-row). "Hi, I found a google pixel phone under the chairlifts (skiing) and want to borrow a computer to remove the password. Do you have one?" No. - your not virus infecting one of my pcs I thought. The silence was also deafening. "I'm helping W!" - (the thrift shop owner). I just stared him down. He went on to enumerate all the reasons why I should do this for him and when I seemed unconvinced, he left. But I tell you, from project managers to street people (indistinguishable at times) one way to turn their disdain for types like you to respect, is the good old , NO! - at all probable costs. :thumbsup:
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
What a pity! You should have come up with some due dates. "I love deadlines. I like the whooshing sound they make as they fly by" DNA :D
Mircea
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
Marc Clifton wrote:
. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?)
This is really the core problem, right? Plus, that may be what some company or many companies think Agile is (running around with no idea what your doing and having your tasks change and be re-prioritized constantly) but it is not. But, that's a much longer story. Maybe you should tell C that when he documents the verbal specs and keeps them in change control so you can view the changes over time, then you would be able to give him better estimates. :-D Software can be extremely easy when you know what your building. Alas, we rarely get to know what we are building. :|
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
A company I once worked for wanted to outsource a project to a team in Romania. So, three managers (also the owners of the company) get on a flight to meet the team and discuss the project for three whole days. When they get back, one of them asks me "can you make an estimation for the project?" So obviously I ask if the remote team shouldn't make an estimation since they would be building it. They did make an estimation, but my manager didn't trust it because it was only one or two months away, which they were never going to make, and now he had more confidence in my estimations. So I aks him how many developers there were on the project. He didn't know :wtf: I asked him what the hell they talked about if they didn't talk about (believable) estimates and size of the team. He answered something like "other things, but not that." So I asked him how the hell he expected me to plan something I don't know anything about. His reply was "I know it's just guess work, so just guess" :wtf: So I "guessed" their original estimate would be accurate, but he wanted another guess :laugh: I think I answered something like "In that case I guess they'll have a hundred developers so they'll be done by tomorrow", but that wasn't the guess he wanted to hear either :laugh: It was hands down one of the weirdest conversations I've ever had :~ Ultimately, the only correct guess, and maybe you've already guessed it, was "never" :sigh: I left the company a year later and another year later they abandoned the project and lost the customer.
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
Yup, I sent a "no" to my boss yesterday. Again. If he wants me to produce "CSV files", I'm going to produce proper "CSV files", e.g. ones which Excel recognizes as "CSV" as it's the de facto Standard for "CSV". He, of course, replied that I should use vertical bars rather than commas because the whack-jobs downstream are using a tool which can't read CSV! In fairness, Microsoft's BCP utility can't read CSV either, but these people are supposed to be developers. And so it goes around again. Some uber-whack-job up above must have read a blog post about how good this tool is and dictated that everyone across the enterprise needs to stop using what works and switch to this one. piece of crap. Hey, it's expensive, it must be good! :sigh: And, yeah, the same uber-whack-jobs up above have also dictated that everyone needs to use "Scrum" even though every word out of their mouths proves that they have not the first clue what "Scrum" is. :doh:
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
Is there a solution to this? Seems this is the case everywhere (maybe almost!) and don't see getting it changed. Think, it's just live with the reaction for saying No. And the best option probably would be to provide best guesstimate and take whatever comes on the way as much possible.
For your read/comments: Beginner’s Guide to understand Kafka Beginners Quick Start to Learn React.js
-
The best project manager I worked with used to take my estimates and treble them - the estimates were then generally accurate. A decent project manager will ask for an estimate knowing that it's really a bit of a guess and communicate that when asking the question.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
The Scotty principle - always multiply your estimates by a factor of four. How else can you maintain your reputation as a miracle worker? :-D
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
I often work with people from other cultures (programmers, customers, etc) where NO is forbidden. It makes life more polite and unnecessarily difficult. Even if I ask something as simple as "Do you understand?" and the heads politely nod 'yes' regardless of whether they followed me or not. X|
-
I often work with people from other cultures (programmers, customers, etc) where NO is forbidden. It makes life more polite and unnecessarily difficult. Even if I ask something as simple as "Do you understand?" and the heads politely nod 'yes' regardless of whether they followed me or not. X|
SteakhouseLuke wrote:
I often work with people from other cultures (programmers, customers, etc) where NO is forbidden.
I thought the same thing when I read that a dev actually said no to someone. Most places there is no possible way to say no. They want an estimate and you give them one. Completely meaningless, but very polite. :|
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
Marc Clifton wrote:
The irony is that this project manager went from being a bull in a China shop to a mouse - no facilitation, no responses to our emails when we actually need some information from the client that he could "facilitate", in fact, no communication at all except an hour before the scheduled weekly meetings "Are you guys ready?"
Decades ago I worked with a QA lead who very much felt that he needed to have some visible authority and that he was constantly getting his hands tied behind his back. He stopped caring and only showed up to collect his regular paycheck. Then he was accused of "not being a team player". I saw him a few years after he was laid off, and was making the claim that "[Company Name] put an end to my IT career". I'm pretty sure he did that himself. As much as I don't like office politics, you have to learn what the rules are, and play by them. Don't sulk for months until you get fired just because you're not getting things your way.
-
I love that word. We live and work in a transient resort town. Yesterday a fresh (they get off the greyhound daily) 1/2 wit was rolling a trash bin from the local thrift store past our shop. On the way back it stopped rolling right in front of our screen door. (ruh-row). "Hi, I found a google pixel phone under the chairlifts (skiing) and want to borrow a computer to remove the password. Do you have one?" No. - your not virus infecting one of my pcs I thought. The silence was also deafening. "I'm helping W!" - (the thrift shop owner). I just stared him down. He went on to enumerate all the reasons why I should do this for him and when I seemed unconvinced, he left. But I tell you, from project managers to street people (indistinguishable at times) one way to turn their disdain for types like you to respect, is the good old , NO! - at all probable costs. :thumbsup:
Ron Anders wrote:
Hi, I found a google pixel phone under the chairlifts (skiing) and want to borrow a computer to remove the password.
Sheesh. Security (yours) reasons aside, for starters, the phone isn't his to remove the password from. That should've shut him up right there and then.
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
The more I worked in the field, the more I understood the wisdom of two year olds. When I was green I was asked to move a deadline on a 3 month project, up a month. I said maybe. My mistake. Since then I have not been afraid of "no." I realized part of my job was to protect management from themselves. Not in the job description, but when the project fails, who gets blamed? It is my responsibility, because it's my behind if it gets behind.
Real programmers use butterflies
-
I often work with people from other cultures (programmers, customers, etc) where NO is forbidden. It makes life more polite and unnecessarily difficult. Even if I ask something as simple as "Do you understand?" and the heads politely nod 'yes' regardless of whether they followed me or not. X|
SteakhouseLuke wrote:
I often work with people from other cultures
I've had that experience - it definitely requires learning how to phrase questions differently, like "tell me what you understand from all this?"
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulation -
The more I worked in the field, the more I understood the wisdom of two year olds. When I was green I was asked to move a deadline on a 3 month project, up a month. I said maybe. My mistake. Since then I have not been afraid of "no." I realized part of my job was to protect management from themselves. Not in the job description, but when the project fails, who gets blamed? It is my responsibility, because it's my behind if it gets behind.
Real programmers use butterflies
honey the codewitch wrote:
I realized part of my job was to protect management from themselves.
Yeah, so often the sad truth. Especially when the manager explicitly says "my boss is breathing down MY neck." Oi. Talk about roll reversal, which it should be the manager's job to protect you!
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulation -
The more I worked in the field, the more I understood the wisdom of two year olds. When I was green I was asked to move a deadline on a 3 month project, up a month. I said maybe. My mistake. Since then I have not been afraid of "no." I realized part of my job was to protect management from themselves. Not in the job description, but when the project fails, who gets blamed? It is my responsibility, because it's my behind if it gets behind.
Real programmers use butterflies
Quote:
...I was asked to move a deadline on a 3 month project, up a month...
I've been asked that recently in a similar timeline. I said "OK" :laugh: Then I said "Which bits do you want me to leave out?" I got some funny looks at that point, and the "nothing should be left out" response. I then wasted another 15 minutes of my life explaining that the work they required would take 4 months, so they could either have all of the work after 4 months or some of the work after 3 months. Now they've got me in overly frequent, regular meetings to review how we are against plan. The irony that these meetings are eating into my available dev time is completely lost on them :doh:
-
I was reminded of this recent event reading Kent's post 5 Project Management Skills Every Developer Should Have[^] My coworker (I'll use "C" for their name) and I were recently asked by the project manager (for context, he was a very new hire, but that doesn't imply he was new to the field of project management) assigned to our project, "Can you and C put due dates on all of the tasks for this project?" My one line answer. "No" The silence was deafening. After the pregnant silence gave birth, the obvious question "Why not???" was asked. Well, because: 1. Our daily activities include a variety of other unpredictable tasks that are constantly shifting in priority (aside - such is the life in a small company. Isn't that the definition of Agile? :laugh: ) 2. We are working with undocumented verbal specifications where new information is provided every week in the weekly meeting with the client and often previous requirements change slightly. (aside - we're an Agile team, right?) 3. The nature of the work requires interfacing with third party API's that are finicky and difficult to map their data responses into something we understand how to map to our fields. (aside - everyone is Agile nowadays, right?) 4. Your own (the client's) dataset doesn't have all the information we need and we're waiting for you to update your datasets. (aside - are THEY Agile???) 5. To put a due date on something, yes, we can estimate the number of hours, on average, per day that we can work on the project, but a due date means figuring out how many hours the task will take, and we're dealing with some unknowns that make that impossible at the moment. (Agile!) Once we have removed those unknowns, it may become possible to predict the hours. Of course, the senior project manager started off the whole conversation with the typical Dilbert-esque management speak: "I am here to facilitate -- if you need something from the client, let me know and I'll make it happen." I've been around the block enough times to know what utter BS that is. So the manager decided that what his male ego needed was a daily 30 minute conference call with moi and C to review, each and every day (except weekends) the status of each ticket. Riiiight. So we complained to our direct manager, who "managed" - managed to get that stopped. I mean reall
I ran my own schedule using scheduling software and told the (user) PM that they had their schedule and I would use mine. Of course, they could look at mine. I had projected finish dates. If there was a "due date", I made them take out "requirements" until my forecast matched their due date (year-end). And, no (I said), "more people" won't help after a certain point. I was never "popular", but never late.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
