

Startups: Don’t Hire Frontend or Backend Webdevs - trotter_cashion
http://www.trottercashion.com/2010/07/07/startups-dont-hire-frontend-or-backend-webdevs.html

======
nostrademons
I'm kinda curious if his definition of "frontend" developers is the same as
mine. To me, the frontend includes everything up to the purely-computational
algorithms and storage of the website. That's the HTML/CSS/JS, but also the
webserver/webframework, RPC system, or database API (but _not_ the database
itself). Rails is a _frontend_ technology.

I consider backend work to the computationally-intensive part. Data mining,
machine learning, information retrieval, any domain-specific algorithms. High
performance storage systems. Managing server clusters.

It's very, very difficult to find both skillsets in the same person, because
both skillsets have incredible depth, particularly if you also want the
breadth that a pivoting startup will require.

I'm wondering if his idea of a startup is the typical web 2.0 startup, where
you slap a web framework on top of a database. Those startups are essentially
all frontend - in that case, it doesn't really make sense to hire "frontend"
or "backend" devs, just pretend that the whole world is frontend. There's
nothing wrong with a startup like that - mine was, as are most gaming, social
network, or social news sites (many iPhone/Android apps too, where frontend in
that case is the mobile SDK). But that space is getting increasingly crowded;
I suspect that many more successful startups will start needing people who can
do the algorithmic heavy lifting.

~~~
strlen
> _I'm wondering if his idea of a startup is the typical web 2.0 startup,
> where you slap a web framework on top of a database [...] I suspect that
> many more successful startups will start needing people who can do the
> algorithmic heavy lifting._

Couldn't agree more with you. Most of the current generation of start-ups is
extremely boring. Quite frankly, looking at Techcrunch headlines is
depressing. When you look at job requirements they post it's pretty much the
same: they're looking for people to write CRUD screens in scripting languages.
The current crop isn't about technology, it isn't about the people who enjoy
writing non-trivial software and couldn't be happier that some one out there
is willing to pay them for it (e.g., people mentioned in Graham's Great
Hackers essay; reading that essay felt like music to my ears when I first read
it and got me interested in the idea of startups in the first place).

This is opposed to those who see technology as just a means to wealth creation
(and there is absolutely nothing wrong with that, there are plenty of "boring"
problems that nonetheless benefit humanity when they're solved). That's not to
say the founders aren't smart: many are coming from top schools, leaving
Google etc... to start their companies; that makes it even more explicit that
they're not there to solve interesting problems, they're there for something
else. It looks like an awful waste of talent.

Out of the web 2.0 crowd, when you look at the successes, you'll also notice
that they're ones solving non-trivial problems (machine
learning/recommendation systems, graph algorithms, scalability and efficiency,
etc...).

I'd love to see more technology startups emerge (i.e., those who do something
technology-wise that no one else dares to try). It's a riskier route, but it's
also more rewarding: you'll be able to attract more passionate people who
would be more willing to actually take the risk even if the pot of gold isn't
in sight (e.g., without VC funding a 100mm+ valuation).

~~~
edanm
As a founder of a startup in the "boring" category, I really disagree with
your take on this.

I used to be all about the great technological breakthroughs, the really cool
algorithms, all the stuff you mention. But as I got older, my interests
shifted to other areas: making kickass applications that people love,
designing usable interfaces, etc.

"[T]hat makes it even more explicit that they're not there to solve
interesting problems, they're there for something else. It looks like an awful
waste of talent."

See, that's where I disagree. I think it takes a great deal of talent to
create software that helps people. It takes _different_ talent than creating a
great algorithm, but it definitely takes talent. That's why so much software
has terrible interfaces and is an unusable mess.

And it takes even more talent to create something which truly shapes humanity.
A lot of the companies that have made the biggest impact have no technological
breakthroughs whatsoever: it's all breakthrough on all those "boring" things.
Wikipedia, Facebook, Twitter, they've all done amazing things by solving
"trivial" problems.

</rant> :)

~~~
daleharvey
I cant agree with this comment more, even when I look at the problems that
exist in my life (which is far more inclined to be technical than average),
not a whole lot of them require technical breakthroughs or "exciting
programming".

Music and TV streaming would be one for me that has only been solved recently
for me (by spotify and tvcatchup), the streaming problems have been long
solved, but convincing the stakeholders to be a part of this business took a
long time with many failed attempts, even now spotify arent able to launch in
the US because of these problems.

