Tag: methodology

Navigating the Uncertain Web

Posted on by Rob Larsen

The current talk I’m giving distills the second chapter of The Uncertain Web into 45 or so minutes (I’ve got the powerpoint on Github if you’re interested.)

As I continue to discuss topics relating to the book here on the blog, I thought it would be useful to outline the core concepts of that chapter in an even shorter format so that even if you haven’t read the book (and you should really read the book- it’s great) or haven’t had the good fortune to see me speak you have some sense of what I’m talking about as an approach to tame the web’s uncertainty.

Here are the basic ideas.

Don’t Blame the Web for Being the Web
The web is a diverse place that’s getting more diverse every single day.

If you accept the web’s diversity (and maybe even celebrate it) and you find yourself getting angry about one thing (maybe Internet Explorer 8) or another (the stock Android Browser) just take a minute to remind yourself that this is just the way the web is.

Repeat after me: This is just the way the web is.

Since there’s competition in the browser space, there’s always going to be a bad browser. When the current bad browser goes away a new one takes it’s place at the bottom of the pile. You just have to accept that and move on with your life.

Identify and Embrace Your Audience
You would think this second general concept would go without saying, but…. You really need to identify and embrace your audience

Do you know who your audience is? You’d be surprised how many clients I’ve had who couldn’t answer this very well at all.

While you can look at web-scale statistics for browser and operating system market share to get some idea of where things are, the only metrics that truly matter are those for your specific audience.

Test and Pray for the Best
This third general concept used to be much easier. Nowadays we’ve got to test in as many devices as we can and then pray for the best in the ones we don’t have direct experience with.

Once you’ve identified your audience, where they are and what they’re using it’s time to define the technical demographics you’re going to target with testing and active support.

You’re never going to test everything. The days of testing 95% of the web with one PC running IE6 and toggling between two screen resolutions are long gone. Test with as many real devices as you can and have a plan for what broad range of devices and operating systems you’re going to support. “Android” isn’t good enough. “Android 2.3 and up” is better and saying you’re going to dig up a Moto X means you’ve got your full game face on.

Focus on Optimal, Not Absolute Solutions
This concept has been with me for many years. My prime example is the many arguments I’ve had against putting in the extra effort to add rounded corners in older IE.

These days you need to focus on optimal, not absolute solutions.

Your site is not an absolute thing. The best possible site you can have will be the best possible site for everyone that visits it. If that means it’s a high DPI, 25MB monstrosity for a guy on a MacBook air in a coffee shop in Palo Alto or just a logo and an unordered list for someone on a-rented-by-the-minute phone in Lagos, then that’s the way it is.

People are used to sites looking different on different devices so take advantage of it and provide them with the best possible experience for their particular setup.

Embrace Accessibility
This concept is unfortunately something I have to call out, but people don’t focus enough on accessibility for the pure sake of it, so here we are.

On the modern web we need to embrace accessibility.

If your site is accessible you’re guaranteeing that you’ll be able to reach the largest possible audience.

You’re also doing the right thing.

I can’t stress that enough. You should be doing this anyway.

Lose Your Technology Biases
This general concept is one that drives me particularly nuts.

You’ve got to lose your technology biases.

Tech folks generally have great hardware and new, high powered smart phones and tablets. Most other people in the world don’t. Tech folks tend to forget that.

Not everyone has a fast machine. Test on crummy hardware and crummy phones.

Not everyone is on a Mac. In fact, the vast majority of people on the desktop are still running Windows, no matter what it looks like at conferences. Test on Windows and test in IE.

Not everyone is on an iPhone. Don’t design your experiences around iOS.

Embrace Empathy
This concept runs through much of what we’ve already discussed, but I still like to call it out. We need to embrace empathy.

Don’t blind yourself to what your audience actually is by assuming that they are just like you.

They’re not. Your average experience at work, at home or on your phone is almost certainly an optimal view of your site. You’re an expert at using the web. Make sure you look at it, really look at it, in every scenario you can muster. Sure, we’re all guilty of demoing code under the best possible circumstances. That’s natural. The thing is, that demo is the ideal vision of your site run by an expert. The thing you’re actually building, the down and dirty version, is for people with a completely different relationship with technology than yours.

