0

What constitutes the "full stack", anyway?

 3 years ago
source link: http://rachelbythebay.com/w/2013/04/16/stack/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

What constitutes the "full stack", anyway?

Descriptive terms are supposed to help people understand the nature of something. If you say "sweet", "sour", "salty" or "spicy", there's a decent chance of conveying useful information to someone else. As I've been discovering, some terms we tend to wield in this industry are not always useful in that sense.

Here's my latest example: "full stack". By itself, what does it mean, exactly? I keep running into posts and stories and people using this term to mean approximately "I can write stuff to talk to the database in the flavor of the month language and I can also write client-side pages and scripting, too."

I guess that's how some people want to say that they do backend and frontend work at the same time. That's all well and good, but calling that the "full stack" seems like an abuse of a term which suggests something far more. When I think of that term, I imagine two far ends of the spectrum. One end has a pile of hardware, a box of cable, a bag of RJ45s and 8P8C connectors, crimpers, punchdown tools, toners, probes, and more. It's the grungy bare-metal stuff which makes the rest happen.

At the other end, I imagine someone who can sit down with a client or customer and figure out what's going on. They can handle support requests and empathize with their users. It's all of those "softer side" traits which aren't commonly found in the entire set of engineers.

Then, in between, I imagine the sysadmin and programming skills and everything else in those realms.

But hey, that's just me. Someone else will probably have a totally different definition of the term. That seems to make it of dubious utility as a descriptive term in the absence of any context.

Want to see how difficult this can be? First, figure out the major components of the "stack" as far as you're concerned. Then start breaking it down into its constituent parts. Don't forget about all of the "meta" stuff which goes with certain tasks. Do you think someone should be able to deal with that stuff as well?

Here's just one example. If you work in certain kinds of business environments, you have to put out a request for bids when purchasing certain devices. I had to do this as part of ordering certain large things at a public school district, for instance. Anything over $10K had to be handled this way.

If your idea of the "stack" includes hardware, does it mean purchasing in addition to assembly? If so, does that include dealing with vendors and things of that nature? Just how "full" is that stack, anyway?

I don't know if this one can reasonably be answered.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK