100%. The thing I'm currently working on has been a pain probably 80% because the work was underspecified and didn't take a bunch of legacy concerns into account and probably 20% because of nature of the code itself.
If it was better specified I'd be done already, but instead I've had to go back and forth with multiple people multiple times about what they actually wanted, and what legacy stuff is worth fixing and not, and how to coordinate some dependent changes.
Most of this work has been the oft-derided "soft skills" that I keep hearing software engineers don't need.
This is gonna rankle folks who like one or the other, but they're basically the same language. When it comes to languages that run on the same VM, Erlang and Elixir are very close together. They aren't nearly as far apart as say, Java and Clojure.
Elixir adds a few things (a lisp-style macro system, protocols, UTF-8 as the default string type, a builtin build tool, streams) but Elixir is not a huge departure from Erlang in the way that Clojure is a huge departure from Java.
By far the biggest things you're going to learn when you learn either one are going to be the BEAM runtime itself and the OTP libraries, which both Elixir and Erlang have in common.
You can (and should) always handle whatever errors you actually want to and are able handle, so if that means catching a lot of them and forwarding them to a model, that's not a problem.
The benefit comes mainly from what happens when you encounter unknown errors or errors that you can't handle or errors that would get you into an invalid state. It's normal in BEAM languages to handle the errors you want to/can handle and let the runtime deal with the other transient/unknown errors to restart the process into a known good state.
The big point really is preventing state corruption, so the types of patterns the BEAM encourages will go a long way toward preventing you from accidentally ending up in some kind of unknown zombie state with your model, like for example if your model or control plane think they are connected to each other but actually aren't. That kind of thing.
It doesn't sound strange, it actually sounds sane and what everyone should be doing.
At the same time, I can't imagine the last time I had a random exception I didn't think about in prod, but I guess that's the whole point of the BEAM, just don't think about it at all.
I might take a stab at Elixir, the concepts seem interesting and the syntax looks to be up my alley.
It's a cult. Really. This is a stock devoid of any connection to reality, fundamentals, products, anything. All that matters is that Musk is on the nameplate. Do not bet against the ability of people in a cult to remain irrational in the face of overwhelming evidence. Do not touch the cult.
With entities like BlackRock. There is always on which part of money they manage they are simple followers. Index funds simply follow indexes. They can not decide not to invest according to set out rules.
And when you get to active management, those managers might not either be that good. And it works as long as market keeps going up.
Huh? Guess you do learn something new everyday - I've been calling it that for ever too but apparently it is "engine-x" ... (thanks to you, I guess I won't sound like an idiot any more, to some ;).
I was in a group who began pronouncing the dashes in command-line options as "tack" and they said it was military lingo, but I cannot now find any connection to dash, hyphen, "minus", or Morse code "dah".
It's extremely human behavior. We all do it to some degree or another. The incentives work like this:
- If all your peers are doing it and you do it and it doesn't work, it's not your fault, because all your peers were doing it too. "Who could have known? Everyone was doing it."
- If all your peers _aren't_ doing it and you do it and it doesn't work, it's your fault alone, and your board and shareholders crucify you. "You idiot! What were you thinking? You should have just played it safe with our existing revenue streams."
And the one for what's happening with RTO, AI, etc.:
- If all your peers are doing it and you _don't do it_ and it _works_, your board crucifies you for missing a plainly obvious sea change to the upside. "You idiot! How did you miss this? Everyone else was doing it!"
Non-founder/mercenary C-suites are incentivized to be fundamentally conservative by shareholders and boards. This is not necessarily bad, but sometimes it leads to funny aggregate behavior, like we're seeing now, when a critical mass of participants and/or money passes some arbitrary threshold resulting in a social environment that makes it hard for the remaining participants to sit on the sidelines.
Imagine a CEO going to their board today and going, "we're going to sit out on potentially historic productivity gains because we think everyone else in the United States is full of shit and we know something they don't". The board responds with, "but everything I've seen on CNBC and Bloomberg says we're the only ones not doing this, you're fired".
Agreed about peer following conservatism as well re: RTO. What is interesting though is how few of these supposedly meritocratic winners fail to have any level 2 thinking.
CTO friend at what you might call a smaller tier 2/tier 3 shop told me about some recent C-suite debates. CEO/COO types concerned that "the office is too empty". One notes that "our compensation costs are very high" and "maybe if we made everyone RTO, productivity would be higher and we wouldn't need as many developers".
One could just as easily & more logically argue - you are a smaller shop that pays less than market, your flexibility re: remote is a "free" benefit you can offer to get senior talent that might not otherwise be able to attract. Enforcing the same RTO as your higher paying and larger competitors opens you up to adverse selection your best talent trading up.
Of course telling your peers that your firm is a scrub is a different challenge.
> I've never seen any tech theme pushed top down so hard in 20+ years working.
> The common theme is C-suite thinks it will save money and their competitors already figured out out, so they are FOMOing at the mouth about catching up on the savings.
I concur 100%. This is a monkey-see-monkey-do FOMO mania, and it's driven by the C-suite, not rank-and-file. I've never seen anything like it.
Other sticky "productivity movements" - or, if you're less generous like me, fads - at the level of the individual and the team, for example agile development methodologies or object oriented programming or test driven development, have generally been invented and promoted by the rank and file or by middle management. They may or may not have had some level of industry astroturfing to them (see: agile), but to me the crucial difference is that they were mostly pushed by a vanguard of practitioners who were at most one level removed from the coal face.
Now, this is not to say there aren't developers and non-developer workers out there using this stuff with great effectiveness and singing its praises. That _is_ happening. But they're not at the leading edge of it mandating company-wide adoption.
What we are seeing now is, to a first approximation, the result of herd behavior at the C-level. It should be incredibly concerning to all of us that such a small group of lemming-like people should have such an enormously outsized role in both allocating capital and running our lives.
And telling us how to do our jobs. As if they've ever compared the optimized output of clang and gcc on an example program to track down a performance regression at 2AM.
That these facets of use exist at all are indicative of immature product design.
These are leaked implementation details that the labs are forcing us to know because these are weak, early products and they’re still exploring the design space. The median user doesn’t want to and shouldn’t have to care about details like this.
Future products in this space won’t have them and future users won’t be left in the dust by not learning them today.
Python programmers aren’t left behind by not knowing malloc and free.
If all you (not you specifically, more of a royal “you” or “we”) are is a collection of skills centered around putting code into an editor and opening pull requests as fast as possible, then sure, you might be cooked.
But if your job depends on taste, design, intuition, sociability, judgement, coaching, inspiring, explaining, or empathy in the context of using technology to solve human problems, you’ll be fine. The premium for these skills is going _way_ up.
The question isn't whether businesses will have 0 human element to them, the question is does AI offer a big enough gap that technical skills are still required such that technical roles are still hired for. Someone in product can have all of those skills without a computer science degree, with no design experience, and AI will do the technical work at the level of design, implementation, and maintenance. What I am seeing with the new models isn't just writing code, it's taking fundamental problems as input and design wholistic software solutions as output - and the quality is there.
I am only seeing that if the person writing the prompts knows what a quality solution looks like at a technical level and is reviewing the output as they go. Otherwise you end up with an absolute mess that may work at least for "happy path" cases but completely breaks down as the product needs change. I've described a case of this in some detail in another comment.
> the person writing the prompts knows what a quality solution looks like at a technical level and is reviewing the output as they go
That is exactly what I recommend, and it works like a charm. The person also has to have realistic expectations for the LLM, and be willing to work with a simulacrum that never learns (as frustrating as it seems at first glance).
When your title is software engineer, good luck convincing the layoff machine about your taste, design, intuition, sociability, judgement, coaching, inspiring, explaining, or empathy in the context of using technology to solve human problems.
If it was better specified I'd be done already, but instead I've had to go back and forth with multiple people multiple times about what they actually wanted, and what legacy stuff is worth fixing and not, and how to coordinate some dependent changes.
Most of this work has been the oft-derided "soft skills" that I keep hearing software engineers don't need.