Try to get in their shoes instead of assuming everyone else is in yours.

Lose Your Stack Biases
This is a new pet peeve that has cropped up over the past couple of years.

Lose your stack biases.

Your users don’t care if your stack is clever. What they care about is the speed, usability, look and feel, interactivity and features of your site. If your stack isn’t adding to one of those then you might be going down the road to stack obsession.

This is the foundation of what I’m talking about these days. This is all covered in much greater detail in the book and in my talks, but the overall gist is here. Now that I’ve gotten this out of the way I’ll get back to diving into the continuing evolution of the web and what we can do about it to make it the best web it can be.

A Long Journey Reaches a Happy Conclusion: The Uncertain Web is Out In All Formats

Posted on by Rob Larsen

lrg

It’s true. After a two year odyssey, The Uncertain Web is finally out in every format that matters. The book has actually been out for a little over a month in multiple ebook formats from O’Reilly and Amazon; but owing to a slight production hiccup it hasn’t regularly been available in print until now (technically this Friday, but Amazon is on the case.) The book is in full color (and looks great) so I wanted to wait until you had the option to get your hands on the print edition before I really started to spread the news.

That time has come. I’m spreading some news…

I’m really happy with the finished product. One of the reasons I’m proud of it is that it’s the first book I’ve written that I could really recommend to my peers– my jQuery book was a hybrid effort with another writer aimed at intermediate developers and Beginning HTML and CSS is book for beginners. The Uncertain Web, on the other hand, works for everyone from a project manager or designer (who could read the first two and final chapters with ease) all the way up to the most technical front end engineer who might be surprised by some of the things that I kick around in my precious 224 pages. Not everyone is going to agree with everything I say in those pages, but there’s definitely something that will make you stop and think about the way you approach the web, no matter who you are.

Here’s how O’Reilly describes the book:

What’s the best way to develop for a Web gone wild? That’s easy. Simply scrap the rules you’ve relied on all these years and embrace uncertainty as a core tenet of design. In this practical book, veteran developer Rob Larsen outlines the principles of what he calls The Uncertain Web, and shows you techniques necessary to successfully make the transition.

By combining web standards, progressive enhancement, an iterative approach to design and development, and a desire to question the status quo, your team can create sites and applications that will perform well in a wide range of present and future devices. This guide points the way.

Topics include:

  • Navigating thousands of browser/device/OS combinations
  • Focusing on optimal, not absolute solutions
  • Feature detection, Modernizr, and polyfills
  • RWD, mobile first, and progressive enhancement
  • UIs that work with multiple user input modes
  • Image optimization, SVG, and server-side options
  • The horribly complex world of web video
  • The Web we want to see in the future

The book is also solely my idea. Which isn’t the case with any of my other books. Typically publishers have a book they want written andthey search for an author. This time I had some ideas I wanted to share and O’Reilly stepped up to let me share them (thanks to Simon St. Laurent.) That, in particular has been rewarding for me.

Have I mentioned I have a back cover blurb? I do. It’s provided by Jeremy Keith and it makes me smile.

“A refreshingly honest look at the chaotic, wonderful world of web development, with handy, practical advice for making future-friendly, backward-compatible websites.”

I also like this tweeted comparison:

All in all I’m a happy dude.

Let’s Talk About your Billable Rate

Posted on by Rob Larsen

I’ve got a few topics relating to my experience at agencies that I’ve been looking to share for some time. Now that I’m going my own way as a consultant with the goal of maybe expanding on that as well as somehow helping out at an agency again; I’m going to start to work through different agency related subjects as time allows. Hopefully you’ll enjoy this stuff.

I’ve related the following (albeit in much less detail) to people who work at agencies and a lot of them really hadn’t thought about the way that their employer makes money off of their services.

It can be an interesting revelation.

