Back around 2013, the term "full-stack developer" started to come up in job descriptions and blog posts. Companies were realizing that hiring developers with expertise in only one language just wasn’t enough anymore. A web developer who could handle a variety of tasks and environments was considerably more useful and was starting to become the norm.
In spite of this, knowledge about web architecture itself did not become widespread. Many developers have been building websites without having a good grasp of how things work behind the scenes. Web forms, caching, the HTTP protocol, the web server—all of these were secondary nice-to-haves.
Perhaps as a consequence of the online learning boom that had started around the same time, the self-taught web developer knows surprisingly little about the web’s underlying technology. Language-oriented courses cannot cover the complete web stack, and students will end up clueless about what an htaccess file does, how to restart a Unix daemon, or how the different types of POST encoding work.
While most coders who are coming out of the bootcamp cottage industry are calling themselves full-stack developers after learning how to work in one technology stack for three months, I hope that "full-stack developer" will come to embody a mindset of full-stack understanding. To me, a full-stack developer is someone who has the curiosity and drive to test the limits of a technology and understand how each piece works generally in various scenarios. Having this mindset will give developers more value and more power in dealing with new situations.
What is a full-stack developer supposed to know anyway?
Job descriptions frequently mention combinations of front-end and back-end technologies such as JavaScript and Node.js, PHP and jQuery, AngularJS and Spring, and many others. In reality, there is a significant amount of information outside those realms that would improve someone's ability to build a website.
Generally, our industry tends to define full-stack developers as developers who are proficient (not just slightly experienced) with all layers of an application. That means HTML, CSS, and JavaScript expertise for the UI/front-end. That means experience in server-side technologies and architecture. That means SQL expertise and database administration skills. And it means version control and testing skills as well.
Some definitions don't go much further than those main parts of an application, but some will add "DevOps" skills like production deployment, continuous integration, monitoring, and testing that developers don't normally do. You can see how the combination of all these skills is more often seen (and necessary) in small, 5-10 person startups.
Gone are the days when you could stick with what you know and make a career out of a single technology. If sticking to your guns won’t suffice anymore, then what can you do, and how can you keep up with the exponential growth of web libraries? There is so much software being released today that the number of possible combinations between technologies is increasing exponentially. Your chances of knowing how to solve problem X dealing with technologies Y and Z are ever diminishing, and any help that Googling can provide is diminishing at the same rate. The window is about to close.
Hackers: The antifragile programmers
I was introduced to this very interesting concept in an article by John Carmack. It’s described in the following quote from the Antifragile book:
“Just as human bones get stronger when subjected to stress and tension, and rumors or riots intensify when someone tries to repress them, many things in life benefit from stress, disorder, volatility, and turmoil. What Taleb has identified and calls 'antifragile' is that category of things that not only gain from chaos but need it in order to survive and flourish.”
This idea reflects the attitude shared by those who used to be called hackers. Today the word has a negative connotation in the mainstream, but in the early days it referred to a person with a certain attitude toward technology. The Jargon File defines a hacker as: “A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary.”
There was a time when looking things up on Stack Overflow whenever you had a problem just wasn’t an option, and many pieces of software had unreadable documentation, if they had any at all. I remember trying to fix a sound card issue as a kid and reading the card’s manual, only to find assembly code listings there, with interrupt codes and all. That is the environment where hackers thrived, and that’s what we are going back to, sooner or later. If your first instinct is to open a new browser tab every time you find yourself dealing with a complex issue that affects multiple technologies, you should reconsider your working habits.
Granted, being too curious can sometimes lead you down the wrong path, especially in the corporate environment, where time is always short. As an example, it can be very enlightening to write test code for the basic use cases when learning about a new library, but coders looking to impress the boss will take the more pragmatic approach of copying the examples from the documentation, fully unaware of how they work. Giving value as a developer requires a certain amount of skill in time management and setting expectations that allow you to seek the knowledge you need and which will save the company money in the long term.
Rethinking the roles
How do you find the hackers? You need to find someone with a specific mindset—the particular curiosity and persistence that I’ve described. This has nothing to do with analytical intelligence or with being able to memorize a particular set of academic algorithms, so whiteboard coding is out, and Fermi estimation problems don’t look too promising either. Ask candidates what they like to do in their spare time or what fun projects they worked on as a hobby, and you might be onto something. I have met many programmers who don’t like to code in their spare time, and that has reliably revealed them to be subpar developers.
If you're a developer, you might be worried that you don't have that kind of drive or curiosity yourself, so what can you do about it?
Here are some pointers:
- Whenever you have to Google some error message or problem, read all the answers. Get as much context as possible, and do not be satisfied just with having come across a solution.
- Learn about the technology, but also about the tradeoffs that were made during its design and development.
- Ask yourself what it would take for you to consider yourself a "complete" developer, and write down a path for you to get there.
- Do what other people don't like doing. Go where they don't want to go, and often enough you will be enlightened by the experience.
Software development is growing fast. Learning to code is easier than ever, and soon enough we will be in a survival-of-the-fittest environment. But the developer who survives is not going to be the developer who first learned about the cool new framework. It's going to be the developer who asked himself what's new about it and what's different this time. If you want to stay up to date with technology stacks, then stop worrying so much about being up to date and start hacking.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
