It’s my experience that the above MVFE is pretty uncommon. The profile describes a person with skills requiring thousands of hours to master, but who doesn’t take part in the holistic decision making process. By nature, the value of a fullstack engineer stems from their ability to make competent unilateral decisions (decisions without asking anyone for permission). I’m sure there are people who mostly fit the MVFE, but I wager that they are few and far between. You could probably summarize my view about the MVFE as:
It’s very impractical to become a fullstack engineer without understanding the big picture.
In my mind, a fullstack engineer’s value is mostly derived from their ability to single-handedly design, architect, execute, and operate an entire end-to-end system. Assuming this is possible, it almost completely eliminates integration overhead.
Source: IMHO: The Mythical Fullstack Engineer – Stack Overflow Blog
There’s a lot of subjectivity in this article, but I think it covers the topic pretty well. I consider myself a full-stack engineer, and that self-identification hinges on both emphasized points above. First, I’ve spent the time to learn all the pieces. Other people don’t see all the late nights, banging away on my home lab, or my church’s setup, forcing things to work when they didn’t want to, integrating pieces all over the stack, setting up solutions to help people get things done, or just to scratch an inquisitive itch.
For instance, I’ve run my own web server on a public address. This will cause you realize how hairy the raw, unfiltered internet is, and will force you to learn about the basics of hardening a server and firewalling a network connection in a New York minute. I’ve run my own email server. That will teach you about spam, attachments, white and blacklists, abuse addresses, and lots of stuff about making your server look legit to other servers. I’ve run a Windows domain for my whole family’s computers, with roaming profiles and everything. (Side note: do NOT use roaming profiles.) I’ve run my own personal cloud. My own mobile sync server. Media servers. TV recorders. The list goes on.
In my professional career, I’ve gotten to work on some of the biggest, baddest tech ever made. I’ve setup a Sun E10000 from scratch. When I took the official Sun training on the kit, I fixed the lab’s setup when it broke. I’ve configured a 384-tape robotic backup system. I’ve commissioned $15M of EMC disk cabinetry. I’ve trained extensively on Oracle, and setup a North-American-spanning network of 20 instances. These technological implementations are fading, now, but the concepts haven’t. We just answer the same questions with different hardware and software these days.
When I encounter a new technology, at this point, it usually doesn’t take long to slot it into the larger context of computing services. For instance, I recently tried to use Elasticsearch for a project at work. While I eventually found an easier way to do what I needed to do, through several weeks of experimentation, I now know what that technology is about, what problems it solves, how it works, and what it takes to implement it. Now I have this tool in my toolbox, and it’s very possible that I will yet use it for a different project. I’m incredibly grateful that I have a job where I can occasionally do a little “R&D” like this, to learn something new, but it takes substantially less time to divert my attention like this, than other people might spend, because of the experience I already have.
Second, I understand the field I write software to support, because I studied it. I think the modern incarnation of the programmer, toiling away in the bowels of a big company — which is most developers, by simple numbers — is the total inverse of this ideal. I have a degree in mechanical engineering. I’m a good engineer, for the same reason I consider myself a “full-stack” guy. I see the big picture, and how everything underneath it contributes to making it look the way it does.
Even more than studying the math and physics, I was drawn to engineering, because that’s how my mind works. When I look at an engine, I notice the systems that are interoperating: the mechanical masses, the fluid flows, the thermals, the electrical connections, the air flow. I feel these things in my gut and see them in my mind’s eye. I understand how all of these subsystems work to produce power and torque, the difference between those two things, and when it’s appropriate to focus on one over the other. To me, it’s the same thing with an IT solution. I can picture the large subsystems working together to make up the final system in my head, and see the servers, the services, the networks, the databases, the networking, and the automation that will be needed to implement it.
In a lot of ways, the training in how to think about a problem in engineering school is perfectly suited to creating full-stack solutions. Start with restating the problem. Get to the heart of the business problem you’re trying to solve. Where’s the friction? State the givens. What do we know already? What pieces of data do we have? How do we get that into the system? Finally, specify what you’re solving for. What are we missing? How are we going to transform what we have into what we want? How will the people who will use the system need the program to work, and the data to be shown?
Most people working in software in my industry have been trained in how to write some code, and that’s about the end of it. They might understand how to write a loop in Java, but they don’t understand how to setup a Java application server, or a load balancer, or a firewall, to say nothing about the database. They also don’t understand how our products work, how they’re designed, or what the engineers working on them need to help them in that endeavor. I find myself in the rather rare position of understanding both halves of this equation. In my 25-year career, I’ve met only a handful of people who can straddle the fence between the physical, engineering problem domain, and the IT implementation like this. In the manufacturing world, we are indeed few and far between.
There’s one other thing I want to talk about, and that this article’s presumption that Javascript is the piece for the front-end, in the jigsaw puzzle that is a full-stack web application these days. I still like Rails’ templates, and, of course, Microsoft is pushing Razor. Javascript enhances both of these things. However, the article hints at how a lot of people are doing the entire front-end in Javascript now, and I find that disappointing. In an aborted effort, I tried writing an application in Java with an Angular2 front end. The amount of duplication astounded me. When you combine this duplication with the fact that Java and typed Javascript are two of the most verbose languages to work with, well, you get a mess.
Using an API back-end and a pure Javascript front-end is, perhaps, the single greatest argument against full-stack development you can make. Given the sheer amount of work involved in separating the front-end, completely, from the back-end, it almost requires two different people or teams. If you sat down, and wrote out the most terrible theoretical idea you could come up with for software development, it would probably look like “write a single application, broken right down the middle, in 2 different languages.” Unfortunately, that’s the nature of web development right now. I lament that this is where we’re at in our technological evolution, but until network bandwidth takes another leap forward, this is what we’re stuck with.