(Thank you Sarah for the comment that inspired this post.)
Define “full stack”
So, in the sense of standing up Linux and Apache and being our own MySQL DBAs, we are not really full stack developers.
Back end, front end, yes. We do that stuff, sure.
And then we fill in the gaps.
Client has no idea what to ask for beyond, “please fix our site”? We’ll interview all the content owners, figure out where their pains are, and design a system or a process to fix it for them. No business analyst needed.
Client has no idea how to organize their content? We break out the card sorts and figure out some kind of reasonable IA based on user data and common sense.
— Lisa Linn Allen (@LisaLinnAllen) March 13, 2015
Designer doesn’t know the content well enough to know what design problems to solve? Okay, we’ll figure it out, we’ll do the wireframes.
— Lisa Linn Allen (@LisaLinnAllen) April 17, 2015
Need to ferret out the usability issues? We’ve run more nickel usability tests than we can remember. Sit in a user’s office, tell them to think out loud and narrate their actions, give them some tasks to perform on the system. Observe without commentary. Don’t commit to changing anything. Reassure them that the system is what’s being tested, not them, and they aren’t dumb. Record observations. Repeat until you’ve found a batch of issues.
Then design the solutions and write the code to fix them.
I guess our stack is a full stack, but maybe not the kind of full stack that gets hired for out there in the world. If you look up ‘full stack developer’ it’s usually a list of technologies that are wanted. Not non-technical concepts or a soup-to-nuts approach to building a web site.
Running a big stack project in a traditional stack world
Our team is a little puddle in a big lake full of SAS and Java devs that work in a more strictly “enterprise-ish” way. Much of our management chain is used to a less start-up-ey approach than we are. Strategically adopting enterprise methods has been great for us, but we still wind up doing a lot of things that other devs don’t because otherwise the project isn’t going to happen. As a result, we suffer sometimes from being misunderstood.
The two reactions we tend to run into are:
1. Management is very impressed by our work. This is great, of course, and always makes us feel chuffed. The nice thing about IA, wireframe and usability testing work is there are very visible deliverables that can be posted to walls and included in slide decks. It’s work we can really show.
I’ve mapped the unmappable! pic.twitter.com/XyxN1Io7A7
— Sarah Ovenall (@sovenall) April 21, 2015
2. Yet still, it is hard for everyone outside of the team to understand why it takes so long to “do” a web site. (But then, every web developer ever gets this one, right?) If the developers are working then why is there no demo or result six months in? Are we back to doing waterfall? No, it’s just that we aren’t writing code yet!
Don’t get me wrong. I think this is all pretty great.
This might sound like a complaint, but it’s not. Writing code exclusively for a living actually sounds kind of boring to me. There’s something delightful about connecting directly with users through a card sort or usability test, or breaking out the sketchpad, pencil and eraser.
I love our stack!