Thanks for the great talk. I can't agree more. I really loved how you mapped how this way of working gives returns for the whole project.

I wonder how this translates to for iterating over existing architecture versus having a fresh start (maybe once in a while) for successive products. It probably varies on a case-by-case basis but would it be better to clean things up and shrink bloat down for every project when you are iterating despite the high load it brings? Will it give meaningful returns on productivity/efficiency/quality, say compared to fixing things only when issues arise?

Thanks for the great talk. Having a team that enables the Developer Journey is new to me, but it makes definitively a lot of sense.
While containers are a great technology as you pointed out, sometimes they get a bit in the way (possibly because where I work there is no dedicated team :-) ). Alternative solutions like NixOS promise to fix all the dependency detail to achieve repeatable builds without the need for containers. Have you tried them? How would you rate them for embedded software development?

Hi Mark - really interesting talk. I have been trying to focus more on setting up a better development environment for myself as of late. The challenge is that in the very small company I am in, I am the electronics department. I do all of the hardware and software work by myself. With that in mind, I am usually rushing to just get things designed, fabricated, coded, and tested within the timeline. So I rarely have time to focus on a better or more efficient process to actually do my work. This was OK for a while, but as our projects have gotten more complex and building upon previous work done, I am finding that my current work flow was not built on a stable foundation and I am struggling to keep up. The real challenge now will be to convince my team that I need to be given time to figure all of this development operation out so I can be more productive in the future.

Hi Mark, thanks for the talk. One gentle push towards what feels like the right direction. :-)

When you talked about testing solutions, you mentioned the importance of emulators which make testing high-level code much easier. I noticed you did not mention Renode (https://renode.io/) and wondered if you had an opinion on it. Looking forward to hearing from you.

Cheers

Thanks very much, Mark, for your containerize hints concerning a "clean desk". Tool chains depending on locally installed tools should be deprechiated indeed.

Good talk. As discussed in the Peopleware book, something as simple as management providing a quiet room to work in, instead of open-plan, improves developer productivity.