A twitter conversation is as good a reason for a blog post. One of the very interesting conversations we’ve had recently has been around reach.

I made the following statement:

I failed really badly at blogging about what i’ve been presenting. Reach is a thing for ideas. I’m fixing this.

— SerialSeb (@serialseb) January 19, 2016

Looking back at my content, the fact that I never blogged about any of the topics I presented on in the last few years screams of cognitive dissonance.

The ever insightful Christos Matskas, which I’ve had the privilege of spending a bit of time with in Tel Aviv and London, tweeted something very interesting to me, probably in between two planes.

@serialseb and I like this idea. The question is, how many attendees will come back to your blog and read the supporting material?

— Christos Matskas (@ChristosMatskas) January 19, 2016

Reach is key when sharing ideas, both because you want ideas you believe are good to spread, and because you want to challenge your view of the world with the cumulated experience of a peer review.

To maximize the engagement with people I can reach, I decided that each of my post would be advertised on all my social media properties: facebook, linkedin, twitter and conference attendees.

Each of those mediums have different audiences. I usually hover around 80 people in my talks, and they are influential to their communities, as they are attending conferences. They don’t represent all the other people that I engage with. Twitter is a larger such circle, full of people I admire and respect. All the same, it can sometimes be an echo chamber. Facebook is my closer friends and people I’ve actually met, and linkedin is whatever community bothers wanting to follow me.

Combining all those communities on subjects I talk bout ensures the maximum reach for the ideas I try to communicate to people.

Dan Barua, which I’ve also been blessed with meeting a few times in London, replied about dark matter developers.

@serialseb @ChristosMatskas ...and how do we reach the dark matter devs?

— Dan Barua (@danbarua) January 19, 2016

For those that maybe were not born back then, Dark Matter developers is a term probably introduced in our communities by Scott Hanselman.

I do have a fundamental issue with the naming. It assumes that there is the visible and the invisible, the wimp and the enlightened, with a clear distinction between them and us.

Ian Cooper told me many times, and I may be paraphrasing wrongly, that you are not always aware of the impact you have on people. It’s both a humbling and an empowering experience, but one that takes time to accept, integrate and leverage.

See, developers are not one kind or another. Everyone lives on a spectrum of engagement and knowledge, and that changes over time. You may not transform a business you work with, but you may re-motivate one person, or a team, or another team you’re not actually part of. Each of these people may bring your ideas and motivation to other groups. You have people that attend conferences and still consider Funcs and Linq to be too complicated for their business.

And yet, a simple idea that you mentioned in passing can have enormous effect on people, transforming, liberating, and empowering those around you. Frustration with not getting the change you want fast enough can sometimes blind you to the influence you may have by the exercising of your capacity to chat about stuff.

I think dark matter is a false dichotomy between them and us, and I believe that engagement is key to reaching as many people as you can with content you care about. If anything, diversity is always preferable to status quo, and reaching more people keeps you honest and challenges you, making you a better developer, a better teacher and a better communicator.

But with great power comes great responsibilities, and on that there is much to write.

Once upon a time, I blogged about my homegrown approach to designing systems using VeST.

I’ve implemented this stack of practices on quite a few projects over the years, and I’ve been pushed to formalise it’s definition. Why coin a term? Because it’s easier to talk about a package when it has a name, and I find those things useful as a package.

Those practices are all anchored in XP and other agile practices, and I have gotten an enormous mileage from using them. I believe sharing what I think I stumbled upon is a great way to move the goal post ad continue the conversation.

The Tenets of Vertical Slice Technologies

Building systems is a complex endeavour. Vertical Slice Technologies is my holistic approach to designing specification-driven applications, iterating over small features and simple systems.

I value the following software principles:

• Building and deploying small features quickly and iterating on a problem.
• Building composeable autonomous components that communicate and work together in a monolith or spread over a distributed network.
• Prioritising Minimum Viable Product features of the smallest possible size that can bring value by being deployed.
• Building as quickly and as early as possible a line through the implementation of a system, a fishing line or tracer bullet to put in place all the required components as early as practical, and grow them as the feature-set grows.
• Focusing on Keeping It Simple Stupid and design the simplest possible system that can work for a feature.
• Discover with the business and the teams what each feature ought to do and what acceptance criterias are upfront, using Behaviour-Driven Design approaches, and encode them in the code where they are the sole source of truth of the understanding of a system.
• Providing, alongside our libraries and services, in-memory fully-featured Production-grade fakes people can use in their own code-base, the same we use to build our systems, so our consumers do not have to mock APIs themselves.
• Providing, alongside our libraries, test rigs for components consumers can implement, so that they don’t have to reverse-engineer the expected behaviour of the extension point we provide, and use them ourselves in our implementation.

This blog post serial will deep dive in how to build a system that follows those principles, not as the sole way of doing it, but as the way I found to be useful.

Thanks for all the reviewers that have spent some time giving me feedback on this entry, you know who you are.

GitHub Pages uses Jekyll, which then uses liquid as it’s templating mechanism.

I didn’t want to maintain various html templates all replicating the content from one another, as it makes large changes much harder.

But I learnt a cool trick from the first iteration of SerialSeb.com, which allows you to replicate master templates from asp.net in Liquid.

Say you want to reuse the same html content, but allow each layout to define its own footer.

Given a blog post, the layout is selected in the front matter, with the layout instruction.

We then include a file in the _layouts folder called post.html.

We use the capture element to capture the string output we want in a variable called footer. As those variables are global to the currently-rendered page, we now have the footer content.

Finally, we include a _master.html file from the _layouts folder, which simply makes use of the variable.

And voila, master pages on liquid. There are other tricks you can use, as the include instruction takes in variable parameters and string parameters, so you can parameterise this string without relying on global variables. I’m lazy today so implementation is left as an excercise to the reader.