blub

Having a team implies that one was a manager or in a similar role.

These roles are nothing like a technical specialist. It doesn’t hurt to know a few things about the general technical details, but a manager or PO getting involved into technical decisions or being too deep in the code is generally an anti-pattern.

Not comparable with a sloperator. The sloperator is ultimately responsible for what their agents spit out. If something bad happens and the law comes looking, it’s their ass on the line. A sloperator will have to set up and manage some review or QA process by themselves. They will occasionally have to look at code, even if this goes against the entire raison d’être of the sloperator and maybe fix it or ask their minions to.

The “yer a manager Harry!” cope needs to be put to pasture. No company thinks that these people are an actual manager or actually managing anything. They’re still ICs.

The subject of the thread is a competition of skill with rules.

This is the second time that I had to read about your off-topic personal projects where it’s utterly irrelevant that you use AI or not. Add an off-topic tag to your messages at least.

This profession really needs to be shaken up by regulators.

Releasing something to customers which hasn’t been reviewed by any human is gross negligence.

If the market falls apart there is no solution except learning another job which isn’t (yet) doable by AI.

I also tend to believe that the market for SW developers will shrink. In Europe, the AI revolution is hitting at the same time as an economic crisis triggered by expensive energy which is in turn making companies cut costs / local positions and outsource to cheap locations.

The idea that more SW will be built is likely correct, but it might not be a well-paying job or be done in Europe at all.

“It's much simpler to update a webpage than force every user to update their app when something needs to change”

That much is true, but I consider this misfeature a clear disadvantage for the customers using the app, which are at the mercy of the developer. The days of updates being something positive are long gone. Nowadays they’re a mix of UI redesigns requiring relearning stuff, spyware, unwanted bloat, bugs and a couple of actually useful things thrown in.

“ being more distrusting of browser-based apps than native binaries, especially with an undue focus on the risk of the app exfiltrating your data over the network”

Not a logical error. A notarized or app store app can be blocked from accessing the network so there is no data exfiltration happening. The malware risk is negligible thanks to Apple’s vetting.

Too many comments about AI read like inadvertent admissions of incompetence or dysfunctional projects.

Couple of WTFs that come to mind:

* How many bugs did one have per commit, that commits have to noticeably grow in order to not have those bugs in the first place?

* How does one even do software engineering if the (best) developers can’t reason about the code?

The whole point of having teachers is to give intellectually developing and still vulnerable children the best possible support they could have from a human which is ideally interested in their well-being, being responsible and in doing a good job.

Replacing that with AI is the kind of SV-stupid which starts making sense after the educational system was hollowed out for profit reasons and is failing. The human in that system is just checking in and DGAF.

A little cheating here, a bit of fraud there and before one knows it, one is CEO of some AI company.

The revealing thing is how the cheating is seen as normal and how the other people are considered out of touch or wrong.

It’s fair to ask people bragging about their amazing AI skills to show their code or GTFO. Hope it becomes established.

Well, low-stakes clients are usually poor clients because they’re clueless and overly demanding.

Real designers would avoid them in the first place.

The problem’s not so much that the posters are AI generated, but that they’re too crowded and unfocused. Their individual elements seem fine and look good, but when taken as a whole they feel wrong.

This may be a failure mode similar to juniors using AI and making it much harder for seniors to find the bugs, because the code actually looks good at first sight.

I don’t think the blog author actually has any design skills based on the prompts and the AI obviously can’t nudge them in the right direction or help them clarify their brief, like a real designer (i.e. not random online freelancers) would.

These kinds of sanitized corporate, feel-good articles are anything but interesting.

A disgruntled former Azure employee posting what a clusterfuck their SW, including their Rust effort is? That’s both rare and interesting.

“Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched.”

That was most of your original comment and it remains wrong.

Now you’re talking about specific memory-safety-related features, but you’re making a big assumption. Not everything has to look like Rust. Goodness no! And C++ is still improving in that area too.

“An incremental language change would be to adopt a Rust-like iterator.” One of many possibilities.

“That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.” Obviously not. Nowadays maybe it could be easily done with AI, even if a Rust-like iterator is not necessarily something that C++ programmers would want.

Replace opt with its equivalent “choose” and it becomes choose-(tobe-)in and choose-(tobe-)out.

The set-up and your reply feel like a Rust sketch.

Not touching a codebase only applies to legacy software which is feature complete. Any actively developed software will benefit from incremental improvements.

Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golang’s also providing solid opposition.

Don’t believe everything you read. Any communication from them is a PR exercise.

On the other hand, I read an interesting substack blog from an ex-Azure employee the other day: the Russinovich-dictated Rust rewrite was allegedly vaporware for a long time and caused lots of headaches that were not widely known. A highlight for me was the use of over 1000 third party crates in their products.

Would be interesting to know how it’s going nowadays.

As any company, the one I work for also has its decent share of rustafarians. The Rust penetration is modest and slow, but the PR is remarkable.

For chests of drawers and bookcases they have one configurable wood product. All the storage solutions for the living room are tiny and almost all of them are made of unstained pine. For wardrobes they have two products, one of which is open and looks bad and the other’s tiny.

There are no wood equivalents to Pax, Platsa or Besta, the Ikea workhorses with a modern design. And even if they existed, I don’t think people would rush to buy them. Solid wood’s not what Ikea’s known for and would cost too much for their target market.

