America is a very big place, and homeownership looks very different depending on the type of home. Maintaining an old, free-standing house with well water in a rural area is a completely different experience from living in a newly built condo. People take on different responsibilities when they become homeowners, and their knowledge varies accordingly.
Idk why. We should be able to have a civilized, intellectually curious discussion about this. The future of Reddit (and its implications for the future of the Internet) is pretty on-topic to me for HN.
Not a fan of rage bait as much as the next person, but these are real quotes from Huffman from a major publication, hardly taken out of context. This is a major story. Why suppress it?
Somebody has got to help Steve get a grip. He's doing serious damage to Reddit and his own credibility. I can totally understand his disdain for people who he perceives are trying to ruin "his baby." But he's got to be smarter than this as a CEO. This is a matter of public opinion, and his defiance is just imprudent.
Hmmm... I'm surprised I'm not seeing anyone else question the validity of this taking "2 hours" Given that it's written on the blog for the product it's using, this reads to me a lot like a pure sales pitch. They want us to believe if you use Patterns (which is neat), your company will be much more cost-effective.
I'm not saying that's bad - that's probably the right thing to do with their company blog, and it's cool nonetheless. But I do get a little tired of people putting stuff out there like this that warps (some peoples) perception around how long things actually take. We wonder why, as an industry, we misjudge timelines on things left and right.
Even if we take it at face value, this is a person who's intimately familiar with this product. So sure, it's easy to set things up when we've done it a bunch of times. If you were doing this, solving the novel problem that you're faced with, is that how long it would take? Plus that's not really what most of us get paid to do. We have to learn on the fly and figure stuff out as it comes.
So rather than have the provocative headline and conclusion, like a lot of other people have commented... this is really something that could amplify that $50/hour employee, not take their job away. And maybe we shouldn't read into the alleged speed so much. YMMV.
I'm someone who tends to get along and work well with others. That part definitely has its advantages for employability (and life in general), and is recommended. However, taking it to this extreme is just dangerous advice. Constantly being a people pleaser can carry enormous risks, especially (but not limited to) to yourself. It's important to learn to be ok with people disliking you sometimes.
I imagine they’re saying that since the team is overall twice as productive, you could say this manager who got them there made each individual 2x productive. And if you add all those together you have > 10x impact.
Napkin pseudo math for sure.. but when has that even stopped us from categorizing engineers with these labels.
I have the exact same line of reasoning.. and unfortunately I think it’s often near impossible to know how laws may be abused (sometimes it’s completely predictable).
I think people have already touched on it potentially pushing certain companies out of PA.. which in theory reduces competition which is bad for consumers. So that’s one example of how this legislation that’s designed to protect consumers could end up hurting them from another angle.
Another thing I’d wonder about is: if laws like this were to catch on.. does it start to disincentivize subscription-based business models? We’ve seen such a shift towards subscriptions.. but would that potentially change dramatically?
First of all - thank you for all the hard work! My team and I are really impressed with what you've built so far.
The company I work for has recently started to adopt RTK and RTKQ. We're working in a legacy React/Redux codebase, and have been evaluating them as core libraries moving forward as we build one of our new features.
One of our other engineers has been leading the charge with learning/applying RTK/RTKQ.. so he has a better feel for it at this point, but I've been following along fairly closely in PRs.. and as the technical lead on our team, I'm responsible for deciding whether or not it's a good fit for us.
As of just a week or so ago, we've pretty much decided to go all in on it.. despite my initial reservations mostly due to worrying that it's just the latest "new kid on the block"
The RTK part I bought into pretty quickly. Having seen a bunch of flavors of Redux code, I especially love the way RTK allows you to write reducers that mutate state directly.. and just really abstracts away a lot of the complexity, providing a means to writing idiomatic Redux code! On the flip side, I am a little worried about how much it hides what Redux really does, as someone who took a while to really understand it myself. It's started to get into Rails territory from a magic standpoint ;)
RTKQ was a bigger leap for me.. my initial impression was that the API seemed a little clunky.. especially the query "builders" part. While I like the way it allows you to inject different API endpoints where they're used, I do fear it will result in some very tight coupling between it and the requests to services. Having said that, the API has grown on me since I first saw it. So maybe it's just a matter of familiarity.
Anyways, there's certainly more feedback I have! And I'd also be the first to admit I'm not totally fluent in all these libraries and concepts.. so not even sure I'm qualified to speak to these things or if this is what you're looking for. But feel free to reach out to me at [email protected]. Would love some feedback in ensuring our team is really using these libraries effectively.
> Passionate people are generally good when their skills and wants align with the company, but if they're not well-aligned then the passion just amplifies every conflict.
I'm starting to see where my original comment was definitely oversimplifying the depths of this topic.
People that show that they want to be there often make for excellent teammates, because they actually care (the old missionaries vs mercenaries idea), and will often be willing to put in the effort to fill whatever gaps they lack, while creating a positive work environment.
Plus, they might have a really good feel for the product and market, because they're genuinely interested in it. You want people like that on your team.
Now, of course - businesses are not a charity that only employ people because they want to be there. There is a minimum bar of skills required and plenty of other traits that matter. And on the employer side, there's a ton of factors there too (budget, existing skills of the team, etc etc).
So yes, I was generalizing. But in general: I'd take someone who wants to be there with high aptitude who has things to learn over someone who has skills but doesn't actually give a crap about the product or company any day of the week, for the types of companies I'm trying to build. That doesn't mean my or your companies needs/goals are the same.
Way to be! It's silly how often employers overlook the "I just really want to be part of/build this" factor. People with that make for excellent teammates.
Wow, I really appreciate you taking the time to thoughtfully answer these. Thank you!
There's no particular mantra I had in mind. Some examples would be to "do things that don't scale" or "fail fast" or to not focus on what your competitors are doing.
I understand there's no one-size-fits-all of course.. and I suppose that's the reason I'm asking. I'm curious what in your experience has turned out maybe counterintuitive or where you went against the grain. And what standard wisdom you may look back on and say: "Wow if we had done what everyone had advised us to do.. I don't think we would've ever gotten here."
Thank you and congrats again! Best wishes to you and Amplitude moving forward.
Kudos to the author for gathering some data and sharing their conclusions. I encourage you all to take a look at the survey responses though. I know Scrum and Agile bashing is fun and all, but we're drawing some pretty big conclusions from just over 100 responses. And while the focus of this seems to be pitting "big tech" against others.. with the assumption that we're talking about FAANG.. there are 16 responses from public tech companies (if I'm understanding this spreadsheet correctly).
I share some of the author's viewpoints and am similarly disheartened by some of the decisions Apple has made over the last several years.
That said, there's a trope displayed in this post that's getting especially old to me on HN, and that's the: "POs/PMs ruin everything (or are useless), and all they care about is getting a raise or promotion.. not the technology (or the users, or the product)."
I find the tribalism baked into this oft-repeated viewpoint super annoying. And I believe the author, and others parroting these ideas.. are projecting a viewpoint all over the place without much substance.
And I think it's actually harmful to organizations and teams working effectively together. So maybe we should look a little deeper and leave the engineers-are-better-than-everyone-else bigotry out of it.