liampulles

It depends really on what you actually want to do. I tend to make a few helper funcs for different kinds of things I want to do. For example, a helper funcs to accept anonymous job funcs and collect output. Then you can compose programs out of those higher level blocks.

If you've written a few GenServers, I'm not sure one would describe it as "magic" in quite the same way. I wouldn't anyway.

I know many programmers for whom "developing domain understanding" is an abstract concept (if indeed, it is a concept for them at all). But in the age of big AI, I see more need for this, not less.

At least this is my observation: when my colleagues have been wholesale chucking stuff over to Claude, they've then been confronted with classic XY-Problem shit, poor user experiences, and over-complex solutions (which will mount future problems regardless of whether a person or an agent iterates on that code). Much of this can be solved by actually sitting down and thinking about it, and I mean at a code design level, not just a speccing level.

Many people don't realize that there are more useful outputs to solving a problem than just a mere solution. Obviously if one has a contractor mindset (you don't care about the after effects of a system) then this is of no relevance to you. Some companies promote that mindset, certainly ones that have no broader aspirations then getting acquired soon. That's fine - but many companies actually are about sustainability, and understanding in these places is paramount.

Fair.

I agree with you, generics reduced the simplicity. Still, better than many alternatives.

Also - and this is very subjective - I find developers who have similarly low view of software development and high view of simple languages, to be very good team mates. We can laugh at the realities and move on pragmatically.

I have a strong belief (mostly borne out by my years as Java dev) that the larger the possibility space of a language (and its ecosystem) the more room there is for inappropriate use and unclear code. Add time and an assortment of rolling devs of mixed ability level, and crap mounts faster then a "simpler" language.

Let me be clear: Do I think it is possible to write good, clear, performant code in Java? Of course - Java can be used to write great software. The problem is that in Java there exist an extraordinary set of variations of a sufficient implementation, many of which are package protected abstract static horrors shows. And that will manifest over time if you add different individual developers. Else the project must engage in bureaucracy and control, where you have meetings over style conventions or hardline architects who come to constrain the joy of programming in the devs.

Its much better when the language itself constrains you, then everyone can just move on. I feel Go, though certainly not perfect, meets this niche.

Java consistently introduces lots of exciting functionality into the language. That's a big part of my dislike and active avoidance of it.

Honesty does not just mean reporting facts. It also requires having an understanding of the scope of your knowledge and then endeavouring to communicate that scope effectively.

At least one of those things is missing here.

The only thing I'd need and want from my office suite for AI are for it to stay in sync with a disk file.

Then I can do stuff to the XLSX with Claude, and work on the spreadsheet in my spreadsheet editor.

What I DONT want is for my office suite to have any limiting AI features built in.

