Startups: Don’t Hire Frontend or Backend Webdevs | Hacker News Reader

Startups: Don’t Hire Frontend or Backend Webdevs

trottercashion.com

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.

> 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).

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> :)

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.

Commonly, in 2.0 shops of few people: Client-side -> "frontend" Server-side -> "backend"

You're right that when the server-side gets nontrivial you need to stratify the architecture and the role definitions for the participants. At that point, "backend" means a just what you describe, and the business logic implementors are building what I'd call the middle-tier; it is seldom more than ORM retrieval, formatting and validation.

When you start involving ETL, algos, complex "systems" programming, deep integration with external vendors then you leave this paradigm and start having "real" backend devs.

Agreed. In my mind "front end" is HTML, JSP, CSS, JS/AJAX, Design, browser compatibility, etc... "Back end" is business logic/code development (Java in my case).

Yeah - That's a pet-peeve of mine: frontend and backend are entirely contextual. Some people would say backend about server side code. Other might split the server side code into two. Some times your application uses web services; Then people often refer to those as being backend for your application. Without further qualification, the words are meaningless.

I met with an angel once who seemed to feel frontend meant suits and backend meant coders. I completely misunderstood his question because I was thinking of the coders' definition of the terms.

Are you sure he wasn't talking about front-office vs. back-office?

Nope, never really followed up on it. We were just having an informal chat and that part was clearly confusing to both of us.

I've heard the same use of the words, although I don't recall the context. Pretty sure he was a suit though.

That's a very good definition. And by that definition I can clearly align myself to one of the two sides (front-end). I wish everyone would use it.

On the other hand I think most people are using the terms a bit differently. A front-end developer is a bit of what used to be called a web designer (html/css+ "photoshop" skills) with javascript newly added that's used just for client-side UI.

The backend people handle the database, business logic and everything else that's on the server. It actually seems like this world doesn't need those domain-specific algorithms people.

With this definition, I prefer to work on the backend, but I can also work on the front-end.

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.

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.

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.

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.

Agree with this. The front-end developer position should include design as well (as all web designers should have strong HTML/CSS skills anyways to correctly do their job).

"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.

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."

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.

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.

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

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.

> If you are lucky enough to hire that person, don't pigeon hole them.

I was thinking the same thing after reading "You’d be much better off getting one of your kickass API developers to spend a little time on the website portion, which would free salary space to hire another kickass API developer.".

My immediate thought is that you'd now have a front end developer. Unfortunately, it is your former API developer turned reluctant front-end designer, who is likely annoyed that his job description changed midstream.

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.

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! :)

> 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.

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.

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.

great front-end devs are sooooo rare.

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.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com