Infrastructure as Code Best Practices with Terraform for DevOps
João Victor Alhadas | Dec 17, 2024
This post isn’t about a brand new discussion. I’ve seen this topic later on Twitter, blog posts, tech conferences – like FloripaJS – in my city, as well as other social networks. So I felt I could bring some of my thoughts about it, because I’ve worked as a Full-stack developer for a long time, and am I living a lie?
To introduce you to this topic I’d like to share some testimonials of what I’ve heard about the full-stack position (you may have read a couple of these somewhere before):
“Full-stack is a lie.”
“Everyone is Full-stack.”
“Full-stack shouldn’t be a position.”
“Full-stack devs don’t know how to do it right.”
“Full-stack is a myth.”
These statements make me think a little because I started my career as a Full-stack dev and today, six years later, I keep working on the same position. Am I on the wrong path? Am I doing something wrong? What’s wrong? Why is it wrong? So many wrongs (keep this question in mind, I want to answer it until the end of this post) but let’s understand this position.
We have enough knowledge to plan, build, publish, and manage applications. In my case, I know the web concept, how it works, and the tools that help me to perform better. There are common skills that identify this kind of professional such as:
In these moments we need to understand whats going on in our context. Tracking metrics is a good start to improve your process and then explore the technologies for our applications.
Anyway, there isn’t an exact time when the term Full-stack developer began. Certainly, tech companies had (or developed) a name for empowered employees with horizontal development skills such as Backend, Frontend, Mobile, Database, Network, and that name was Full-stack. The market demand for these professionals grew up and, in fact, nowadays Full-stack is the most required developer position – StackOverflow has been reporting it since 2015 (click here to read more)
I’ve heard many arguments about it, to highlight a few:
I really don’t agree with what most people say. If you ask me what’s a Full-stack developer in a few words, I’ll say: “It’s a FIREMAN in the project”.
In my point of view, Full-stacks look like a fireman because they need to be prepared to solve problems anytime no matter what. If something bad happens you can call a specialist but also you know that Full-stack can act in these moments. Full-stacks sometimes don’t know how to handle the problem, like everyone, but certainly, they know where to look and/or who can help.
And If you then asked me what’s so special in this position, my answer would be: “They know how to deliver the utmost value”. It means that it is not required to be an expert in every project area (Frontend, Backend, Mobile, DevOps) but she/he knows how to deliver/add value to each one of these areas.
Nowadays we have more specific positions such as Frontend Engineer, Frontend Architect, Front-End JavaScript Developer, Front-End Web Designer, Web/Front-End User Interface, etc… (only in front-end side, there would be a bigger list if include backends, DevOps, and others :/) and those delivering values are being lost for other parts of the system. I mean it’s more simple for a Front-end developer to forget to perform something in the Backend because this area becomes so far and unusual for him/her and vice versa.
I’d like to say it always will exist specialist and generalist professionals for ‘no matter what position’. As such a medical environment sometimes you won’t know what is happening with you, and you will be looking for a general doctor, and he/she will know what to do and then she/he will suggest to you what to do or find the right doctor.
I believe Full-stack Devs have a global vision of the product and it’s simpler to become a Software Architect in comparison to other developer positions.
It would be great if every developer had the opportunity to read “The Full-Stack Developer: Your Essential Guide to the Everyday Skills Expected of a Modern Full Stack Web Developer” by Chris Northwood. This book is a full guide for organizing our job defining a plan, tracking metrics, manage our time, bug, continuous improvement, testing, and other skills.
“Refactoring: Improving the Design of Existing Code” by Martin Fowler also is a good choice because when we are working in a complex project where the code is hard to understand, Fowler gives us tips on how to do it well and, believe me, you always will go through these moments.
So that’s it. Regarding my first question, I can say I’m not wrong, I’m happy doing what I do, so I think I’m on the right path. In the end, this is what matters regardless of job title. Thank you for your attention.
That is my point of view and if you have a different point of me, or not, let me know. Good discussions always are welcome.
I like to solve problems with code. So, give me a problem and I'll give back a pretty coding solution to you.