Originally posted internally 16 Aug 2016:

The title of this post comes from a tweet by Evan Goer I saw last week. It’s derived from Michael Pollan’s statement from In Defence of Food: ‘Eat food. Not too much. Mostly plants.‘

Write code

Just as food fuels our bodies, code fuels our industry. The world is moving to infrastructure as code, which I’ve written about before. I noted yesterday that GE’s CEO Jeff Immelt is quoted as saying ‘We hire 4,000 to 5,000 college grads every year, and whether they join in finance or I.T. or marketing, they’re going to code.’ – so whatever you’re doing it’s likely that you can do it better/faster/cheaper by writing some code, and if you don’t know how to do that it’s never too late to learn.

Not too much

Everything in moderation. Quality beats quantity with code just as it does with food.

Mostly docs

Because people need to understand what the code does, and ‘use the source Luke’ just doesn’t cut it. Good docs give your code the superpower of enabling other people to (re)use it.

Collaborate

Finally share, share, share – put the code and docs on GitHub where your colleagues can find it, use it, improve it.

Retrospective

This was a reminder of my earlier ‘The value of artifacts‘, where I first started banging the drum about the importance of documentation (and samples and examples).

Along with the infrastructure as code Katacoda scenarios I’ve published a screencast on getting set up with Git Bash and Atom, and one of the things I highlight there is Atom’s built in Markdown preview, which is super helpful to anybody writing docs that are going to live in/on GitHub.

Original Comments

GS

This is a simple yet good write up to promote movement from sys admins to sys engineers in the organization.

MN

I believe his point was that people working in fields that use computers (not just Information Technology) will need to understand coding just a little more than they do today.

IP

I think we really need to go for infrastructure as code and start cranking it out but I wonder how long before serverless overtakes.

Incidentally are we building infrastructures as code libraries for our partner’s clouds? Be really something if we one day had them available to clients in a catalogue such that they could build their own CSC supported environment, then just press a button to handover support to an SLA. Too much dream?

MN

I’ve been working a bit with containers and I think there’s some legs to it.

There seems to be a need for a universal mediator or we’re just going to be continually tying together pieces.  With SDN, it actually seems like it is getting worse, where vendor specific technology/implementations are driving the need to create zones of intermediary relationships.

Function based serverless looks pretty nifty.  It is certainly another tool in the toolbox.  I’m not really sure how it differs all that much from container based workload chaining though.