Another PMF-inspired practice in vogue is using Google Adwords to channel keyword searches to a dummy product site listing various features. The idea is to establish PMF before even beginning work on the product. A certain click-through rate establishes a clear need and a ready market to consume the product.
I've always disliked this strategy. It doesn't feel good to start off your relationship with a customer with deception.
The landing page should say: "We are building this product, but it's in the early stages. Leave us your email if you're interested to learn about its progress and availability before your competitors do. Early adopters will get discounts / free plans."
If this page gains any traction, subscriptions, interest expressed via the "Contact us" page, then the product is likely worth building past the feature list and a general idea of the architecture. You better have a prototype that will allow you to quickly demo some of your key promised features.
If you have no idea how to build that product, no plans, no realistic way to do it, then yes, a deception.
If you have a proof of concept, have put in some thinking, made UI sketches and flows, etc, you have started building the product, because you can't advance further without that. But you have to find out if it's worth putting more effort and money into it.
If the building of the product is contingent on the CTR, and the landing page does not mention that contingency but just says it’s being built, it is deception plain and simple.
Cleverly worded gotcha deception, sure. But deception none the less.
Email signups can be meaningful if the product doesn't cost the user much (e.g. ad-supported web or app), but for paid products, getting a commitment to buy something is more real. Even then, something can have a very successful Kickstarter (for example), but then the product itself is disappointing or fails in some way when it actually ships to the customers, and it never sells more than the initial batch.
> "Early adopters will get discounts / free plans."
If you include this then you're not even validating to the extent that you think you are. Because you're validating that people will sign up to use it for a discount / free, which doesn't necessarily mean anyone will pay full price for it.
The problem with this strategy is that the product that might exist is always better then what actually can exist.
People building AI-powered things are doing this a lot: add AI and clearly the product will now do <thing it's not clear you can actually deliver value on>.
There are ways to do this that are sleazy, slimey and sneaky. And there are ways to do this that are genuine. What and how you communicate to potential customers matters a lot. But this is one of the best way to develop startups.
"Of all the jobs I’ve had – creative agencies in London, content creator for a produce supplier in San Francisco, a digital marketer in Melbourne – nobody has ever breathed a word of interest in where I went to university."
If you like game progrmaming I recommend some of the low level C courses by Pikuma. I've done the 3D graphics from scratch course and will do the Playstation 1 Programming course next.
Someone gave me a pack of Indome noodles and I started making them like the soupy instant noodles I had normally eaten. Someone saw me and said "That's not how you make those" as I was about to squeeze the sauce sachets into the hot water with the noodles.
I said "I know how to make instant noodles!" and I continued making them. He replied with "Okay then".
After I had made them I realised he was right. I also thought it was cool that he just let me be wrong. In his position I would have pestered the other guy into doing in the right way.
I learnt a few lessons:
1. How to make Indome noodles
2. I'm not always right
3. It's okay to let other people be wrong.
Be that as it may - if you already have Kubernetes up and running, what would be the additional value of having both PM2 running alongside Kubernetes?
Fwiw, last time I asked myself this question my conclusion was that there was no additional value, and we opted to not use PM2. This was a long time ago however, so take it with a grain of salt.
I had a close look at RxJava and decided I wasn't smart enough to understand it. I intentionally didn't tell my colleagues about it, they would have loved it and I would have been in big trouble.
Yeah, I'm in the same boat. I'm coming fresh to the team and I haven't written any Java in anger for 8 years, and there's Rx in here. I'm sure I could sit here and study it over and over until I get it, but why? My service is running at <10 QPS. I cannot believe the runtime value is worth the SWE onboarding time.
Promises are all over the place too. I understand why someone thought this was a good idea ("I'm doing the scalable thing!"), but in the end it appears completely unnecessary (e.g. doing a blocking get call in all uses).
The problem with Java isn't Java. The problem with Java is that it lets so many people hold it wrong, and the Java ecosystem encourages it.
Yeah the problem with Java and a language like Kotlin is it has so many language features. Meaning programmers can do lots of hard to understand things.
I've been coding in C recently and really enjoy the limitations. Usually there's only one way to do something.
It depends on the kind of game you're working on, but arguably if you're working on anything ambitious then you can't do it. Yes you can scrape by doing pointless heavy updates every frame for only 100 objects in the entire game world.
The moment you want to simulate something more interesting these walls will be hit and it will directly affect your design process though (design is ongoing as the game is built!). So if you want to be a better game developer, develop in ways that you'll hit these walls less often and limit you less.
Those updates don't need to be heavy if nothing is happening.
And as I related elsewhere, with a Ruby-based game engine it took 1000+ objects being updated every frame alongside other heavy stuff (multi-voice waveform based on-the-fly sound-synthesis, in Ruby) and actually passing each of them to the renderer, before I needed to bother to add any filtering.
And then when I did need to it was a trivial change to filter the list of objects to update. To the point where I literally just currently naively every frame does a map over every object in the level and check if they're within the viewport before doing the update.
Yes, you will sooner or later hit limits, but 1) you're likely to hit them later than you think, 2) it doesn't matter because when you do hit them you're likely to have a good idea of what characteristics to filter them by. E.g. for some games you want to update, but not render, objects outside the viewport in many situations based on other measures - e.g. Minecraft-style simulation of mobs within a certain distance of the player; for other games once an object is off-screen it can cease to exist instantly. But it takes consideration, and you might as well defer that consideration until you need to, because it's orthogonal to the actual update.
