Full Stack of Something

Here’s the thing that’s hurting my head today: the “full stack developer” job listing.

A Full Stack Developer is someone who can develop at every layer of the software development stack, from the servers to the front end. This includes:

  • Server, Network, and Hosting Environment.
  • Data Modeling
  • Business Logic
  • API layer / Action Layer / MVC
  • User Interface
  • User Experience
  • Understanding what the customer and the business need.

My role as an Information Architect lands firmly inside of the sixth one down, “User Experience”, and often I’m not the Information Architect on a project, I’m the User Experience Designer. (Even as an Information Architect there are expectations that I can talk fluently about the business logic, user interface, and customer and business needs, so the User Experience container is by no means leakproof.)

User Experience is a huge field of study in and of itself. In the “tradition” of the Full Stack Developer posting, I suspect we should call ourselves “Full Stack Designers” instead of User Experience Designers, because it gives a much better impression of our wide range of responsibilities, which include:

  • Information Architecture
  • Architecture
  • Content creation
  • Visual Design & Information Design
  • Human Factors
  • Industrial Design
  • Interaction Design
  • Human-Computer Interaction
  • Sound Design
  • Interface Design
  • Usability Engineering
  • Content Strategy

…and probably more than I can’t think of.

Each of the topics that makes up a Full Stack Designer can be (and in many cases is) its own full career with its own full educational system, training, and roles in an organization.

For example, I’m thoroughly well-versed in Information Architecture and Interaction Design, comfortable in some of the Usability Engineering methods and knowledge and some of the Content Strategy methods and knowledge (but not others), and not as deep in Visual and Information Design. I can’t even comfortably say I’m a Full Stack Designer (since I’m aware of my own weaknesses and imposter syndrome is a thing).

I suspect the same thing is true of all of the other traits that a Full Stack Developer is supposed to be familiar with.

So how in the world is someone supposed to be a Full Stack Developer and be set up for success by their employer? Is it a significant reliance on vendor products, frameworks, and external knowledge? Is it by only building small websites? I’m baffled.

And suspicious. I should add that I’m suspicious, because to do six careers well takes a lot of time, and while it might come with a lot of salary, I’m having trouble imagining it comes with a lot of sleep. Hustle is hype, and anyone who’s told me otherwise was trying to pay me one salary for at least two jobs worth of work.

Me, I’m happy with one job that pays the bills, the occasional vacation, and a few pinball tournaments or races or Phillies games. And as much as I believe that there’s space for both specialists and generalists (and maybe even a few compartmentalists) I’m also quite a bit worried that anyone working six career paths under one job title is, well, over-generalizing.

I’m worried about the Full Stack Developer precisely because it includes the Full Stack Designer. If an employer believes that the 8+ specialties in my field are nothing but a subset of skills for someone who is already doing 5 other jobs, then what do they think of hiring someone in my field? Are you specializing in IT by being a generalist in Design?

I don’t have answers, just a headache, and an observation that this “full stack” world seems awfully general.

Navigating the jotter pad

As someone who works on the web, I rarely see criticisms of physical objects (Design of Everyday Things doors excepted) that this paragraph from James Ward’s Adventures in Stationery delighted me:

I find jotter pads confusing. The spiral binding across the top makes it easy to take notes, flipping each page over at a feverish rate as words are quickly scribbled down, but I gradually lose sense of what is ‘forwards’ and what is ‘backwards’ within the notebook. I get lost by the middle of the pad. Normally, when trying to find a particular note or idea I hurriedly wrote down, I can at least remember if it is on the left or right page of the notebook or pad and then try to find it that way. The jotter pad offers only vague locative information. That crucial scribble could be anywhere. Notebooks need a ‘search’ function.

Yes, exactly, the sense of environment and direction of a physical left-right page book or notebook is critically important. I can find content in my physical copy of CSS Pocket Reference at ten times the speed I can find it in the Kindle version, and not just because I wrote notes in every margin. There’s both physical and visual memory associated with one’s place in a physical book; the weight of the pages on one side or the other, the look of the way the pages curl, the depth perception of the edge, all contribute to remembering one’s place just as much as the content.

The fact that this happens in jotter pads should have given us a bit of a warning that it was also going to happen on tablets and smartphones. But, humans, meh, what can you do?

Accessibility, Recovery, and Posters

It’s been a bit crazy around here.

On February 3rd, my scheduled article for The Pastry Box, Recovery, went up. That was, as usual, exciting for me. This month’s post was about being kind to yourself, because you can. People seem to like it a lot.

So my phone was already buzzing with twitter notifications as different folks found and commented on that post, which made me pretty happy.

Then about mid-morning, A List Apart posted Reframing Accessibility for the Web, a piece I wrote about ableism, accessibility, and testing strategies that move accessibility into technology. That’s when my phone started vibrating off my desk.

The article, which has been read and tweeted about more times than I can count, has been very well-received. The most an author can accomplish is to get people thinking — anything beyond that is a bonus. Based on the comments and feedback I’ve gotten, I’ve gotten people thinking, and that makes me very satisfied indeed.

It’s also gotten me remembering the requests I’d received for a printable version of An Alphabet of Accessibility Issues back in July.

So here it is, better late than never, an Alphabet of Accessibility Issues PDF that you can download and print onto whatever size paper you happen to have available. Hang it around the office, in the lobby, or wherever you work on your design and development stuff. Update: thanks to the fine folks at Emerge Interactive the PDF is now tagged for better accessibility!

As for me, I’m thinking of something more oriented toward design heuristics for my next piece. It’ll be fun.