swat17

how could you justify not resolving it prior to release?

I'm not objecting to him addressing the lag, I'm objecting to him resolving it first. Until you've built something people want to play, addressing lag (and similar tertiary problems) is solving a hypothetical problem for a hypothetical player. And it may well be wasted effort, if you never nail the core product. But if you approach it from the other direction, as most game devs would, you know with a greater degree of certainty whether you should spend the time polishing. You either nail the core mechanics of the game and know that your polish work is justified in bringing the product to market, or you discover you don't have a product at all and avoid wasting your life solving imaginary problems.

Because even side projects are resource constrained. He missed a vacation with his wife. This is tragic, and happens all too often when you approach a product from a technical perspective prematurely.

It seems so obvious reading his post that he went at this backwards. The basic idea of developing and iterating on a lightweight MVP is completely absent.

I'm genuinely curious - because I see this error replicated all the time when engineers try to take a side project to market - why otherwise rational people do this. This approach is obviously doomed to failure. I understand that as programmers we enjoy solving technical problems, but that should be second to actually building something that people enjoy (if that's your stated aim). Why do developers so often seem to lack this foresight? Are we just too absorbed in our craft to see the forest for the trees, and we mis-prioritize as a result? Shouldn't there be some moment of self realization, akin to "oh fuck, I just spent the last 3 months fixing the lag on a game that doesn't actually exist?" The psychology of this error bewilders me.

His conclusion doesn't match up at all with the rest of the article.

For what it's worth, I'm a student at the University at which J Politz teaches. I haven't taken the programming languages course which is taught in Pyret, but it's worth noting that it's an upper level course here and everyone I know who's taken it is a fairly experienced programmer (relative to university CS standards, of course). So, if the fear is that Pyret is an unrealistic/overly complex/non transferable language to learn, it's definitely not marketted towards beginners here. By the time you're taking this class, you should already be well versed in Python and C++.