Title: Teaching Developer Hygiene
Date: October 10, 2016
Tags: me devops 
========================================

How do you teach non-developers good development practices and process and get
them to like it?

Where I work, people write a lot of code.  Not all of them are developers and,
more importantly, not all of them are writing code to create a software product.
For them, the code is a disposable tool that generates *results* which are
important to them.

Management wants everyone to be writing better, more professional code.  Those
writing code, want to write it quickly, get out of it the "important"
information then throw it away.  To make this complicated, it's the important
information generated by the code that management truly values.  So that makes
my job: get people to do things they should be doing, don't want to do, see no
value in doing, and without incentive to do it.

We do have "actual" developers as well.  There are people who have worked for
commercial companies building software products.  I'm trying to tap into their
experience and knowledge of software process.  I'm no stranger to it myself.
I've worked as a developer and in roles very close to development and am
familiar with development process and tools.  To these developers, things like
testing and code review, are like brushing your teeth.  It's just something you
do.  It's automatic and even though you don't see it right away, in the long
run, you're better off for having put in the time.  That's the key.  Making them
want, or at least, not feel like it's extra work to follow a good process.

The level of ideas I need to get across run the full range.  Check your code
into source control...repeatedly as it changes.  Use branches and merge them
often to keep them up-to-date.  Automate tasks that you have to do all the time
so they actually get run.  Tag, date, document, name, something, releases that
you hand to someone else so when they get to it 6 months later, you know what
you gave them.

Some more advanced topics might be:  Use a good branching strategy to separate
development, releases, and hot fixes.  Write and automate unit tests, as well as
system or integration tests.  Maybe throw in some fuzzing or static or dynamic
analysis.  Use a code style, write comments and generally make the code
readable.

I want to live in a world where a developer writing code, collaborating with
other developers, doesn't have to be told to check in their changes so the
others can use and build from it.  I have to create that world.