When you work for an agency your talents are for sale to clients. While the relationship is marketed in another way (agencies bid for projects and/or try to gain permanent relationships with clients) this is the basic financial currency of agency life- providing bodies to clients either directly or hidden within the completion of a project. There are basically three ways that your clients pay for your services. One of them ties directly to the number of hours you work. Another feeds into the internal agency accounting in ways that can be detrimental to your health. The third can just be boring. I’ll define them and then I’ll let you in on a little secret about the way that the agency views your relationship with each of those models.

  • Time and Materials

    In this model, the agency bills the client for your time and expenses when working on a project. For example, if you’re, say, an Art Director at an agency[1], the company might charge something like $200/hour for your services. If you then worked 40 hours in a given week, the company would charge $8,000 for your time.

    This model is useful because, generally[2], the agency gets paid for the work they’ve done. There will be an estimate done at the outset of the project, but if the project goes, say, 10-20% over budget the client can still be charged for those hours.

  • Fixed Cost or Fixed Price

    In this model, the agency provides a fixed estimate of the cost of the project. Working through a gigantic spreadsheet (or something web-based that does the same thing as Excel) with limited information, the agency team will put together a proposal that’s supposed to predict, with pinpoint accuracy, how much the project will cost- including enough margin left over to keep the lights on.

    This model is great for the client, since they know how much the final bill will be. This model can be great for the agency, especially if the project comes in under estimate. The thing is, that almost never happens and when the reverse is true and the project spirals out of control it can quickly turn into an emergency situation. Just like a startup working through their pot of money, projects have a burn rate, which indicates the daily/weekly/monthly resource usage on a project. When the burn rate indicates that a project is going to bust the budget, step back, grab some popcorn and watch as executives go into disaster recovery mode.

  • Staff Augmentation/Dedicated Teams

    In this model the client buys your exclusive services for a period of time. This is not project based and can last for many years[3]. This can be on or off-site. If it’s on-site it’s basically like you’re an employee of the client company (except you have to kiss everyone’s ass and get none of the perks of the client company.) If it’s off-site it’s basically an arrangement that means that important staff can’t be pulled away from one client to serve another need within the agency.

    This model can work for both sides as it represents a steady stream of income for the agency (albeit potentially a discounted one) and the client can flexibly fill positions with skilled staff.

Now it’s time for the secret. While your boss, their boss or even their boss’s boss (all the way up to the guy or gal that runs the place) might care about your well-being, the Agency, as a capitalist organism, does not. The Agency as a capitalist organism doesn’t believe that you’re a special little snowflake. The Agency thinks you’re a replaceable cog and doesn’t care about how many awards you’ve won or how clever your code is. With that in mind, with any of the models the agency is almost always healthier in the short term if you work 50-80 (or more) hours a week[4], every week until you quit, die or retire.

In reading this, if you’re unfamiliar with the way that agencies work, you should keep in mind that agency deadlines are pretty psychotic.

The folks that interface with clients would rather chew broken glass than tell a client that a deadline is going to be missed. Missing deadlines hits the wallet and (worse) the reputation and relationship with the client. It’s not something you want to do ever. So whenever a deadline is approaching the project team goes into “whatever it takes” mode to get the work out the door.

So, with each of the models, you being willing to put in 80 hours a week, sometimes for months at a time, is vital to the success of the organization. This is both down to the danger of missed deadlines and also down to the pure math of being an agency employee.

Lets look at how that math works with each of the models.

  • Time and Materials

    Cutting through any potential confusion, if you’re working 80 hours a week on a time and materials project you are getting royally screwed. Let’s take the example of the $200 an hour Art Director. To keep the math round, assume the Art Director makes $125,000 a year plus $25,000 in various other compensation (health insurance, 401k match, etc.) That works out to about $72 an hour[5] for a 40 hour workweek. That adds up to $2880 a week. So, how much do you get paid if you work 80 hours that week? $2880.

    What’s your effective hourly rate? $36 an hour. But yet, the agency is going to bill $16,000[6] for the full 80 hours. You’ve increased the company’s margins by a wide margin with your dedication.

    You win free pizza at your desk for dinner, stress related hives, and an angry spouse.

    There’s also a morale cost with this model. If you’ve got pure freelancers working alongside agency employees and both sides are working late nights, the freelancers are invariably going to be happier about the situation since they’re actually getting paid extra for their effort. Trust me, it sucks when you’re stuck in the office at 9:30 and the freelancer next to you is whistling while he works thinking about the new addition he’s going to put on his house.

  • Fixed Cost/Fixed Price

    Fixed cost projects only go awry, from an accounting perspective, when the agency needs to add more bodies to a project. Otherwise, with the planned number and makeup of the team, the only thing that matters to the Agency is whether or not the deadline is hit. To that end, if you need to sleep at your desk for two weeks straight and work weekends for six months, then it’s all good.

  • Staff Augmentation/Dedicated Teams

    Your number one job in this kind of role is making sure the client is happy. Depending on the engagement this can, of course, include long hours. That said, I’ve seen examples where these can be the healthiest situations in terms of the number of hours you have to put in every week and the pace of your day.

    There are other downsides to being in one of these roles, but generally it‘s not the hours or the pace. The biggest is the common refrain of, “If I wanted to work at Client Company for the next five years I would have applied for a job at Client Company.”

    That said, in terms of hours you can get lucky in these kind of engagements.

