|
I've continuously campaigned for poo poo like this and every time they just want it in a deck. Which of course is not enough depth, so everything looks shallow or too hard to follow, so we have to meet for hours and round and round we go. I should frame the slack message I got from a boss once. So neatly summarizes corporate.txt " I don't think it's an accident that two of the richest men in the world [Jeff bezos and Warren buffet] advocate for these long form memos you are pushing, but you're fighting a whole culture here"
|
#
?
Apr 1, 2021 00:08
|
|
|
|
| # ? May 9, 2024 14:09 |
|
|
smackfu posted:Has anyone ever heard of this Amazon 6-pager thing? There are people at my gig that like to do something like I'm not a fan. I need time to think about and digest a document before having a meeting about it. But talking about things that aren't slide decks
|
|
#
?
Apr 1, 2021 00:21
|
|
|
It kind of sounds like instead of the presenter reading a document on a screen to everybody, everybody is looking down and reading the same thing themselves. Can't most of that be done outside of a room together? Who am I kidding, nobody ever does.
|
|
#
?
Apr 1, 2021 15:27
|
|
|
smackfu posted:Has anyone ever heard of this Amazon 6-pager thing? Sounds like something that could have been done over email
|
|
#
?
Apr 1, 2021 16:21
|
|
|
I can see some value in setting aside time to make sure everybody reads the loving agenda and also some value in limiting that time so it falls within the meeting's actual time slot, but gently caress wasting all that paper and gently caress everybody who repeatedly never read the loving agenda and necessitated strategies like this.
|
|
#
?
Apr 1, 2021 17:01
|
|
|
It's an alternative to presentations, not the agenda.
|
|
#
?
Apr 1, 2021 17:04
|
|
|
Rocko Bonaparte posted:It kind of sounds like instead of the presenter reading a document on a screen to everybody, everybody is looking down and reading the same thing themselves. Can't most of that be done outside of a room together? Sounds like the point of having everyone sit there with a printout in silence is to make sure they don't have anything better to do than read the thing.
|
|
#
?
Apr 1, 2021 17:05
|
|
|
Yup. The point is that people never prepare so prep goes into the meeting. Fwiw the few times I've managed to get people to do this it's gone well. I also wrote a product pitch in something like this format, to show the format, I thought the idea was mediocre. VP loved the idea, his peers and sales execs did too. So guess we're going to build that. Format was forgotten. So lol I guess.
|
|
#
?
Apr 1, 2021 17:25
|
|
|
So, you have 2 java devs, 1 golang and 2 java/golang. When adding more devs for your microservice project what's the next dev you add? .Net
|
|
#
?
Apr 1, 2021 17:51
|
|
|
Rust obviously.
|
|
#
?
Apr 1, 2021 20:14
|
|
|
Depends, who’s paying us more money?
|
|
#
?
Apr 1, 2021 21:10
|
|
|
The 6 pager thing is honestly a pretty reasonable solution to the problem of "I need to call a meeting to get input and decisions, but everyone is on their phones and laptops paying half attention at best." It also prevents people from getting stuck looking at one thing and keeping everyone else there who doesn't have any issues with it. It's dumb and wasteful but the alternative is having a half hour meeting that accomplishes nothing.
|
|
#
?
Apr 2, 2021 01:11
|
|
|
Volmarias posted:It's dumb and wasteful but the alternative is having a half hour meeting that accomplishes nothing. Another alternative is to send the document around for asynchronous comment without a meeting.
|
|
#
?
Apr 2, 2021 15:32
|
|
|
Paolomania posted:Another alternative is to send the document around for asynchronous comment without a meeting. This would be preferable if recipients could ever be trusted to read something sent to them. I would love to get rid of meetings but discovered the hard way that they mostly just serve as social pressure to get attendees to all actually focus on the task at hand.
|
|
#
?
Apr 2, 2021 15:54
|
|
|
Paolomania posted:Another alternative is to send the document around for asynchronous comment without a meeting. I still can't get people to answer more than one direct question per mail, so yeah about that 
|
|
#
?
Apr 2, 2021 15:57
|
|
|
Must be a culture thing. In my group people are so thirsty to critique a design that sending a doc around is like hazing.
|
|
#
?
Apr 2, 2021 16:19
|
|
|
Paolomania posted:Another alternative is to send the document around for asynchronous comment without a meeting. I try to do this all the time and nobody ever responds. 
|
|
#
?
Apr 2, 2021 17:25
|
|
|
Paolomania posted:Must be a culture thing. In my group people are so thirsty to critique a design that sending a doc around is like hazing. That sounds absolutely miserable and truly toxic.
|
|
#
?
Apr 2, 2021 21:38
|
|
|
Blinkz0rz posted:That sounds absolutely miserable and truly toxic. My company has a culture where commenting on docs is encouraged (because it's easy to substantiate as impact at review time). I also can't get anyone to comment on anything I've written usually. In conclusion docs are a land of contrast
|
|
#
?
Apr 2, 2021 23:02
|
|
|
YanniRotten posted:My company has a culture where commenting on docs is encouraged (because it's easy to substantiate as impact at review time). Commenting on docs is one thing but people being "so thirsty to critique a design" sounds awful. If I were a junior engineer working in a system like that I'd be absolutely terrified of submitting anything for fear of it being torn apart for fun.
|
|
#
?
Apr 3, 2021 01:38
|
|
|
Blinkz0rz posted:That sounds absolutely miserable and truly toxic. This is an odd view. There is nothing toxic about writing valid critical feedback on a design doc. Early on I learned a lot from more experienced engineers commenting to point out hidden complexity, maintenance burden and production issues that I hadn't thought about. We also have other stakeholders comment such as ops and front line techs. Beating up an idea in the design is far less painful than struggling with those issues and changing course during months of development and years in production.
|
|
#
?
Apr 3, 2021 07:34
|
|
|
Paolomania posted:This is an odd view. There is nothing toxic about writing valid critical feedback on a design doc. Early on I learned a lot from more experienced engineers commenting to point out hidden complexity, maintenance burden and production issues that I hadn't thought about. We also have other stakeholders comment such as ops and front line techs. Beating up an idea in the design is far less painful than struggling with those issues and changing course during months of development and years in production. Talking about how thirsty people are to comment and likening it to hazing makes it sound pretty bad. Also using language like "beating up an idea" ain't great either. If I didn't know anything else about your org I'd assume whenever anything goes wrong there's a huge round of the blame game and consequently anyone even moderately junior tries to stay as small and as quiet as possible so they don't make a mistake or get blamed for one.
|
|
#
?
Apr 3, 2021 13:04
|
|
|
Blinkz0rz posted:Commenting on docs is one thing but people being "so thirsty to critique a design" sounds awful. If I were a junior engineer working in a system like that I'd be absolutely terrified of submitting anything for fear of it being torn apart for fun.
|
|
#
?
Apr 3, 2021 15:14
|
|
|
Blinkz0rz posted:Talking about how thirsty people are to comment and likening it to hazing makes it sound pretty bad. We have a formal blameless post-mortem. Everyone has skin in the game because responsibility for the system is shared and therefore it is in everyone's best interest to get it right early. Ideas are not people. Designs are not people. Processes are not people. Being critical of an idea is not a personal attack.
|
|
#
?
Apr 3, 2021 15:47
|
|
|
Paolomania posted:We have a formal blameless post-mortem. Everyone has skin in the game because responsibility for the system is shared and therefore it is in everyone's best interest to get it right early. Ideas are not people. Designs are not people. Processes are not people. Being critical of an idea is not a personal attack. You were the one who used the word "hazing" to describe how a design was treated
|
|
#
?
Apr 3, 2021 15:51
|
|
|
Paolomania posted:We have a formal blameless post-mortem. Everyone has skin in the game because responsibility for the system is shared and therefore it is in everyone's best interest to get it right early. Ideas are not people. Designs are not people. Processes are not people. Being critical of an idea is not a personal attack. No matter how much you want to claim that "being critical of an idea is not a personal attack", having a team culture that salivates at tearing ideas apart isn't good for anyone trying to develop their skills much less grow a team where everyone actually has equal skin in the game versus the loudest people in the room. What you wrote is the tech jargony equivalent of "toughen up snowflake" and that's super not great.
|
|
#
?
Apr 3, 2021 16:06
|
|
|
Psychological safety is imperative to successful teams. Hazing is antithetical to psychological safety. Thanks for coming to my ted talk
|
|
#
?
Apr 3, 2021 16:11
|
|
|
I don’t think careful politeness and avoidance of conflict to ensure safety is good for teams either. As long as everyone’s having fun with the way things get critiqued and everyone feels secure, it’s not ‘toxic’. Some teams don’t even have juniors that need encouragement and safety so there’s no need to tiptoe around each other. I’d rather have a team of people who can rip each other’s work apart in fun and good humour than people who are too polite to say anything at all. Some people even find that a confidence booster rather than the opposite (“hmm, this team all get really quiet and polite when they disagree. It must be unsafe to speak up and I should follow the leader. But this other team all make their voices heard loudly. If I show my own strong opinion in that team, I think they’ll respect me for it.”) Different teams and people find their own equilibrium.
|
|
#
?
Apr 3, 2021 16:40
|
|
|
Prism Mirror Lens posted:I don’t think careful politeness and avoidance of conflict to ensure safety is good for teams either. Being polite and avoiding conflict aren't conjoined ideas. The way criticism is communicated makes a huge difference in the environment and in how that criticism is received. A process where a design has gotten to a stage where it's being critiqued without the team having already made whatever fundamental decisions are causing it to be bad enough that people feel justified tearing it apart also seems pretty dysfunctional. If they aren't fundamental issues then the only reason to rip it to shreds is that you're an rear end in a top hat. Wallet fucked around with this message at 20:50 on Apr 3, 2021 |
|
#
?
Apr 3, 2021 20:43
|
|
|
Wallet posted:Being polite and avoiding conflict aren't conjoined ideas. The way criticism is communicated makes a huge difference in the environment and in how that criticism is received. I had a design get ripped to shreds by someone after I'd spent a couple of months on the project. I was like "You know what? Clearly the person critiquing my design has a vested interest in doing all the work. Look at the passion in all these criticisms." I then gave the project to that person and he had to design it and implement it himself.
|
|
#
?
Apr 3, 2021 21:14
|
|
|
fourwood posted:Yeah I’m with you, this kinda skeezes me out. And in my experience the types of people who are really “thirsty to critique” are all in on the bike shedding and not actually being constructive. This this this. I had an extremely "met expectations" annual review and was called out for not participating as much in design conversations because I kept reasonably quiet during a lame agile multi-hour planning session for our next 4 quarters instead of endlessly wasting time bike shedding about work months from now, versus acknowledging that we are a small enough team to turn on a dime if we had to. Still getting the hang of this process heavy/lean results team 
Smugworth fucked around with this message at 01:49 on Apr 4, 2021 |
|
#
?
Apr 4, 2021 01:46
|
|
|
One of the things I like best at my company is how often someone will say "ok let's deal with that when we get there" instead of endlessly speculating about how we might build some feature that may end up not even happening
|
|
#
?
Apr 4, 2021 02:38
|
|
|
I don't feel like I'm experienced enough yet to with enough different teams and enough different projects to say something as sweeping as, "The more you enforce 'academic' coding standards on a project, the less output you'll get", but I'm increasingly convinced that is indeed the case. I also think trying to design around every potential future problem is a huge mistake. I more and more believe that you should build a thing the best way you and your team currently can, and be prepared for the consequences of inexperience, looser standards, or likely both. If you are in a field where mistakes are truly catastrophic, then a different set of rules probably apply, but for the vast majority of software, a bug doesn't mean that a plane crashes. The most successful stories I have about my career for both personal/team growth, and for a final product usually start with, 'We made an MVP that became the product really fast...' and end with, '...and then we lit it all on fire, started over, and rebuilt knowing more about our product, data pipes, and stakeholders'. My hot take: Be less scared to just trash a project and start over.
|
|
#
?
Apr 4, 2021 03:20
|
|
|
When I joined my new team as a senior I was told to by the team to shake things up a little, ask pointed questions and criticize the status quo seeing as I was new blood. I thought fair enough, but better to step lightly until we've gotten to know each other. Three weeks later my boss has to come speak to me because some people on the team had thrown a major fit and gone behind my back because I had asked for the context of certain decisions and dared question some of their undocumented coding style choices in a pull request. I'm taking a promotion and transferring to a different team. Point is, teams where nobody can agree on anything and every decision requires a debate are no good, but neither are teams where there's no culture for constructive criticism or flexibility. I feel like the most effective team composition is one where you have both seniors and juniors, and where both of these groups have outspoken types and keep your head down types. In theory an all senior/outspoken group can work, but only if they all see eye-to-eye from the onset. Still, such a group will probably struggle with on-boarding new people. Oh, and another lesson is that there's not necessarily any correlation between what sort of culture a team claims to have, and what that culture is actually like. thotsky fucked around with this message at 03:31 on Apr 4, 2021 |
|
#
?
Apr 4, 2021 03:27
|
|
|
Canine Blues Arooo posted:My hot take: Be less scared to just trash a project and start over. On the other hand, don't prolong failed concepts by suggesting multiple rewrites 
|
|
#
?
Apr 4, 2021 03:29
|
|
|
You can positively criticize. Appreciate the progress so far, encourage to move in different directions, get excited about the oncoming results after fixes are made. Everybody wins. I know you all are way more experiences at this than I but chipping away at a few layers of built-up salt might do some good.
|
|
#
?
Apr 4, 2021 04:01
|
|
|
Prism Mirror Lens posted:I don’t think careful politeness and avoidance of conflict to ensure safety is good for teams either. As long as everyone’s having fun with the way things get critiqued and everyone feels secure, it’s not ‘toxic’. Some teams don’t even have juniors that need encouragement and safety so there’s no need to tiptoe around each other. I’d rather have a team of people who can rip each other’s work apart in fun and good humour than people who are too polite to say anything at all. Some people even find that a confidence booster rather than the opposite (“hmm, this team all get really quiet and polite when they disagree. It must be unsafe to speak up and I should follow the leader. But this other team all make their voices heard loudly. If I show my own strong opinion in that team, I think they’ll respect me for it.”) Different teams and people find their own equilibrium.
|
|
#
?
Apr 4, 2021 05:02
|
|
|
Canine Blues Arooo posted:"The more you enforce 'academic' coding standards on a project, the less output you'll get", but I'm increasingly convinced that is indeed the case. My experience re: this concept and this wider discussion is that there is definitely (obviously) a happy medium between "I am free to do whatever I want at work so long as I personally conceive it to be productive" and "as a rule, I viciously attack all work I don't personally produce", but also, trying to discuss where that happy medium is located is totally pointless without a formalized and adhered to design process. The best org I've worked in, in this perspective, definitely cultivated a culture of active peer review and critique. We also had consensus based standards so the critique was always "This implementation could more closely follow X design principle (link to document explaining it) by making these changes" or "Since we adhere to YAGNI, it is better if you don't pre-implement this interface and just take the naive approach for now". Part of even being able to produce a design that is peer reviewed involved participating in an onboarding process and first having reviewed another design yourself, which you did with your mentor and they would explain the process, go over the standards, etc. The more potentially heated/fundamental discussions (ex: ORM or not) happened on a different cadence, in a different forum, and with a different set of participants including engineering leadership. Litigating nested list comprehension vs nested for loop in pull request comments is a negligent waste of your own time as well as the the time of your coworkers. That design review could even be perceived as either polite or impolite is also an indicator that the design process itself is flawed.
|
|
#
?
Apr 4, 2021 05:24
|
|
|
thotsky posted:When I joined my new team as a senior I was told to by the team to shake things up a little, ask pointed questions and criticize the status quo seeing as I was new blood. I thought fair enough, but better to step lightly until we've gotten to know each other. Three weeks later my boss has to come speak to me because some people on the team had thrown a major fit and gone behind my back because I had asked for the context of certain decisions and dared question some of their undocumented coding style choices in a pull request. I'm taking a promotion and transferring to a different team. You just have a lovely manager. I say pretty much the same thing for each hire, "Your new eyes are the rarest resource we have, if you don't understand the how or why ask and let's talk about it before group-think takes hold." There's plenty of great experiences that comes from that from Mids, Seniors and even Leads that are 95% managers. The fact that: A) The manager didn't seem to have your back to shut down that bitch session and B) The manager has fostered a team where such a bitch session was considered ok rather than being an opportunity for introspection.
|
|
#
?
Apr 4, 2021 07:02
|
|
|
|
| # ? May 9, 2024 14:09 |
|
|
Slimy Hog posted:You were the one who used the word "hazing" to describe how a design was treated I admit it was an offhand and hyperbolic statement. I should have just said "if your team is good at giving asynchronous feedback on documents you can skip the read-the-design-doc meeting".
|
|
#
?
Apr 4, 2021 07:28
|
|