Online banking and micropayments would be another problem in that category
that has not been solved as yet. while writing an online bank is hard, it is
still at the core a crud system, however its impact on users lives are
massive.

While I do love programming, I have come to realise it isnt the technical
challenge I enjoy, its the benefits I can bring to peoples lives that I really
enjoy.

------
tonystubblebine
I have a five person team and the fifth person, a front end developer, is a
frickin' godsend. He has a design sense. He knocks out new designs and design
changes in minutes whereas the rest of us take days to come up with crummy
looking updates. My lesson in this: as you grow you'll find your team has
holes that need patching. Go and patch them.

~~~
mattew
So many developers underestimate the need for good, quality visual design and
aesthetics in their work. In my experience most non programmers evaluate
something first on how it looks, and if it doesn't look good, they won't be
interested in how well it actually works. Most programmers on the other hand
seem first to be interested in how well it works, without taking into account
the look and feel.

~~~
johnrob
I'm surprised this isn't one of the main concepts that repeatedly gets mention
on this site. We obsess over 'make something people want', but never drill
down deeper. Good design can go a long way toward making people want
something.

I'm willing to bet that mint.com got a fair amount of popularity (and
memorability) because it was so nice to look at.

~~~
aaronblohowiak
It really depends on the market and your positioning in the market. pg's
startup didn't have awesome design, but it served a need that people had in a
way that worked. "make something people want" doesn't have to mean "make
something mass-marketable", though it frequently does.

------
efsavage
"Most small startups (by which I mean fewer than 20 people) don’t have enough
work..."

What? WTH kind of startup is short on stuff to do? If you have 2 general-
purpose devs, they're going to be 100% busy. if you have 1 front-end and 1
back-end dev, they're going to be 100% busy. If you add another dev, that
person is going to be 100% busy, whether they're front-end or back-end.

~~~
nerme
If there are two guys, one guy working on server-side code and another guy
working on client-side code, either side could get held up waiting for the
other guy to finish his part of the project.

Even if people aren't waiting around for something to be completed by someone
else there is an overhead in communication. "Oh, you wanted the LIs to have
that class name? Well I've got to go fix my CSS now... gimme a few minutes."

------
troygoode
The problem with this notion - as mentioned by a few people in the article's
comments - is that it is difficult to find developers with a high level of
expertise for both sides of the fence. Is it worth the extra expenditure of
time in the hiring process to look for two people who are good in both realms?
Or is it better to spend less time looking for one front-end expert (with
passable server skills) and one server-side expert (with passable client
skills)? My experience interviewing/hiring suggests the latter.

I will concede the obvious: if you find someone who is great on both sides,
HIRE THEM. If you are lucky enough to hire that person, don't pigeon hole
them.

~~~
btmorex
You can also just hire someone who's smart and willing to learn. I mean web
development isn't that hard. I know everyone wants to hire someone who meets
every single one of their many requirements (we've all seen the job ads), but
realistically how long is it going to take a smart developer to pickup say
Javascript + whatever APIs you're using? A few weeks? You could easily spend
months trying to find the perfect hire.

~~~
mattmanser
lol, web development isn't that hard? Dream on.

~~~
oscardelben
It's not that hard compared to other skills. Anyway web development includes a
lot of stuff, and you can really go low level if you have to implement
algorithms and address scalability.

------
dasil003
I agree with the idea that specialists are probably not a good fit for an
early stage startup. There are a lot of hats to wear. But front-end vs back-
end is a false dichotomy.

If you can get your hands on a brilliant illustrator who can also do pixel
icon design as well as strong layout and UX , then even if their HTML skills
are shakey they're going to be a strong asset. Similarly, if you have a back-
end dev who writes really solid, performant, maintainable code and can handle
infrastructure and sysadmin work (eyeballs drifting involuntarily in Zed's
direction) then who cares if he has no experience stitching together CRUD apps
with the framework dujour.

In other words, hire the best people you can get your hands on and put their
skills to use.

~~~
hammerdr
Yes!

Draft for talent, not for needs.

This has been proven time and time again that people that grab the top talent
in a limited talent pool (rather than trying to address their perceived needs)
are the most likely to succeed.

The best analogy is sports. In (American) football, the Colts' Bill Polian
regularly uses this strategy in the draft. In football, ManU's Sir Alex has a
strategy to acquire what he calls "characters." While you may not like either
of these teams (I love them both! :) you cannot deny that they have been among
the most dominant franchises under their managers.

The real challenge is to somehow identify the best talent! :)

