The Modern Dev Team
January 22, 2018 | OpinionThe other day I was chatting with some friends in Slack, watching them discuss Kafka âstuffâ and things that are good and bad about Kubernetes (which I think youâre supposed to call K8?). I made a small quip along the lines of âI think I need to get a real jobâ as Iâm having an increasingly hard time caring about this stuff.
One of the people in the room, Rob Sullivan, had an epic response:
At first I was like "oh you can f*** right off" but then I just turned 50 so I have a bit of a soft spot when it comes to "falling behind". This is captured perfectly by one of my favorite authors, Charles Stross:
An unspecified time after the impostor syndrome goes away, over-the-hill syndrome moves in: the irrational conviction that you're a burned-out has-been, phoning it in, best days behind you, a broken-down hack whose audience is losing interest rapidly.
â Charlie Stross (@cstross) January 22, 2018
It really has been a while since I've worked on a "modern" team. I still write code, in fact, I do it every single day. Mostly for myself: I have 3 running projects which are all focused on helping me run my business - but that is hardly the same as being part of a team.
I think the last time I was part of a team like that would be (gasp) 2009 or thereabouts when I worked at Microsoft. The project was called Orchard and I hated every minute of it. That's a whole other story⊠but I think that's the last time I ever did institutional coding.
My goodness.
Am I a Burned Out Has-been?
I don't think I am⊠but then again I do catch myself lamenting over "the good old days" more and more. Obviously, this is a massive cliché and I know it when its happening, but there is a shred of truth to it sometimes.
Trying to be a good person, I decided to face this question head-on. Just last week I headed over to NDC London and had, once again, a really really good time. I think this was probably the best NDC London yet, primarily because they moved the venue to the Queen Elizabeth Center, right down the street from Buckingham and across from Westminster Abbey.
While I was there, I decided to dig into Rob Sullivanâs thought a bit: what would happen if I joined a modern dev team? I remember sitting in the back of the room during Felienneâs amazing keynote, pondering what that would even look like:
Lots of Docker? Probably. Learning new systems and ways to decentralize things? For sure. Solving the same problems that teams have had forever but in a new way? Absolutely.
That last bit wasnât me being snarky! Evolution is an iterative process. New tools give us a fresh way to solve old problems, so Iâm in! But⊠am I just fooling myself? Have I been out of the loop for so long that getting up to speed on modern "stuffâ would drive me to constant complaining?
After 3 days of sitting in talks and seeing what people are doing at their jobs (which are my favorite talks: the good old war story), I decided that no, Iâm not quite burned out yet. In fact, Iâm likely more energized than Iâve been in a very long time.
Why? Because unlike many years ago when I had to learn all this stuff from scratch: I already know most of the problems trying to be solved, or at least I feel like I do. Itâs fascinating to see how theyâre being approached today as well. Let me explain...
Itâs Still a Thing: Reinventing Erlang
OK that does sound snarky, but itâs also true: building concurrent applications invariably leads one to rediscover what Erlang solved so many years ago (and solved well). Yes yes! I know I sound grumpy! But stay with me as I donât mean to be a jerk about this: it just is. If we can accept this truth without tribalism flaring up, we can free ourselves to introspect whether modern solutions might be better.
Deep breath, let me fill in some details.
Hereâs a simple truth that I think we all recognize: The Free Lunch Is Over:
The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency.
That post was written many years ago by Herb Sutter, and itâs slowly coming true. Concurrency is a thing, and with processor clock speeds reaching the top of their asymptotic rise, the programming industry is trying to figure out ways to catch up.
Architectures are shifting to allow for this. Microservices. Parallel/elastic scaling, message-based architecture, orchestrated containers and serverless functions in the sky - these all focus on the idea of concurrency. Programs that grow sideways with more cores rather than up, with faster cores. Or no cores at all, in the case of serverless...
I know you know this. At least you should. You probably also know that this is precisely the problem that Erlang was created to solve. That doesnât mean that everyone should stop what theyâre doing and use Erlang! It just means that understanding a bit of history will help you know when youâre doing things better, or worse.
Containers, Processes, and Serverless
I sat through a few talks about container orchestration, the most fun was with Scott Hanselman and Alex Ellis entitled Building a Raspberry Pi Kubernetes Cluster and running .NET Core. One of the demos showed how Kubernetes will monitor a node and if it dies, restart another one. Straight from the Erlang playbook: "let it die". I love that approach to writing programs with Elixir (and Erlang), and its great to see it being used elsewhere.
But you don't need the Erlang VM for this, just a bigger infrastructure to run Kubernetes, Docker and so on. Is this a good tradeoff? I suppose it must be as people are using it.
Other talks I went to discussed serverless âfunctions in the cloudâ. Some used Googleâs Cloud bits, others focused on Azure and gave a nod to AWS Lamda. Each of these talks also weaved together a story where you could âwrite a single function that takes in the data it needs and returns an answer. String these functions together and you have an appâ.
In other words: functional programming using the actor model. Well, for the most part, I guess. Youâre forced to reconsider the notion of state, something you donât have with a function âin the skyâ. Yes, you can use a database, but then your endpoint becomes dedicated so what's the point?
Functional purity (and the actor model) is something I learned well when I started doing Elixir. I donât think Iâm being a crabby jerk by recognizing this. In fact, itâs the opposite: Iâm seeing interesting ways in which existing patterns are being applied with new solutions, outside the Erlang ecosystem, solved with infrastructure rather than a platform. Fascinating!
The Next 10 Years
10 years ago I turned 40 and I remember wondering what I would be doing 10 years from then when I turned 50. I found out what I would be doing during NDC London, on a boat on the Thames. A really fun way to celebrate my 50th birthday: surrounded by good friends and a big ass chocolate cake.
As we motored along, I remember looking over at the London Eye, all lit up, looking grand:
What will I be doing 10 years from now?
I hope these years will be fun, just like the last. I think Iâm old enough now to be able to step back from quantifying my value by whether Iâm âin the trenchesâ or in front of an audience. I love what I do, whether itâs writing a book about what Iâve learned or stressing out over a breaking build: itâs just stepping from one role to another.
That said, I did walk away from NDC London with the possibility of joining a very, very interesting project. Iâd be part of a team - a very modern team at that. Iâm quite excited about it! Just as I am about the next volume of The Imposterâs Handbook, which is well underway. I guess this much seems obvious: choosing which thing to do is kind of silly.
Have fun. It doesnât matter how you have it. Oh, and recognize when youâre being a crabby jerk :).
Join over 15,000 programmers just like you and me
I have a problem when it comes to trying new things and learning about computer science stuff. I'm self-taught, so it's imperative I keep up with what's going on. I love sharing, so sign up and I'll send along what I've learned right to your inbox.