T recruitment in 2020 is living in Full (stack) paradise. If you are into the junior ranks which i.e anywhere less than 8 years of experience then Full stack is your zone. At higher levels, it might not be part of the designation but its always implied. But at that level, you are way better “experienced” to handle job and career .So this post is focusing on Ture Full Stack Developers (TFSD, a term which if not coined already, might become reality soon).
The ask: Full Stack Developer (FSD)
The most popular description of FSD is a software engineer who can do backend and frontend, both. An alternative description is that FSDs do client-side and server-side development in addition to database work. In specific you are the one who knows to :
- Work on UI
- Work on services
- Work on data storage
Based on your IT stack this could mean web/mobile/desktop/low-end IoT displays for UI, some combination of web services/streams/security backing it and at minimum a database/cache/session working across.
Benefits of FSD
For startups, this offers a sweet spot. We can work with smaller teams of talented engineers who can do the “whole thing”.Often FSD also leads to complete ownership of the “whole thing” to a developer. Which is why most training plans for entry-level engineering talent are Full-stack. In fact, it also expands to some orientation on OS, UX, network and so on. Rightly so. A good breadth both in training and work exposure is good for engineering organizations. Except that it is a means and not an end.
From Full-stack to Fools Stack
Proficiency, expertise, and words like them are used in Job Descriptions(JD) of software engineering to imply a good quality of depth. Except that it should be Full-Stack. That’s asking “to have great depth across the breadth of the technology stack(we use)“. This is not asking for specialist developers with good breadth. This is asking for a specialist in everything!
We even have cute words coined for them, LAMP-MEAN-MERN and so on, signal this very thing. And it works.
The hidden fallacies
Developing a liner flow of requirements fits naturally to how we think. We start doing one thing and can finish it well. The same linear flow can be coded full stack – end to end. Except for software development ,it doesn’t remain linear. Functionally as well as technically. The lines cross, merge-diverge, conflict and suspend. This needs specialization. If your org is working well with FSDs then you are sure to have these specialists hidden (and operating and sustaining your FSDs).
Some examples. On an agile task board, the UI development might look like a diagram that needs to be drawn on a device/browser. But it also involves lots of animations, offline ability, support for disability norms. We have to also make sure that the components don’t make too many server loads and it needs to handle clickjacking and lots of web security stuff. And your business user also wants a responsive web design where the page supports text entry on full form but falls back to toggle on smaller ones. And yes we need to also support integration with the camera. And yes lots of browser types we need to support. And yes it will be great if somehow we can also make it work(render) on Alexa show or your watch.
These are not very unusual or problematic requirements. But they are so specific that one cannot handle it without going deep into core issues like HTML/CSS/HTTP/Device or delegating to some specialist.
The same can happen to your back end. We can start with some combinations of REST-microservices. And you need to also work with auto scaling design, support distributed commits, comply with tracing, also use some queuing. And we also need to support headless mode for some peer to peer calls. And some batches also. And some of the data can be binary. And we need to also use API gateway/service registry. And also support multiple service versions.
We could go on writing the same expansion of depth for the data side as well. All of which/this is not unreasonable. But taken together this is a lot. And we also expect the developers to understand and model the domain wisely (along with their tinder and insta 🙂 )
Yet we see neither FSD’s complaining or projects failing. For 3 reasons, I say.
- People are more talented than the slice of intelligence we pay them for. So they pull it off.
- This pull off is at the cost of some other super developer or their own passion for something else.
- The technical debt and bugs it creates are not accounted for in the delivery/shipping based criteria of the project’s success.
Why FSD is hard
In the time where I started my career, we used to call them technical architects. These were little experienced people who happened to work across the application and managed to retain the skills acquired. It took them time. But they had stronger grip and wiser intuition of it all.
Most of the JDs we see for FSDs are 2 to 5 years or similar experience. But FSD is hard due to multiple factors that play out.
We are coding to frameworks
If you the FSD JD’s they are full of frameworks. Frameworks are great in abstracting problems and offer a great productivity boost. But they don’t eliminate them. That’s the nature of an abstraction. In IT projects the fundamentals of technology, as well as design, show up unannounced. This increased workload is not factored in the FSD world. Not only does it cause increased workload for Jr developers but it also kills their opportunity to have a detailed understanding of how the framework builts on top of the underlying technology, the choices it made, the problem it solves and then ones it skips.
You mistake layering for the stack
If we carefully analyze the full stack it closely aligns with how the projects architecture diagram looks like. Often the full stack is vertical slice of this diagram. What is, however, missing is that your diagram skips lots of techo-framework details due to its 2D drawing nature. Security, Monitoring, Deployment, Packaging, Scaling, Performance, etc. are part of the work in equal measure which cant be completely kept separate from Jr developer’s work package. And did I mention the design principles, process, testing, and documentation?
While FSD style hiring can give initial relief on staffing, we are greatly missing on maturity aspects.
Your stack is not alone
Oh yes, Unless you are a startup building the next uber/google/amazon or what it is. Your stack is not alone. There are always some enterprise systems that we need to integrate with. Some SaaS-based products, a BPM, an ERP, Rule engine. Some schedulers or some in-house “stuff” that is recommended as a norm.Or at least AI in included 🙂 . New hires are lucky if they are told about this with JDs.Often this is missed and needs to be paid for later, somehow.
Developers have inclinations
Each developer has its own inclination towards soft aspects of technology. A UI developer often called as frontend developer can intuitively realize the event-based nature or the aesthetic pleasure of laying out and the experiential nuances (UX) and pursue it. A server or DB side developer might like the notion of event sequence and the time-space nature of their work and hover there. And So on. May be younger developers are not able to verbalize it well, but when an able programmer says he enjoys it(his work), the reason is not comfort-zone but the sense of joy he gets.
The problem FSD creates for developers
We can go on about structurally how FSD misses on lots of aspects of the actual work conditions and how it needs to be paid for later by organizations. But the developers who manage to pull of FSD tag for years have a lot waiting for them also.
Stack Stress
The frameworks change very fast. It’s very common to get a new version of your tool every 6 months. Some times the changes are also breaking. Taken together, full-stack. This is a lot to cope up with. On top of it, your project might not even choose to use the new thing. In which case the individual need to figure out how he will keep updated.
Dwarf experts
The world is full of great brains. Brains that can pull off all stack development and brains which are truly masters of all parts of the stack. I love to work with such brains.
But are they so common? If not, then as the industry we are pushing the teens to war without letting them develop a deeper understanding of tech.
Resume driven development
How ready are you to recruit a great swift developer for nodejs project? or an angular developer for React ? or hands-on Unix admin for Kubernetes?
The answers that we get from the hiring community and mangers are not encouraging. Everyone wants a perfect fit for the project without realizing that we are breeding disposable developers. But the developers know this intuitively. And they fightback. With resume driven development.
The greatest and shiniest thing has to be on one’s resume or we are willing to change the tech stack/project/company. (If only we were paying them much higher for such disposable hiring ).
Joyless Work
Given the target of FSD hiring and this post is below 30 years developers. This is a major factor. The FSD hiring movement doesn’t talk of development plans, career paths, mentoring models or code retreats. We instead have hackathons, reskilling, upgrading. We have even stopped talking of reading long format books on our work area .The buzz in skills development is all the online courses. If we ask other arts professionals, the fundamentals give them joy and the latest style and trends let them keep their jobs. The FSD movement in S/W misses the technology fundamentals part.
And I am not even talking why they also need to code on algorithms and data structures in their first-round(what a nuisance of proxy it is for talent)
The Way out
The way out is to train them across the pyramid and be candid if FSDs mean disposable recruitment.
So much we talk about how fast the landscape is changing for technology professionals it is not the reality. The underlying technologies that drive our tech stacks change in span of multiple years. It’s only the stylistic solutions based on them change. Even then we often see these frameworks use designs and techniques from the same neighborhood. A very terse list [(System V to VMs to containers),(make-maven-npm),(taglib-web components),(grid computing-bigdata)(DW-ML)].
My approach was to always train them (or make them self train)on how the framework built up happened. This means knowing the basic technology in its bare form. Knowing the significant earlier attempts in the framework space that existed. And then training them the given framework. The same approach was used for the so-called tech stacks we had in our projects. We also exposed them to wider QoS needs that the frameworks might miss or partially cover. And the standard design approaches in S/W. This allowed them to see through the stack. This not only allowed them a great grip on them but also the new changes in these framework/space did not cause surprise.
I have been working in architecture teams.The examples I give here took anywhere between 3 to 5 years to train a good developer across layers and components of the products. These were also full-time direct reports. (often our mentor relations will continue across companies).
Chances are that the developer you are recruiting as FSD has done this/similar approach on his/her own. (S)He has also done the hard work to read a lot and do hands-on work. And will have to continue doing so.
But we must pay them well for this hard work and the tough job of keeping up to date. We must also realize these are the folks that seek joy in their work on the lines of a craftspeople and have different self-esteem than usual. Handle them well recruiters….
(and to these folks…I will welcome you all to the technology architect community soon, unicorns 🙂 )