cstrahan
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.
Recently let Claude Code handle some commit history clean up: split a couple commits, reordered some, and identified some that could/should have been fixups, and reduced the number of commits from ~70 down to ~40. Very happy with the results and time savings.
FWIW, here’s my interactive rebase skill: https://github.com/cstrahan/claude-plugins/blob/main/skills/...
Nope. At least, not without proof. That would, IMO, be kinda crazy. We could argue semantics - maybe “stupid” would be a better word? Lacking in critical thinking skills? Whatever “it” is, it isn’t good.
Imagine old school machinists saying to a CNC machinist “Ha! See, maybe you don’t jog the axes manually, but you still have to be involved in placing the stock material, and you have to do the CAD/CAM work - so did it really machine the part for you? No!”
AI is a tool like any other. It has its limitations. It has classes of problems that it is suited to handle, and others it isn’t. If it’s true that they haven’t written (as in “typed out by hand”) a single line of code, why can’t they say that without you making that statement into more than it is?
I haven’t written a single line of code in 6 months, and that’s simply fact. It is also true that I put in a lot of other work to make that feasible, but that work isn’t in the form of writing code.
“it’s mature and the next step of engineering”
Tautologically, it’s mature enough for what it is mature enough for, and it certainly is the next step in the same way that CNC was the next step for machining — if you’re not using it as a machinist, you’re going to produce less compared to those who are.
Same thing with garden hoses. Yes, you can go fetch water from a lake and splash it on your lawn, or, you know, you could just use a sprinkler connected to your garden hose. Doesn’t replace buckets. Buckets just have a narrower scope in a world where garden hoses exist.
I’d be curious how you’d do on a hue test: https://www.xrite.com/hue-test
For me, each colored square is plainly, obviously different, and it is immediately obvious how they need to be sorted. But I also know people I’ve shown the test to who thought it was a trick - “there’s only 3 or 4 distinct colors, so how am I supposed to sort the same-colored squares?”
If one’s perception is particularly lossy, it makes sense that lower fidelity displays and audio will likely be indistinguishable from higher fidelity ones.
Nearly drove me insane, until I developed separate muscle memory between the two apps/sites.
My doc looked at me like I was crazy when I asked if it could be done without sedation, and reminded me that it would be uncomfortable, but otherwise didn't have any problem with it. I've endured 50k runs, brutal workouts, and traumatizing childhood neglect - I really can't see what the fuss is with mild discomfort that, by comparison, barely registers, and for such a short amount of time at that.
If you’re thinking of higher level libraries, involving http, html, more typical file operations, etc, what you’re saying may generally be true. But if you’re dealing with Direct Memory Access, MCU peripherals, device drivers, etc, some or all of those libraries have two options: accept unsafe in the public interface, or simply don’t exist.
(I guess there’s a third option: lie about the unsafety and mark things as safe when they fundamentally, inherently are not and cannot be safe)
See, for example:
> The next-gen LR parser framework for creating elegant and efficient language tools
> BABLR is a new kind of thing that does not quite fit into any category of things that has existed before it. In purpose it is made to be an instrument of code literacy -- a unified toolchain for software developers that supports a new generation of richly visual interfaces for coding. In form BABLR is a collection of scripts and virtual machines written in plain Javascript that run in almost any modern web browser. BABLR is also a community and an ecosystem, including a small but rapidly growing collection of ready-to-use parsers for popular languages.
Depends on what the aim of your labor is. Is it typing on a keyboard, memorizing (or looking up) whether that function was verb_noun() or noun_verb(), etc? Then, yeah, these tools will lower your value. If your aim is to get things done, and generate value, then no, I don't think these tools will lower your value.
This isn't all that different from CNC machining. A CNC machinist can generate a whole lot more value than someone manually jogging X/Y/Z axes on an old manual mill. If you absolutely love spinning handwheels, then it sucks to be you. CNC definitely didn't lower the value of my brother's labor -- there's no way he'd be able to manually machine enough of his product (https://www.trtvault.com/) to support himself and his family.
> Using these things will fry your brain's ability to think through hard solutions.
CNC hasn't made machinists forget about basic principles, like when to use conventional vs climb milling, speeds and feeds, or whatever. Same thing with AI. Same thing with induction cooktops. Same thing with any tool. Lazy, incompetent people will do lazy, incompetent things with whatever they are given. Yes, an idiot with a power tool is dangerous, as that tool magnifies and accelerates the messes they were already destined to make. But that doesn't make power tools intrinsically bad.
> Do you want your competency to be correlated 1:1 to the quality and quantity of tokens you can afford (or be loaned!!)?
We are already dependent on electricity. If the power goes out, we work around that as best as we can. If you can't run your power tool, but you absolutely need to make progress on whatever it is you're working on, then you pick up a hand tool. If you're using AI and it stops working for whatever reason, you simply continue without it.
I really dislike this anti-AI rhetoric. Not because I want to advocate for AI, but because it distracts from the real issue: if your work is crap, that's on you. Blaming a category of tool as inherently bad (with guaranteed bad results) suggests that there are tools that are inherently good (with guaranteed good results). No. That's absolutely incorrect. It is people who fall on the spectrum of mediocrity-to-greatness, and the tools merely help or hinder them. If someone uses AI and generates a bunch of slop, the focus should be on that person's ineptitude and/or poor judgement.
We'd all be a lot better off if we held each other to higher standards, rather than complaining about tools as a way to signal superiority.
So, what about outside of some set of categories? Well, generally, no such thing exists: new ideas are extremely rare.
Anyone who truly enjoys entering code character for character, refusing to use refactoring tools (e.g. rename symbol), and/or not using AI assistance should feel free to do so.
I, on the other hand, want to concern myself with the end product, which is a matter of knowing what to build and how to build it. There’s nothing about AI assistance that entails that one isn’t in the driver’s seat wrt algorithm design/choices, database schema design, using SIMD where possible, understanding and implementing protocols (whether HTTP or CMSIS-DAP for debugging microcontrollers over USB JTAG probe), etc, etc.
AI helps me write exactly what I would write without it, but in a fraction of the time. Of course, when the rare novel thing comes up, I either need to coach the LLM, or step in and write that part myself.
But, as a Staff Engineer, this is no different than what I already do with my human peers: I describe what needs doing and how it should be done, delegate that work to N other less senior people, provide coaching when something doesn’t meet my expectations, and I personally solve the problems that no one else has a chance of beginning to solve if they spent the next year or two solely focused on it.
Could I solve any one of those individual, delegated tasks faster if I did it myself? Absolutely. But could I achieve the same progress, in aggregate, as a legion of less experienced developers working in parallel? No.
LLM usage is like having an army of Juniors. If the result is crap, that’s on the user for their poor management and/or lack of good judgement in assessing the results, much like how it is my failing if a project I lead as a Staff Engineer is a flop.
{ [count] paragraphs backward. exclusive motion.
} [count] paragraphs forward. exclusive motion.