[1]
The weight of titles can vary, as can bill rates across agencies so don’t linger too long on the price quoted here. I’m sure there are folks with the title Art Director that bill out over four figures and others that bill out much less than $200. It’s just a nice round number.

[2]
generally.

Projects can be 50-100% (or more) underestimated, and in those situations it’s tough to keep asking for more.

Imagine a project budgeted for three years of development at, say, $1,000,000 a year. Then imagine that $2,000,000 worth of work is done in the first 6 months… That’s capital T trouble and there will be some awkward C-suite type conversations.

[3]
I’ve seen people who were embedded for more than five years at client organizations. Something like this: “I got into the office for my first day. they told me to go to client x later that afternoon and I’ve been here ever since. That was in 2007. I got back to the agency office 2 or 3 times a year.”

[4]
Some agencies have slightly different DNA that values talent as talent and wants to cultivate it and keep it from burning out. If you’re at one of those places you’re winning.

[5]
Keep in mind that the gap between $200 an hour charged out to the client and the $72 in total compensation per hour isn’t the entire story on margins in the industry. There are a lot of non-billable people in an agency and there are always billable people who aren’t billable at any given moment. There are a lot of slices to be taken out of that $128 difference. So many, in fact, that margins can be down in the single digits at some shops. I don’t have encyclopedic knowledge of margins across the breadth of traditional and digital agencies, but I don’t think they get much higher than maybe 15-20% anywhere

[6]
No, this doesn’t always happen. Sometimes an agency will eat the extra hours to maintain the client relationship or because it was your, or the agencies’ fault that you had to work 80 hours in the first place. That said, many times, if the numbers are okay, then $16,000 it is.

Notes from the Interview Front

Posted on by Rob Larsen

Interrogation Room #5

Sadly, I won’t be sharing a bunch of funny anecdotes from my time on the interview trail. While that might be fun, there are some bigger trends that I wanted to talk about after having reviewed dozens of job descriptions and talking to dozens of people at one level or another over the month of March.

AngularJS is the new boss

At least in terms of green field development it seems like no one is talking about anything other than AngularJS right now. My year and a half’s worth of Angular experience set off alarm bells for many recruiters. Backbone comes up, but not with as much frequency. Several people were moving from Backbone to Angular. Nothing else in the MV* space was really in the running.

Lots of smart people (including many that I know) are still pouring a lot of time and effort into Backbone, so it’s clearly not going anywhere. It is weird, however, as Angular seems to be winning developer mind share no matter what the regular front end engineering taste-makers might think about it. I’ve had a lot of conversations with people (including some big names) where they’re completely flabbergasted that anyone is even using Angular, forget about the fact that it’s storming the castle.

It’s definitely storming the castle.

In the course of writing this post, I saw a bell clear sign of Angular’s rise. I saw an “Angular expert” job posting from a company who had spent a ridiculous amount of time and money (hundreds of thousands of dollars worth of developer hours) crafting a “perfect” Backbone based application development stack. I’m sure they’re still quite fond of Backbone, but it was interesting to see them hedging their bets, trying to get some Angular expertise on staff.

Start-ups are spreading like wildfire.