I’m not saying they’re bad - I own several of their products, and while I’m overall pleased with them, I don’t love them. The compromises and cost-cutting design choices are always there if you know what to look for. None of my Ikea furniture brings me joy or makes me want to touch it. It’s functional and looks decent to good.

Hollow panels are too light, not robust enough and essentially unrepairable. One could buy some Ikea pieces and cut them / adapt them in irder to upgrade them. These panels make that impossible.

It’s useful for DIY, but definitely not great. One has to carefully double-check everything; there’s no unit-tests to save your butt.

It can help out with understanding tools, workflows, materials, etc but doesn’t actually understands what it’s writing about and is prone to over-engineering, making critical mistakes or just replying with nonsense (for example swapping dimensions, recommending a completely inappropriate procedure, the wrong tool, etc).

This is all with Opus and Sol. Paying 22€ per month for that is a bit pricy for what one gets in return.

Names and links or they don’t exist :)

Even their absolute high-end stuff is at best particle board with veneer. And you can bet the back will still be that thin 3mm fiberboard, no matter how high-end they look.

Unfortunately, top models nowadays have more and more hollow panels. Seems to me that quality’s going down and they’re trying to save money with the materials they offer. But they can still be a good enough compromise, as I found out when looking for e.g. a TV sideboard.

In my experience, those that can’t understand design in the small (code level) don’t understand it in the large (sw or systems architecture) either.

Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management. This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D

I don’t think anybody except those working with e.g. DO-178B or ISO26262 does BDUF.

Iterative processes are state of the art. The RUP iterative lifecycle illustrates this nicely, with a big chunk of design in inception (first project phase), but also a non-trivial amount of implementation. The design & implementation flow in parallel in the next phases.

No part of your list was just a detail, but all parts of the list consist of essential properties and details. As I said, many of those details will fall into place when one starts implementing the core architecture.

It also matters a lot what scale one is operating at. Bigger scale will require more effort up front, PoCs, several big iterations, etc.

To give a smaller scale example, I defined a general simple protocol for two local components, picked the IPC and defined the handshake and teardown sequence. The developer defined the message contents. Reviewed together, then it was implemented. Testing showed that component B, which was OSS and had a fixed rate was sending too fast so the developer patched it to do debouncing.

Coding is nothing like changing tires. To abuse an incorrect analogy even more, the architect would prescribe the properties of the tire or even the behaviour of the vehicle and the developer would design and construct the tires/tracks/whatever either from existing parts or from scratch. Possibly going back and forth on the actual means of locomotion.

To wrap it up. Requirements, architecture and design can be changed. When implementing features I always do architecture review with the team and adapt it based on their feedback. We have rejected or negotiated requirements based on PoC or just developer evaluation.

Sometimes that doesn’t work, sure. If it’s a critical feature or there are hard architectural restrictions one puts in the dev work to figure it out and maybe this leads to a non-ideal implementation. Fundamental mistakes at requirements or architecture level do have higher impact, but iterating and having a good arch <-> dev feedback loop is one of the best methods I know to tackle that.

To give another example, I investigated the potential implementations for a feature and prepared a list of technical approaches sorted by specific architectural attributes. The dev team wrote the code to validate them and option 1 turned out to be impossible because of platform constraints. I adjusted the architecture to use option 2.

Getting everyone to understand the problems, working together, etc, etc are issues that are inherent to organisations.

They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :)

Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that. Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.

The software world has an abundance of mediocre coders that just happen to be good at writing e-mails, meetings, architecture (but not really), powerpoints, navigating customer requirements and product design. It’s in their interest to downplay coding skills.

While the former can certainly be challenging, it’s by far not rocket science. Any reasonably intelligent human can discuss requirements or design a product at a decent level.

Writing code at a decent level is beyond the average reasonably intelligent human. If your mind doesn’t tick a certain way, you will not be able to do it and it will be painfully obvious to anyone that can do it.

No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software.

Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc.

The idea that code is mere transcription - which I see a lot in these AI discussions - is completely false. Code is a form of low-level design and is where the rubber hits the road.

The best requirements, designs, marketing, etc are worth jack if one fucks up the code. The code is the actual product.

Rustafarians do seem to be worried by Fil-C and for good reason.

One of the top two issues with Rust is its cumbersome and overbearing syntax and anything which sidesteps that is automatically attractive to anyone which is worried about memory safety and doesn’t like to encode every little detail about in the type system. That’s the majority of programmers… think about it, that’s one of the big reasons people switched to GC languages which are the most popular languages.

The classic Rust approach to addressing criticism of the syntax was a mix of downplaying, gaslighting and “you’re holding it wrong”. But if easy to use, reasonably ergonomic alternatives become available, I expect that most would prefer them to Rust.

It’s trivial to publish these so that they’re both easily available and easy to understand. I’m guessing that’s not the case for the CDC, since you didn’t post any link or guideline.

A nice example was the EUCDC guidance on AstraZeneca’s vaccine which showed that for young age groups the vaccine was more dangerous than the disease. That allows anyone to make an informed decision for themselves instead of being bullied or emotionally blackmailed “for the greater good”.

Par for the course, I can’t access the actual study from The Lancet and have to settle for second-rate journalist summaries which are typically biased and ultimately worthless.

The Covid vaccine was not recommended in Germany and other EU countries for children. The risk of the vaccine was higher than the benefit for them.

It think the guidance was more nuanced for teens, but for kids it was very clear.

The vaxmaxxer vs. antivaxxer - like most culture wars - is a US phenomenon.