------
ibejoeb
> Most small startups (by which I mean fewer than 20 people) don’t have enough
> work to justify splitting the team into frontend and backend components

I disagree. Most startups have a _ton_ of work, but they often don't have the
money or the structure to support a large engineering team. Those switch
hitters that traverse the stack are really important for these situations.

There's an added benefit, too. Since one gets to that level by having done a
lot of different jobs in a lot of depth, that "macro" view tends to be
extremely valuable in sustaining the technology through growth.

------
jgilliam
What I've found works well for me, and is gettable, is a designer who can do
HTML/CSS/light Javascript. Then I do the rest.

------
dotBen
Yep, absolutely. But in reality there aren't that many brilliant developers
who can do both with skill and you are lucky if you can find them AND convince
them to join you.

To attract those, you're going to have to have a big offer (both remuneration
and the nature of the startup) to attract these folks.

Another school of thought is find back-end devs that can do some ops (although
yes, it's ideal to have that as a separate position if possible) and front-end
devs who can also do UI design and usability. You will need these two hats
too.

~~~
aaronblohowiak
great front-end devs are sooooo rare.

------
terra_t
In my experience, successful RIAs require close co-design between 'client' and
'server' components. Many people think they can "encapsulate" these issues
away but distributed systems break most people's assumption.

You can have people who are database experts, Flash or HTML "designers" or mad
javascript, actionscript or Silverlight coders -- but if there isn't somebody
in charge who understands distributed systems and the restrictions that exist
on RIAs, you are d00med.

------
d0m
I don't really agree. Front-end web developer have totally different skill
than back-end developer. In a startup where there are few employees, the
front-end developer can work extremely well on "design" part of all aspect of
the company.. Video sh outcast, publicity, marketing, even building design.

As, back-end developer can do a lot more then back-end service.. they can work
on backup, administrative unix task, optimizing task, inner-house tools, etc
etc.

So I think it's more like: Design=front-end, ComputerGeekStuff=Back-end.. and
it's really rare to find someone that does both of those things.

------
rdl
For a consumer web app, I would split it into a Product Designer (someone who
can do art, UI design, product concept, workflow, html/css/js), and a
developer (who does some js, all server side work, and the related tools.

Finding the product designer is going to be the hard part -- there are a very
limited number of visually oriented product designers who can also code. I
think that person should either be a cofounder or hired as first employee with
1-5% of equity; on par with a later VP Engineering hire.

------
iamdave
The point being missed is this:

Does the flexibility of your salary options translate to a better product, or
does a better product translate to the flexibility of your salary options?

If your answer is the latter, then it makes much more sense to hire front-end
and back-end developers to focus on their respective niches; front-end devs
focus on making the product usable and keeping users engaged. Back-end devs
focus on making sure the product functions, builds features that evolve out of
user interaction and keeps those features running.

When you try to combine these niches and ask a guy to play both front-end and
back in his priorities become conflicting and your product becomes one of
those sites that was either "Built by a designer" or "Designed by a
developer".

Don't hire an architect to do an engineer's job, is what I'm saying. They play
similar roles, but they have very different focuses that can directly impact
the final product. Exceptions exist.

------
heatdeath
Frontend and backend are different skill sets and proficiencies. Backend is
more analytic, frontend is more aesthetic. I've never worked at a company that
didn't have this distinction; people tend to naturally go one way or the
other.

------
arijo
I think there's a bit of confusion here between designer and front end
developer. A front end developer to me is someone with extraordinary
javascript skills capable of working on new generation rich client/thin server
web applications.

<http://www.javascriptmvc.com>

is an example of a javascript framework a front end developer would use to
build this next level type of applications.

------
wookiehangover
God forbid you're grouped into a caste of skill sets based on experience
and/or expertise. If you started off with a homogenous group of developers and
set them to work on building an MVC app, the group would eventually split into
who favors scripting, css and markup versus those who prefer writing business
logic.

Hire what your team needs. If you need a duct tape dude who can do a little
bit of everything, great. If you actually assemble an entire team of those
guys, good luck.

