“Saying the quiet part out loud” is a phrase I’ve just made up, to describe a method of building alignment on practices within a team. It’s the habit of stating why you are doing things a certain way, even when you would assume it’s obvious.

“Institutional knowledge” - the information that a company collectively knows - is a familiar concept to anyone involved in hiring processes. When an individual leaves who has knowledge the organisation needs, companies will organise offboarding sessions to keep that knowledge within the institution. Maybe they’ll even try to hire someone with similar experience.

Lots of companies similarly try to optimise for “Institutional learning”, especially smaller firms. This makes a lot of sense - smaller companies don’t have the resources to buy in extra experience, so they focus on rapidly expanding the experience of their existing employees. It also fits really well with the agile philosophy of fast development cycles to maximise your knowledge about customers’ needs.

Talk given at Codebar Festival.

If you wish to see my slides in their full glory, they are available on Slideshare.

I used to stress a lot about the “efficiency” of how I was using up all the minutes in my day. I’d to cram in as much as possible into time. eg. read on a 10 minute train, write code in the half hour before bed, etc.

While I stressed about it a lot, I never found that I did the “10x” things I read about that were supposed to emerge as a result of this extra “efficiency”. For example I have only finished one of the three side projects I started in 2016, despite promising myself that those wouldn’t take long.

A theme of the last few books I’ve read has been user testing. Specifically, that it is completely unreasonable to suggest that you could produce a system that will work smoothly in production without first getting several actual human users unfamiliar with your system, from your clients or in a related industry, to road-test the system.

I think anyone can see that this is a good idea. It’s far too easy to make assumptions about the users’ requirements or use cases. Without user testing software would rarely solve the problems it was designed for.

Last week I went to a jobs event, recruiting for my company. I was there on my own, and recruiting is a pretty new experience for me, so I was kinda excited about it. The attendees were a mix of graduates, bootcampers, and a few more senior developers, but mostly the crowd were looking for their first or second job. I enjoy going out and talking to people about their experiences with software – I think breadth of knowledge is really valuable – so I found it interesting seeing what other people are looking for in a job. I’ve only ever had one; maybe I’ve aimed for all the wrong things!