The Boston start-up scene is pretty nuts. I’m not generally interested in start-ups, but as part of my “talking to everyone” thing I ended up talking to a few of them. I remain mostly uninterested from a full-time perspective, although I did get up to the brink with one group that seemed pretty cool.

There is a lot of opportunity out there for someone like me to help them out on a short-term basis, however, so in my new life as an indie consultant, I might go back into the fray.

Start-up Geography

At this point start-ups are no longer crowding around South Station. They’re in South Boston proper. It’s a walk to get over there these days.

Bocoup might be leading a smart charge over to North Station.

Agency vs. Startup/Product

When I interview at agencies I don’t do tech screens. No one has asked me to do anything like that in 4 years. The shared experience of the agency existence and the number of people I usually have in common with agency folks means that the “tech” portion of interviews usually doesn’t go beyond philosophy and general experience. For most agency people knowing the level I’ve been at the places I’ve worked is a pretty good indicator that I know what I’m doing.

Product people, on the other hand, are super wary of my experience. They seem to think that because I’ve been a manager and been in charge of teams that I don’t know how to code. Some of them have even made the assumption that I don’t want to code (yes, I do open source software to torture myself.)

Interviewer: “So you’ve been a manager, running teams for a while. You haven’t really been coding since 2007 then?”

Rob: “No, unless today is opposite day. I’ve worked on probably 20 sites or applications in that time. Some with thousands of lines of JavaScript and incredibly complex UIs.”

Let me set the record straight on that assumption. Being an engineering manager at some companies might include no coding/all meetings, but at an agency the pendulum usually swings way too far in the other direction.

A technology manager at an agency will probably be doing coding/architecture most of the time and will not have any time officially allotted to do anything strategic or to work with their team on anything other than project work. .

Even if their target allocation is something like 60% billable work, they will probably be fully allocated to client work. Occasionally, they will be over-allocated to a client (or two.) Oftentimes, soft-skills “manager stuff” happens in hours 40 and above (or 80 and above.)

Personally, at one point a couple of years ago I was allocated 100% to two separate divisions at the same investment bank for six weeks. Not a lot of time to get soft when you’re scheduled to work 80 hours a week 🙂

This is actually a systemic problem at agencies. There’s not a lot of room for people at even the director level and above to really nurture staff. There are exceptions, of course. If you look around and spot stable teams at different agencies you can usually spot a guy or gal at the top who makes a point of keeping their staff happy, but the pressure to do that is not coming from up on high. The pressure from up on high is to keep your billable rate as high as you possibly can in order to justify your continued presence at the agency.

To that end, senior people at agencies are constantly getting their hands dirty. No one is hiding. I know start-up people think their experience is special, and in a lot of ways it is, but the experience on the agency side isn’t any easier.

To be perfectly honest, looking at someone from an agency with a good engineering culture and thinking they’re going to be soft is insane. That person has probably built up and torn down more architectures than most people do in a career in the product world.

There is a reverse bias

Agency people don’t want to hire people who don’t have agency experience. This is undeniably true. There’s a fear that you will hire someone, they will walk in the door, see the maelstrom and walk back out the door.

That happens, so it’s a valid concern, even if I don’t put as much weight into it as some people do. For my money, I’d rather have people get the shot and fill the role than play gatekeeper just because someone is coming from another industry. Sometimes it turns out really well.

Front-end engineering isn’t, universally, a first class discipline (although it’s getting closer to being one)

Something similar to the following happened twice when interviewing for very senior architect positions (including one that was titled something like “Front End Architect.”)

Hiring manager: “We want an architect whose focus is on the front end. You’ll lead projects, working with other developers and vendors, but we really want someone who can make a difference with the user interface layer. We see it as a game changer for us. ”

Me: “Sure, great. I’d love to come in”

Rob interviews

Feedback: “Rob was really strong on the front end, but he wasn’t as strong as we want him to be with Java/C#”

(So you actually want a Java guy? You want a Java guy who’s also an expert with JavaScript? Does such an unholy chimera even exist? )

The thing that drives me crazy about this scenario (beyond the fact that it’s a waste of my time) is that I’ve worked with architects who knew so little about JavaScript that they didn’t know enough to leave the JavaScript alone. I’ve seen very smart people completely break the UI because they were completely clueless about JS and didn’t even realize the depth of their cluelessness.

