chpmrc

I don't mean to generalize but every time I had to deal with a DevOps team shipping velocity was much slower compared to when I was able to handle infrastructure myself through a vendor like Heroku, Vercel or even plain AWS.

I find myself agreeing with the part about "scaling", meaning a (good) DevOps team makes it easier to integrate new projects into an existing infrastructure that's built in house. The point where relying on the vendors above becomes more expensive than having a full time DevOps team only happens once you react a certain scale.

This is not a great take. I have plenty of things to do outside of work and I will still do what's "right" in my mind, especially if there's enough evidence that it will make my and other people's life easier in the long run.

There are plenty of people like that in a company but they normally don't cluster together, so it feels like "nobody else cares". That's false. At times that's how exactly how products, or even entire companies, are saved. Because a bunch of individuals who think like that get together and work hard to accomplish something.

Whether that effort is recognized or not depends on the company. If it's not then, I agree, it would be irrational to keep pushing. But you can't know until you try.

(Edit: to be clear, I'm not advocating prioritizing work over anything else, that really depends on you, but there's a fine line between "working hard" and being obsessed. The latter will more often than not result in a net negative in most cases. The same level of effort and/or prioritization should be applied to all areas of life)

I don't think it's too far fetched to hypothesize that the next major global conflict will be between accelerators (e/acc) and decelerators. I see a parallel with political/economic ideologies like capitalism and communism. One of them will eventually prevail (for most of the world) but it won't be clear which until it happens. Scary but also exciting times ahead!

I've been following you (among other indie hackers) for a couple of years. I respect and admire the heck out of what you're doing. But I have a huge problem with the fact that you keep referring to the income brought in by ShipFa.st (again, heck of a product!) as "51K/m" (as of today this is what your X's bio shows), when pricing is obviously not recurring.

What would be a lot more indicative of the financial success of the project (and less misleading) would be something like "trailing 3 months". But I get it: telling the world you're making $X/mo is a blast. And it definitely helps with exposure! But IMO it gives off guru vibes, especially when paired with the fact that you seem to be veering towards paid educational content (nothing bad with that obviously).

I wouldn't even bother writing this if it wasn't for the fact that you literally open with the line "my income jumped from $1,500 in January, to $65,000 in November", of which $50k is definitely not recurring.

(Again, not a hater, quite the opposite so I hope you take this as constructive feedback!)

I don't claim that Python is the perfect language and it will never be replaced, in popularity, by something that is better.

What I'm saying is that considering Python a bad language, just because there are some languages that improve on some of its shortcomings, is just wrong.

As of today, Python is the most popular, hence (as a corollary) the best choice for most people. One day that might change, sure. These aren't mutually exclusive.

I don't agree with the claim about the market not being "rational". Someone who adopts Python even when given requirements that are clearly beyond the language's capabilities isn't going to last long in such market (and neither will their choices).

On the other hand there are plenty of people (myself included) who prefer using Python whenever possible, even though they have been "educated" in the use of other languages (I'd say I'm fairly comfortable with Typescript or even C building non trivial systems). I guess I'm not innovative enough :)

Yes and that would be a correct claim. Unless one assumes that a language is objectively "good" or "bad", in which case, rationally speaking, we would only be using "good" languages, which is clearly not the case. Ironically the same happens with natural language. In theory we should all be using Esperanto by now, in practice English as the de facto international language is totally fine.

The main difference with JS is that we don't know whether it would be so commonly used if it wasn't for browsers. Still, it seems that the majority of efforts are towards augmenting JS' capabilities rather than finding ways to use alternative languages on the web (yes, I'm aware of WASM and maybe in the long run this statement will be proven false).

I could address each of these "issues" but I'd rather focus on the following:

> The language itself is extremely poor

> I think this is not something most Python users are aware of

These two statements are contradictory. If it was indeed so "poor", people would notice :) If they instead increasingly adopt it (out of appreciation, not because they are lobbied into doing it) it becomes really difficult to logically demonstrate that it's a poor choice. Software development is a very efficient market. Everyone is (or can be) aware of (almost) everything. So if most people (including experienced devs) gravitate towards a certain technology, the only acceptable explanation is that the technology, as a whole, is good.

Deconstructing and pointing out the flaws of the individual components is a common flawed thought process IMHO. Python is great despite all the issues you point out. To me this is equivalent to comparing individual components when shopping for a product, missing the fact that it's the ensemble of all those (flawed) components that make the product (or the language, in this case) work. The easy syntax, the packages, the community, those are all things that make "weird scoping rules" pretty much irrelevant.

I've built Django projects for years and wondered the same thing whenever I had to build something in Javascript land. There are some scaffolding tools that do pretty much what those frameworks do (e.g. create.t3.gg, which I've used recently for a couple of small projects and really liked) but obviously lack that feeling of cohesion that strong opinionated frameworks like Rails or Django come with.

Not sure if that's a plus or a minus, after all there might be devs whose preferred stacks differ by 1 or 2 items (e.g. prisma over drizzle, nextauth over something else) and they'd both benefit from having a standardized template to start with.

EDIT: just remembered I fell in love with Meteor for a while. Then they started shoving React and other external stuff into it to gain more market share and it inevitably lost that opinionanted nature that, IMO, made it so good. Choice isn't always a good thing for the end user (even, and sometimes especially, when that end user is a professional who just wants to get things done).

I think so too. Thankfully most of them enable face/touch ID login so logging in is pretty seamless.

Is there a list of "security advice that doesn't really make sense but we keep following just because"? This is a great one, another good one is regularly changing passwords. What else?

This story perfectly aligns with the arguments in this article. I'll add it as a note if you don't mind.

I completely agree. "Smart" isn't used sarcastically here. It's an adjective that most young devs would (rightfully) like to be referred to as. But I see experienced devs as less interested in looking/being "smart" (or clever or whatever word you want to use) and just getting things done in a way that allows the org to make money and get rid of BS (unrelated to the above) as much as possible.

Maybe there's a better way to outline this difference.

For the sake of transparency it was explained to me that the title was too "link baity" and that the comment section was a bit too heated. I appreciate the explanation and I agree this kind of moderation is, unfortunately, required to keep things civil and constructive.

I can't see how making that statement undermines the rest of the argument. It would help if you could clarify that relationship.

And I'm not sure I understand why, if you can't distinguish them, the distinction is unimportant. It's hard to distinguish an edible mushroom from a poisonous one and yet making that distinction makes a huge difference.

Interviews are definitely a limited tool to do so btw, this is only something that you realize over time. It's also very easy to play an interviewer if the interviewee's soft skills are better than the interviewer's (which happens often in this industry).

Welp! For some reason someone at HN decided to change the title and bump this down to the 11th position (atm). Not sure what I did wrong here but it feels pretty crappy...

@dang any chance you could help here? :(