Tag: philosophy

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 ↩

Please Fill Out My Front End Engineering Roles Poll

Posted on by Rob Larsen

As you may know, I’ve spent some time thinking about front end engineering at a higher level than just the code that we write and the technologies that we use. I’ve written about what we do both in terms of the flavors of front end developers that exist and in terms of the roles that we slot into at work.

The two posts on the subject are:

The Front End Engineering Spectrum- The Three Generic Types of Front End Engineers
and
The Front End Engineering Spectrum: The Roles

Check them out, I think they’re pretty cool.

These posts have resurfaced a couple of times recently and in reviewing them I thought it would be interesting to see where people’s experience plots against those roles.

To that end, I made a quick poll.

If you’re the “front end” guy or gal at your job, please fill it out. It will only take a minute

Check back here May 20th when I’ll share the results. The poll will close next Thursday, May 16th at 11:59 Eastern time.

Fill it out below, or if the form isn’t loading, at this link.

Also, please share it far and wide!

If You Want to Share Code, Please Add a License

Posted on by Rob Larsen

This has come up a few times recently (example), so I thought I’d point it out here for all the world to see.

If you’re sharing code on a blog, Github or anywhere else you think people might find it and want to use it, please license it in some way. If you don’t, it won’t be used the in the way you might want and expect.

Let me explain.

Many organizations are friendly to open source software. As a consultant and “agency dude”, I’ve seen far more companies that were happy to use open source software than companies who were completely freaked out by the prospect (although I have seen a few completely dysfunctional organizations that wanted to pay money for horrible solutions just because they had the fear.) This is a good thing because 10-15 years ago that wasn’t the case.

The thing is, and it seems some people don’t know this, unless you explicitly license your code, your software isn’t magically open source or free to use.

The lack of a copyright notice or license doesn’t mean you don’t have a copyright on it.

It is, in fact, the complete opposite.

In all countries where the Berne Convention standards apply, when you make software you automatically own all the rights to that software– even if your intent is for it to be free for everyone to use and you hate the very idea of software patents or copyright. Without a license allowing people to use your code within acceptable guidelines you are the only person that has a legal right to use it. While you probably won’t turn around and sue everybody that uses your code (because hey, you’re cool and you wanted to share it with everyone in the first place), there’s also nothing stopping you from changing your mind later and sending out nastygrams asking for big bucks from everyone who ever even sniffed at the code. Right or wrong, that would be your legal right.

And that’s why we need licenses. Any organization (or, really, individual developer) with any sense is going to steer clear of a situation where they might end up having to call their lawyers. Using software without explicit permission is exactly one of those situations.

So, if you’re doing anything that people might find interesting please think about how you’d like to see it used and add a license.

I use what’s commonly referred to as the MIT license because I can understand it and it allows people to do whatever they want with my code.

You might want to choose something else.

That’s cool, as long as you make a choice and let the rest of us know about it 🙂

My New Job

Posted on by Rob Larsen

I’m late with this post. I’ve been busy! Finishing this post has been tougher than I imagined it would be.

Starting a new job is tough enough, adding in two visits to New York, one to Toronto and getting ready for HTML5 Live have made it even tougher. I think I’m through the toughest part of the transition now, so here I am, writing like a madman.

Anyway, I promised to talk a little bit about my new job. I won’t go into exhaustive detail, but I know some of you are interested, so I might as well get it out of the way now, before it doesn’t feel like a “new” job any more.

As I mentioned previously, I’ve moved over to Sapient Global Markets. My title is Senior Specialist, Platform.

As for what I’m doing, my job splits into three basic components- thought leadership, building a world class front end engineering team and bringing cutting edge solutions to clients.

  • Thought leadership. I’m not a huge fan of the phrase, but “writing and talking about emerging technology” doesn’t fit as well in a job description. I’ve already been doing this as much as possible. The difference with my new role is that it’s written into my job description and mandated from up on high. So, now I’ve got scheduled time for the kind of activities (writing, speaking, open source work) that I previously had to fit in around client engagements (which rarely happened) or after hours in my “free” time. Hopefully you guys will get some benefit out of me being able to write a little bit more.
  • Building a team. I’ve been instrumental in hiring and have worked developing junior staff for a few years now, so I’m pretty comfortable with this aspect of the job. The two key differences here are that I’m basically starting from scratch at my new role and I’ll be looking to build a truly global team. I’m not 100% sure what the eventually distribution will be, but I’ll be filling out slots between Boston, India and potentially a couple of other spots around the world. Making sure a team with that sort of geographical spread feel like a “team” will present a new wrinkle.

    Another clear challenge is cultivating front end engineering talent in India. Traditionally, people doing front end work there are junior and are doing so as a steppingstone on their way to writing “real” code- C# or Java. The combination of looking ahead to getting to do “real” work and the limited experience these guys possess have conspired to make it tougher than it should be to staff front end engineers in India. Hopefully I can help to change that by getting young Indian engineers excited about the web as a platform and open standards in general.

    By the way, one of those roles is already open. We’re looking for a Senior Interactive Developer in Boston. Come work with me. It’ll be fun. Shoot me an email, if you’re interested.

  • Client Work. The interesting challenge at this job is that I’ll be working with clients who are much more conservative than some of the organizations I’ve worked with previously. Educating some of the financial services giants on the power of the open web platform and delivering work that leverages those technologies in novel, but concrete ways will be an ongoing challenge. The good news is many of the cooler open web technologies are tailor-made for markets based businesses, so I’ll be selling them on Canvas, SVG, WebSockets, etc. Should be fun.

And that’s it. That’s the new gig. It’ll keep me busy for a while, I think.

On Interviewing Front End Engineers: Be Prepared (or at Least Pretend You Are.)

Posted on by Rob Larsen

On more than one occasion I’ve been interviewed by someone and they’ve told me, point blank, that they “didn’t prepare at all for this” or “didn’t even look at your resume.”

Really?

While this is lame no matter what industry or role, with front end engineers it’s incredibly frustrating.

Throughout the “Ajax era” any other experienced front end engineer has been interviewing from a relative position of strength. In my personal situation, I’ve been employed over the past five years by good companies, working with people I like and respect; but anyone with a strong background in HTML, CSS and (especially) JavaScript who is looking for a job is going to have several options available at any given time. That’s just the nature of the industry right now. We’re in an extremely fortunate place right now.

So… with that in mind it should be clear that if you’re hiring on the front end you have to actively recruit. This is just the reality of hiring front end engineers. Everyone wants someone great and there just aren’t that many great people around. If you find someone you’ve got to put forth some actual effort. I know all about this from both sides of the table. For example, we’ve had this role open at Isobar for ages and we haven’t found the right fit just yet.* There aren’t all that many people that fit those requirements.

So, what’s a candidate supposed to think when someone walks in and admits, in effect, that the candidate’s time and/or the role isn’t important enough to merit even minimum effort?

How is that recruiting?

It’s not, and speaking from experience, being on the other side of some of those comments it reflects poorly on the organization as a whole. People picked to screen and interview staff should recognize that it’s important for a team or organization. It should never be such a burden that they can’t even do the minimum, and in the rare occasions where it’s impossible to do proper set-up they have the common decency to pretend that they did so as to not insult the candidate. If the person you’ve picked to do interviews can’t do that minimum, it’s probably time to pull them out of the rotation.

Putting it simply: it’s hard hiring people that do what we do. You’ve got to take it seriously.

*Hopefully moving downtown will help us fill it (plus don’t you want to work closely with me? Wouldn’t that be awesome?)