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.
Ops person(s) embedded within the Dev team dealing with/helping with/teaching about that one team's "Ops stuff" --> DevOps --> team gets faster because no Ops team hoops to jump through.
A separate DevOps team --> corporate rebrand of the separate Ops team --> no real change, or even slower because more hoops to jump through.
DevOps was always about meant to be about breaking down the separate / silo'd teams and combining them together. Ownership and responsibility is with that single team for their code from development through to production.
The corporate rebrand of Ops teams is what you're coming up against. It does my nut in and I'm sorry to that you have to deal with it.
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 come from a country where work culture has gotten to the point where no one cares. It's a self-fullfilling prophecy of delays, lies, and lower compensation.
The correct approach is to be flexible, recognise that your family is worth more than the company, but still give a shit about your work and getting it done.
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!)
It's definitely grifty. The shipfa.st copy makes it sound like you need it to build products so you too can make lots of money like he does. Except if you look at his website, the thing that makes all that money is.... shipfa.st.
It reminds me of people who sell classes using tales of their success, except all of their success comes from selling the classes in the first place.
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.
> These two statements are contradictory. If it was indeed so "poor", people would notice :)
Would they? The history of programming is full of great ideas that took a very long time to reach mainstream adoption. We also did some things that in hindsight were bad ideas, but for a time were very popular.
This is because the programming language "market" is not rational. It moves at the speed of education, not the speed of innovation. People learn a language and they make useful things with it. Why would they stray into niche languages and PL research?
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 :)
You could claim the same thing about JavaScript. It's very possibly more popular than Python, but it's definitely not better designed than Python or most of the other languages in current use.
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'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).
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?
NIST dropped the password change recommendation a while back [1] but it still lingers on. The staying power and long tail of this deprecated advice is unfortunate, to say the least.
I don't personally agree that short sessions is bad advice, but Phil Venables has an article that you might enjoy, "Ceremonial Security and Cargo Cults" [2]
My experience with security auditors from big firms is that they have a checklist including recommendations like 90-day password changes, composition rules, and so on, and will probably never get rid of those.
You may be able to explain to the assessor that "we don't force password changes because NIST no longer recommends it", and they may be sympathetic, but they are still ultimately going to deliver a report that you got dinged on two items because you answered those parts of their questionnaire "wrong".
I have had issues raised for a site having a robots.txt file. NOT that there was a sensitive URL listed in the robots.txt file, or that we were using it to try to hide stuff that wasn't locked behind authentication. Just that we had one at all.
It ends up being way easier to just get rid of it and comply, than try to explain to multiple people at different levels of management how robots.txt works and how it could be associated with vulnerabilities due to misguided usage while also having NOTHING to do with security when used properly.
Reminds me of the anti virus software at work many years ago that did not allow me to download a password encoding library, because the filename contained the word "password"
I've also experienced automatic security reports that complain that the configuration file contains the word "password" (as in "database.password="). I had to argue with them that we did not actually store passwords in Git as they could clearly see, but that it was set using a environment variable by a secrets manager when actually running in a container. Next time we had a similar use case we would just give it a different name to avoid this complication
> another good one is regularly changing passwords
I believe someone stuck forced password changes in legal banking regulations at least in the EU. In spite of all having hardware or mobile based tokens.
Needless to say, I just increment a number 10 times, because they "prevent password reuse" as well.
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...
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 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.