It’s been a great week at Networking Field Day 28 this week with some great presentations and even better discussions outside of the room. We recorded a couple of great podcasts around some fun topics, including the Full Stack Engineer.
Some random thoughts about that here before we publish the episode of the On-Premise IT Roundtable in the coming weeks:
- Why do you need a full stack person in IT? Isn’t the point to have people that are specialized?
- Why does no one tell the developers they need to get IT skills? Why is it more important for the infrastructure team to learn how to code?
- We see full stack doctors, which are general practitioners. Why are there no full stack lawyers or full stack accountants?
- If the point of having a full stack understanding is about growing non-tech skills why not just say that instead?
- There’s value in having someone that knows a little bit about everything but not too much. But that value is in having them in a supervisor role instead of an operations or engineering role. Do you want the full stack doctor doing brain surgery? or do you want him to refer you to a brain surgeon?
Tom’s Take
Note that I don’t have all the answers and there are people that are a lot smarter than me out there that have talked a lot about the full stack engineering issue. My biggest fear is that this is going to become another buzzword just like 10x engineer that carries a lot of stigma about being less than useful while being a know-it-all. When the episode of the podcast comes out perhaps it will generate some good discussion on how we should be handling it.
The Networking Nerd 
There may be a misunderstanding of what a full-stack person does. Many developers understand their toolset very well, but don’t always understand the implications of what they do on network traffic. Or on security. Or on database performance. Or in a network of microservices. Or on orchestration tools. Or the interaction of all of the above. The same applies to networking specialists – they will only see “you guys are sending me too much traffic” without being able to pinpoint why that is happening. In the real world, some problems are intricate issues were each individual part may work well, but, for example, timing issues that originate in layer 3 can cause deadlocks in the database if the user clicks a button too quickly.
A full-stack person’s skills will allow him to follow a problem from the UI to the database and the network, and fully understand why things happen the way they do. That’s one fundamental difference to the “full stack doctor” – a GP often simply sees “there’s a problem with the kidney, and I don’t know enough about that, let’s refer him”. A full stack engineer will personally understand every layer enough to do in-depth troubleshooting.
Pingback: Friday Thoughts on the Full Stack - Tech Field Day