jimbomins

But it does leave me wondering how would we know if it hasn't already happened in some company?

An AI may be making an ultimately random choice (prove the CEO isn't) but it's actual options are weighted on statistical grounds from much wider sources of data than a human can knowingly handle.

I say knowingly because actually the sum total of accumulated info for just a month or two of human activity eclipses even today's LLM.

And the CEO decisions are frequently flawed because there's a strong filter of the information from below.

Perhaps a crowd sourced (employee sourced) decision making process would be best with the wisdom of crowds.

No because it would be too well informed to make biased (company focused/favouring) decisions. (Joking)

It strikes me that software has become a bit like law and accounting used to be. "We had to suffer and so must you". Making it pointlessly hard to keep people out.

Rather than dealing with people on real problems.

I'm currently getting interviews. For work that I know from having done it for twenty years that coding is only a small subset of. But the emphasis is far more on coding than application of experience gained to overcoming similar problems quicker the second, third or fourth times I'd be working them.

It's sad. I'll certainly just say no to leetcode for the kind of engineering I'm looking for. Rather go do some (paid) gardening.

I've never looked at any Rust. But this mini thread leaves me expecting the Rust world to be like Perl. The experienced Rust/Perl user uses every feature and short cut for magnificently dense expressive (alt. incomprehensible gibberish to anyone else) and doesn't comment it because the code is self evident. When actually they just want to code wank showing how clever they are and how lazy anyone else is if they haven't take the time to understand the details and thus understand.

But like I said, I've not looked at any Rust despite its marketing success.

frama-c

Indeed. My daughter did a couple of games in Scratch when she was 8 (possibly younger).

But from other comments Scratch seems to have picked up a lot of extraneous crap like social and tiktok in the intervening years (decade).

My variation of what you say is read lots, look at what people are doing, then make sure you have a big space that lets you stop thinking. Once I'm in that "hey I'm not distracted by a million things" space ideas and solutions just pop to mind as I manage to focus on one thing.

I wouldn't call it diagnosing. Just suggesting they consider it.

Personally it all sounds very familiar. So familiar I'd admit I'm mildly depressed. But I do still have a pad of good ideas that I add to.

Also very interesting is that yes even with ideas I'm not good at doing them - but the suggestion that their thing might be the enabling others to achieve theirs really sticks out for me. I'm definitely at my best helping others to do better.

All in I'd say it was a good response.

Most of my former colleagues just ignore it. Big USA company and turns out they only started mandating it because the USA offices were going in so little.

Others go in, have lunch (free canteen), then go home. Having ticked the system for enough days in. Then do their work from home because the office is such a disruptive place to get anything done.

Most managers don't care so long as the work is getting completed on time.

I'm not sure your point "3." is wholly correct.

They do also go much wider than just combinatorial math.

Probably because two years would let you produce a skinny inconsequential dip into a topic that would quickly be surpassed or barely distinguished from introductory texts on programming.

Is Charles Dickens worth it? It's a matter of time, taste and purpose (in reading).

I've enjoyed dipping in. Sometimes found it directly useful to work. But the best of his works I read (in full) was the MMIX book that is a literate program of the interpreter. Second to that was the typography book, a total fascinating delight.

In reality there's probably almost no one who reads any volume of TAOCP in full.

The only way to answer your question is probably to start reading and see if you enjoy it. But expect it take some effort.

Is Charles Dickens worth a read. Depends on your time, purpose and taste.

I've my doubts about Arm's future with the reports of intending to up the price of licensing. That strategy seems insane with the Risc-v progress and increased uptake by big tech companies.

£320 on Amazon does not seem to fall into affordable to me compared to a RPi 4

Benefit of the doubt. I try and start from the assumption it might be me that is missing something. Or just let it go.

The latter being more difficult to do these days as I boggle at the environmental decline and general reaction to ignore it and similarly the outrageous politics of the right that seem to dangerously deny truth.

They are only used in places where confusion benefits the user. It has to be deliberate so people accidentally opt in. I've assumed it's a dark pattern.

If you have an engineer the whole point of them being able to claim the title is they are educated and expert in their field. Without knowledge and expertise in a field you aren't going to get any engineering done.

Which is different to saying anyone trained to be an engineer will be able to get stuff done. But getting stuff done was always a recnognised requirement of an engineer; i.e. by definition they should be getting stuff done.

"removing impediments" - just sounds like good managers in any process. Bad managers often are an impediment.

Small groups of 1+ with a vision isn't really software engineering though. You aren't building to solve someone else's problem and it's that which is engineering. Turning up to the beach with bricks and cement on a whim with mates to create a small damn because it's your vision? Well that's kind of build it and (hope) they will come.

Or to be kinder. If you are filling your own hole (identified need) you can be more free in your approach. After all only you decide if it's right, finished, a failure or success.

To be clearer than my first post. The whole set of processes that are software engineering are fun, including dealing with people for requirements, design, analysis. But programming at the end is like writing up the final report once you have the answer.

I find the opposite. Analysis, requirements capture and design get you to the point where programming is required. But it's the least interesting part of the process.

I don't consider Agile as software engineering it's managed hackery intended to keep people sprinting until they drop.

Programming as an aspect of analysis is however fun.

You're kidding if you think the premium brands you list don't have massive dependence on software systems. The basic physics is, as you say, better because they've kept mass distribution in line with how it was.

And how about the additional failure mode for say BMW. It's modern controllers have all the software for all the features in, just disabled unless you pay more. So a theoretic sophisticated attack could throw all sorts of crap into operation.

That's not strictly fair. The problem is that the critical systems were moved to share transport on the main hub with infotainment (safe, I did modelling of the messages for Volvo way back). On that hub is wireless access. Cars have been using CANBUS way longer than that issue entering play and without physical access you wouldn't be able to hack them and with physical access you could easily tamper with brakes or other systems.

You may get your wish. Recent research has shown that real knobs and switches are much less of a driver distraction than trying to fiddle with screens or get voice commands correct. The two either mean you look away from the driving because you can't just feel your way across a screen like physical controls or you add cognitive load whilst thinking and talking.

I'm with you and hope all the idiot touch screen crap is ditched.

I've been out of automotive safety critical software (engine, brake, controllers, etc...) but still have friends in it. Proper best practice is still followed by the likes of Toyota, Jaguar and Ford as the ones I've had experience in. That means the coding standards mentioned. Full requirements->design->implementation with functional unit testing, module unit testing and system testing including using simulators. Multiple people doing reviews, strict standards enforcement. Static analysis and code test coverage aiming for 100% path coverage with testing even when I was doing it. With staff typically staying on projects for the full 5 years of development.

Ford as one I can speak about with knowledge took seriously the cost of recalls versus catching issues in testing. It's massively cheaper to spend money up front to do full process and catch every bug you can than to cover recall costs to update later not even considering liabilities if anything does go pop.

Mistakes of course happen. But they're also rarely working from scratch.

It makes working in modern ways horrific seeing the shoddy shit tossed out to meet consumer gadget deadlines.

Faking those things is a totally different state of affairs to safe operation. I've been out of automotive for 20 years but never met anyone who would compromise normal operational safety. Let's face it most people who work on cars love to drive cars. They would be putting their own and families lives at risk.

I don't think size of company is as relevant as the market sector. My employer is a 40-50k work force globally and it's bash stuff out. But similar size companies doing medical or CNC, etc, where errors kill write to best practice.

Didn't sound like there's a team. More that everyone is working in their own silo. Under those conditions do your own thing.

Similar state of affairs in my current "team". None of us really work on the same thing at the same time.

I'm currently fascinated by the comparison of me and a colleague. They bang out code (comparatively) but it's clear from the waves of fixes and bugs they also have to fix that the net result is not really moving faster overall than I do. With my more investigation, more design and incremental expansion.

They originated in quick to market software where as I began in high reliability and safety critical stuff. Personally I hate modern software that is tossed out fast, barely functional and always in need of updates. But in our hyper consumption economics there's not much scope for doing things properly.