Up until they start breaking things, I’m cool with this. As long as folks delegate I don’t want or expect someone to be an expert across the whole system or to be able to code the whole system. I wouldn’t trust many of the absolute geniuses I’ve worked with to code the front end of any system. Just like they wouldn’t trust me to code up the services layer or come up with a database schema. But yet, in many organizations, you are simply not allowed to be in charge if you don’t have significant back-end experience. It doesn’t matter that the heavy lifting is happening in the browser now. It doesn’t matter that the potential advantage is in the user interface because there’s still an incredible shortage of strong front end engineers. It doesn’t matter than getting people to be effective at their jobs is a skill that stretches across technology domains. If you’re not a Java or C# expert, in some places at least, you still can’t straddle domains and run the show.

It is getting better

The good news is, the previous used to be universal. It’s no longer. I did interview for two general technology leadership roles (Director/VP) and those were judged on their own merits. No one once gave me the stink eye because I’m not a reformed Java developer.

Random notes

The Interrogation

  • I don’t like people who do tech screens like it’s an affront to their honor that you would even think you are good enough to work at their company. This doesn’t happen too often, but it does happen and I fill up with quiet rage pretty quickly when I encounter one of these people. When I run tech screens, I want to fill the role. I’m not happy when people aren’t up to snuff. I’m truly disappointed. It seems to me like these people would be happier to keep the role unfilled. That’s the absolute wrong way to approach the interview process. My reaction is invariably: “You don’t want me here? Cool, I won’t work here.”
  • I’ve been contacted by 28 separate recruiters in six weeks for various jobs at one company. I want to opt-out permanently please? I wish there was a central registry to opt out of contact by company.

  • I’ve got a hint for people who have been trying to fill roles for a six months or a year and can’t find anyone. Pay more money. Instead of losing out on some opportunity waiting to get someone at a 50th percentile wage and fitting it into some budget, push the pay envelope by 10% or more and people will be a lot more receptive. There are very few job descriptions I’ve seen in the Boston area, at any level, that had an aggressive (for the level) salary attached. There are some, but not many (maybe 10%.) Everyone else seems to think that being able to use new technology and getting free soda and coffee should be enough of a selling point to get you to choose them in the middle of one of the hottest skill sectors in the job market. The salaries seem to slot into very clear strata and there are few outliers. I know people are afraid because money is money and front-end developers should be worth $xxx. But if you have a need now, paying aggressively is one way to fill it that’s within your control. Everything else is outside of your control. Pay more than your competitors. Everyone is using Angular or other modern architecture. Everyone gives out free snacks and coffee and all that crap. You can’t win with that stuff.

And that’s it for now. I may add onto this as other trends percolate around in my brain. For the most part I enjoyed the conversations I had even if nothing turned out to be a perfect fit for me and I hope that people on the other side of the desk felt the same.

Front End Engineering Spectrum Poll Results

Posted on by Rob Larsen

The results of my poll are in. Thanks to everyone who filled it out and shared it. It’s much appreciated and it gave me some insight into where we are in terms of roles, organizations size and maturity and, probably most interestingly to me, what we’re called on out business cards.

Let’s look at the results.

Describe Your Current Role

The Hybrid 25 11%
Soup to Nuts 37 17%
Full Stack 53 24%
Markup Master 2 1%
Front End Developer 107 48%

As defined here.

Obviously, this isn’t a scientific poll1 and based on my audience there are going to be some biases in the makeup of this sample.

That said, it’s heartening to see so many of you focused on core front end technologies.

Also, I’m surprised that there were so few Markup Masters out there. I’ve interviewed a few of them over the past couple of years. I guess they’ve all been nudged over to being Hybrids or Front End Developers.

I feel for all you Soup to Nuts people. Here’s hoping you aren’t spread too thin.

What is Your Current Job title

CTO 3 1.4%
Developer 12 5.6%
Director 5 2.3%
Front End Developer 31 14.4%
Front End Engineer 11 5.1%
Front End Web Developer 5 2.3%
Interface Developer 4 1.9%
PHP Developer 3 1.4%
Software Developer 11 5.1%
Software Engineer 19 8.8%
UI Developer 7 7%
Web Developer 35 16.2%
Other 70 32.4%

