Earlier this week I had a really interesting conversation with Thijs Feryn. You may know Thijs already, and you may have seen him / heard him speak at one of 171 different conference talks across 14 countries.
I was lucky enough to catch Thijs speak at PHP North West 2015. Incidentally, the 10th Anniversary of PHP North West occurs at the end of this month – shout up if you’re going, it would be great to meet up.
I’ve met a couple of Technical Evangelists in my time, and I have found them to be amongst the smartest people I know. And yet I’ve never though to ask them how they got that job role / title. Until now:
What I wasn’t quite expecting was the depth and quality of his response.
Thijs recorded a really interesting video / vlog answering the question:
The video itself was enough to make me sit up and take notice, but the accompanying blog post included even more depth and avenues to explore.
I shared this link out with a few devs I know earlier this week. There was a complete division that caught me off guard.
The responses I got were either:
Hey, cool, thanks for sharing, this looks interesting
WTF is a technical evangelist?!
Ok, so I paraphrase, but that’s the gist.
Now, I’m no expert. I can only share my view-point from the outside looking in. But here’s what I think when I hear “technical evangelist”:
A technical evangelist is a mixture of pre-sales / sales, consultant, and conference speaker.
As a technical evangelist you would be an expert in a particular field, or technology.
This typically means keeping a blog about your specialist subject, and regularly creating new content in that subject area. It helps to create very high quality / useful content as the perception that site visitors have of you both during, and after the site visit will influence who they choose when things go wrong / get complicated.
In Thijs’s case this also involves becoming a published author as a direct result of evangalising a particular tech (Varnish). Thijs goes into how this book came about and how this is different to the usual approach to writing a book.
The short version of this is best viewed from a real world problem I experienced in a previous role:
- My employer bought some expensive hardware
- I was out of my depth, so started having to learn both on the job, and in my own time
- Google searches led me to the same blog, over and over
- I went to a conference in Manchester where I met said blogger after watching him do a talk
- I went back to the office and told my boss about “this guy” who knew all about our problem space
- A few phone calls were made, and “this guy” and others from the same organisation came in to do salesy / consultancy type stuff
- Lots of money changed hands
I think the details here may be a little hazy as this was ~10 years ago.
Ultimately though, the company I was with at the time would never have chosen to start working with that consultant at random.
By establishing himself as a subject matter expert, backed up with conference talks and a decent blog, a lot of trust was pre-established.
From here the sell is a lot softer. In fact, I ended up as the internal advocate for this particular chap, which in turn opened the door for his company.
I can imagine, because it involves sales / money, that this whole thing sounds quite sleazy.
I would argue against this.
Sure, money changes hands. And in the context of big business, that can be big money.
But on a personal level I got to work with a subject matter expert who was both incredibly helpful, and still in my mind the very best person for the job.
Anyway, that’s why I find the whole “technical evangelist” role so fascinating. It encompasses so many of the facets of “the business of software” (or hardware) that I find so interesting.
The reason I wanted to share this with you – beyond the unexpected response from Thijs – is that there are opportunities out there that you very likely will not see advertised on the job’s boards.
To get these roles requires you to push yourself outside your comfort zone and think beyond coding.
I genuinely found this whole exchange fascinating. I’d urge you to read Thijs’s blog post, and watch his video. We spend our 37+ hours a week at work, we might as well do something super enjoyable – and being paid to evangelise a tech you personally love sounds like a brilliant role to me.
Here are some other posts on “what is a technical evangalist”, as maybe I didn’t do this justice:
I said last week I hoped to get out some “beta” invites.
I’m almost there.
Just the 23 remaining tickets in my GitLab issues register 🙂
What’s crazy about this whole process is all I am doing at this stage is reproducing exactly what I already have. In other words, everything you see on CodeReviewVideos.com at the moment will be how the new site looks and feels in the first phase of version 2.
Kinda nuts. It’s a lot of work for the same outcome 🙂
There is method to the madness though. There are some crucial fixes to some problems of my own making in the first version of the code.
There’s also a completely new member’s area – probably the most requested feature since Site Search.
On the subject of site search, I’m now using Elasticsearch whereas the existing implementation is just MySQL fulltext (aka meh).
I’m looking forward to getting the new code “out of the door” because it means I can get back to recording a lot of new content. And I have a ton of content I want to cover.
Thank you to both respondents to my request for new instructors. This made my week last week 🙂
If you’d like to create tutorials / screencasts then please do get in touch (chris @ codereviewvideos.com) and I will tell you more.
There will be a set of new pages on the new site version that explains this process further.
The short version is simply:
If you’d like to share a screencast on any subject (front end, back end, devops, open source, WordPress, Magento, other) then you are more than welcome at CodeReviewVideos.
Aside from growing your own knowledge, and sharing that knowledge with others, there is a potential for earning a monthly recurring income.
You need not be the World’s best screencaster – sharing your knowledge is the most important part.
This week saw three new videos added to the site.
This video is answering a question I received regarding Sorting in Symfony (in this case, a Symfony 3 JSON API) without relying on third party bundles, such as KNP Paginator Bundle.
We cover how to sort on one field, in both Ascending, and Descending order. To this we borrow an idea from Django Rest Framework.
Then we cover how to sort on multiple fields at the same time. We cover a few ways we might restrict down what fields can / cannot be sorted on.
And we finish up by discussing whether adding this logic to your code is worth it, when more full-featured plugins (such as the aforementioned KNP Paginator) already exist.
In this video we cover the differences, and similarities between Docker Images and Docker Containers.
The tl;dr version of this would be that Docker Images are very similar to Classes in object oriented programming.
Docker Containers are as though we new up an instance of that Class.
As with almost everything in Docker-land, you can dive a lot deeper than this if needed. However, for most day-to-day tasks you likely only care that you a) have the right Docker Image, and b) can create a Docker Container from that image.
By the end of this video you will have learned about the differences between Docker Images vs Docker Containers, and have had hands-on experience with both.
I’m indulging myself somewhat in this short video series on Elixir, Phoenix, and Docker.
Yes, Docker is featuring heavily on the site lately 🙂
In case you aren’t aware, Elixir is a functional programming language.
Phoenix is a web framework for the Elixir programming language.
And no, I am not abandoning Symfony or PHP 🙂
I am firmly in the camp of thinking that learning a new programming language is one of the very best ways to improve your programming knowledge.
In the case of learning Elixir I have greatly improved the way I think about the structure of my code, and how each method / function can often be bettered modelled as a series of transformations of data.
Elixir has some incredibly interesting patterns and paradigms that coming from a PHP-background have been very tricky to learn.
In this short course we will create an Elixir / Phoenix stack along with Postgres for our database, and Docker to manage our infrastructure. We will then spin up a typical JSON API with all the expected interactions:
This sounds like a lot of work, but if you’re anything like me, you will be amazed at how quickly this implementation can be achieved.
As ever thank you very much for reading, have a great weekend, and happy coding.