[Themaintainers] How to Build for the Handoff

Mason Scholl strax22 at gmail.com
Fri Aug 4 12:21:27 EDT 2017


In a similar vein, the Embedded podcast recently had an interview
with Chris Svec (@christophersvec) about empathy driven software
development.

http://embedded.fm/episodes/78

He gave a talk at the 2015 Embedded Systems Conference on the subject. You
can find the slides here:
http://chrissvec.com/empathy-driven-development-slides/ .

It's an interesting subject that most developers don't often think about.

On Thu, Jul 27, 2017 at 12:50 PM, Lee Vinsel <lee.vinsel at gmail.com> wrote:

> Yes, thanks, Camille.
>
> Andy and I gave a talk at a conference of maintenance professionals,
> Mainstream <http://www.mainstreamconf.com/>, a few months ago. I learned
> from one attendee that handoffs are an extremely difficult and fraught
> issue within technical organizations. In heavy industry and the energy
> sector, accidents and deaths, including around maintenance, often happen
> around shift changes. Companies are working hard to improve the
> process—often by using computerized management systems that standardize the
> information that is handed from one shift to another—but difficulties
> remain.
>
> Lee
>
> On Thu, Jul 27, 2017 at 12:54 PM, Andrew Russell <arussell at arussell.org>
> wrote:
>
>> Thanks Camille - yes, relevant and fascinating.
>>
>> Apart from the merits of this approach as a good business practice, and
>> sound/sane technical practice, the word that came to mind as I was reading
>> was *courteous*.  How cool would it be if "courtesy" became a
>> coding/business buzzword? (One can dream, right?)
>>
>> Andy
>>
>> On Jul 27, 2017, at 11:47 AM, Camille E. Acey <connect at camilleacey.com>
>> wrote:
>>
>> *"Write and review code for maintainability, readability and
>> extensibility (versus terseness or cleverness). Code that engineers can’t
>> understand is code that engineers can’t build on, and it’s code engineers
>> will want to throw out and rewrite. When we’re writing code to hand off, we
>> stay wary of anything that is so clever it is opaque, where function and
>> variable names aren’t readable, expressive, and clear, where the code
>> structure makes it difficult to find what you need. Documentation should
>> accompany most changes, and standard code style should be enforced
>> throughout. "*
>>
>> https://trackchanges.postlight.com/how-to-build-for-the-
>> handoff-a2af3421be11
>>
>> I thought this was a relevant read!
>> --
>> Camille E. Acey
>> http://camilleacey.com
>>
>> *"Caring for myself is not self-indulgence, it is self-preservation, and
>> that is an act of political warfare." - *Audre Lorde
>>
>> _______________________________________________
>> Themaintainers mailing list
>> Themaintainers at lists.stevens.edu
>> https://lists.stevens.edu/mailman/listinfo/themaintainers
>>
>>
>> _______________________________________________
>> Themaintainers mailing list
>> Themaintainers at lists.stevens.edu
>> https://lists.stevens.edu/mailman/listinfo/themaintainers
>>
>>
>
>
> --
> Starting Fall 2017—Assistant Professor
> Department of Science and Technology in Society
> Virginia Tech
> leevinsel.com
> Twitter: @STS_News
>
> _______________________________________________
> Themaintainers mailing list
> Themaintainers at lists.stevens.edu
> https://lists.stevens.edu/mailman/listinfo/themaintainers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.stevens.edu/mailman/private/themaintainers/attachments/20170804/29466572/attachment.html>


More information about the Themaintainers mailing list