This reminds me of d2lang's sketch mode[0], which I really like. Amazing if you want to publish a diagram for comment but have it not look so official someone can steal it and promise it to a customer with your name attached. Naming no names.
> I suspect that the number of people that use and know Groovy is steadily declining
One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.
> What's more, they're a publicly traded company. That means their primary product is no longer what they sell. Their primary product is stock dividends. That is their primary business now. Whether you're buying a service or a product from Google, you're no longer their true customer.
It's not hero worship to think he knew what a customer was. It's pretty basic, and given he won the 1976 Nobel Memorial Prize in Economic Sciences, he probably knew more than the basics.
It can be the case that people don't want to accidentally mis-state the problem, or get into a debate about the problem because they know people will chime in about nonessentials. I would recommend "Have we written down the problem we are trying to solve? I'd like to understand more." And get it written down if it isn't already.
Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.
This is likely the start to a useful approach. I suspect the crux of the challenge is that engineers who need to write code get very pedantic in their questions and picking the answers apart (because we need to be! code leaves no room for ambiguity or intuition). And you can imagine how that feels from the other side. I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate. A natural response will be to try to dictate what to build (often micromanaging) and avoid the discussion about why at all costs. Writing offers a bit of a neutralizing buffer, at least.
> I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate.
Wow, that's describing it really well. I work for a guy who basically started a company by trying to vibe code his ideas into existence (late 2023 LLMs) and realized he would need actual developers to get anywhere.
It was excruciating trying to make him answer questions to get proper domain modelling going since LLM use had made him think of software as being wished into existence in a "declarative" way.
Not to mention the heavy contrast my persistent questioning had to a background of sycophantic yes-man claudespeak.
I was really wondering what these replies were talking about until this one - when I remembered a guy I used to work for that was just like this.
I think I have been pretty lucky the last 5-6 years of my career at least, where someone asking those questions is treated as trying to drive the team to a better result, rather than a pedant.
O(1) insertion is the amortized worst-case time complexity, actually. (Amortized in the sense that the O(n) cost of copying is paid only during the n-th insertion). Average complexity is a slightly different thing.
It is not “worst-case” (as the post demonstrates, you can get worse results by using specifically crafted data that exploits hash collisions). There are algorithms that can get you O(logN) instead of O(N) even on such data.
You always still needed a specialist per-platform even if most of the code was RN or KMM[0]. But I agree - a thousand not-great mobile apps sprang from this idea.
[0] I always thought the best answer was something like KMM to do all the backend comms and local data model in a shared way, and then a bespoke UI building on what that shared code exposed.
The criticism of Cloudflare here is reasonable, I think. I really like the CF building blocks - they're neat and conceptually useful and quite unusual. I think they could have a better developer experience though (though it probably is better than when I last tried it), and I also think they could have a little more confidence in their overall platform's usefulness and open up more of their model as open source. For example, I'd love to run my CF workers in CI locally without creating infrastructure (again, this may have changed since I last tried it).
What I always liked about mobile app development, or Docker-based development is that it increases the value of the garage programmer - they can now produce a complete shrink-wrapped piece of working software ready to go.
[0] https://d2lang.com/tour/sketch
reply