Bastien bzg

Google Presentation Link [goo.gl]
PDF Presentation Link [s3.cleverelephant.ca]
"Ottawa turns to U.S. tech giants too often: internal memo" [cbc.ca]
"Government as a Platform: the next phase of digital transformation" [gds.blog.gov.uk]
DevOps Real Talk [www.theregister.co.uk] "incremental change, tight feedback loops, shared knowledge, and mutual respect" "If you're a developer releasing large changesets, you're part of the problem."
The Government IT Self-Harm Playbook [medium.com]
Better For Less (UK IT) [[drive.google.com](https:/

Rich Already Answered That!

A list of commonly asked questions, design decisions, reasons why Clojure is the way it is as they were answered directly by Rich (even when from many years ago, those answers are pretty much valid today!). Feel free to point friends and colleagues here next time they ask (again). Answers are pasted verbatim (I've made small adjustments for readibility, but never changed a sentence) from mailing lists, articles, chats.

How to use:

The link in the table of content jumps at the copy of the answer on this page.
The link on the answer itself points back at the original post.

Table of Content

Product managers

Seek out failure, it teaches us to think like a scientist. If you start with a hypothesis, then try to prove yourself wrong, you’re bound to make much better decisions. You have to be willing to fail, and that in itself is going to help you build confidence and be more convicted about what your strategy is in the end.
There are hundreds of methods for building products and running teams. As a quality PM, it's important to have an open mind about all of it, but finding your own process and philosophy can be grounding. It helps you find your pillars so that you don't smash into things while you're building. Remember, however, that you can always find a budget for remodeling. 😉
The beauty of a good process is when it just becomes how you do your work. When you forget you're following a process at all is when you know the process is working for you, your team, your company, and your customers.
The advice I give new Product Managers or PMs coming onto a team for the first

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
Once documentation has been written, development should commence, and test-driven development is preferred.
Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
When a feature is being modified, it should be modified documentation-first.
When documentation is modified, so should be the tests.

With leiningen http://leiningen.org/

lein new clojure-into

You can then open your project in LightTable http://www.lighttable.com/ and start hacking !

	;;; -- lexical-binding: t; --

	;; $ emacs -Q --batch -f batch-byte-compile example.el
	;; $ emacs -Q --batch -l example.elc -f disas
	;; $ emacs -Q --batch -l example.elc -f bench

	(defun add (a b)
	(+ (car a) (car b)))

	(defalias 'car-alias #'car)

	(ns localstorage)

	(defn set-item!
	"Set `key' in browser's localStorage to `val`."
	[key val]
	(.setItem (.-localStorage js/window) key val))

	(defn get-item
	"Returns value of `key' from browser's localStorage."
	[key]

	;;; Create and display an `ibuffer' showing only `org-mode' files.
	;;;
	;;; I have bound this to "\C-cb" using:
	;;; (global-set-key "\C-cb" #'org-ibuffer)
	;;;
	;;; Now "\C-x\C-b" creates a generic `ibuffer' and "\C-cb"
	;;; creates an `org-mode' `ibuffer'.

	(require 'ibuffer)