I am in a local Slack channel for software developers. There are individual threads for everything you can imagine all the way through mechanical keyboard enthusiasts. I tend to follow the quality assurance thread, and the jobs thread to stay on the lookout for work in my area. Nearly every job posted has the text ‘full stack’ at the top of the description. Maybe with the exception of company looking for Java or C# developers.
My co-blogger here on Uncharted Waters, Matt Heusser, wrote an article this week defining the full stack developer based on a RPG point system. I want to take a step back and look at where full stack developers came from and how they are built in the workplace.
I have considered moving into development on and off throughout my career. I’ve always wondered how people learn so many languages, so many technology stacks, so many different working conventions. The answer I have come to lately, and I think it matches up with Matt’s post, is ‘just enough’ of each tech to be useful (or dangerous) combined with rapidly improving tech. Modern development languages abstract away a lot development that used to be difficult or left to the experts. Most languages have libraries for things like authentication, and handling database queries built in. I won’t say you ‘just’ write a few lines of code and the language feature set handles everything for you, but we are reasonably close to that.
Enter the full stack software tester.
This is supposedly a person that has deep understanding of software testing, and software development practices. Hiring people, I think, naturally believe that because full stack developers exist that there are also full stack software testers. Lots of them in fact. The reality of course is that there aren’t very many of them at this point. There are developers acting like testers, and testers doing a mediocre job at development tasks. But, most of them probably aren’t skilled enough at both disciplines to call them full stack.
Making a full stack tester requires the same conditions it takes to make a diamond; time and pressure. The way I would do it is to spend somewhere around 5 years in one discipline, development or test, it doesn’t matter. After this, you find someone in your company that will let you make a move, or a kind soul at another company to take on a pet project. Over the next 5 years, you learn the other discipline. At this point, you might qualify to be a full stack tester. You know enough about testing to write automation that will actually discover bugs in the software rather than throwing up a bunch of assert.true() when a page loads correctly. You know enough about testing to know that many tasks handled through code might be better handled by a person. These people also know enough about development to write tools to help people test faster, and how to build automation that won’t fail when the wind blows too hard outside.
I am no where near a full stack tester despite being in test for 10+ years and spending a lot of time working in automation. Off hand I can think of a handful of people that really are. There are probably more, those are just the obvious ones from my professional network. The full stack analogy doesn’t stretch across disciplines very well because the tools we use haven’t advanced at the same pace. As of right now, full stack developers are born into the world, it is what the market wants and the technology encourages. Full stack testers on the other hand have to do things the slow way. For the moment at least.