Developers love to read (you’re a case in point…), but oftentimes we read alone, merrily absorbing information that could be valuable to others on the team. One thing I’ve found valuable in the past is to create a reading list.

Like Twitter, reading everything on the list isn’t compulsory. Reading lists works on the same “stream” basis. If you happen to see something that you fancy, click through and read it, but if you miss it, no biggie.

In the past, what I’ve set-up before is a system where anyone can just dump links to stuff that they find interesting. These links then get “promulgated” around through some mechanism.

Here’s a blueprint for my current preference of doing this.

Step 1

First of all, create a channel on Slack called, for example, #readinglist.

That’s it! That’s all you have to do.

Well, not quite, because now you have to encourage people to use it.

Engagement

What you’re really trying to do here is to create a private social network – a little group within the team that are sharing information, and improving from it as a result. However, this needs to have a different dynamic than if you were sharing it publically.

The point of public sharing (which we’ll come onto) is that you want everyone on the internet to think that you are the smartest person in the room. You want people to re-share, and amplify, and engage on things that you post. However, in a private team, you don’t want to be the smartest person in the room, because you’ll break the dynamic of the team. Whereas on public social networks the goal is engagement, on a private social network the goal is applicability -- i.e. can you surface something using his method that has beneficial application to this and future projects.

So, the idea is not to post something, and then enter into a discourse on Slack as to whether it’s good or not, because that’s the fast track to arguments. The risk is that the most dominant personality on the team simply smushes out any discussion. You need to find a way of embedding the “learns” from this information sharing into your reflective practice. You can do this by using the reading list to feel into standalone R&D activities – for example, “people keep posting articles about Scala… maybe we should take some time out to build a little Scala POC?” You’re looking to build on the inspiration that can come from having a shared reading list.

Bonus points

We’ve discussed how to support a private social network, but there is value in taking the articles on the reading list and publishing them on social networks. This process – content curation -- is already known to be valuable. When a business tries to use a social network to sell, their goal is to seen as having authority within their chosen domain – for example, if you sell air conditioners, being known as the company for air conditioners is valuable has an advantage in that a) people will seek you out, and b) you can close sales more efficiently.

That obviously works best if you are a technical business – e.g. if you promote a lot of articles on Scala, and you sell Scala training, that lines up. But every technical team has a “sales-like” issue with regards to recruitment. There is a huge benefit in having the engineering team having an independent presence on social networking, as it makes it easier to recruit and retain staff.

This can be done through simply linking a few APIs together. You can pull the reading list out of Slack, and construct posts for whichever linked social media accounts you fancy.

However, a word of warning. Whilst it’s easy enough to think about setting up a Twitter account for the team, e.g. FoobarEngineering, this type of activity on social networks work better if it is based on individuals. You shoulc create FoobarEngineering, but the value comes from encouraging team members to link up their own social media accounts.

Of course, an issue here is that you may need to moderate the posts before they go out, to de-risk either an accidental or malicious “bad share”.

Conclusion

A shared reading list that everyone contributes to can be hugely advantageous in helping the team find inspiration. By taking that reading list and sharing it on public social networks, you can create benefits in recruitment and retention too.

The power of banning the word "bug"

Software developers don't think twice about referring to "bugs", but customers don't care about what causes there issue. They just want their problem understood, and a solution put into place. Banning the word "bug" is a very powerful move.

It's 2018, and it's time to use TypeScript

TypeScript can have a profound, positive effect on making complex JavaScript codebases easier to maintain. You definitely should be using it, regardless of where you sit on the static vs dynamic-typing debate.

Software engineers, or software developers?

One of the age old questions in our industry is "are we software engineers, or are we software developers". We want to be "engineers", because it sounds more worthy... but in this piece I'll argue we're actually "developers".

Share

Our evolving "Digital 247" Software Architecture Methodology helps us guide our technical leadership. We maintain it
in two forms — a benchmark that you can fill out to get a feel as to where you are with regards to your
peers and competitors, and a 7,000-word downloadable white paper that is free to download and is full of
helpful information and advice.