May 29, 2017 12:00 pm
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.‘
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.
Everything in moderation. Quality beats quantity with code just as it does with food.
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.
Finally share, share, share – put the code and docs on GitHub where your colleagues can find it, use it, improve it.
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.
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.
Posted by Chris Swan
Tags: documentation
Mobile Site | Full Site
Get a free blog at WordPress.com Theme: WordPress Mobile Edition by Alex King.
[…] [1] My first ‘outside in’ project here was the DXC Blogs series, where I republished a number of (edited) posts that had previously been internal (as explained in the intro). I’ll refer to some of those past posts specifically. [2] I’ve been a huge fan of understanding anti-patterns since reading Bruce Tate’s ‘Bitter Java‘. Anti-patterns are just so much less numerous than patterns, and if you can avoid hurting yourself by falling down well understood holes it’s generally pretty easy to reach the intended destination. [3] It’s crucial to make the differentiation here between streams and lakes. Streams are about working with data now in the present, whilst lakes are about trawling through past data. Lakes and streams both have their uses, and of course we can stream data into a lake, but much of what we’re doing needs to have action in the moment, hence the emphasis on streams. [4] More on this at 3 Ways to Make DXC Better [5] Code is super important, but it’s of little use if we can’t share and collaborate with it, which is why I encourage you to Write code. Not too much. Mostly docs. […]
By Bionics – a primer | Chris Swan's Weblog on June 1, 2017 at 7:28 pm