My quest for identity in Software Engineering
Tags: serverless, jamstack, devops, sre
Published: 2020-01-29 10:17:04

> Keep walking. If I look back I am lost.
>
> ― George R.R. Martin, _A Dance with Dragons_

They say that the sum of all our past choices and experiences makes up most of who we are. Despite that knowledge I never liked to invest much of my free time thinking about the past.

I always thought there's such a thing as the right to forget and to be forgotten, that the opposite (to look _forward_, to imagine how the future could be, some might say [_to dream_](https://open.spotify.com/track/3uYrVtgRuz4XiOOXDV805X)) is one choice that more consistently brings better outcomes.

If only I could perfectly stabilize [between those two opposites](https://en.wikipedia.org/wiki/Nirvana_(Buddhism))... but that's maybe for another time.

## Faulty Random Access Memory

> I have to believe that my actions still have meaning, even if I can't remember them.
>
> ― _Memento_

There's more. It turns out that our brain is not very accurate at _remembering_.

Contrary to the common belief, it doesn't store a perfect snapshot of reality as a calculator might do: immutable, _pixel perfect_ and ready to be retrieved at will. Multiple loads, same exact results.

The human brain apparently doesn't care much about _von Neumann_ architecture and goes its own way as it did for the latest [three hundred thousand years](https://www.britannica.com/story/just-how-old-is-homo-sapiens) or so.

When remembering, i.e. creating a representation of a past experience in our mind, the hippocampus [coordinates](https://www.psychologytoday.com/us/blog/the-athletes-way/201507/the-neuroscience-recalling-old-memories) the decoding of various _media chunks_, loading the bits and pieces scattered (should I say sharded?) between different areas of the neocortex into a coherent entity.

There's consensus between neuroscientists on how incredibly plastic our brain actually is, how it's constantly and frenetically rewiring itself, creating new pathways and dropping established ones to make room for new models of reality. All of that while running countless maintenance jobs in the background. It is hard to say to what extent this frantic synaptic rewiring activity is messing with the memories of what actually happened.

That's not the point I want to make with this article though, neither _looking forward_ is a dogma for me. I always liked to keep flexible, leave doors open and go out of the ordinary _when it makes sense_.

The more I get older, the more I recognize circumstances where it does make sense so, with my 40th birthday knocking at the door, it feels safe and fair enough to _look back_ and indulge in some wrap-ups and _where to go from here_ kind of reflections.

## Special Circumstances

> Just remember that the things you put into your head are there forever, he said.
>
> ― Cormac McCarthy, _The Road_

If I do look back now I can't think anything other than "it has been a great ride". Sometimes harsh. Sometimes exhilarating. Never boring.

The truth is, I was lucky. Not because of some mysterious invisible force keeping me pointed in the right direction, neither because of the average quality of the choices I made.

I was born lucky.

Lucky enough to spend the formative years in a rich economy that gave me, between other things that today for many are still mere luxuries, a solid education paired with early access to new fancy technologies.

On top of that, I had a very timely chance to give a closer look at what back then was the new rising star in the global sky: the "World Wide Web".

## How _deep_ is your learning?

> I’m floating around the universe on this giant sphere, suspended here by gravity and going for a ride.
>
> ― Anita Harris, _Conscious_

With a growing stack of knowledge and experiences coming along wherever I've been, I was allowed to keep building new skills needed to constantly practice a profession that I still love today as much as I did when moving my first steps, if not more.

Since then I could travel far and abroad, always to find a more than decent occupation virtually everywhere without much of a sweat. Titles have been ranging ever since from _Sysadmin_ to _System Engineer_ to _DevOps/SRE Engineer_ but those labels never truly mattered to me: I just wanted to deliver value doing what the business needed and it turned out their IT infrastructures needed a lot of care.

I met a lot of professionals on the way. Some of them brilliant and ingenuous. Some flamboyant and inspiring. Some pretentious and annoying. Many though, if not all, joined by a common passion for what we _crafted_.

That multicolored _culture within the culture_, made up of uncountable people and ideas and cool new technologies and funny but [visually ugly](https://devsum-archive.s3.amazonaws.com/automate-meme.jpg) memes (...and on and on), soon became fuel for virtuous loops of **discover => learn => practice => discover** that, almost mindlessly, kept me moving ahead doing what I liked and getting a pretty good living out of it.

## Eventually inconsistent

> Do not confuse _duty_ with what other people expect of you.
>
> ― Robert A. Heinlein, _Time Enough for Love_

I'm increasingly unsure about how to answer the question _"Would you do any different?"_ though.

I dropped out in the middle of my engineering studies and still forget _big O_ magnitudes 10 minutes after a coding interview is over. I never worked for a _BIG_ nor visited Silicon Valley. I didn't write a kernel module nor create any widely used (Free and Open Source) software. I was never fully in charge of any product beside when freelancing or working on a personal one.

I could go on indefinitely.

Heck, let's be honest, I was never **the best** in anything I did, neither while studying the theory nor putting it into practice. For sure I missed out interesting but invisible (to me) opportunities, and a few times I even dropped already taken good ones while pursuing other more important goals.

Finally, I lost the count of the many pet projects I fell in love with and forgot soon after, a behavior that at this point we can safely call chronic. It's true that some of those projects left a mark on me, increasing my knowledge and experience, but none of them ever truly conquered my heart.

Maybe it's true what they say then: the _first love_ you can't ever forget.

## Contacts[0]

> Common misconception that; that fun is relaxing. If it is, you’re not doing it right.
>
> ― Iain M. Banks, _The Player of Games_

I first got interested in _the web_ around the late Nineties, when I connected to the Internet with a noisy _28.800 baud_ modem and upgraded to a _PPPoE_ ADSL soon after.

Broadband connectivity in 1999... **that** was luxury!

The initial heat soon dissipated though. I started to believe I missed a key natural skill required to become a decent (web) designer, and if you see my hand writing you'd know instantly what I mean.

The first attempts to set up from scratch a decently looking template for a website put me off as an impossible feat and made me wish for something... [more ergonomic](https://devsum-archive.s3.amazonaws.com/css-meme.gif).

To be truly honest with you, the main reason I gave up is because _it wasn't fun_.

## Got _ROOTs_?

> Control can sometimes be an illusion. But sometimes you need illusions to gain control.
>
> — _Mr. Robot_

Sending cryptic commands to an IRC bot [while waiting](https://www.xkcd.com/303/) for a recompiling (2.x) Linux kernel. Configuring MTAs to securely relay and deliver `root@localhost` emails to [_some mbox_](https://www.xkcd.com/838/ 'open /var/spool/mail/root'). All while jumping between one (hopefully _secure_) _shell_ to another, palms sweating before hitting `enter` when commands ended in something like `-j DROP`.

All that was way too much fun to go in search of any other digital adventure. Even better, I discovered almost without realizing it that businesses were already willing to pay me to do that, full time.

I soon lost interest in the new world of web development while I dived deeper and deeper in the one of networked computer systems. The _back_, the infrastructure, the invisible _end_ felt like the right place to be: abstract, loosely constrained, wild and unexplored. So there I decided to put my _roots_ (pun intended).

The _web_, the **front**end, was out of my way for good. Or so I thought.

## Breaking (out of) DevOps

> "Evolution [is] a random walk across a minefield, not a pre-ordained trajectory, onward and upward toward _perfection_."
>
> ― Greg Egan, _Permutation City_

Jump forward a couple of decades and here I am, microblogging [about Vue.js](https://fosstodon.org/web/statuses/103039798260051036), discussing [about](https://a.l3x.in/2018/07/25/lambda-api-custom-domain-tutorial.html) _Serverless_ [every](https://a.l3x.in/2017/02/28/lastversion.html) chance [I get](https://a.l3x.in/2017/05/30/sslnotifyme.html) and subscribing to ([excellent](https://www.youtube.com/user/DesignCourse/)) web design courses and [CSS](https://css-tricks.com/) RSS feeds.

Wait... WHAT?

It looks suspiciously like the classical mid-career/mid-life crisis, right? Just a feral impulse to an easy change: let's get rid of the past with one clean stroke, reject altogether the idea of self-managing backend systems for good. `ssh` is dead. Get over it.

I'm afraid the truth is far from that, even though my opinion is that today there's generally no real need to orchestrate any fleet of servers running SSHd... unless you are deep in _legacy territory_, a (ti)*tty* fetishist or some kind of (cloud) service provider.

## SSH is dead. Long live SSH

> Humans are meant to work and sweat to earn a living. That's the lesson.
>
> ― _Cowboy Bebop, Jupiter Jazz (part 1)_

I'm not saying server administration is dead. Heck no, long life to Linux & Co. and all the community around it, and most importantly, my sincere compliments to all the _System / DevOps / SRE Engineers_ out there for keeping the Internet alive and kicking, 24/7 365 days per year.

Taming the operational complexities in this era of _Global Scales_, _Spot Instances_, _Chaos Monkeys_ and _Multi Regions_ is a **very difficult task** and one that most of the time gets only little appreciation (to the point of [publicly asking for some](https://sysadminday.com/) every new year) because it's not _on the front_ of IT.

A smarter move might just be to let those brilliant and hard working professionals take care of _that_, those who have been running the (invisible to the end user) Internet infrastructure for the last decades or so and today most probably work at AWS, Digital Ocean, Netlify and so on. They are the best suited to take care of _that_ anyway, so everybody else can focus on tasks more directly tight to the actual business at hand.

I'm not saying that you absolutely must avoid _old style_ operations involving servers either. I'm just stating that if you're starting a new software project today, adopting one or more servers (because that's what it is going to be: you'll need to nurture them for as long as your business runs) **might not be the best way to go**.

Simply put, today system administration is most probably a skill you don't want to internalize unless it's a core pillar of what you're building.

## Free lunch? Maybe just a cheaper one

> The task of a craftsman is not to generate meaning, but rather to cultivate in himself the skill of discerning the meanings that are already there.
>
> ― Cal Newport, _Deep Work_

Unless you operate in some specific and/or constrained context (or if you're operating at _Netflix_ kind of scale and it might economically make sense to _self host_), today there are simpler and more effective methodologies that help you build and deliver highly performant (and massively scalable) software products without the need to own nor manage any (virtual or otherwise) server.

Even if you are a strong _old school_ advocate or worry about _cloud lock-in_, you should at least agree with me that the benefits (auto-management, built-in autoscaling, reduced attack surface, cheaper bills, faster _Time To Market_... to name just a few) are too many and too appealing for discarding those new trends as _just a buzz_.

_Serverless Computing, Jamstack, Static Site Generators_... today all of those technologies are mature and my opinion is [not mine alone](https://www.wsj.com/articles/nasdaq-cio-sees-serverless-computing-as-a-2020-tech-trend-11579213416): many successful enterprises are adopting them as we speak and at an increasingly faster pace. [A few](https://read.acloud.guru/journey-to-serverless-d3256d91af16) of [those](https://winterwindsoftware.com/real-world-serverless-case-studies/) are [kind](https://thenewstack.io/irobot-confronts-challenges-running-serverless-scale/) enough to openly [discuss](https://www.youtube.com/watch?v=mtZvA7ARepM) about them so we can make better informed decisions when evaluating adoption of those technologies and adapt them to our context.

To embrace the new a small but sensible paradigm shift is needed and letting go of old familiar practices always comes with some friction. In my opinion though there's nothing truly dreadful as you might soon realize by yourself once you break the ice with those (only [relatively new](https://dev.to/shortdiv/what-makes-a-site-jamstack-ib1)) concepts.

## Sir _Chaos_, please have a sit

> I must not fear. Fear is the mind-killer.
>
> ― Frank Herbert, _Dune_

We've been using web services to build our applications for long now. We even survived the global Micro-services invasion that, even though they massively increased the complexity burden on _operations_, forced us to think about our applications more in terms of _fault tolerant, self-contained and independent blocks_, orchestrated by asynchronous communication delivered via remote APIs.

I'm oversimplifying here, but I guess you get the point. AWS Lambda today is only 5 years old, Fargate 2, but if you (try to) keep up with the tech landscape it truly feels like those kind technologies have already become a commodity. In time even _BOFH_ kind of sysadmins are learning how not to worry about it... and even love it.

**Chaos, unpredictability, is not to be feared.**

Maybe it's even your best ally, the one who keeps your edge sharp: _listen to relevant events only, embrace eventual consistency, expect peers unavailability_. These are the new kinds of mantras.

At this point should be obvious that personally I bet the new _dudes and dudettes_ are here to stay, so if you have read so far and you're not thinking yet I'm completely delusional, try to follow me a little longer while I _look forward_ and _keep walking_.

## join(past, present, future)

> “Who are you?” he would ask her every day.
>
> “No one”, she would answer.
>
> ― George R.R. Martin, _A Feast for Crows_

I don't feel there's any discontinuity, neither practical nor ethical (professionally speaking), between _being in operations_ and developing applications following [Jamstack principles](https://jamstack.org/best-practices/).

At this point we've been sharing tools and practices between _devs_ and _ops_ for so long that they're overlapping to the point of fading almost completely. Take this example of a common daily workflow of one of your colleagues:

1. pick an assigned ticket
1. analyze its content in search of meaning
1. identify the relevant repositories and relative file(s)
1. fire up an IDE to edit these files(s)
1. implement the requested functionality in a feature branch enforcing best practices
1. add (unit/E2E/whatever makes sense) tests (move this one up if you prefer)
1. iterate until all tests are green
1. push the patch and wait for code review
1. wait for thumbs up, go back to #2 until done
1. squash/rebase/push the new commit to `master`
1. wait for the CI/CD system to run tests, build artifacts implementing the requested change and deploy them to production
1. keep an eye on telemetry and alerts to ensure everything is fine
1. set the ticket state to _closed_

It might be a bit contrived but it shouldn't be _that far_ from the real thing. Can you tell his/her job title from this list alone? _That_ old fence line has become quite thin, hasn't it?

And it might be a very good thing too. We're left with _only_ engineers working on some task at hand regardless of age or gender or (previous) job titles, everything redundant like labeled hats dropped for good.

## Open _Change_, last revision

> Law 25: Re-Create yourself
>
> ― Robert Greene, _The 48 Laws of Power_

With that said, whether you consider yourself a _dev_ or an _ops_ or just a _wildcard_ engineer, it seems to me that the foundations of software development and operations did not change much from my first days as a junior.

Performance, maintainability, availability, data consistency and confidentiality... all those needs are still with us and relatively unchanged. Some might be new (I might be wrong but for example _accessibility_ didn't feel _that_ important back then), most of them are not.

To sum up with a one-liner, the need to **get the work done** is with us today as much as it was in the past, virtually untouched. Stakeholders needed to _get it done_ then as much as they need it today, they never cared much how fancy were the names filling up the tech stack as long as they were functional in hitting the mark.

## Real Matter

> No fear. No distractions. The ability to let that which does not matter truly slide.
>
> ― Chuck Palahniuk, _Fight Club_

I'm sure some of you grins at the idea of a Perl runtime serving traffic via Apache and CGI today. Try to explain why that's funny to _amazon.com_ or _booking.com_ shareholders, to name just a couple.

Trust me, I don't reject old and battle tested _boring_ technologies at all, quite the opposite.

I work with the terminal every day and I couldn't get anything done without the repeated use of `grep` and Unix pipes. I still love to code in _Python_ even if I feel like everybody else is jumping on _Go_ or _Rust_ or... put your favorite modern language here.

I just say, let's use the best tools at hand today for the job avoiding all that's unnecessary.

Sure, the tech landscape evolved in the meanwhile: tools, frameworks, methodologies got new names and restyling. Practices to better manage complexity evolved along with them but nothing ever truly got rid of it completely.

For each new approach that gave us a step forward in simplicity, soon we got more pressure in the opposite direction, pushed by needs like bigger scales of operations, more integrations, more _delightful_ user experiences, smaller _time to market_... and the list goes on.

Once the two opposed forces have stabilized, new balances emerge making room for bigger amount of business value, delivered faster and to more (hopefully _delighted_) users.

## SQEmpathy injection

> Anyone got time for a [code review](https://devsum-archive.s3.amazonaws.com/dont-git-blame-me.jpeg 'Once you start git-blaming')?
>
> ― anonymous colleague

Most importantly, the need for _empathy_ is also unchanged. We might write in [computer languages](https://abstrusegoose.com/249), but the ones who read and write in those languages all the time are, as far as I know, still _humans_.

Empathy for the end user AND for the developer both should drive our efforts, and if you're reading this article there's a good chance you are one of the latter... so do yourself a favor today and remember to be empathetic to _your future self_ too.

I don't refer to the kind of empathy you might feel for someone recently [_friend-zoned_](https://devsum-archive.s3.amazonaws.com/friendzoned-meme.jpg) but the kind you feel when you see a colleague struggling with something unnecessarily complex.

Care for user experience is an act of empathy. Why should only the _end_ user benefit from it? Software engineers are software users too and have the same right for a good experience.

That's at least what I always tried to keep in mind while trying to write maintainable (Configuration as) Code automation. (If you are a former colleague, trust me when I say I truly hope you didn't have to swear too much when dealing with what I left behind).

I believe that maximizing value delivery to the business should not be the only deciding factor when choosing a technology stack. As the developer tools and practices evolve and become more ergonomic, it's reasonable to wish for adopting _the new_ and leave the old where it belongs.

In the end people make the product so is reasonable to believe happier developers lead to better products.

## _Left_ in the middle. _Down_ to Earth. _Up_ to something?

> There are no two words in the English language more harmful than _good job_.
>
> ― _Whiplash_

So here I find myself today: unable to define _home_ more precisely than _planet Earth_, neither to define a job title any better than an all encompassing [Full Stack Software Engineer](https://cv.l3x.in/ 'My curriculum vitae'), in an evolving polyamory relationship with browser dev tools, APIs, FaaS runtimes and _container_ orchestrators.

In balanced tension between _back_ and _front_, the old and the new, the _boring_ and the _bleeding edge_, the server and the (perceived) absence of it.

In time, who knows, I might finally meet _that_ redhead, the kind who keeps telling "_you know nothing!_" and follow her in yet unexplored wild(lings) territories, leaving all my (techie) legacy behind for good.

Until then I guess I'll keep telling myself the same thing I've been telling myself for the latest 20 or so years: there's never been a better time to _be in IT_.

_Originally published on [Alexander Fortin's tech blog](https://a.l3x.in/)_

## References

I link here some of the media content cited above. The list represents part of what I have read/watched/listened to (either very recently or long ago but still stuck in my head) that inspired me and I find worth recommending:

- the world of __A Song of Ice and Fire__ - <https://awoiaf.westeros.org/index.php/A_Song_of_Ice_and_Fire>
- __Memento__, the movie - <https://www.imdb.com/title/tt0209144/>
- __The Road__, by Cormac McCarthy - <https://www.goodreads.com/book/show/6288.The_Road>
- __Conscious: A Brief Guide to the Fundamental Mystery of the Mind__, by Anita Harris - <https://www.goodreads.com/book/show/41571759-conscious>
- an immortal classic: __Time Enough for Love__, by Robert A. Heinlein - <https://www.goodreads.com/book/show/353.Time_Enough_for_Love>
- __The Culture__ saga, by Iain Banks - <https://www.goodreads.com/series/49118-culture>
- __Mr Robot__, the tv show - <https://www.imdb.com/title/tt4158110/>
- __Subjective Cosmology__ series, by Greg Egan - <https://www.goodreads.com/series/160715-subjective-cosmology>
- __Cowboy Bebop__, in my opinion still the best _anime_ ever made - <https://www.imdb.com/title/tt0213338/>
- the excellent __Deep Work: Rules for Focused Success in a Distracted World__, by Cal Newport - <https://www.goodreads.com/book/show/25744928-deep-work>
- another immortal favorite of mine: __Dune__ saga, by Frank Herbert - <https://www.goodreads.com/series/45935-dune>
- __The 48 Laws of Power__, by Robert Greene - <https://www.goodreads.com/book/show/1303.The_48_Laws_of_Power>
- a modern classic: __Fight Club__, by Chuck Palahniuk - <https://www.goodreads.com/book/show/36236124-fight-club>
- __Whiplash__, the movie - <https://www.imdb.com/title/tt2582802/>