Like many "cloud native ideas" there is a core 20% to the idea of feature flags that is useful to 80% of teams, and then a remaining 80% of periphery concerns that are relevant to 20% of teams (and I'm erring generously on those figures).

Specifically, the idea of putting toggles on risky functionality is a good idea that is useful broadly. Being able to dynamically toggle feature flags without a restart, or apply some features to some segment of users is unlikely to be useful and entails a lot of complexity and potential footguns.

My approach to feature flags is even simpler than what is suggested here: feature flags are just a section in your config. Done. Even if you are confident that you need more advanced capabilities, you should not "advance" to that level until you have demonstrable proof that your team can manage simple config values for it.

So I love good old fashioned desktop-oriented websites, and the most complex thing I do on my phone is Google Maps... but I also recognize this is not true of the general population.

Almost no one else except the PC gamers I know really like using desktop (or laptop) computers. Most people love being able to sit on the couch and use apps on their phone. Its not like massive portions of the population were loving their desktops until smartphones arrived and they transitioned, no - smartphones are what helped the internet revolution really inseminate into the general population.

I don't bother, because again, the value is in me thinking.

One will lose the opportunity to develop domain understanding if they do not get into the weeds of thinking through the problem.

I use Claude plan mode to do relatively small changes and even then I find that if I actually try and think through the problem and solve it myself that I find good metaphors that will aid future work, and I will discover tangential issues which are then important to look at.

Mindset is important. If you care about the craft of programming then you can easily get into a mindset that software must be "perfect", which is almost always impossible to achieve, and so you will become continually dissatisfied. I got into this mindset when I was a junior dev, and it only served to fuel frustration for me and others.

I try to take the mindset of "continuous crap reduction". I let go of the things that are out of my control, and seek to reduce the biggest problems that are in my control. Then I can get a "win" every day, and I don't try and fight the stuff out of my control which is only a little crap. I have to try and be principled without being opinionated.

It might be a little worse, but it will definitely be way cheaper.

I think the main difference between me and Claude's work is that it doesn't find a needlessly complex solution offensive, and is happy to contribute that complex solution and to then move on and build further on it. After all, it works.

The problem comes later when the code no longer reveals the domain and the processes of the business, and where changes start affecting other expected business behaviors (at least that is what I think would happen, I find the code too distasteful to let it get that far).

Yes, that's partly a sense of qualified taste I've built through experience, but I think it also comes from trying to actually understand user needs better. E.g. Our finance department says they wants a daily report of invoices, but what do they ACTUALLY NEED? Maybe the problem to solve is to allow more flexibility with billing dates, or increase billing strike attempts, etc. That stuff sometimes doesn't come out until you really ask because of all sorts of organizational and social beliefs, fears, etc. Practicing that and recognizing the signs means you can do that rethinking earlier on in the process, before dev starts.

For me, domain discoveries and elegant solutions arise out of periods of deep befuddlement, and are often a saving grace that can avoid lots of code.

I'm lucky I guess that I've had enough time in this career to experience these moments, and enough experience to know which code I should write and which code really is rote and can be generated (most of the time). Hopefully it keeps the loss of enlightenment to a minimum.

We've pivoted pretty hard from infra being cattle, haven't we?

Wasn't Capital One founded on the premise of massive-scale market and product experimentation? Makes sense that they would design tools that match that approach.

I love the principle of this. I hate the truncated graphs.

The copy here says that your data is Local-only and that it can interface with Claude, Codex, or Gemini... are you running these models locally, or am I missing something?

Great video on the subject of applying science to business and government: https://www.youtube.com/watch?v=sf0vb4yiZR4&t=2s

Having deno desktop do the framework handling for a bunch of popular options is an interesting choice. It seems deno is trying less to be an agnostic JS runtime, and more an "integrate everything toolkit" (not unlike Spring in the Java space).

It's very similar to Optional types in Java.

At a previous job, we introduced a simple Optional generic type, with JSON implementation, and it pretty much solved uncertain nil issues. Sometimes the solution is simple and boring.

There is a core 20% to Kubernetes which is very nice, mostly being the Deployment and Service management stuff. That along with a very basic GitOps for cluster management (an infra repo for operators using Flux, applying service level yaml from app repos in CI) above a cloud managed Kubernetes cluster, where you still keep your DB and build servers off the cluster, can be quite nice for a small team.

Beyond that, there are massive holes of despair to fall down if a novice team starts to engage with extensive operators (starving the control plane), DB operators (distributed persistence) and build operators (spikey, expensive loads). At least, I know that I've had to dig out of those holes.

I just hope people don't use k8s in the same way many use microservices: as a way to introduce complexity for complexity's sake.

Most stupid animations I have seen introduced to UIs are done because they are stupidly effective at impressing business stakeholders, especially non-technical ones.

It never fails to astound me how some people will fawn over "delightful" transitions. I guess I can understand it in the sense that it is an easy thing to help communicate the perception of high quality to the broader business.

*Claude Fable is relentlessly burning your dollars

There, fixed it for you.

The original Skunkworks optimizes for a low production volume of vehicles which operate in a very extreme band of performance. And yes these projects are able to deliver within budget, but they are still very expensive machines. This is totally opposite to what is applicable to Ford, where really the innovation needs to be in the factory.

The other key lesson from the Skunkworks book, which is applicable, is that to the greatest degree possible, one should not reinvent the wheel. Reuse parts from other high production vehicles, which have proven their reliability. Focus the innovation tactically.