I was surprised by the prevalence of “Front End Web Developer.” It makes sense, sure, but I was still surprised by the specificity of “web” being inserted in there.

The CTOs were all in smaller organizations (less than 50). It’s still nice to see people with the job title in this space, but I yearn for the day for a CTO who’s truly one of us at a big-time organization.

On that note, two of the Directors were from larger organizations (101-1000 and over 10000) so there’s light at the end of the tunnel. Let’s promote those guys.

Also, there was one VP :).

If you’re looking to standardize on something for your job titles, you should start with Developer as the foundation. It’s clearly the most common noun for what we do. I will say I was susprised to see the generic Web Developer title win out over something like Front End Developer. Not super surprised- plain old surprised.

Random notes from the Job Titles

There was only one Ninja2. To make up for it, there was a Kahuna.

There were only two people with JavaScript in their title. More people had PHP in their title than JavaScript. I don’t know what that means.

I was surprised to see only two people had Mobile in their title.

There were two Webmasters. Party like it’s 1999.

While cleaning up the data to do generic comparisons3 I learned that “Front-end” vs. “Front End” was a thing. I write Front End, but a lot of people hyphenate it. I don’t judge.

There was not one “Creative Technologist,” but we did have a “Computer Scientist.” That’s one in the win column. I’ve never liked the phrase Creative Technology. I don’t know where it came from or what it really means, so I’m pleased that it didn’t show up.

There were no Managers or Senior Managers. I’m mad at all the senior Sapient people I know who didn’t fill this out.4

How Old is Your Front End Engineering Team?

Less than 1 57 24%
1-3 96 40%
4-7 45 19%
More than 7 40 17%

I knew the results for this one were going to stink. I chose 7 years because that was just about when Ajax was everywhere and forward looking companies would have had at least a chance of putting a focused team together. Unfortunately, not many of them did.

The teams in the poll were much younger, with the majority being less than 3 years old5. Knowing from firsthand experience what it looks like with a mature team and what it looks like with an immature team I can say, without hesitation having some maturity in your overall team is a godsend. It allows you create world class solutions and creates a professional, supportive structure for front end engineers. It also allows them to operate at a very high level even when key members leave. People are automatically groomed to step up.

Having to build up those structures can take a while, so organizations with more experience are going to have a real advantage.

Organizations with more maturity are also more appealing to work for because there’s a track record you can point to in the recruiting process. A lot of people say things like “this is what we want to do” when trying to hire talent in this space. Speaking from experience, there’s a big difference between aspirational talk and talk based on real-world results. A group that has already proven it’s worth is a much easier place to be than one where the value top front end engineering is still an iffy proposition. Building everything from scratch can be fun, but it’s not automatically so.

How Large is Your Front End Engineering Team?

0 (You Don’t Specialize) 33 14%
1 35 15%
2-5 110 46%
6-10 23 10%
11-25 18 8%
26-100 7 3%
100 or more 12 5%

I don’t know that there’s much to gain from this chart other than my concern with the prevalence of people who don’t specialize. What we do is hard to do at a high level right now and pawning it off on someone who’s also doing Java or design or… whatever doesn’t seem like the best idea to me. I know there are exceptions and I’ll have to analyze the data a little bit more to see if these are all shops, but it still concerns me.

I’m going to play around with this data versus the size of the organization to see if there’s something that shakes out there. Obviously a five person team in a ten person organization is more interesting to me and a five person team in an organization with more than ten thousand employees.

That’s what I’ve got. If you’d like, you can look at the full results. Feel free to share anything you notice in the comments.

I’m also going to follow up with an opinion piece that’s been brewing for a while. The results of this poll solidify the thought behind it, so the time to write it is now. Check back for that in maybe a week or two.

  1. as I am not a scientist, although I do like this Guided by Voices song ↩

  2. an HTML5 Ninja even ↩

  3. comparing titles without “Senior”, “Junior” or “Principal”, etc ↩

  4. I’m taking my ball and going home now ↩

  5. Which coincides nicely with the HTML5 era ↩