Full-stack engineering is one-third as good.. except when you apply teamwork
-
So, I saw this infoworld blog pass by, discussing how full-stack is a fallacy in and of itself. The take away being that a good team consists of specialized people, backend and frontend. Not people that "pretend to know it all" and "take twice as long to do anything". This notion has ruffled my feathers the wrong way, for a couple of major reasons. - I run a very small team, about half the size of a typical team within our company. - Every team member is full-stack, from junior to senior. - Every year, for the past 3 years, we are attributed at least 50% of the entire value proposition created each year. We are not specifically gifted, we don't pretend to know it all, and we regularly make mistakes. Even still, our delivered quality is regarded as exemplary, and by far, we innovate, iterate and improve the most, relative to the other teams. So, what's going on here? Why do we succeed, while teams with dedicated backends and frontends seemingly require more time and coordination to succeed, in the same company? Ironically, for exactly the same reasons as written in that blog post. We work together and we specialize. The key being, we don't specialize on arbitrary lines. We specialize in our understanding of the code. Because all of us can do the same tasks, we are regularly confronted with our strengths and weaknesses, and the entire team can give feedback and advice to each other, on everything. Instead of artificially limiting the scope of tasks each developers gets assigned, we can and do collaborate on everything. Instead of creating an artificial wall where ownerships gets handed over, each developer can complete a feature or bug from start to finish. Instead of creating little islands of specialized knowledge, where only 1 or 2 people can ask critical questions, everyone within the team can ask critical question about anything they don't fully understand. And we don't fully understand very often, and ask a lot of dumb questions.. which is very good when it comes to quality! The end result is that all of our solutions are easy to understand, have a single owner, and are never over-engineered. Yes, teamwork is essential. But having a team that actually works together is a prerequisite for that! And as a side bonus: - we caution each other to not take on to much work at once, because we can assess each others workloads - we actually feel like a team of equals, regardless of personal experience - the personal gratification we get when
-
So, I saw this infoworld blog pass by, discussing how full-stack is a fallacy in and of itself. The take away being that a good team consists of specialized people, backend and frontend. Not people that "pretend to know it all" and "take twice as long to do anything". This notion has ruffled my feathers the wrong way, for a couple of major reasons. - I run a very small team, about half the size of a typical team within our company. - Every team member is full-stack, from junior to senior. - Every year, for the past 3 years, we are attributed at least 50% of the entire value proposition created each year. We are not specifically gifted, we don't pretend to know it all, and we regularly make mistakes. Even still, our delivered quality is regarded as exemplary, and by far, we innovate, iterate and improve the most, relative to the other teams. So, what's going on here? Why do we succeed, while teams with dedicated backends and frontends seemingly require more time and coordination to succeed, in the same company? Ironically, for exactly the same reasons as written in that blog post. We work together and we specialize. The key being, we don't specialize on arbitrary lines. We specialize in our understanding of the code. Because all of us can do the same tasks, we are regularly confronted with our strengths and weaknesses, and the entire team can give feedback and advice to each other, on everything. Instead of artificially limiting the scope of tasks each developers gets assigned, we can and do collaborate on everything. Instead of creating an artificial wall where ownerships gets handed over, each developer can complete a feature or bug from start to finish. Instead of creating little islands of specialized knowledge, where only 1 or 2 people can ask critical questions, everyone within the team can ask critical question about anything they don't fully understand. And we don't fully understand very often, and ask a lot of dumb questions.. which is very good when it comes to quality! The end result is that all of our solutions are easy to understand, have a single owner, and are never over-engineered. Yes, teamwork is essential. But having a team that actually works together is a prerequisite for that! And as a side bonus: - we caution each other to not take on to much work at once, because we can assess each others workloads - we actually feel like a team of equals, regardless of personal experience - the personal gratification we get when
Well written Kate-X257. It sounds like you are a member of a great team. That doesn't happen for everyone. Congratulations and best wishes! Craig Robbins
-
So, I saw this infoworld blog pass by, discussing how full-stack is a fallacy in and of itself. The take away being that a good team consists of specialized people, backend and frontend. Not people that "pretend to know it all" and "take twice as long to do anything". This notion has ruffled my feathers the wrong way, for a couple of major reasons. - I run a very small team, about half the size of a typical team within our company. - Every team member is full-stack, from junior to senior. - Every year, for the past 3 years, we are attributed at least 50% of the entire value proposition created each year. We are not specifically gifted, we don't pretend to know it all, and we regularly make mistakes. Even still, our delivered quality is regarded as exemplary, and by far, we innovate, iterate and improve the most, relative to the other teams. So, what's going on here? Why do we succeed, while teams with dedicated backends and frontends seemingly require more time and coordination to succeed, in the same company? Ironically, for exactly the same reasons as written in that blog post. We work together and we specialize. The key being, we don't specialize on arbitrary lines. We specialize in our understanding of the code. Because all of us can do the same tasks, we are regularly confronted with our strengths and weaknesses, and the entire team can give feedback and advice to each other, on everything. Instead of artificially limiting the scope of tasks each developers gets assigned, we can and do collaborate on everything. Instead of creating an artificial wall where ownerships gets handed over, each developer can complete a feature or bug from start to finish. Instead of creating little islands of specialized knowledge, where only 1 or 2 people can ask critical questions, everyone within the team can ask critical question about anything they don't fully understand. And we don't fully understand very often, and ask a lot of dumb questions.. which is very good when it comes to quality! The end result is that all of our solutions are easy to understand, have a single owner, and are never over-engineered. Yes, teamwork is essential. But having a team that actually works together is a prerequisite for that! And as a side bonus: - we caution each other to not take on to much work at once, because we can assess each others workloads - we actually feel like a team of equals, regardless of personal experience - the personal gratification we get when
I'm with you on this. Used to manage three small teams until recently (now I'm a single warrior), of 3, 6 and 4 developers on three different continents. You have to use effectively all available resources, which is next to impossible with specialized developers like "backend", "frontend/presentation" and "DB developers". You grab the first available developer and work with him/her on an urgent task. I would prefer a specialization based on areas of work and/or business segments for long term projects, rather than specialization in technologies. And this goes to all fields, not only .net fill-stack developers. Imagine embedded systems programmer with absent knowledge in computer architectures (or electronics). Not cool. Not cool at all.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
So, I saw this infoworld blog pass by, discussing how full-stack is a fallacy in and of itself. The take away being that a good team consists of specialized people, backend and frontend. Not people that "pretend to know it all" and "take twice as long to do anything". This notion has ruffled my feathers the wrong way, for a couple of major reasons. - I run a very small team, about half the size of a typical team within our company. - Every team member is full-stack, from junior to senior. - Every year, for the past 3 years, we are attributed at least 50% of the entire value proposition created each year. We are not specifically gifted, we don't pretend to know it all, and we regularly make mistakes. Even still, our delivered quality is regarded as exemplary, and by far, we innovate, iterate and improve the most, relative to the other teams. So, what's going on here? Why do we succeed, while teams with dedicated backends and frontends seemingly require more time and coordination to succeed, in the same company? Ironically, for exactly the same reasons as written in that blog post. We work together and we specialize. The key being, we don't specialize on arbitrary lines. We specialize in our understanding of the code. Because all of us can do the same tasks, we are regularly confronted with our strengths and weaknesses, and the entire team can give feedback and advice to each other, on everything. Instead of artificially limiting the scope of tasks each developers gets assigned, we can and do collaborate on everything. Instead of creating an artificial wall where ownerships gets handed over, each developer can complete a feature or bug from start to finish. Instead of creating little islands of specialized knowledge, where only 1 or 2 people can ask critical questions, everyone within the team can ask critical question about anything they don't fully understand. And we don't fully understand very often, and ask a lot of dumb questions.. which is very good when it comes to quality! The end result is that all of our solutions are easy to understand, have a single owner, and are never over-engineered. Yes, teamwork is essential. But having a team that actually works together is a prerequisite for that! And as a side bonus: - we caution each other to not take on to much work at once, because we can assess each others workloads - we actually feel like a team of equals, regardless of personal experience - the personal gratification we get when
Once there were programmers. Then there were analysts; to guide the programmers. Then to simplify things, they added programmer-analysts. When the software got too "techie", the programmers split into systems and application programmers ... who needed their own supervisors, directors, and VP's. Then the system software got too "fat", so there came database analysts, programmers, and administrators. Then the big machines got smaller and ... It's all just a question of scale.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
So, I saw this infoworld blog pass by, discussing how full-stack is a fallacy in and of itself. The take away being that a good team consists of specialized people, backend and frontend. Not people that "pretend to know it all" and "take twice as long to do anything". This notion has ruffled my feathers the wrong way, for a couple of major reasons. - I run a very small team, about half the size of a typical team within our company. - Every team member is full-stack, from junior to senior. - Every year, for the past 3 years, we are attributed at least 50% of the entire value proposition created each year. We are not specifically gifted, we don't pretend to know it all, and we regularly make mistakes. Even still, our delivered quality is regarded as exemplary, and by far, we innovate, iterate and improve the most, relative to the other teams. So, what's going on here? Why do we succeed, while teams with dedicated backends and frontends seemingly require more time and coordination to succeed, in the same company? Ironically, for exactly the same reasons as written in that blog post. We work together and we specialize. The key being, we don't specialize on arbitrary lines. We specialize in our understanding of the code. Because all of us can do the same tasks, we are regularly confronted with our strengths and weaknesses, and the entire team can give feedback and advice to each other, on everything. Instead of artificially limiting the scope of tasks each developers gets assigned, we can and do collaborate on everything. Instead of creating an artificial wall where ownerships gets handed over, each developer can complete a feature or bug from start to finish. Instead of creating little islands of specialized knowledge, where only 1 or 2 people can ask critical questions, everyone within the team can ask critical question about anything they don't fully understand. And we don't fully understand very often, and ask a lot of dumb questions.. which is very good when it comes to quality! The end result is that all of our solutions are easy to understand, have a single owner, and are never over-engineered. Yes, teamwork is essential. But having a team that actually works together is a prerequisite for that! And as a side bonus: - we caution each other to not take on to much work at once, because we can assess each others workloads - we actually feel like a team of equals, regardless of personal experience - the personal gratification we get when
Sure, after 40 years of developing, one can really learn backend and frontend well. But
full-stackis a term that's abused and overused way too much. What it's come to mean colloquially is "I do some backend and well I've seen a few bits of JavaScript. What's CSS again?" The idea a junior or even a mid can be full stack is an outdated notion. The frontend has evolved tremendously. Even outside of that, I can't even begin to tell you how many "full-stack" developers still don't know CSS even. They all swear they do because they've seen a div. But nope. They cannot beat a real expert that dedicates their time to it. The problem is, a lot of developers have no respect for the frontend. And in their mind they think they can do it all. Nothing could be further from the truth. Personally, I'd never hire someone who claim to knew it all. Even after 30 years of development and being able to hold my own on the backend, I still specialize in the frontend and don't know it all on the backend. I'm good, but I won't beat someone who dedicates all their time to it. Not to mention, you take two seconds to sneeze and even the frontend changes. This isn't the 60s... the industry has evolved.Jeremy Falcon
-
So, I saw this infoworld blog pass by, discussing how full-stack is a fallacy in and of itself. The take away being that a good team consists of specialized people, backend and frontend. Not people that "pretend to know it all" and "take twice as long to do anything". This notion has ruffled my feathers the wrong way, for a couple of major reasons. - I run a very small team, about half the size of a typical team within our company. - Every team member is full-stack, from junior to senior. - Every year, for the past 3 years, we are attributed at least 50% of the entire value proposition created each year. We are not specifically gifted, we don't pretend to know it all, and we regularly make mistakes. Even still, our delivered quality is regarded as exemplary, and by far, we innovate, iterate and improve the most, relative to the other teams. So, what's going on here? Why do we succeed, while teams with dedicated backends and frontends seemingly require more time and coordination to succeed, in the same company? Ironically, for exactly the same reasons as written in that blog post. We work together and we specialize. The key being, we don't specialize on arbitrary lines. We specialize in our understanding of the code. Because all of us can do the same tasks, we are regularly confronted with our strengths and weaknesses, and the entire team can give feedback and advice to each other, on everything. Instead of artificially limiting the scope of tasks each developers gets assigned, we can and do collaborate on everything. Instead of creating an artificial wall where ownerships gets handed over, each developer can complete a feature or bug from start to finish. Instead of creating little islands of specialized knowledge, where only 1 or 2 people can ask critical questions, everyone within the team can ask critical question about anything they don't fully understand. And we don't fully understand very often, and ask a lot of dumb questions.. which is very good when it comes to quality! The end result is that all of our solutions are easy to understand, have a single owner, and are never over-engineered. Yes, teamwork is essential. But having a team that actually works together is a prerequisite for that! And as a side bonus: - we caution each other to not take on to much work at once, because we can assess each others workloads - we actually feel like a team of equals, regardless of personal experience - the personal gratification we get when
Also, the business priority for smaller companies cater to the need of not having specialists in order to save money. But that doesn't mean a generalist actually knows what they're doing or is better at their job.
Jeremy Falcon
-
So, I saw this infoworld blog pass by, discussing how full-stack is a fallacy in and of itself. The take away being that a good team consists of specialized people, backend and frontend. Not people that "pretend to know it all" and "take twice as long to do anything". This notion has ruffled my feathers the wrong way, for a couple of major reasons. - I run a very small team, about half the size of a typical team within our company. - Every team member is full-stack, from junior to senior. - Every year, for the past 3 years, we are attributed at least 50% of the entire value proposition created each year. We are not specifically gifted, we don't pretend to know it all, and we regularly make mistakes. Even still, our delivered quality is regarded as exemplary, and by far, we innovate, iterate and improve the most, relative to the other teams. So, what's going on here? Why do we succeed, while teams with dedicated backends and frontends seemingly require more time and coordination to succeed, in the same company? Ironically, for exactly the same reasons as written in that blog post. We work together and we specialize. The key being, we don't specialize on arbitrary lines. We specialize in our understanding of the code. Because all of us can do the same tasks, we are regularly confronted with our strengths and weaknesses, and the entire team can give feedback and advice to each other, on everything. Instead of artificially limiting the scope of tasks each developers gets assigned, we can and do collaborate on everything. Instead of creating an artificial wall where ownerships gets handed over, each developer can complete a feature or bug from start to finish. Instead of creating little islands of specialized knowledge, where only 1 or 2 people can ask critical questions, everyone within the team can ask critical question about anything they don't fully understand. And we don't fully understand very often, and ask a lot of dumb questions.. which is very good when it comes to quality! The end result is that all of our solutions are easy to understand, have a single owner, and are never over-engineered. Yes, teamwork is essential. But having a team that actually works together is a prerequisite for that! And as a side bonus: - we caution each other to not take on to much work at once, because we can assess each others workloads - we actually feel like a team of equals, regardless of personal experience - the personal gratification we get when
I think it depends on what your target for the full-stack is ... For a full Windows system from driver to service to GUI that manipulates sensors / processes data / munches on ordinary files (i.e. no database, no web), I'm your person. After nearly 40 years, I can do all those and do them well; isn't that the definition of full stack? However, add even a hint of web or database or internet communications, I would fail miserably if I tried to pass myself off as full-stack for that target.
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
-
I think it depends on what your target for the full-stack is ... For a full Windows system from driver to service to GUI that manipulates sensors / processes data / munches on ordinary files (i.e. no database, no web), I'm your person. After nearly 40 years, I can do all those and do them well; isn't that the definition of full stack? However, add even a hint of web or database or internet communications, I would fail miserably if I tried to pass myself off as full-stack for that target.
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
Hah another old school SF reader!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
Well written Kate-X257. It sounds like you are a member of a great team. That doesn't happen for everyone. Congratulations and best wishes! Craig Robbins
-
Well written Kate-X257. It sounds like you are a member of a great team. That doesn't happen for everyone. Congratulations and best wishes! Craig Robbins
-
Sure, after 40 years of developing, one can really learn backend and frontend well. But
full-stackis a term that's abused and overused way too much. What it's come to mean colloquially is "I do some backend and well I've seen a few bits of JavaScript. What's CSS again?" The idea a junior or even a mid can be full stack is an outdated notion. The frontend has evolved tremendously. Even outside of that, I can't even begin to tell you how many "full-stack" developers still don't know CSS even. They all swear they do because they've seen a div. But nope. They cannot beat a real expert that dedicates their time to it. The problem is, a lot of developers have no respect for the frontend. And in their mind they think they can do it all. Nothing could be further from the truth. Personally, I'd never hire someone who claim to knew it all. Even after 30 years of development and being able to hold my own on the backend, I still specialize in the frontend and don't know it all on the backend. I'm good, but I won't beat someone who dedicates all their time to it. Not to mention, you take two seconds to sneeze and even the frontend changes. This isn't the 60s... the industry has evolved.Jeremy Falcon
It's a good counter-point. A junior full-stack, for me, is a junior that can be effective in all parts of the stack, and takes ownership of the work until it's done. I have one, and every time he doesn't fully grasp something, he asks the most experienced full-stacks within the company on how they would approach the problem, and he openly discusses complex issues with other front-end specialized people. He collaborates effectively. I strongly believe front-end specialists are valuable and needed within every company. I just don't agree that a full-stack team cannot be effective. :)