Future Software Should Be Memory Safe, says the White House

[Nominal Animal]

Just so, but don't forget to add "show me the reward structure and I'll tell you how people will behave".

Hey, full circle: that is exactly why I said memory safety is a social problem, not a technical one.

[Wil_Bloodworth]

That too can be a problem.  It fails for interesting projects where any of these apply...

Eh... I'm not convinced that ever reporting what you did yesterday and reporting what you're going to do today has anything at all to do with the work or the context in which you're doing it.  Transparency is transparency regardless of any other factors.

But maybe I'm misunderstanding the point you're making.  My point was that "standup" weeds out laziness.

[Siwastaja]

I think the whole point is in understanding that this initial effort is required to enjoy your laziness in the longer run. And so, IMO the main problem is not with software developers being lazy per se, but the need for immediate reward, preventing them from investing this initial effort to make their life much easier afterwards.

This appeal for immediate rewards is what plagues software engineering in particular, and our whole socieity in general.

In embedded, I have developed this pattern which seems to serve me well:

The first prototype must be over-crappy, beyond any salvage. I mean a single long function, with while(1) loop calling blocking delay functions and writing some stuff on debug UART, no datatypes, no structure, copypasta if necessary. Bonus points from goto. Proof of concept can be demonstrated within hours and then it is (hopefully) obvious to both managers and programmers this piece of code cannot be used at all for the actual implementation. But because you have demonstrated the viability, now the team including management cannot pull out of the project so you get at least some time and resources to actually implement it, maybe a 3-4 days for a simple module before anyone starts asking questions.

And, because you tested some ideas, the structure is now starting to form in your head. It's best to do such initial tests near the end of the week so that your brain gets at least a few days of subconscious processing time before real implementation begins.

[tggzzz]

That too can be a problem.  It fails for interesting projects where any of these apply...

Eh... I'm not convinced that ever reporting what you did yesterday and reporting what you're going to do today has anything at all to do with the work or the context in which you're doing it.  Transparency is transparency regardless of any other factors.

But maybe I'm misunderstanding the point you're making.  My point was that "standup" weeds out laziness.

Let me use the old aphorism as a hint: "research is what I am doing when I don't know what I am doing".

For the interesting projects I have worked on, only a very small proportion of the time has been spent writing code. Most of it has been spent on deciding what to do and how to do it, then noticing a big hole in those thoughts, and starting again. Eventually start coding, discover the tool has been oversold, start again. After a few repetitions, find a good path, then realise it is over-complicated, so chop half the code.

None of that occurs in boring CRUD projects.

None of that is captured or capturable in a daily standup.

The other obvious point is that I have never worked with lazy people! Good companies weed those out during interview

[tggzzz]

I think the whole point is in understanding that this initial effort is required to enjoy your laziness in the longer run. And so, IMO the main problem is not with software developers being lazy per se, but the need for immediate reward, preventing them from investing this initial effort to make their life much easier afterwards.

This appeal for immediate rewards is what plagues software engineering in particular, and our whole socieity in general.

In embedded, I have developed this pattern which seems to serve me well:

The first prototype must be over-crappy, beyond any salvage. I mean a single long function, with while(1) loop calling blocking delay functions and writing some stuff on debug UART, no datatypes, no structure, copypasta if necessary. Bonus points from goto. Proof of concept can be demonstrated within hours and then it is (hopefully) obvious to both managers and programmers this piece of code cannot be used at all for the actual implementation. But because you have demonstrated the viability, now the team including management cannot pull out of the project so you get at least some time and resources to actually implement it, maybe a 3-4 days for a simple module before anyone starts asking questions.

And, because you tested some ideas, the structure is now starting to form in your head. It's best to do such initial tests near the end of the week so that your brain gets at least a few days of subconscious processing time before real implementation begins.

Yup, pretty much the case.

Fails when people don't understand the concept of "throwaway concept code", and want to put it in a version control system and start mutating it line by line. Been there, got the scars

If there is a GUI involved, one imperfect defence is to use the "napkin look and feel". The GUI is functional, but Very Clearly Not Deliverable.