cstrahan
Joined 15 years ago
Joined 15 years ago
The crucial choice is not (just) the one made in a pivot: choosing any DB (or any similarly foundational stratum of your system) is always a crucial decision. Ultimately, you have two choices: put off making an informed, optimal choice, or make an informed, optimal choice now - or if not now, then as soon as you have enough data/experience to make the optimal choice for your needs.
I think you might be attributing the bulk of potential cost to the act of migrating away from an initial choice. But the cost of migrating away from something is proportional to the extent to which it is intertwined/coupled with your system, which in turn is largely a function of the scale at which you are operating. The problem, at least as I have seen it, is that organizations often pick something with minimal (if any) thought put into that initial choice, wait until scale reaches a point that switching away is matter of life and death, and then have to desperately fight against inertia. I think that's what the parent of your post is getting at.
I have seen countless "founding engineer" job ads with every little detail of the desired stack/architecture spelled out: Java/Spring/MySQL/Linux/Log4J, C#/RabbitMQ/MSSQL/SSIS/Windows, etc. Non-technical founders/recruiters/etc don't want to "leave things to chance", and will happily overly specify the constraints, mostly informed by popularity ("Nobody Gets Fired For Buying IBM"), rather than leave the solution space unconstrained for some "generalist" to choose. I mean, how do you even know someone is competent if you can't grill them on a concrete set of buzzwords?! The horrors! So of course the recruiters gotta make up constraints to find someone "qualified".
Heck, I've personally seen this pattern at every step of company growth, from 5 employees to hundreds. I've watched as my employer's recruiters would explicitly seek tons of things we weren't yet using. Why? Because when performance isn't as desired, the first thought is not "hey, maybe our approach to managing people and projects is dysfunctional", but rather "maybe we just haven't found the silver bullet yet; let's go shopping". In my experience over 20 years, that represents 99% of the cases where new crap gets introduced: Scrum, Jira, SQL Server Integration Services (SSIS), front/back end frameworks, consultants ("our developers must be idiots, so let's get outside experts"), etc.
I think it is true that there are cases where developers will push for things like particular front end frameworks, but that's almost always the exceptionally rare case where there's any resistance to push against: few companies aren't already using the stack du jour, so most developers (especially greenhorns) will have bought into that stack ('cause "gotta pay the bills"), so a new developer brought into a nonconforming engineering org will quite likely want to use the tools they know and thus push for it. The real culprits, though, are usually the non-engineers: founders/recruiters/etc who create a financial imperative to adopt whatever is trending, which results in developers who spread that popular mediocrity elsewhere.
On the other hand, I don't remember things being this bad before the acquisition.
Similar reasons: the intended audience isn’t the average person.
https://www.eginnovations.com/blog/agentless-vs-agent-based-...
https://www.reddit.com/r/sysadmin/comments/js8h65/looking_fo...
https://www.ibm.com/docs/en/aix/7.2.0?topic=tools-performanc...
https://jolokia.org/agent/jvm.html
https://www.oracle.com/technical-resources/articles/javase/j...
Why complain about the outcome? The old game remains available, and you can play it for free. This isn’t some zero sum situation where the existence of the remastered game sets the world back in some way. I could see being more interested (or only interested) in playing the original, but I don’t see what motivates the negativity.
This is the exact example I used the other day. Same with pick-and-place, CNC for subtractive manufacturing, 3D printing for additive, plastic injection molding, etc. I wouldn't want to live in a world where the only option for products produced by such automation were instead done one-off by artisans. Sure, if you want a hand crafted laptop where everything (save for the silicon, I suppose) was hand carved, hand placed, hand soldered, etc, you should, by all means, be allowed to pay $20,000-$200,000 for that privilege, instead of ~$2,000.
It's bizarre to me that so many developers are overly attached to typing every individual character. If I could get paid for my sense of knowledge and good judgement to design software while delegating 100% of the process of creating to a team of engineers, I would. And as a staff engineer, I'm already close to that, but there are things I have to roll my sleeves up and handle myself.
It's such a stifling, self-limiting belief that it's actually saddening :(.
It's also a hypocritical belief: the machine they used to type out these thoughts were assembled in a factory, using CNC, pick-and-place, laser engraving, plastic injection molding, etc. With the exception of a few things (ex: the silicon itself) all of these things could be hand crafted - it would just make the price of computer impractical. Commoditization is a good thing, and automation is necessary for that.
I can only imagine that what is actually happening is that these people are attached to the craft of software development, and AI represents a threat to that, just as CNC milling has displaced manual machinists. But then everyone would be better off if they found an appropriate place to vent that frustration (a therapist? a friend? like-minded forum dedicated to AI complaints?), rather than projecting onto (and leveling complaints at) people using AI.
1. Were produced via plastic injection molding.
2. Were machined by CNC.
3. Have PCBs that were fabricated by machine, milled by machine, and populated via pick-and-place machine.
4. Were laser engraved, or silk screened, or printed.
5. For food/foodstuffs: were processed in an automated factory.
When you use all of these things, do you complain about using/consuming something that someone "couldn't be bothered to hand craft"?
If you don't see/anticipate the utility in a thing (like I don't have any interest in wicker baskets, hand crafted or not), why complain about that thing, instead of just moving along? I'd get it if you wanted to provide constructive feedback, but you can't do that if you're not willing to read the code.
Harboring (and expressing) negative sentiment for things that you opt to not be involved in sounds like a recipe for misery, as there's an infinite number of things to actively dislike if you go looking for them: movies/music that aren't to your tastes, mediocre restaurants, cities you wouldn't want to live in, etc.
Having an inverted index (as with FTS5) is useful in that, for a basic single-term lookup, you reduce a sequential scan, O(N), down to O(log N). For small N, the performance difference might not be meaningful. Performance gap widens with more sophisticated queries (boolean operators, ranking, etc).
Unless the loop is unrolled, yes, there is a branch to exit the loop. But then that doesn’t matter because the whole goal at the beginning was to avoid branch misprediction (which is not the same thing as avoiding branches entirely).
1) It isn’t a matter of literally “pasting into a terminal” (with the terminal emulator shoveling bytes into the TUI’s stdin), rather it’s “a TUI key-binding tells TUI app to read system clipboard”. No different than any other app.
2) This works on macOS, Linux and Windows, but not WSL. Sounds fair game to call this a bug, or at the very least a feature disparity.
Software Developer in Washington, DC
[ my public key: https://keybase.io/cstrahan; my proof: https://keybase.io/cstrahan/sigs/yV0wzDolQldJ9GSMuflLE9_PIggrsCf9jzIQPUHqzKE ]