Your maze demo gave me the idea to try out the "speculative fan-out" pattern [1]. It seemed interesting to try solving mazes in one-shot. Unfortunately it seems like Jev can't reliably solve basic mazes even with a step count of 1! [2] I was very surprised. Could you point me in the direction of your maze solving code so I can see if it's a skill issue? The only other explanation I can come up with is that Jev was not trained on spatial reasoning tasks at all, and on the other hand DiffusionGemma has a vision tower and significantly more spatial data in its training set.
There's a Joel On Software post [1] in the same vein as this, which totally changed the way I think about writing software. You should aim to write software which can be verified locally with the smallest window of context. It's informed a lot of my decisions around linters, static analyzers, assertions, etc. I'm always looking for assertions that narrow state and reduce the number of lines you need to read to verify the correctness.
Rust has definitely caught my eyes a few times here, since most of what I described is manual. Particularly in the embedded space RTIC [2] has some really neat stuff going on. Other languages have good type systems and spatial memory safety, but nothing else seems to have Rust's killer features around concurrency.
> Isolated QA should not exist because anything a QA engineer can do manually can be automated.
I almost entirely agree. You'd certainly want a majority of QA responsibilities to fall to devs since that keeps the feedback loop tight. Also with the amount of compute we have you can trivially outpace a typical QA team with a single dev working on fuzz tests and property based tests. If you really still feel the need to outsource then there are cool tools like Antithesis [1] which let you trade money for compute in their complicated fuzz testing suite.
Where that falls apart imo is when your software interacts with hardware in any non-trivial way. Fuzz testing doesn't really work when your system is spinning big and heavy things for example. Real hardware that interacts with the world will always create this gap where the devs don't know how to fully test it. Your systems engineers are best equipped to handle this and ensure certain controls follow the right curves, but they typically don't have the bandwidth or are very inexperienced with software. I think a QA organization _can_ fill this gap and deliver value. But I'd almost always prefer hiring another 1 or 2 system engineers who can work towards this problem full time instead. It's much easier to train someone in software than it is to train them in motor control or sealed systems.
But they're not willing. And they'll often just cause more damage/loss than they provide in benefit to the company. Even the most benign drug which people claim is fine is one that makes you lazy and slow. Why would you employ someone so addicted to it that they can't abstain for a few weeks?
"Piss tests" filter out a lot of anti-social behavior.
>And they'll often just cause more damage/loss than they provide in benefit to the company.
That's for the company to decide.
>Even the most benign drug which people claim is fine is one that makes you lazy and slow.
If you need someone hyper to do it, then hire the meth freaks.
>Why would you employ someone so addicted to
You seem to have misread my comment. I haven't deleted it, go back and check. I didn't say "companies should be forced to hire them". I promise that's not what you saw. But no need to take my word for it, move your eyes upward about 2 inches and check it out.
>"Piss tests" filter out a lot of anti-social behavior.
No, it literally causes people to steal copper wiring and pipes, turning salvageable houses into wrecks, causing millions in property damage, and in some cases causing deaths. Piss tests let them decide to not hire people who were borderline enough that the only way they could tell they were using drugs was to use piss tests. And I don't know how you can't see this, you're being irrational.
I think it mostly comes down to the standard library guiding you down this path explicitly. The C stdlib is quite outdated and is full of bad design that affects both performance and ergonomics. It certainly doesn't guide you down the path of smart design.
Zig _the language_ barely does any of the heavy lifting on this front. The allocator and io stories are both just stdlib interfaces. Really the language just exists to facilitate the great toolchain and stdlib. From my experience the stdlib seems to make all the right choices, and the only time it doesn't is when the API was quickly created to get things working, but hasn't been revisited since.
A great case study of the stdlib being almost perfect is SinglyLinkedList [1]. Many other languages implement it as a container, but Zig has opted to implement it as an intrusively embedded element. This might confuse a beginner who would expect SinglyLinkedList(T) instead, but it has implications surrounding allocation and it turns out that embedding it gives you a more powerful API. And of course all operations are defined with performance in mind. prepend is given to you since it's cheap, but if you want postpend you have to implement it yourself (it's a one liner, but clearly more expensive to the reader).
Little decisions add up to make the language feel great to use and genuinely impressive for learning new things.
Antithesis talks about some very particular use cases, but they're not the first to explore this. SQLite has something similar in the form of their `testcase` macro. [1]
What's most shocking about their whole website is how it goes to show how unserious the software industry is at large with regards to testing. It's not surprising when a good chunk of the programmers I know are vehemently opposed to "adding too many assertions", let alone something like this.
I think what the article gets at, but doesn't quite deliver on, is similar to this great take from Casey Muratori [1] about how programming with a learning-based mindset means that AI is inherently not useful to you.
I personally find AI code gen most useful for one-off throwaway code where I have zero intent to learn. I imagine this means that the opposite end of the spectrum where learning is maximized is one where the AI doesn't generate any code for me.
I'm sure there are some people for which the "AI-Driven Engineering" approach would be beneficial, but at least for me I find that replacing those AI coding blocks with just writing the code myself is much more enjoyable, and thus more sustainable to actually delivering something at the end.
I think it boils down to personal preference where some people want to use AI while others don't. I also learn when coding with my AI agent. I learn about using the tool more effectively. As someone who has been coding for 10 years, I find more pleasure in AI assisted coding.
But aside from taste, the product and the business don't care about what I like. It's about shipping quality updates more quickly. And while there might be some tension in saying this, I'm convinced that I can do that much more quickly in AI assisted coding.
"learning is maximized is one where the AI doesn't generate any code for me"
Obviously you have to work to learn, but to me this is a bit like saying learning is maximized when you never talk to anyone or ask for help — too strong.
I don't think it was that strong of an over-generalization. AI doesn't seem to help out in the same way a human would. My teammates will push back and ask for proof of effort (a PR, some typedefs, a diagram, etc.). And sometimes they'll even know how to solve my problem since they have experience with the codebase.
On the other hand you have AI which, out of the box, seems content to go along with anything and will happily write code for me. And I've never seen it have a single insight on the same level as my teammates. All of which is to say, AI doesn't really feel like something you can properly "ask" something. It's especially far away from that when it's just generating code and nothing else.
Type hints seem fantastic for when you're in maintenance mode and want to add sanity back to a system via automated tooling.
However for new projects I find that I'd much rather pick technologies that start me off with a sanity floor which is higher than Python's sanity ceiling. At this point I don't want to touch a dynamically typed language ever again.
Vibes are totally different though. People go childfree by choice, whereas men go MGTOW because there __is no other choice__ (that they find easy or preferable). I've heard it described before as "men sent their own way (MSTOW)", which is fitting since one usually identifies with the label after many unsuccessful relationships.
I work on embedded appliance software at my job. A few comments:
It's quite easy to find yourself having non-zero boot times for some unfortunate reasons. At least in my org, the software as a whole is RAM/ROM constrained rather than speed constrained. Even when you're this close to bare metal, devs tend to write over-abstracted code riddled with inefficiencies. And of course most people don't profile the application at all. This is a symptom of the software being under-tested imo. I have personally written tooling to integration test the whole application for a few appliances, and for one appliance initializing the application 56 times took over 1 second. On a modern machine it should take milliseconds. After profiling I found that 99%+ of our time was spent servicing a subscription tied to all events, that really only needed to subscribe to just one or two.
Along with that there are other reasons for long apparent boot up times:
- Waiting for other boards to connect and talk to each other. Your UI can't do anything until it knows the state from the main control.
- Randomized delays to prevent current surges after a blackout. You'll see this on ACs or other appliances that might have hundreds of identical units in a building.
- Waiting for flash memory to be readable
All of this adds up to seconds of boot time. Yet ultimately none of this matters to the business people because we're an appliance company, NOT a software company. Our software is mostly incidental to having a functioning product, and boot times could go way higher without the business being worried. Though recently yes, we have entered the data market hence the push for smart features. Word to the wise, avoid any appliance with Android in it if you don't like the idea of forced connected features!
I unfortunately don't have any solutions to most of the problems presented in the article. All I can do is continue to try writing bullet-proof software and push back against forced connected features.
I'm sorry for shitting on your job, but it seems like the solution is to bring back the buttons we had in the 80s and 90s and drop all the software garbage? I don't want a UI, I want an On button.
It's fine, I take every opportunity I can to shit on my own job lol.
Ironically what you're looking for can be found in the lowest end, and the highest end products. Low end means low features, so you can get away with just a knob and maybe a few LEDs. Look at Hotpoint (GE's low end brand) or a low end LG washer [0].
High end usually forgoes a flashy UI as well since it's about the style and being a centerpiece.
The mid end is where it's weird because features justify the extra cost. In order to make those available you need to have an LCD screen and more buttons.
In all these categories you'll run into software though. It's cheaper than a electro-mechanical solution. We only fall back to the old ways when required for safety/compliance.
[1] https://docs.typesafe.ai/patterns/fan-out [2] https://github.com/Bud-ro/jev-demos/tree/master/packages/maz...
reply