I expect anyone within earshot who cares about me to put me down if I ever used any of these phrases in a serious context.
Master the Art of the Product Manager 'No'
131–140 of 173 posts
Re: Master the Art of the Product Manager 'No'
#132Earlier quoted context omitted.
No. The engineers can talk to the customers and figure out what they want. Cut out the redundant middleman.
Which engineer talks to the customer? That person shall henceforth be called the Product Manager.
"Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?"
Re: Master the Art of the Product Manager 'No'
#133Earlier quoted context omitted.
As a PM, I factor this into prioritization. An engineer passionate for a product will lead to better engineering output, increased morale, and feeling of being heard. A motivated, bought-in engineer team is important when it comes to building the ‘high impact’ products. Prioritization isn’t always black and white. These qualitative factors matter and shouldn’t be ignored. As always, you weight it against other trade…
I’ve been a pm Eng and designer and this sort of patronizing attitude sucks. Look at the end of the day you should be cultivating fellow thought leaders because when you grow up you learn your priorities are more often than not just your own egotistical nonsense and wrong. But you have a lot of phrases to cut others down. Try something different.
Is it actually all that patronizing to say "If your engineer really wants to work on something, you should probably let them"?
Re: Master the Art of the Product Manager 'No'
#134Earlier quoted context omitted.
I guess the correct way to present this is something like "I know how to fix this in the short term but we should consider simplifying things because as far as I can tell the current code is much more complex than it needs to be".
Yeah that's pretty much what I told them, except I didn't know how to fix it in the short term. That's kind of my whole point - the "quick fix" took longer than a proper fix would have.
I don't know the exact situation but I just wanted to point out not to fall into the "I have looked at the thing for a little. I don't understand it and I can't be bothered to understand it because whoever write it, was an idiot. We need a full rewrite with my favorite shiny tool. The rewrite will be easy" trap. I think that triggers a lot experienced people.
But maybe you are right. That's also very possible
Re: Master the Art of the Product Manager 'No'
#135Earlier quoted context omitted.
I once worked on an application that integrated with a third party api. The way it did this was with a large and horrible client library that used a separate db to cache the data. The data was then fetched from the main application and used to rebuild the pages (in the main db) based on this data once a day. The library had lots of problems, and one day it stopped working. I was tasked with fixing it - we had the sou…
I've been on both sides of this table multiple times, as the IC and as the Manager of an eager IC. Here's a list of all the reasons why I as your manager would also flat-out say No to this situation. (These are of course heavily tainted by my own recent experience of trying to coach a mid-level dev through a very similar problem) - "Pretty much working" means all the fun stuff is done and the actual hard thing is lef…
You could also ask the developer to write comprehensive documentation and test cases, not only for the new code but also for the older code, to ensure the new one can replicate the bugs higher level systems depend upon.
Re: Master the Art of the Product Manager 'No'
#136Earlier quoted context omitted.
"I spent most of the week if not more trying to figure out what was wrong, but I couldn't. What I did learn was that this library was some of the worst most pointless code I'd ever seen." I would probably be skeptical if somebody made these statements. You don't know what's wrong and you declare the code to be pointless. Maybe you put a good effort into it but I have heard it too many times that somebody declared "th…
The problem was not that I did not understand the code. I understood it just fine, it wasn't complicated it was just bad and old. All it did was get some data from an api, change it somewhat, store it in a db. Then a scheduled job would call a method which would get that data, change it a bit more and return it where it would be changed yet a bit more and stored as pages for the main web app. There was no reason all…
> We're talking about what you might expect if you gave a mediocre first year CS student the task of parsing some specific xml.
It's ok, you can say it was a bunch of regex.
Re: Master the Art of the Product Manager 'No'
#137Earlier quoted context omitted.
I love when people like you post with no concept of "per capita". Then there's always frustration at the people who do understand the concept and realize the "point" is simply a result of ignorance. China is at 30% renewable energy. The US is at 21%. And the president of the dirtiest country in the world, lots of smart people are saying it, that's just what they call the US these days, they say, passed an executive o…
/forehead slap If China is using more renewables, then why are they producing way more GHG? See how this line of reasoning is flawed? This reality undermines your snark about having a higher % mix or per capita production, which is an incomplete rebuttal and serves greenwashing arguments.
Because they have 1.4 billion people.
https://www.collinsdictionary.com/dictionary/english/per-cap...
Some useful terminology for your journey.
Imagine you have a buffet. You have five people who each take 1 steak. Then you have one person who takes 4 steaks.
You are the person saying the one person taking 4 steaks is okay. The problem is the selfish four people who are eating 1 steak each. If they all stopped, the other guy could have 9 steaks.
Which is of course a silly proposition. The one guy could simply eat fewer steaks.
China is also the center of world manufacturing. The fact they make almost everything on earth but still have lower per capita emissions than the US is impressive.
Re: Master the Art of the Product Manager 'No'
#138Earlier quoted context omitted.
except that these things are measurable and quite trivially
Not when actors report false numbers. China's track record is terrible on honest environmental reporting [0] and their power consumption has been greenwashed with electrification that makes a minor portion of their GHG growth [1]. [0] https://www.nytimes.com/2012/06/06/world/asia/china-asks-emb... [1] https://dialogue.earth/en/climate/chinas-manufacturing-pushe...
You have a 12 year old article about manual reporting of smog levels that's moot given the past decade of gas measuring satellites, and you ignore the fact that China isn't a closed country, it's one routinely visited by internationals including those from the IEA that directly inspect energy infrastructure.
Re: Master the Art of the Product Manager 'No'
#139There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting. 2. This idea needs to be more fully developed before we can decide whether it is good or bad. 3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a pri…
>hijacking the agenda to turn the meeting into a brainstorming session As someone who has reason to call technical meetings on a regular basis, I've always had trouble with this. Do you mention 'brainstorming' in the agenda? Do you use a different header? Most of the meetings I end up having are only vehicles to get necessary players into the same room and engaging in dialogue about a problem with a technical angle.…
There are almost certainly different approaches depending on the environment and situation. But, especially if this is a "culture" problem one of the best fixes I've found is to make shorter meetings with a defined agenda, such that you can always pull out a, "I'd love to take this offline, but we need to get back to..."
I've personally found you should almost never need more than 30 minutes unless you specifically want to get into rabbit holes. And if you do need more than 30 minutes, it's probably better to split it into multiple sessions of no more than 30 minutes anyways to prevent this from happening. If you still have this problem at 30 minutes, shave 5 from either side (or both), which you can even use the excuse of giving time to transition between meetings.
That's not to say you shouldn't genuinely allow room for brainstorming, but if you're going to take an entire room of peoples time, make sure it's something the room agrees is worth discussing and find another time to do it instead of getting sidetracked now. If not, offer some 1-on-1 time, and move on.
Re: Master the Art of the Product Manager 'No'
#140Earlier quoted context omitted.
I once worked on an application that integrated with a third party api. The way it did this was with a large and horrible client library that used a separate db to cache the data. The data was then fetched from the main application and used to rebuild the pages (in the main db) based on this data once a day. The library had lots of problems, and one day it stopped working. I was tasked with fixing it - we had the sou…
I've been on both sides of this table multiple times, as the IC and as the Manager of an eager IC. Here's a list of all the reasons why I as your manager would also flat-out say No to this situation. (These are of course heavily tainted by my own recent experience of trying to coach a mid-level dev through a very similar problem) - "Pretty much working" means all the fun stuff is done and the actual hard thing is lef…
And that's how you lose good developers