Picture Me Coding
Picture Me Coding is a music podcast about software. Each week your hosts Erik Aker and Mike Mull take on topics in the software world and they are sometimes joined by guests from other fields who arrive with their own burning questions about technology.
Produced by Neiko Will.
Logo and artwork by Jon Whitmire - https://www.whitmirejon.com/
Reach out to us here: podcast@picturemecoding.com
Picture Me Coding
The End of the Fullstack Developer Era
Mike made this argument recently that the era of the full stack developer is over. The so-called stacks are still around, but they're now surrounded by so much infrastructure and supporting technology that claiming to be full-stack is misleading. Mike wrote a whole essay about this, in fact, which you can read over here.
This week, we talked about his idea that fullstack engineering is going away, and we included commentary from an essay called "The Myth of the Fullstack Developer" as well as a mastodon post by Daniel Stenberg that Erik mentioned.
Finally, we closed with a discussion of a related article, "HTML, CSS and our vanishing industry entry points" by Rachel Andrew.
[MUSIC] >> Hello, welcome to Picture Me Coding with Erik Aker and Mike Mull.
Hi, Mike.
Nice to see you again.
>> Hey there.
>> Mike, it's now summer and I have maybe a personal failing, which is that every summer I am transported back mentally to the summers I spent in Hawaii with my grandmother.
I would spend a month in Hawaii with her and people in our family and our family friends, all summer long, would listen to a style of music they called Island Music.
The rest of the world seems to call this music reggae and every summer I listen to, I find myself listening to.
It's not a purposeful thing.
It's like this hole that I fall into.
>> It's not just all ukulele?
>> No, it's not all ukulele, not all slight key guitar.
There's that too, Island Music.
It just seems to happen to me.
It's like a thing that happens.
It's not intentional.
Anyway, I discovered that happened again this summer when last week I found I was listening to this Protege album In Search of Zion.
Protege's album came out last year.
He was busy last year.
He wrote a children's book called Here Comes the Morning too.
I really liked his record, Ancient Future, came out in 2015.
I couldn't call myself a committed and knowledgeable fan of reggae and dancehall, but I find that I get sucked into certain records and then I listen to them for a long time afterwards.
And Ancient Future was like that.
So I started listening to this album in search of Zion.
It's pretty good.
I like about half of it.
But now here we are in summer and I'm listening to Island Music again, not on purpose, just a thing that happens to me.
>> I will have to check that out.
I have to confess that is something I have essentially no experience with knowledge of.
>> What are you listening to lately?
>> So my choice this week is a little bit kind of meta.
So it's not a particular piece of music.
There's a guy named Evan Goldfein and he's doing this project this year called A Year of Bach.
It's kind of a blog thing, but he sends out an email about once a week or so with stuff that he's been listening to.
And he's kind of trying to go through, you know, a substantial fraction of Bach's massive catalog.
So it varies quite a bit.
Some of it I really like, some of it has been a little bit too weird for me, but -- >> Too weird?
Bach?
>> Too weird.
>> There was one album that was pieces on a mean-tempered harpsichord.
I don't know.
It doesn't -- it sounds like the harpsichord is in a bad mood, but it apparently has something to do with the tuning.
And about half the pieces in there sound like they are out of tune to somebody in the 21st century.
>> It's kind of like Alice Coltrane does Bach or something like that.
>> Yeah, it's interesting intellectually, but that's something I would probably listen to.
There was one album, though, that was harpsichord and violin pieces.
It's just really beautiful that I've been listening to a lot.
So anyway, I recommend it.
If you search for Evan Goldstein, you'll probably find this project, and you can subscribe to the emails that he sends out on a periodic basis if you're a Bach nerd.
And he makes links to Spotify and iTunes and Bandcamp, I think.
So it's a worthwhile thing if you're a Bach nerd.
>> I hope you're not going to hate this comment, but I am not a Bach nerd, and I don't think he sold me on it just then.
Seeking out this Evan Goldstein year-Bach thing.
>> Well, it's definitely something for Bach lovers, not sort of an introduction to Bach sort of thing.
>> I kind of like coffee shop Bach.
That's my thing.
Going to the coffee shop is playing in the background.
That's my depths of affection for that music.
>> Yeah, I'm cool with that.
I'm a little bit of a fan of the music, but I'm not a fan of the music.
I'm a fan of the music, but I'm not a fan of the music.
I'm a fan of the music.
>> Half.
>> I like imagining these beautiful Venn diagrams.
You wrote a blog post recently that I read.
I thought it was good.
Maybe it sounds self-serving, but you're like, "Oh, my co-host wrote this great blog post."
But I read it as if I could speak objectively about it.
I thought, "Wow, this is pretty good."
I want to characterize your argument because I wanted to talk more about this this week.
I'm going to try to characterize your argument.
I want you to tell me a little bit about where this perspective comes from.
You can tell me if my characterization is right.
What I get from your post, it's called the end of full stack.
The era of the full stack developers over is what you're saying.
You're saying there's stacks still around, but there's so much stuff around them, infrastructure and technology, that you can't claim to be full stack.
If you claim that, it's really just misleading.
You have to either accept that there's stuff that exists around you that helps you, so you don't need to have deep knowledge of those areas.
So infrastructure is code and observability.
You've got a platform that does stuff for you.
You're really arguing that our ability to say that there is a thing called a full stack developer has eroded to such a degree that it's now just completely misleading to use that term.
How am I doing?
Did I care?
I thought this was provocative, but maybe I'm mischaracterizing what you're saying.
No, that's a pretty good summary.
I myself have not clear if this is a particularly hot take or if it's just something that everybody agrees on now.
But I guess what sort of prompted this is two things.
One is if you look at, I spend a lot of time on LinkedIn these days, and it's not because I'm necessarily looking for jobs, it's because I'm kind of looking for what the industry is doing.
And if you look at the scope of jobs that are being offered, there's still a huge number of full stack engineer, full stack developer job ads.
So that's one thing.
And then the other thing is I've been doing some work with GPUs and deep learning in particular running on GPUs.
And I sort of came to this conclusion that not only are things getting so specialized, but there's a sense in which you, like when I started out working in this industry, it was kind of the desktop computer era.
You could do the same programming at home on your desktop that people were doing in a commercial environment more or less.
And now there's situations where if you want to do certain types of work, you really can't do it from home.
You have to use a cloud provider or you have to work for a particular company.
And so there's the sort of generalist hacker that I could have been 35 years ago.
It just isn't really a thing anymore.
So you started doing Windows stuff and working with Java in the early 2000s, but you did web stuff early on too, right?
Yeah, I guess it depends on how you web.
I had exposure to the web in the 90s and I was around at the beginning of the Java applet era and stuff like that.
And did some CGI bin stuff in the 90s.
But there was this period in the early 2000s where I was doing mostly Windows stuff and a little bit of client server Java work up until, I don't know, 2003 or so.
And so didn't really think of myself as a web application programmer.
And then soon after that, I started working for a company that did, it was just like a streaming music service.
And so, you know, I was officially in the web world then, but I was doing mostly backend stuff because, you know, my area was music recommendations.
And when that company was bought by a large internet company, stuck around there for a few years and then one of my good friends, he went off to this ad tech company and he said, "Hey, you should apply here."
So I said, "Okay, I'll give it a shot."
And they sort of gave me this take on problem to do.
And it was a totally front end project.
Wow.
They looked at your resume and they said, "Wow, this guy's done Windows, Java, music recommendations.
Let's have him do a front end web project as a take home project."
Yeah, it was surprising to me and also I just had no idea what I was doing.
Wait, wait, wait, wait, can we put a pause in?
What was the, about what years would this have been?
Because I want to guess what the front end web would have been like at that time.
It was probably at this point late 2006, early 2007.
Oh, geez, I was going to say, I thought you were going to be like 2008, 2009.
I was thinking jQuery, maybe Backbone.
When did Backbone start?
Backbone 2011, one of the first JavaScript, oh no, there were earlier frameworks.
Geez, I can't even remember their names now.
Yeah, I know my friend used Mootools.
That's right.
And there was one that started with a why.
What was it called?
I can't even remember what it was called.
Yeah, yeah, I'd have to search the archives.
Okay, sorry, I interrupted you.
So they gave you this take home project to do a front end web stuff.
This is like 2006.
What did they want you to do?
Do you remember?
I don't remember the particulars of it, but it was just sort of basically to verify that you, you knew the front end.
And at that point, front end was starting to mean Ajaxy stuff.
And not XHR requests.
Yeah, not just HTML and request response type of stuff, but Ajaxy.
And I just had no clue.
So I did this Ajaxy thing like pure JavaScript.
And it was a train wreck.
And they just said, "And get that job."
But that kind of put me in that path.
And I started to learn that stuff and got relatively competent with the jQuery by 2008 or so.
JQuery was hot at that time. 2009, 2010, it was a big deal.
Yeah.
Way to target all kinds of weird browsers, different browser stacks at the time were a nightmare to deal with.
Yeah, I really like jQuery.
I was perfectly happy with that.
And I don't know, anyway, there was a period there for probably four or five years where I was using, I would have called myself a full stack developer.
And I was doing what I considered to be full stack work.
Well, AngularJS would have been what, 2011, 2012, I think is when it came out.
Did you go to that from jQuery?
Did you use it like a backbone or AngularJS?
Yeah, there was one place where I used backbone.
And it was around that time where I started to realize these front end frameworks are getting complicated enough that it's really difficult to be an expert in both front end and back end.
So, especially when I, from 2009 to 2013 or so, I was using mostly Django.
And when you're using Django, you can feel like you're a full stack person regardless of how competent you are on the JavaScript side.
Or even the Python side, not to disk Django developers, but you could write a lot of Django without thinking too Python-y if you want.
Yeah, fair enough.
But yeah, once people started doing Angular, it just felt like there was no a front end specialty and a back end specialty.
And I was probably going to fear toward the back end.
So, at this point, I would consider myself to be pretty exclusively back end and would feel a little bit awkward about advertising myself as a full stack guy.
From your essay, you wrote this line that I thought was interesting.
And you, you know, from your personal story, you're saying in your own case, it was over 10 years ago where you stopped thinking of yourself as a full stack guy.
And in your essay you're talking now, 2024, my thinking has evolved on this topic.
I now believe that it's no longer really possible to be a full stack developer, even though there are dozens of organizations promising to train people to become one.
And hundreds of job ads seeking to hire one.
So you're not just saying for myself, I don't want to claim this, you're saying for other people, it's not quite fraudulent, but not quite accurate way of portraying yourself.
It cannot be is what you're saying.
Yeah, I mean, I don't deny that there are still people who do front end and back end work semi-competently.
I mean, you're one of them, obviously.
I don't know.
I was going to, all right, well, sleep me out of it for now.
But, you know, I think when people started looking at full stack developers or, you know, started that as sort of an idea of a job title.
You know, I liked it from my personal experience being sort of a generalist and somebody who is self taught.
I really like the idea of being able to do a little bit of everything to make this entire application.
And I confess that there are still people who have skills on the front end and skills on the back end and maybe some database knowledge and so forth.
But I also think at this point, you know, that's not really all that relevant because it just means that you are slightly less specialized than the other specialized people working on a particular project.
So you really can't be expert in all things is I think what you're implying.
You brought to me this essay called The Myth of the Full Stack Developer.
And I thought it was similar to what you're saying here.
Like, you liked being able to call yourself a full stack developer.
There was this empowerment in that.
I can bootstrap a complete app entirely independently.
I don't need anybody's help.
I can build the entire thing front end, back end.
I can get it out there in the world.
And that was exactly what we did in, you know, 2009.
You know, you could sit down, write the back end, write some front end code, deploy that to a Linux server and, you know, make it available to the outside world all as a single individual.
And there's a feeling of empowerment.
I just mentioned about that.
Like, wow, I can do everything.
I don't necessarily need anybody else.
I'll start from scratch and I'll have a working complete thing.
In this essay, The Myth of the Full Stack Developer from Code Motion, the line I liked was, "Over time I realized that the allure of this definition, Full Stack Developer, has captured the hearts of many people mainly due to a common belief.
Being full stack means being a complete programmer.
And for companies, hiring a full stack developer represents added value.
Is that what it means being complete?
You are a complete developer and you provide value to a company in that way?
I totally agree with the idea that that's the allure of it.
And I think that was, you know, the intention in the early days was that you could do essentially everything and that made you both a better rounded programmer and somebody that was valuable to companies because they could hire one person.
Or they could hire multiple people with those skills and those people could trade around on the things they were working on so there was no, you could put them on different projects and they would still bring different skills to that project.
There's a few things underneath what we're saying here.
You're sort of arguing that stuff has gotten more complex in the last 10, 15 years.
It's gotten so complex, in fact, that you can't just accurately declare that you are full stack.
This is similar to what shows up in this essay.
The term is now too inflated.
This author writes and when written on the resume of a junior programmer, it adds no value.
So we like the idea of being full stack.
It's this empowerment, this empowering feeling that we have about our ability to bootstrap and build apps from scratch.
There was this era, maybe 15, 20 years of the developer, the software engineer as a kind of almost like a hero of our culture.
They can appear and spawn businesses and software spontaneously from their brains and suddenly they've got a company and that allure, that heroism or whatever, like that myth maybe, it seems to be fading.
It's lost its sheen in the last couple of years, but it also could be that you and I, and I can't put myself in your category, we've been around long enough that we know there's a lot of stuff we don't know.
Maybe that's what's going on here.
Once you've been around long enough, you start to see, oh, I don't know all these things.
I will say this, when I think about starting projects now, I think about front end and back end.
If they're my own projects or projects for friends or family, I think to myself, geez, I don't have a lot of time.
How can I reduce to almost zero the amount of effort I'm putting into one component on this project?
And I do think, wow, if I'm going to work on a real front end, a full front end for this, it's going to be a huge amount of effort and a full back end for this huge amount of effort.
Let me just sort of tamp it down to virtually nothing.
To be fair, I think that even at the time when this term was developed, it was probably a little bit misleading to say that one person could do everything.
I mean, a lot of the companies that I worked for at that time did have systems people.
I rarely had to spin up my own databases, for example.
The network connections to the outside world were established by other people.
I guess my take now is that if you do some front end and you do some back end and you maybe know a little bit of database, perhaps that is valuable, but it's ignoring DevOps.
It's ignoring CI/CD pipelines.
It's ignoring observability.
There's just so much that's going on around the applications.
It's either done by a specialist or is done by the platform for you that I think the term is either not that useful or potentially like the guys implying on the code motion essay.
It's maybe a little bit laughable if you see it on certain people's resumes.
Yes, I guess we should try to define it a little more strictly.
When I think of full stack, the abstract areas of knowledge that I'll leave to mind are databases and maybe your question as I start reeling these off is, well, but how much knowledge?
So databases and how deep deploying code and again how deep back end HTTP web service stuff and front end.
And that back end HTTP web service stuff can also be applied to maybe data engineering, but we're just talking full stack and full stack is probably client server applications mostly deployed by a web today.
Databases, deployments back end, front end.
Is there anything I'm missing that you would want to include if somebody were really going to be a complete full stack developer?
Do you mean now or in the- I mean right now, 2024.
Is there any other piece of knowledge somebody would need that is not covered by these abstract categories databases, deploying code?
Maybe I'm lumping infrastructure in there.
You use this as a ability.
I'd put that in there.
Database is deploying back end and front end.
There's nothing else, right?
I think it depends a little bit on what you mean by deploying.
There was a time when for me working in say a startup company deploying something meant that I would have to spin up my own machines and my own databases and- And you're going to go in like slash etsy on Linux and do a bunch of junk.
That's what you're talking about.
Like you're going to write config files and stuff.
Potentially or you know at least you know write something to what's that AWS language that everybody hates.
CloudFormation.
Sorry if you love it.
I think we're getting good at offending at least one person every episode now.
Wait, wait, wait.
So my contention is you seized on deployment, which is fair.
I don't disagree with what you said.
My contention is you could do that on any of these categories.
You said it depends on what you mean by deployments.
And I think you could say it depends on what you mean by X where X is databases or X is back end or X is front end.
All of those topics.
Yeah, that's fair.
I mean databases in particular.
Yes.
When I started doing web programming, I came to that with far, far more extensive database experience than most web programmers do.
So I was already, I would say I was pretty close to expert with SQL by the time I started doing that.
And I could spin up my own, you know, MySQL instance or whatever.
I'd been working with Postgres since the late 90s, which probably makes me something of a rarity.
But so yeah.
And but I've worked with people who are full stack developers who really were relying on say the ORM and Django to do the database side of stuff.
Well, I mean, you said, oh, and you're a full stack developer talking to me and I'm thinking well, but my database knowledge is like, I can look at a database and I can look at some inefficient queries.
And go, oh, we should add some indexes here, but I'm not really going to write these Postgres SQL CTE file.
I mean, I could look up syntax, you know, like I look at the data engineering interview process that a buddy of ours, who we work with, he sometimes will talk about.
And I think, wow, I would get 20% of these questions right 30% of these questions right.
I know enough database stuff to be able to optimize it roughly for a web application.
I know how to look up the things I don't know.
I would not call myself an expert on databases.
Yeah.
And I think that's typical of all full stack developers.
Well, most I'm sure there are people who have deep expertise in all the levels, but I think it's always been the case that people were much better at certain layers than other other layers.
So what's the likelihood that someone could truly be an expert in each of these categories?
It's probably pretty low likelihood.
Would you agree with that?
I guess maybe a different way to say it is what would it take to claim expertise in each thing?
You just said I'm pretty expert or I was in databases.
So for me, if you can go from nothing to a deployed web application, you can probably legitimately call yourself a full stack developer still.
I think there's obviously many more ways to do that than there were 15 years ago.
And it depends on your volume too, right?
If you've got very low traffic versus very massive traffic, the problem set is different.
That's a whole other specialty now, dealing with auto scaling and streaming and things that are necessary for scale.
But yeah, I mean, if you can go into a place and they want a web app that lets people register themselves on your website, and you can start with nothing and put that on the public internet, you can probably call yourself a full stack developer.
But even that now, we've talked recently about this Cloudflare dev platform and how nice it is in terms of being able to do a lot of stuff for you.
Cloudflare pages, maybe what you're referring to?
Cloudflare workers for serverless stuff on the edge.
Yeah, we've both recently, you introduced me to it and we've both recently deployed stuff using that, which for all practical purposes, you could call web applications.
They're not super sophisticated, but they look good and they're deployed to the outside world.
But there's so much there that the platform was doing for me.
I didn't have to get a certificate to use HTTPS.
I just basically pointed the platform at my GitHub repo and it did most of the deployment for me.
So I technically deployed a web app, but would that be considered a full stack developer effort?
I don't know.
It seems to me like a lot of shortcuts happen there.
Yeah, I think in a whole field of deploying code, there's cloud specialization and that's an extremely deep topic.
So can you imagine just hiring somebody who says, "Well, yes, I'm an expert on just cloud A or cloud B or multiple clouds?"
Those people definitely exist, but that's a kind of rarefied scale as well.
And as the way in which we deployed has changed, the knowledge required has changed.
It used to be AWS, we had auto scaling groups, we had load balancers, we had ALB and ELB, and then we had a bunch of virtual machines and we would kind of scale up or scale down and we would figure out how to get our code mushed onto those servers in some way and some reliable way.
Hopefully this is where you had the Ansible and the Salt Stack and the Puppets and the Chefs and stuff like that.
And then now you've got a lot of serverless deployments and you've got a lot of Kubernetes deployments.
So Kubernetes is a whole specialization in itself.
And incumbent upon someone who's going into this is broader knowledge about what's my network segmentation and things like DNS, right?
I mean, that's a lot of knowledge that someone would potentially have to claim expertise on to be a full stack developer.
Not only just building like Docker images and configuring Linux machines anymore, which is great knowledge to have too, but the amount of things in just the stack of "I'm deploying code" is massive.
And then you've got third-party services, you've got log aggregation, you've got observability.
Very, very large field today.
Yeah, I think one thing that is maybe not obvious to people now is that when the cloud stuff was new, there were not things like RDS or managed databases.
There was no Docker.
Well, I guess Docker was maybe...
No, I guess 2008, 2009, I was still pretty Docker.
So the way people did cloud in the early days was you were basically spinning up virtual machines of various sizes.
And they were just plain vanilla virtual machines and then you would install your own software on them.
And so it was really not radically different than putting things in a co-low center or having a rack of servers in your building.
So that whole world has changed so dramatically over the last 10 or 15 years that it's almost a different field than it was then.
Yeah, I agree with you.
So I started with these four categories, databases, deployment, front-end, back-end, and we already muddied the water quite a bit.
Just for databases and deploying.
If we just leave those aside, what if we just talk about just web, back-end, and web front-end?
Is it possible to be expert on these today?
I saw a post from Daniel Stenberg, the creative curl this week.
He was talking on mastodon about HTTP, HTTP protocol.
And he wrote on mastodon, this is his post.
"On this day 10 years ago, we lost our innocence as the former single-page HTTP 1.1 spec RFC 2616 exploded," he writes in quotes.
"Into six separate new documents, RFC 7230 and family.
We could then no longer pretend HTTP was a simple protocol."
So he's talking about 2014, they exploded the HTTP 1.1 spec into six separate new documents.
He says, "Two years ago, in June 2022, it was again updated, RFC 9110 and family.
The spec is now split up into five main documents, semantics, caching, and separate specs for each version 1.1, 2, 3."
Daniel Stenberg in this post, the last sentence he concludes with is, "Those five documents hold 143,000 words combined.
HTTP is not easy."
Yeah, yeah, when you have to be a specialist in HTTP, just to understand what's going on, it's hard to argue that you have deep knowledge of all the layers of the stack.
I guess it's one of those things where you sort of have to decide where the level is that you have to understand.
In the real world, do you have to know quantum mechanics to understand why grass is green?
I don't know.
Is there quantum mechanics involved in why grass is green?
Probably, I don't know.
I don't have a clue.
It is, but do you really need to know that?
That goes back to the question of how far do you need to know in this thing to be expert enough to call yourself a full stack engineer?
I tend to trust Daniel Stenberg.
He's got a reasonable voice, creative curl, one of the most successful open source projects in the history of software, open source software.
And here he is saying, "HTTP is not easy, and I trust him when he says that."
Now, knowing HTP is a protocol with which we tend to communicate in front-end and back-end projects, tend to always.
Is it impossible to be expert in just front-end and back-end?
Yeah, I honestly don't think it is anymore.
People may claim that.
So, you know, this is a story about me, so maybe I'm just not as clever as I used to be.
But I've been focusing on back-end stuff now for at least close to a decade, I guess.
You know, I consider myself to be pretty competent with multiple types of database systems.
I consider myself to be at least surface level, competent and distributed systems.
I know I've used all three major cloud services.
I understand bits and pieces of them.
But I've deployed, I've done, I don't know, probably two dozen APIs for various things now.
If somebody came to me tomorrow and said, "I need a GraphQL API," I would have to go look it up and study that and figure out how it works.
I've never done a GraphQL.
You know, even with focus on back-end for 10 years, I've never done a GraphQL.
I've only done WebSockets one time.
So, there's just, even if you're, even calling yourself a back-end specialist is a very difficult thing to do now.
You almost have to be like a particular type of back-end specialist.
I wouldn't, I would bet that you could spin up a GraphQL service pretty quickly though.
I'd give you a week and I bet you could do it.
But then by the end of the week, you'd be like, "Are you sure you want this?
I don't think you really want this."
The reason that came to mind is I was just looking at a diagram of Netflix's architecture and apparently they are GraphQL-based.
So, I should probably know that.
When I look at these domains now, front-end, back-end, I think, what would be the knowledge I would expect someone who's a front-end, back-end specialist.
We'll call them full-stack for the purposes of this conversation.
Front-end's all async, JavaScript, maybe TypeScript.
A lot of state-based problems.
So, we're dealing with async state.
That's already massively complex.
And then you're rendering things.
You've got this user interface, which usually involves display and some aesthetic decisions.
Often we use CSS on the web.
I'm typically using CSS on the web.
And then you've got this massive, infinite, bizarre of the JavaScript ecosystem.
And this is a lame comment, but I look at JavaScript projects today and I look at them.
I'm like, "Wow, they sure need a lot of files to just deploy this one project."
Like two dozen files, or three dozen files on the root directory of a JavaScript project.
It's like, "Wow, that's a lot of files!"
It's linting and configuring, formatting, and then you've got your test configuration.
And maybe you have this in other projects, too.
You compare this to back-end, and back-end may be async, but it may also be sync.
And a lot of the back-end knowledge seems to be when and how do I connect to other things.
Like, when do I use Postgres SQL?
When do I use a cache database or a search server or things like that?
When do I use a document datastore?
I've also need to inject configuration and secrets management into my back-end service.
Maybe I'm dealing with my logs and log aggregation.
And maybe, like you said, observability.
Maybe that's part of the knowledge, too.
Maybe a little bit.
Maybe not as much as we were saying before, but a little bit about deployment.
I don't need to be able to configure segmented networks in the cloud.
But I need to be able to package my software up so that it can be deployed somewhere.
So, I guess we could probably agree, companies, when they're asking for full stack developers, they're not looking for experts in these things.
But I guess the question then becomes, "Well, what are they seeking?"
And your question is, "Why?
Why are there so many LinkedIn results?"
I guess I would argue, if a company advertises a full stack developer role, I want to know, "What are they building?"
A lot of times, it's web stuff.
And really, what they probably want implicitly is, "Can you contribute to our React projects?"
And "Can you contribute to whatever we're doing on the back-end?"
And that feels quite a lot narrower than saying full stack developer.
My take is that companies are still sort of seeking with two things.
One is, I think some companies just want to hire as few people as possible.
And they think that by hiring somebody who can work on all levels of the stack, they need fewer people.
I think that's a complete miscomprehension of what the idea is behind full stack.
You were saying there's a pointy-headed manager business decision, which is like, "Hey, this would be a lot cheaper if we just hired fewer people.
Let's find someone who can do everything and we'll put them to do everything."
What if I told you, "Hey, there's a software engineering team in this org," and that software engineering team decided they wanted to hire a full stack engineer to help them with their projects?
Does that change what you're doing?
Is it a little less cynical maybe?
So the other reason why I think companies, even engineering managers who are hiring people sort of like the idea of full stack developers is because, and this is cynical, I admit, is because they are somewhat fungible, meaning if they don't work out on one project, you can put them on another.
But also, if you hire somebody who's a deep distributed systems back-end specialist and they turn out to be crucial to your project, you can't really go out and hire another one of those easily.
So I think people like this idea of people who can be replaced easily with another person of the same skill set.
People are fungible.
Wow, this is a very business-y, non-sexy way to talk about the people you work with, who we hire and our organizations.
I think going back to your point about you didn't believe at the time, 10 years ago, that you could call yourself full stack.
Now you don't believe it's really possible for people to call themselves full stack.
Implicit in what you're saying, the inference I'm drawing here is, these fields that we've identified, they never seem to get simpler, do they?
They will sometimes reinvent stuff that has existed in the past, our industry is famous for doing that, but overall, any particular area of knowledge only seems to get more complicated over time.
So for example, if I find someone, I give them a time machine, and maybe it's six years ago and they know React, I bring them forward six years in time, are they still going to be an expert in front-end software dev today?
It's like that area of knowledge is a pool of water that just gets deeper and deeper and deeper.
And knowing that, how could anybody possibly be a full stack engineer?
The amount of stuff you'd have to continually, perpetually learn, the depth of that pool of water, as it gets deeper and deeper and deeper, that you have to plumb the depths of, it just seems impossible.
You wrote on your blog post specialization as the norm now, and the specialties get more narrow every year.
Is that really what's happening?
Stuff is never going to get simpler, is it?
That's my belief, yeah.
I think a good example lately is that we've had data scientists and data engineers now for, what, ten years.
It's been a recognized title for quite a while now.
And a data engineer is typically somebody who is a software engineer with some connection to data science, knows the operation of things like Scikit-le or PyGeorge or things like that.
Knows not to judge those data scientists for once again, not submitting any tests with their code.
Okay, that's fine, I'll do it for you.
That's how I think of the data engineer.
You built your model in a Jupiter notebook.
Oh boy.
Great, I will operationalize that for you once again.
Yeah, exactly.
So now we have LLMs and we have people working on applications that call LLMs, and the field has already decided that data engineers and data scientists are not specialized enough to do those things.
So now there's this emerging field of AI engineering.
There's people who are calling themselves prompt engineers, that kind of thing.
And I just, it's possible that maybe the AIs get so sophisticated that they eliminate a lot of these sub-specialties, but my feeling is that it's very, very difficult now to even be broadly a back-end engineer or a front-end engineer.
You just, I don't know too much about front-end stuff anymore, but it seems like it would be hard to be expert in all of the technologies that go into building a front-end.
Like, for instance, we have you, we have design and UX specialists in a lot of companies now.
So even if you are competent with the frameworks, you may not be the person doing the visual layout and the human interaction stuff on that site.
I want to come back to a post that you shared with me.
It was written in 2019 by Rachel Andrews.
Rachel Andrews, sorry.
Rachel Andrews works at Google, and she's a technical writer there.
She does content.
She's a lead on content for Web Dev and developer Chrome.com.
There's a person who's been doing web development since the mid-90s.
It's a person who's an expert on CSS.
I think I can say that, an expert on CSS.
I am not an expert on CSS.
She starts this post in a way I really liked.
Everyone is angry about CSS.
Again, she writes, which is just like, there's so much in there already.
And maybe we could talk just briefly, like just a little bit of context.
Software engineers, people like us often complain about CSS.
I often don't like trying to get the box to be in the middle of the damn page.
We get real mad about that.
Anyway, that's probably what she's talking about.
But she continues, "I'm not even going to try to summarize the arguments.
However, it always seems to boil down to the fact that CSS is simultaneously too easy to bother with, yet so hard.
It needs to be wrapped up in a ball of JavaScript in case it scares the horses."
I just love this paragraph.
Yeah, it's like, I always got so annoyed when I got asked to do CSS just to get so frustrated and I couldn't do it really confidently.
I suck at it.
I still suck at it.
I just do enough to get it close to what I want and then I walk away.
I am not an expert in it.
And I have used these tools that use JavaScript to bundle it all together.
I don't even know what they're doing below the surface and I don't care.
And in a way, she's right.
She's critical of this type of move.
So, you're treating it as like a ball of radioactive waste.
There's a phenomenon that happens with CSS and I think it's true of technologies broadly where you have these things and they seem kind of messy and complicated and so you build a thing around them.
Yeah.
Like, so for instance, I've been using Tailwind recently and I like Tailwind and it makes life simpler in a lot of respects.
But the thing about Tailwind, I don't feel like I am thereby exonerated from ever learning anything about CSS.
So, it's not a replacement for CSS.
It's sort of a simplifier for CSS.
Well, you gave the example of an ORM earlier.
Yeah, an ORM is fitting to-- Exactly.
The same thing I was thinking is that an ORM is something that basically takes away the necessity to think too much about writing SQL and making tables and worrying about fields and-- It puts those sweet little rubber buffers on the edges of all the furniture.
So, you can't bonk your head on it that easily.
Right.
With a consequence that you get a 90% solution and then there's this 10% of stuff that doesn't work and you have to go learn the details of SQL and databases and indexes and all that stuff.
And I think it's the same with something like Tailwind is that, you know, it's a 90% solution but it kind of obscures the 10% that you're going to eventually have to know to make things actually work.
I'm sure there's a name for this phenomenon.
But yeah, I like what she's saying here and I think it's kind of what made me think of this topic.
You know, there was a time when 40 years ago when I started messing around with computers, you could do almost anything on your desktop computer that people could do with, you know, the computer at their company.
It was, you know, probably a smaller scale.
But like, I was doing scientific computing on a desktop computer 40 years ago and it was slow and not as, I couldn't do the scale that you would do on a department computer or a ZIPR computer obviously.
But now if you look at, if you want to buy a computer with a desktop computer with this consumer grade GPU, you're looking at more than $5,000.
If you're looking at doing GPU stuff in the cloud, you're looking at anywhere from 50 cents to $5 an hour to rent time on those machines and it just feels like she's saying in the essays, there's certain fields now where there's really no entry point if you are a beginner.
Yeah, exactly.
I wanted to get to her conclusion.
I have to say, I feel like she levels this charge about it's too easy to bother with but so hard that we got a bundle inside JavaScript so it doesn't scare the horses.
I love that line, but I read that and I think, "Ooh, you got me.
Guilty as charged."
There are areas of knowledge which I am not that interested in, but I do not want to commit the sin of looking at people who are interested in that and sort of waving my hand and being like, "Their knowledge is not valuable or not complex or not difficult."
I've seen this with backend developers who are backend specialists.
They look at the front and they go, "Ugh, that's just whatever."
And they kind of dismiss it or hand wave it away.
This stuff is not freaking easy.
Otherwise, it'd be so easy that I could just not have to even learn it, right?
What I want is someone to wrap up this thing I don't want to get close to in a very easy box and I just shoved the key in that they gave me and I opened the lock and magic pours out of it.
And I don't have to learn it.
I don't have to do very much.
There are areas of knowledge that that's the experience that I want.
And although the promise is that regularly, we talked earlier about building things to pad other things, the reality is you still usually need to know.
So I want a nice safe package to not have to do things I don't want to do, but the promise never is realized for that safe package.
I just think it goes back to the point that she's making is that it does connect to our original premise, which is that it's very difficult to be a full-stack person now.
But I think part of that is because as she's implying here, you could sit down and still write a web app that is just HTML and just plain request response.
All that would still work.
See the rise of something like HTMLX, which is trying to make it simpler for people who don't want to commit to JavaScript frameworks.
But that is not what people consider to be professional programming anymore.
It's a useful pedagogical experience, but it's not what's really happening in the software engineering world right now.
So before we throw away entirely this term full-stack developer, I want to close with Rachel Andrews comment at the end of her essay.
This is what she ends with.
I think I want to give her the last word here.
She writes, "I might be the 'old guard,' but if you think I'm incapable of learning React or another framework and I'm defending my way of working because of this, please get over yourself."
However, 22-year-old me would have looked at those things and run away.
If we make it so that you have to understand programming to even start, and an aside here for me is she's saying start in web development, then we take something open and enabling and place it back in the hands of those who are already privileged.
I have plenty of fight left in me to stand up against that.
I felt like almost an accusation as I read this essay, but I like the essay.
One is, here you are again, you're hand-waving away things like CSS.
You could just learn it and then you wouldn't have to be scared of it.
The other is, traditionally, web dev has been pretty egalitarian.
You can show up and contribute.
Yeah, we've talked about how much expertise you need to be able to be an expert in those things now, and obviously that's pretty vast, but for many, many years, decades, people can show up, they can learn a little bit of these things, HTML, CSS, JavaScript, maybe another language for the back end, and already that sounds like a lot of nulls, but you could do that in a relatively short amount of time and then you could bootstrap yourself into an application.
And Rachel Andrew here is saying, we're shutting the door a little bit by maybe making the knowledge required so massive just to get started.
She's saying we're losing something by just dismissing this idea of the full stack developer.
What do you think?
I agree.
I think one thing I would say to sort of clarify my original point was that I'm not happy about the end of the full stack developer.
I was a hacker from the beginning.
I did not go through computer science curricula.
I was in college, they really weren't undergraduate computer science curricula.
So I am largely self-taught and I think it would be much, much harder for a person to do that in general now.
Everybody has a computer now.
Every 12-year-old has a laptop, but I think it would be much harder to sit down and write useful applications on that laptop than it was 40 years ago when I had a cheap desktop.
And I think that's sad.
I agree with her premise is I think it should be, I think it would be nice if people have the ability to write applications and really sort of understand how that computer works to not just, you know, you always see people trying to write languages or low-code applications that let people do things in a more simplified way.
Which is fine, but I would also like people to have the ability to do programming in the same way that real programmers do programming on their computers, which I don't know if people can do that anymore.
And the history of these areas of knowledge getting further and further specialized doesn't indicate to me that it's going to be, the arrow doesn't point towards simplification.
So maybe you're right.
Maybe people can do that.
And there's not a lot of hope that they will be able to in the future either.
Yeah, maybe quantum computers will replace everything in another decade and you'll have to be a full-stack quantum developer then.
Or the AI promise.
I'll just be, I'll have my own specialization and everything I don't want to do.
Well, the AI thing will do that for me.
All right, this has been another episode of Picture Me Coding with Eric Aker and Mike Mall.
Mike, thanks for bringing this topic up, talking to me about it this week.
You're welcome.
We will see you again next week, my friend.
Hope so.
Bye-bye.
[Music]