> My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because:
I think you're misusing the term "monorepo", no? Monorepo is just a technique for organizing source control repositories. It's possible to have microservices AND monorepos.
This is weird, I had Zoom installed a long time ago but uninstalled according to their instructions [1]. I'm a macOS user.
As soon as I clicked that link, the client downloaded a PKG file, installed itself and launched itself without asking me if I wanted to share my camera or audio.
I uninstalled according to their instructions again, searched for all "zoom" files in my disk and rebooted.
This leads me to believe that following their uninstall instructions is insufficient, and there are hidden files left on my computer.
Don't be sorry, same thing happened to me just now and I'm trying to figure out how they are installing locally from a URL click with no further input from me.
> After a year or so of trial and error, we have pretty much stopped using reduce
I see Reduce (along with recursion itself) as the equivalent of a "low-level" construct in functional programming.
It is a great building block for other functions like sum/product, and even those demonstrated in the article, but not something that programmers should be using everyday.
I think it's very appropriate to have a rule to only use reduce (and recursion too!) inside "utility" libraries.
IME the thing that matters the most is focus, both on the micro and macro level. It's way too easy to get caught on things that won't make an iota of difference in your future. Focus is the first thing that goes out the window as soon a a company reach just a bit of momentum.
I've seen several startups suffering from not being able to decide what they were. Engineering teams fractured because the company wanted half of them working on their bottom line and the other half working in some offshoot product.
Even gigantic companies need that: notice how people criticize Google for creating and killing way too many products, and at the same time praising their minimalist webpage (since 1998), early GMail, etc. Same with Apple when Jobs returned to Apple and streamlined their product line, etc.
I agree with this but want to add prioritisation is key. As per Fred Brooks, there is no silver bullet. What he meant by that is that you can't get an order of magnitude more work done using a tool or process because in programming, 25% of your time is spent doing analysis and there is no way to reduce that (To me, that's only if you are executing well!). This generalises to a lot of other pursuits.
Prioritisation is about deciding what not to do. Forget the BS story about putting rocks and sand in a jar, where the secret is to put the big rocks in first so that everything fits. That's not how you need to do prioritisation, because order does not appreciable change the amount of time something takes. The secret is to put only the big rocks in. Period. You go 6 times faster because you have 6 things you could do, but you only do one of them.
Now the real kicker is that the only way to determine which one thing to do is to do analysis on all 6. An HN post is not really a reasonable way to describe this. However, consider a requirements discovery to be like a tree. Requirements are discovered at a particular rate, as you work on something. Discovery of one requirement leads to discovery of new requirements. It's a feedback loop. Pruning the tree as early as you can leads to significant gains later on. So while you can't actually get the 6x development time by avoiding 5/6ths of the requirements, you can pretty easily get 2-3x gains.
BTW, for anyone interested in a more rigorous approach, consider taking something like Littlewood's model of defect discovery and assuming that requirements discovery has a similar curve. Littlewood's model is very naive, but I've found that it still has a lot of value. Again, sorry for cryptic hints here, but I don't have time to write a book on it (which it would certainly take...)
The parent comment on focus and this comment on extreme prioritization are so helpful.
Recently we are focused on just one objective and key result - it took years to get that far - we used to have so many. But even now with just one objective we still picked 25 initiatives to attempt to reach our goal. In retrospect it was an obvious fail because we only executed on a few well. We did some initial analysis but considering your comment I think we could have done much more analysis and cut much deeper and picked just a few or even just one. This is radical thinking!
Thank you for getting deeper into this. Do you have any other hints on where I could learn more about the approach you are describing?
> Don't invite someone and when they arrive tell them they are not welcome to speak. Post a list of speakers before, get your feedback and live with your decisions.
The speaker was notified in April 25. The conference will happen in mid-June. She was given fair warning.
> It does not really seem that he tried to talk to the person whose talk was cancelled (and who had probably already bought plane tickets, etc).
You missed that as well. He and another person of his group reached out to her beforehand. Here's the part in the article that says so:
> Therefore, on April 25, 2019, I, along with an employee of my company, communicated to her our decision in a meeting held in a place of her choice. She took it badly.
The conference will happen next June.
--
> Whatever, it is a bit absurd to have an opinion on this question without information from both sides.
The people who were denied were the ones who came forward and they never addressed nothing of the sort. They only engaged in doxxing, harassment of other speakers and false accusations.
This is not a proportional response.
All that happened in public. If you need info, just ask instead of assuming.
I watched this unfold on Twitter, and you're misrepresenting the situation.
The people removed from the conference have a history of disruption and harassment in the community. They were removed because of previous behavior that the organizer was not aware beforehand. He relied on the testimony of people he trust.
--
> Being able to deal with people that make you very uncomfortable without creating a fuss is a fundamental requirement of adulthood
The only people who engaged in "creating a fuss" were the speaker and a third-party related to her. They decided to come forward and "out" themselves. Up to that point, everything had been handled in private. There was no need to involve other people such as the organizer's girlfriend or other speakers.
--
> It is exactly the same behavior.
The organizer denied a speaking position and did so in private, without incurring any shame or denying participation in general.
The speaker and a third party started a campaign of doxxing, harassment and, as other commented put it: "public shaming using false allegations of stalking and harassment".
There's a world of difference between those two behaviors.
I think you're misusing the term "monorepo", no? Monorepo is just a technique for organizing source control repositories. It's possible to have microservices AND monorepos.
You're probably thinking of "monolith".
https://en.wikipedia.org/wiki/Monorepo