heckanoobs

At my workplace we have a daily DMZ (De-Meetinged Zone) from 11 to 3. Since engineers tend to roll in btwn 10 and 11 and most product ppl work normal hours and leave by 6, you end up with a lot of meetings btwn 3 and 6. But at least they aren't methodically fracturing your entire day anymore.

Care is needed when scheduling. Standard parallelization stuff. If all your sub teams want to have sub team meetings (retro, planning, blah blah), try to parallelize those meetings so there's more time on the clock for cross team meetings. If you don't do this, manager schedule ppl will start violating the DMZ.

To manage Slack interruptions disable whatever your personality is distracted by. For me I turn off all notifs that aren't direct messages to me or @mentions. I hide chat rooms with no unread messages. And most importantly I don't keep Slack on top 24/7 on some second monitor. When ppl need me the client grabs my attention and I answer. The rest of the chatter can be read at my leisure. We use emojis in our engineering channels to make it easy to scan for action items like code reviews and we use threads for replying to ppl so the channel is like the top level view of a message board.

This is functioning fairly well with ~30 engineers at the org but i think we will need to more consciously manage the 3-6 window if we doubled in size again. Fred Brooks stuff, the 3 hour window is fixed but as teams grow so does the communication overhead.

Yeah I personally use the concepts interchangeably but if you go to the pun competitions in the bay area they will disqualify spoonerisms in the general sense which includes any partial word substitutions like "punderdome"

The puns in this thread are a great example of why people hate puns. Also a lot of them are spoonerisms and not puns, which will get you ejected from a pun contest

The perf improvents are real, I recently updated our build tools from npm3 to npm5 and it shaved minutes off. npm ci is a real treat as is reliable parallelism of npm i.

IMO yarn was a protest movement when npm wasn't adding the features devs wanted. npm5 is the direct result and yarn should pat itself on the back and bow out to avoid fragmenting the community.

There's no reason you can't have a 5/5 framework with huge community and support.

Tribalism leads to choosing between two hobbled solutions because it closes the door on teamwork across tribes. Ember has its flaws but their upgrade strategy is world class. Every maintainer of an open source project should at least be familiar; but how can that happen when ppl happily report they "have heard of Ember and would NOT use it"?

I think there is a lot of tribalism in the js community and liking one framework (often the one you use for work) is synonymous with hating the others. Take this survey done where the people who have "heard of Ember and would NOT use it" is completely outsized with the rest of the data. (https://stateofjs.com/2017/front-end/results/)

I've been developing professionally for 15 years and even in that short a time I've had to frequently start fresh in new frameworks or languages as the old ones lost their edge. The concept that someone would all-caps "NOT" use something is hilariously junior to me because the sands _will_ shift and you _will_ one day face the cliff of: my existing skills have no job demand, do I learn new skills or change profession? Harboring tribalism toward frameworks will not help you make the right decision in times like these.

Why would you block all the domains but still keep your account that you would no longer be able to access? The account is the problem not the domains. You would have to block the domains on every device you use. Just kill the problem at the source and delete your entire surveillance account with facebook.

I'm not sure how we draw the line. But it should at least feel ethically itchy if ppl can use data you collected to statistically infer things normally considered private information.

This puts Google on the wrong side of the line, wherever it is, next to other big offenders - fb, twitter, linkedin.

To waffle less, I would absolutely be very cautious with who you give access to your gcal. You can tell a lot about a person knowing their schedule, who they meet with, where they meet, when they fly, etc. Lots on a calendar

I used to make fb apps, any app gets full access to fb's user graph as long as they request the relevant permissions.

Users don't comprehend what permissions they are giving to apps they run. A quiz site getting full access is not surprising.

Once an app has any amount of access the only thing stopping them from harvesting their own clone of your data is an agreement in the ToS that you won't store PII for more than x hours.

These rules are like the bare minimum to stop good actors. If you're a bad actor fb does not do a single thing to protect users from you. As evident in this report fb is also not above blaming the users for the hostile environment fb created and placed them in.

There must be countless copies of harvested fb data out there. My employer at the time once realized we were accidentally storing some PII permanently in a derived field. If good actors can't even keep above the law what do you think the ecosystem looks like in the shadows?

IMO we aren't having the right conversation with fb over how they mistreat our PII and we should loosen the definition of that term when companies like the one in the article can infer our political preferences from the innocuous bits of our lives we tag on facebook.

We should be asking why even an authorized API that can't stop you from copying the data doesn't count as a systemetized data breach.