You aren't saving the planet by purchasing a product from Apple. They are the kings of planned obsolescence and also have release cycles and marketing to make their customers over-consume.
Marketing that seems to have worked with you. I'm wondering if you even did any research at all.
Instead of using a garbage phone from Apple, go with better alternatives that are made to last, can be fixed, is more environmental safe, can be fixed etc.
The latest version of iOS supports phones from 2019 and Apple releases security patches for phones older than that. Which Android phone from 2019 is getting updates? Which phone before that is getting security patches?
With latest OS update - Apple watch series 7 decreased battery life, Siri started acting weird (sometimes I have to keep pressing crown till I finish the command, sometimes not). It stopped showing battery percentage while charging long back.
Meanwhile I like the optimization analysis, the initial assumptions are very wrong. I know the author mentioned that they are optimizing for stats + being resistant to other Pokémon types, but that analysis will lead to very bad results.
There are Pokémon with certain abilities or tricks that makes it much better than legendary ones, with certain move sequences that could wipe the entire other team.
There are also Pokémon with certain types that are actually good against what the 'data' would say otherwise.
Maybe the analysis could be better done if you instead analyzed matches data.
BTW, the way people pay Pokémon since many years is to also divide the Pokémon into tiers and in a competitive setting, you are only allowed to pick Pokémon from the same tier or lower. This adds another level of complexity.
I generally agree with you on the point that a "good Pokémon team" can be better encapsulated by other attributes, including those you mentioned. I would disagree on assumptions being very wrong, because I am not assuming that the objective and constraints chosen are ideal or even good enough, I am choosing them simple for illustration purposes.
I actually found it interesting that in spite of what is a clearly overly simple model, the non-legendary non-multi-starter you eventually get is quite a good one, in my opinion better than what the naive constraints would lead me to think.
Also, keep in mind that I'm not talking about competitive matches here, just mainline gaming. For that end, types are usually all you need, and in that area the main thing I would do is generalize type constraints to not be just defensive but also ensure each resistant Pokémon has a good enough attack against that type.
In my opinion, abilities, nature, objects are:
1. Too complex for such models (MIPs are still exponential-time)
2. Overkill strategy when all you wanna do is beat the league
That's where I disagree as well, the non-legendary non-multi-starter is also a crappy team as Pokémon isn't a rock paper scissor game since a long time.
You'd need to take into account innate abilities, how to also understand the impact of HP/ATK/etc in each Pokémon.
Snorlax for example is quite good, as it's pretty tanky and have a good moveset that can help it set it up.
Dragonite has multiscale, stuff that doesn't show up in by just looking at Pokémon types and stats.
Again, my main point was... analysis could be much more interesting if it analyzed battle data, rather than a very shallow assumption that a combination of Pokémon types and stats can win a battle.
With that much revenue, maybe it's time to look into your ratios of payment processing method being used.
For example, if 90% use Credit card, go with a simpler and cheaper payment provider and implement a mechanism that switches between them based on some frontend configuration.
I've worked for a company that they've essentially done that.
I know you might then need to handle having two places where you have invoices etc, but for the amount you are transactioning, it might be the right way to go.
This isn't important only to reduce how much you pay, but your lock-in and dependency on them, otherwise you have no leverage on those negotiations.
It's easy to write that blogpost when you are in a position of a lot of privilege, in arguably the best software engineering company in the world, and got where you are surely for your competence, but also a high degree of luck.
Some other people has to grind harder and even be better than you to get half of your success, that doesn't mean that they are wrong, or that the book is wrong.
I believe a lot, if not all advice there in the book is necessary. Other people might not work at Google, but as I've said before, might need to grind different gears in order to be successful, if you don't -- good for you!
A lot of your suggestions would get you fired very quickly on many companies, it's good that it all works for you.
My goal with this post was not to claim this is a universal template to success for everyone but simply sharing an approach that worked for me.
I tried to point out several times that, yes there are places where a "move fast with leadership" approach works better. And yes this only works in the biggest companies capable of sustaining an infra team for a long period of time.
It is a large amount of luck, obviously. You didn't hard-work your way out of brain damage at birth. You didn't hard-work your way into your geographic location which gave you access to the resources that lead you to where you are, which are unavailable most places in the world. You didn't hard-work your way out of avoiding a draft for a war where you got killed at age 18.
Sure, if a butterfly flew past one of our parents on the day of our conception, causing them to spend a second glancing at it, then they may have had sex slightly differently that night and we wouldn't exist. We're all lottery winners in a billion different ways.
What is the practical application of bringing that to mind when considering what actions to take for career advancement?
> It’s not luck. To assume so, let alone say so, is uninformed and quite rude.
They did not say that. They said it included a high degree of luck. It's easier to get there when you grow up in a country where you have access to a computer, for instance.
> If you feel it’s only achievable with luck, I suggest you’re selling yourself short.
It most definitely is only achievable with enough luck: given the same "hard work", not everyone on Earth will get to the same point. I find it amazing how people don't understand that.
It doesn't mean that there was no hard work. Just that "I am here because nobody on Earth would deserve it more and luck has nothing to do with it" is... I don't know... narcissistic?
There are staff level jobs like that in every company. However they are hard to get into. You have to prove yourself constantly and for long enough that the executives trust they can leave you alone and you will solve problems. You here means your team, as a staff engineer you likely have a lot of more junior engineers working under you.
My brother had an internship in a medium-sized company, and after 6 months, a new product (that he was hired for basically) and 3 new internal tools (including one for reading data trace, which, after reading this, is quite a propos), he was hired as a staff engineer.
I do not have his proactivity for sure, nor I have his ease with other people, but I managed to land my job in an infra/tool for network and security without much difficulties.
US pedestrian deaths increased almost 100% the last decade or so... and the Cybertruck is the most hilarious car, a representation of bad US car standards.
With its pointy edges, even in a very slow accident hitting a pedestrian, the outcome will make any Tarantino movie look soft, in terms of blood being spilled around.
Don't even get me started on those huge American cars, they are the absolute terror in terms of pedestrian safety.
They should integrate this to ruby-core and make it even better by changing the parser and making it faster in terms of performance, as optimized as it can.
But I have a hard time believing ruby-core will want to hear community feedback... people have been talking about this for ages... Ruby is omakase?
RBS and Sorbet suck. One is very limited, the other isn't part of ruby-core and makes you rewrite the function arguments again, similar to Java's annotations... Doesn't look like Ruby at all, or DRY, mostly like a workaround!
LowType is what it should have been -- hard to believe we are in 2025 and we still don't have a decent, programmer-friendly solution in ruby-core.
Meanwhile Python has it right since a long time. No wonder it is so stagnated with people going for other stacks.
Ruby is slowly becoming what Perl did, a very niche language.
Ruby needs a Typescript. Leave ruby-core as it is. Let us write Ruby with type annotations, where the compiler does type checking, strips the annotations, and leaves us with plain runnable Ruby.
I agree with your analysis that RBS and Sorbet suck.
I disagree that this here should be part of ruby-core, largely because I don't think any of this type madness should infiltrate ruby.
Ruby does not necessarily follow "DRY" - that appears to have been coined by either DHH or the pickaxe guys. More than one way to do it, is kind of orthogonal to DRY too. Note: I do not disagree that DRY has value. What I am saying is that ruby's design does not necessarily follow DRY as a guiding principle.
> hard to believe we are in 2025 and we still don't have a decent, programmer-friendly solution in ruby-core.
I do not think the year has anything to do with it. If they suck - and types suck - then they should not be in ruby core. I understand you have another opinion, but that's the beauty - we have orthogonal opinions there. One says must be part of ruby core; the other says should not be part of ruby-core ever, no matter the year.
> Meanwhile Python has it right since a long time.
The question is: how many use it there?
> No wonder it is so stagnated with people going for other stacks.
Lack of types aren't the reason ruby declined. That is a wrong assumption here.
> Ruby is slowly becoming what Perl did, a very niche language.
That is true, but not due to lack of types. Python without types would
still be at rank #1 at TIOBE for instance. Your analysis is simply wrong
here.
I see a big amount of naiveness on his post, I tried to view it with a positive mindset, but I can't help myself and think how naive his perspective on that is.
First, lots of server-side code is IO-bound, writing it in Rust vs. Java/C# would barely show any difference in a Monitoring tool, in a real-life scenario.
His authorization system is very limited in scope, of course it can be fast! Get real users and we will see if that will still be fast.
When you are running it in production, even if using Zanzibar's approach of loading everything into memory, you'd still need to handle many aspects he didn't think of, like updates to such permissions, and dealing with sharding etc. Things are always more complex in real life.
And last not but the least, Notion is really fast as it is. I never knew it was slow.
Without bringing any new concept to "Notion", I find it hard to believe this will ever work.
I hope he finds happiness building it though, building is fun!
This is always my biggest complaint about Ruby. Last time I made a fuss about this on HN someone pointed out rbs-inline which might make it into the core rbhs gem itself soon! This would be huge for the Ruby community imo
From where I stand, Ruby has much more interesting work going on JIT land than Python.
Much of the Python stuff, is actually about rewriting Python tools into Rust due to its interpreter slowness and no one caring about PyPy, now apparently there is even a PEP to rewrite CPython!
I'm still a Ruby fan but I share your immense, nearly immeasurable disappointment on the implementation of RBS. It's as though someone was tasked to add types to Ruby but do it specifically in a way that would guarantee zero adoption.
Marketing that seems to have worked with you. I'm wondering if you even did any research at all.
Instead of using a garbage phone from Apple, go with better alternatives that are made to last, can be fixed, is more environmental safe, can be fixed etc.
reply