> It has always been overpriced and had huge margins.
This is the engineer’s take on things. I am entirely sympathetic to it.
I also think it missed a lot of what management values in consulting. At its best, you can offload a lot of things unrelated to your business to people who are experts. At its worst, you’ve offloaded the blame to a group of over-worked twenty-something’s with impressive degrees who have no idea what they’re doing, but who sound really fucking confident about it.
Can an internal team do it better? Probably. Will they be cheaper? Probably. Will they assuage management’s anxieties and deflect some/all of the blame? Nope, not at all.
I did some software consulting years ago. Were we overpriced? Probably. But I also saw why we were brought in:
- A TDD loop where the Indian QA team played the role of the tests. The engineers would yeet some broken code at the end of the day, the poor QA testers would click through all the broken interfaces, and then the engineers would fix it the next day.
- A release process that was so slow and hellish that everyone just went to the DBA to have him add a stored procedure to implement their feature. He could get it in for you the next day.
- A frontend framework discussed in hushed tones, being built by a mysterious monk-like engineer, which was going to be the client's big secret weapon. In reality it was a terrible version of React built on top of jQuery.
- A core in-group of backend devs (most of these guys had advanced degrees for some reason), who would stay late every Friday, going through heroics to do a release of the client's email-templating app. There would be then be lots of back-slapping and congratulations the next Monday for these geniuses who were keeping the business afloat.
- "when in doubt, set timeout". They didn't know about callbacks
Usually consultants are brought in when upper management can tell that there is something very wrong and they can't fix it within the chain of command of their full-time staff.
Ah yes, the old trope of "consultants are only there to take the blame". Sure.
Having done a stint in consulting, most internal software teams are useless, that's why these companies hire outsiders. They are sick of having to deal with stubborn teams who think they know everything, and refuse to change. You can see that mentality in these threads.
Claiming “50-100 years” is a misleading and hand-waving way of saying “futuristic.”
It tries to get you to imagine that advances in the last 50-100 years will project linearly into advances in the next 50-100 years.
This is not generally the way that science and medicine work. Even if you add in gobs of questionable data collected by companies with a bad track record of doing right by it.
They’re essentially trying to get you to believe that AI + your data will give you the kind of step change in medicine that we got from penicillin and X-rays/MRI/CT imaging. It’s a cheap rhetorical trick.
Eh, I bet an intern with AI could build some internal tooling stuff for the non-profit that they use for years. Same as they’ve been using, unedited, that one Excel sheet someone wrote in 1995.
I love that we’re already talking about “proven experience” for a technology that’s essentially 15 months old, arguably only broke into the mainstream 3-6 months ago, has an unclear RoI for many companies, and seems to be changing quickly in both cost and “best practices.”
You’re more or less admitting that you’re playing trendy tech lottery. Which is fine, but maybe not generalizable to the whole industry.
15 months, 15 months ago, is not the same 15 months now. You'd be ignorant to think this a trend that will just fade. If we look at that has happened the last 15 months, it'll keep getting bigger and better. Hopefully not more expensive though.
I don't know about that, and I am 100% biased so take what I say with a grain of salt. My position is very much this: you may not trust coding agents to make code changes, but if you're not willing
to treat them as a research aid or have them work for you, you're pretty much saying they can't help you work more efficiently.
It's a fork of BurntSushi/ripgrep. What I hope to show with it is that you don't have to use coding agents to code. They can be used to surface knowledge that's buried in documents, issue comments,
PR discussions, and other places.
Believing coding agents are trendy would be like saying search was trendy in 1998. They're not going to change the world the way Anthropic wants us to believe, but they will shape how humans develop software. And I think for the better, since AI is capable of processing information at scale to help you move forward.
Regardless of how you think about LLMs (I do find them useful), there’s something really odd to think that you can select for “proven experience” in a young technology where current experience appears to have little to do with experience 15 months ago, and where the biggest boosters fully claim it will have nothing to do with experience in 15 months.
What you’re selecting for is enthusiasm, knowing the current shibboleths of the in-group, and possibly for who knows how to use them to make a good demo.
And, fair enough, if that's what you want. But it's not "proven experience" in my mind.
> For any practical application, you are only interested in finite set of concrete identities
I do a lot of numerical work in settings where computational efficiency is useful.
In my work, most cases you can do numerically using integration or Monte Carlo sampling or whatever.
It’s slow. It often pays to find a closed-form solution. Even if it’s just a starting point that needs refinement.
To put in terms of the Pythagorean theorem: Proving the Pythagorean theorem gives you a relationship that’s reliable, fast to evaluate, and general. Proving individual tuples gives you none of this.
That doesn’t even touch on how theorems give us a glimpse at deeper structure and truths. Proving a bunch of right-triangle tuples will probably never lead you to the rest of the identities in trig.
Tcl 8 introduced dual-ported objects. Everything can exist as a typed object that is convertible back to a string in certain cases (some form of string operation typically). That plus the bytecode engine makes it work completely different than prior releases.
No. Tcl is all strings from a language point of view. To your Tcl code, everything is a string.
Internally in the main Tcl implementation, it isn't just strings. It's a bit cleverer so it can be faster. But that is completely invisible to the Tcl programmer.
JavaScript is not just strings. It has real types (even if it is happy to coerce them to strings at the drop of a hat).
To put it another way, JavaScript has `typeof` which returns the type of an object. Tcl doesn't have that because the answer would always be "string".
> ::tcl::unsupported is a namespace that contains bits and pieces of Tcl that are experimental, not intended for production code, perhaps useful for debugging and introspecting Tcl, and liable to change or removal without warning.
It’s also OK to be turned off by AI use in hobby projects and it is also OK to prefer disclosure of the use of AI in projects so I can make that choice.
Ideally contractors that benefit you personally (eg: your buddy who now owes you one), but definitely contractors that let you outsource the responsibility.
Even better if you get some management consultant to suggest the idea and/or do the subcontracting.
Definitely buys you a few quarters of bonus and some time to land your next gig.
This is the engineer’s take on things. I am entirely sympathetic to it.
I also think it missed a lot of what management values in consulting. At its best, you can offload a lot of things unrelated to your business to people who are experts. At its worst, you’ve offloaded the blame to a group of over-worked twenty-something’s with impressive degrees who have no idea what they’re doing, but who sound really fucking confident about it.
Can an internal team do it better? Probably. Will they be cheaper? Probably. Will they assuage management’s anxieties and deflect some/all of the blame? Nope, not at all.
reply