Spiders are some incredible creatures. They spin beautiful, deadly webs with impressive speed and efficiency. Their webs are both intricate and elaborate, but strong and effective at specific critical tasks. A spider can tell whether the vibrations reverberating through a web are caused by struggling prey or an innocuous leaf. Some are so sophisticated as to, if they leave the web, spin a small “warning line” while traveling afar to alert them of any hapless prey.

A good full-stack developer reminds me of a spider. They are masters of their domain and, like a spider spinning its web, are efficient in writing code that is beautiful through simplicity and efficiency. They understand the connectedness of different parts of their stack and how small imperfections or imprecisions can sometimes bring down an entire system through a catastrophic chain of events.

A Spider on its Web (This is what a good developer looks like)

Whenever there is some unsolved issue with a production system, management always runs to the few “angel” developers certain to divine the cause no matter the subsystem. Just as some spiders can tell the difference between prey and a leaf hitting a part of their web, good developers are able to quickly identify obscure messages or log spam pointing to the root cause instead of focusing on background noise. Instead of innate natural abilities, a good full-stack developer attributes his ability to an impressive collection of domain knowledge through thorough study and understanding of his own stack (and, fine, maybe some innate ability).

Lawrence Gellert has an interesting article on what makes a good full-stack developer that I think addresses much of what is important. But what I want to focus on is the last paragraph of his closing thoughts:

I’m not sure you can call yourself a full stack developer until you have worked in multiple languages, platforms, and even industries in your professional career. Full stack goes beyond a ‘senior engineer’, as it is along the same lines as a polyglot programmer but with a higher view of all the connecting pieces. …

Whether or not you have earned the “title” of full-stack developer is immaterial and unimportant. If you are writing code that is part of a larger, more complicated system you should adapt a full-stack mindset. Gone are the days of javascript being used only for simple user-interaction. Now every line of code that is written (wherever it falls in the stack) can, and might, affect different systems in a variety of ways. A large and robust back-end infrastructure can be brought to its knees by improperly implemented client-side code, particularly in today’s environment of complex web applications.

Even if you spend all of your time purely on the front-end, seek to know how your data is being delivered. Try to understand the mechanisms in place to serve users at scale. Do your web-service or FE boxes sit behind a proxy/reverse proxy? Why/why not? If things suddenly come under heavy load can you fall back to a static version of your page? Will your back end handle the new multitude of API calls you want to make? If you are more of a BE person, is there a better way to structure your data so that the FE’s aren’t pulling their hair out? Are your api’s optimized for their actual use cases or do you spend too much time on calls nobody even knows to use? The more you reach out of your comfort zone to empower your understanding, the more valuable an engineer and the more productive you will become, especially when a member of a team. You will be easier to work with and people will appreciate you taking the time to learn their craft.

Funnily enough (and despite this blog’s title), I don’t think the term “full-stack” developer is very accurate. A stack is a fine model for a simple site architecture, but as requirements grow any platform turns into something that looks more like, you might have guessed, a spider web:

A Complicated Web Architecture (From http://docs.openstack.org/)

To me, a stack model implies I can start at the beginning, and move to the end. It doesn’t really express the cyclical nature of larger services and fails to illustrate the level of coupling that can occur between components. Regardless of the applicability of the term (and I wouldn’t want to try changing the common vernacular anyway), try to grow your “full-stackness” and understand more of these relationships. Obviously everyone will have their area of expertise, but taking a little time to understand how the threads you weave affect those they connect to will be better for everyone. Learn what type of issue causes particular vibrations on your own strands, and how your own issues can cause vibrations on others. Try to become a spider.

blog comments powered by Disqus