Over-specialization is the curse of our profession | Hacker News Reader

Over-specialization is the curse of our profession

onebigfluke.com

25 pointsbslatkin52 comments

I disagree actually. I think having a specialization (front-end vs. back-end for example) is a good thing. It allows someone to dedicate themselves to one specific area and learn it thoroughly. When I'm doing back-end development, I love having a front-end guy who can make it look pretty - I don't want to have to use time/energy up doing that when I'm concentrating on making a secure, fast, maintainable back-end.

However, there is a limit to this. A back-end guy should still have some idea what goes on front-end and vice-versa. So, the key is to be an expert at what you're best at, but not to be a dummy at what you're not as good at.

[On a side note, I don't see why specialization should create contempt. In my opinion, it should breed appreciation]

What you said:

"When I'm doing back-end development, I love having a front-end guy who can make it look pretty"

How that sounds to me:

"When I'm done with a hard day's work, I love having a wife at home who can make me a drink"

Seriously! Read what you wrote.

Hehehe, that's a good one. But we both know what he meant :)

I don't think I understand the analogy? If two people are working on the same project and one enjoys and specializes in front-end development and the other enjoys and specializes in back-end development, and the project is roughly 50/50 front-end and back-end, why on earth should they NOT split up the project accordingly? They will both enjoy working on it more, they will get it done faster, and with better results than if they each took half the front-end and half the back-end work. Neither partner is "exploiting" the other or anything like that (as implied by your analogy); it's just in their mutual interest to divide the work in this way.

He was saying that the phrasing, from a back end guy, revealed exactly the lazy attitude that was described in the post.

When a back end guy says, "Hey front end guy, make it look pretty" -- that's not showing much appreciation for what they actually do. Front end guys: is what you do just making things look pretty? Or maybe it's closer to understanding how people actually use a product. And designing a UI that can cater to both novices and experts, etc.

Here's the reason I said that: "No matter what I try, I can't make it look pretty. I realize I'm such a horrible artist/designer that no matter how much effort I put in, it's always going to be an ugly mess if I do the front end. So what I appreciate most is them making it look pretty. Other aspects of the jobs I can do better, so it's not quite as important to me to have someone else doing it. Perhaps it is a "lazy" attitude, but it's not a condescending one. :)

But that's not what front end devs do. Maybe you could say that's what designers do. Front end dev != designer.

It all depends on whether you take "make it look pretty" as an insult or just a simplified statement of what a front-end person does.

I, for one, read "make it look pretty" as "make it look like something people would want to use".

relevant (figure of speech) > http://en.wikipedia.org/wiki/Lipstick_on_a_pig

When I'm doing front-end development, I love having a back-end guy who can flip the switch and turn it on.

I agree with this, but for a different reason.

Having specializations work for developers, not against. Consider all these technical lead sort of job openings in start ups asking the developer to execute everything from being archetecture to test/development to deployment. If you want to subject yourself to this, by all means, but keep in mind that there are developers who just want to go home at 5.

This is really interesting. It makes a nice template when the subjects are different but the sentiment is the same.

For example:

I'm sick of the distinction between developers and operators.

The developers think they're hot shit because they solve the big problems. They know how to scale. They look down on operators who are only solving trivial problems. Developers build the real things. They don't have time to learn about Apache configs or how to determine how many servers to allocate to a task. Without them, a project can never be successful.

The operators think they're hot shit because they're the closest to the metal. They know to perfect an infrastructure. They look down on developers who have no idea how the product is actually run and who don't get woken up at night when it breaks. Operators build the real things. They don't have time to learn about the rails stack or wretched languages like JavaScript. Without them, a project can never be successful.

You're both wrong. You must do both or you'll be irrelevant (somewhere).

Over-specialization is the curse of our profession. Stratification breeds condescension. The only remedy is for all engineers to do devops.

Ditto with Dev vs QA.

Ditto with Dev vs BA.

Ditto with Dev vs DBA.

Looks like the recurring theme here is Dev vs X

nice point. I first read the article as:

I'm sick of the distinction between Surgeons and physicians. The surgeons think they're hot shit because they solve the big problems. They know how to cut. They look down on physicians who never get their hands dirty and don't know how the body is put together. They get up in the middle of the night to save lives, and sacrifice their own to make this happen.

The Physicians think they're hot shit because they're the closest to the patient. They are masters of social interaction. They look down on surgeons who think that the answer to everything is to cut. Surgery should be a last resort, not a first.

Over-specialization is the curse of our profession. Stratification breeds condescension. bla bla

Good luck being a decent front-end and a decent back-end developer.

Besides their different nature. The volume and amount of knowledge is too much to be able to do both at a decent level unless you sacrifice your personal life or you are some sort of super talented nerd.

If you dedicate 24 hours a day to both, there will always be someone who will dedicate theirs to only one. You can't beat that competition and it is only going to get worse from here as the technology develops and both of these streams will become more sophisticated and require more knowledge and experience.

Yes, back in 1980s a programmer could easily do both because front-end wasn't much more than some simple html tags. But not now.

Front-end and back-end go hand in hand and it is good to familiarise yourself with which ever you don't specialise in and recognise and appreciate its importance but if you try being both you'll most probably end up being a half-arsed back-end developer and a half-arsed front-end developer.

Nonsense. You just need to have a huge amount of experience which can be gained which takes time.

There will always be a lot of people who have spent their time focusing only on one of the two.

If you have put in the same level of effort, he/she will have twice as much experience as you in which ever of the two they have chosen to specialise in.

Yeah, but as soon as they need to bridge the gap, they have to enlist help from someone else.

And when they find that person, they have to communicate their needs using voice or text rather than raw thoughts. Need to change requirements? Send another email or walk over to your partner's desk.

Never underestimate the cost of communication.

There is plenty of value for people who can do both. Or at least most of one and a good amount of the other.

I have become a generalist at a company that definitely has distinct frontend and backend teams. I started as backend dev but started doing frontend work too. I have found myself in great demand due to my unique role at the company.

Since I know a lot about the entire tech stack, I can act as a routing agent for product managers and other non-developers. They ask me questions, and I can give them a pretty good answer. If they need something done, I can refer them to the specialist who wrote the code that needs changed.

When I am coding small tasks, I can write both sides of an API much faster than it would take two devs to negotiate the requirements. Communication is a time sink. Rather than writing emails or tasks requests, I can just write code and be done. There is a threshold though where it is better to split the work. There is only so much I can hold in my head at once. But even then, I find I am better at communicating because I know how both sides work.

Does the project have a nasty bug that needs tracking down? The generalist can lead an investigation the whole stack, asking specialists when needed. Last week I solved what our CTO referred to as "the ninja bug" that had plagued another team for months. The root problem was on the frontend (ios client), and I pushed an instant fix by updating our server code to compensate.

Lastly, some companies have skunkworks projects with very small teams. Being able to own both sides of a task means fewer people required to do it. I have become the goto guy for whipping up prototypes. I typically work directly with our CEO to create a proof of concept as fast and cheap as possible. When things look promising, we bring on more specialized devs and I lead the project.

You may not want to be exactly 50/50, but definitely be aware of how the other side lives. And dont be afraid to ask for a role change to broaden your skill set!

Agreed, there is simply too much to know, for someone who programs as a day job. At my previous job, I was becoming the DBA, and I actually quite loved it, as it was a fairly complicated setup w/high traffic.

At my new job as purely backend developer, I found my previous software skills rusty. A couple months later, I am a strong software developer again, but ask me a DB question and it will take me a minute to bring it all together. Sadly, the area that was once my strongest has become weaker. If I wanted to keep up on my DB skills, I'd have to be studying/reading DB on the side, which I don't have time to do considering I'm a family man.

You cannot have everybody do full stack development and devops and [insert whatever specialization you have here]. I know great programmers that got stuck in another specialty (because my company tried to create such broad specialization employees) and left, because they were only interested in a field, like backend programming or mobile. But they never said "I don't want to do sysop because it's not hot", they said "I don't want to do sysop because it's not my job".

I'm a programmer that now trains as a DBA+sysop and I like it. I saw condescending (brogrammer style "I'm way cooler than you") types in both camps, but usually from the guys that never tried to understand somebody else('s job). For my colleagues I tried to create small presentations like "this is what a DBA can do to help you and this is the way you can help them" and "what an usual programmer knows about databases" to bring the camps closer together and to understand eachother.

And the author is also wrong, because he thinks that all software is made up of a frontend and a backend.

Unless, of course, by "our profession" he means "us, the people who can only code web apps"

I think it was just an over all generalization. I wrote my opinion based upon reading this article and i am not even remotely doing a web app for over 7 years. It is mostly embedded / networks / c. Still i didn't feel like he was talking about web apps only. Full stack - front vs back end are standard terms often mentioned in recruiting at all big name companies as well as startups

Hm hm hm. Ok.

That must be regional then. Where I'm located (the Netherlands), these terms are very much web app only. Nobody working in embedded systems would call himself a "full stack engineer". Stack? What stack? I make robots move!

I disagree too.

I've tried many a time over the years to do good front-end work (especially where web apps are concerned), and I've concluded that I suck at it. Really. The things I find appealing are entirely orthogonal to the rest of the world, especially that cool school of UX engineers. I'm generally content with synchronous http requests, and adding Ajax is always an afterthought.

As a result, I stopped making crap websites for people. I started making nice backends, and who doesn't love a nice backend(?).

Everyone (especially me) is a lot happier when I'm not breaking the look and feel of a site/app/application/product, and I'm a lot happier when I don't have to care how it looks. I'll provide an API, and some other person can make it look good. That's the way the world works.

Asking everyone to be a full-stack engineer is a nice pipe dream, but consider the same in other professions. You'd be asking neurosurgeons to know the same level of detail as dermatologists, and vice versa. You'd be asking a Professor of Particle Physics to understand tertiary protein folding (as his biological counterpart might).

There is no such thing as "overspecialisation", only oversimplification of the job at hand.

I think everyone of us should try and specialize in at least one thing. That does not imply that you do your best to know nothing about relevant fields. For example if you are a web developer who works on Ruby on Rails and makes awesome web apps but don't like working on the front‒end, i.e HTML/CSS/JS then that is OK as long as you have some basic knowledge about those technologies and respect those who do work in that area.

Back to the specialization, I really think you should have at least one area in your chosen field where you have deep knowledge. How deep? On the above example - maybe you know internals of Rails + Rack very well. If you are on the front‒end may be you should have a thorough understanding of how browsers work, how HTML/CSS is parsed and rendered etc. I don't really have a good explanation as to why this is important but I've noticed that the really good web developers or designers tend to have at least one specialization or deep interest within their fields.

The computer graphics industry is highly stratified with only true independents being able to cut across different domains. This is probably because learning the skills required to be top-ranked in any given discipline is extremely demanding.

A highly skilled animator may not be the best modeller, and an amazing rigger might be terrible at texturing.

The software business is both older and newer than computer graphics. It's older in that people have been doing it since the sixties, but it's newer in that the "pipeline" has radically shifted several times in the last twenty years. Each new delivery platform, be it desktop apps, web apps, or now mobile apps often requires re-thinking how things are made.

The problem here is a lack of people who've spent time in different disciplines to understand them better, not that there are disciplines in the first place.

Well, I'll be the devil's advocate. What about Adam Smith? He noted that division of labor in a factory will increase its productivity and make the workers much more effective. While a software company is not entirely comparable to a factory, why does the same principle not apply? Devs who can concentrate on one part of the stack can become experts in that area, increasing their productivity--and consequently increasing the productivity of the company.

Adam Smith was pre-industrial revolution. He had no idea how far this would go. But he probably understood diminishing returns or hidden costs.

It's true that specialization is good for company, but you have to have right employees for that to work. If forced overspecialization makes your developers bored, they will be less effective at work, thus diminishing the effect of specialization. In addition, your best people will leave out of boredom, or require much better compensation to stay. Luckily for software developers, right now we have a choice to change jobs, and don't have to put up with things that people in most other professions have to.

You should read about the Toyota production process which showed that for more complex operations that was not the case.

Not to mention, in a lot of factories, although the labour is broken down into operations, operators will be trained in every operation and switch between them.

Also, I think working only on backend or only or frontend is kinda boring. I like to tackle the whole thing.

Looking at Software from the perspective of other engineering disciplines, I certainly wouldn't say that I see any over specialization. My dad, for example, is a structural engineer, with a PhD is fracture mechanics, who has spent most of careers specializing in cracks in welds and for the latter half of his career sub-specializing in cracks in welds in underwater pipelines. And even with all that specialization (and probably because of it) he has more work than he has time to do and is very far from being irrelevant.

The author provides neither evidence nor any logical argument for any of his claims.

He says "You must do both or you'll be irrelevant."

But there are plenty of examples of people doing cool stuff that is specialized.

Categorization is subjective. Both of those categories are so expansive that you could spend lifetimes learning to be better and never fully mastering them. The problem isn't camp A thinks they're hard shit and looks down on camp B, it's that young programmers / engineers think they're hot shit when they have a lot more to learn. Choosing a specialization is hardly ever a bad strategy, but it's important to keep prospective and be able to learn / play other roles.

I don't see what is wrong with having interest in one area say back end, having done it most of the time during your experience and hence have more relevant material on your profile. But still being open and able to do front end when needed. However, clearly lack enough exposure or substance on paper for that. To me it is the resistance to do any thing different from previous experience that is the culprit. Not the basic classification

Our industry is less specialized than even 5 years ago.. let alone 20. With better communication comes less specialization.

No. With better communication comes the opportunities to specialize even further as the market grow.

I've never worked in a business where there was a social stratification between specialists in the manner that was outlined in the blog that was linked to.

Deep specialization in one area with a narrow, but broad enough knowledge of other areas seems to be the norm to me now...and when I started working over a decade ago.

Really? What have you been doing?

Agree with the author on how over-specialization is a bigger curse on our profession than most others. But breeding of condescension is a rather petty justification for becoming a more broader human being/ programmer. Many bigger gains come from having ample breadth at personal and group levels.

That sounds totally wrong. As others have pointed out, specialization is the main ingredient in successful division of labor.

Read my variant at http://shezi.posterous.com/over-specialization-is-the-curse-...

I'd say your variant doesn't work because there's a hierarchical relationship between white-collar and blue-collar workers (one is hired by the other). This is not true for frontend vs. backend engineering in my experience. They are supposedly equal peers.

Not necessarily. A guy working in the workshop of a mechanic vs. a secretary in the same shop don't share the hierarchy you outline, yet the piece still works.

In any case, it was just a cheap shot at the silly point that specialization is bad.

Over specialization is for insects

Front end developer should rather work on his designer skills rather than backend stuff. Not being able to design cool interface makes frontend dev boring to work with.

The issue is about ego and understanding, not specialization.

Fishermen probably think they're hot shit and that developers are useless people building addictive distractions.

its not very specialized at all

education is basically free, educate yourself on anything you want - front end, back end, devops whatever.

its your own choice and problem to not broaden your skills when the cost of doing so is so low.

but it would be super HARD to do both well

communication between developers is most important!

Reply on news.ycombinator.com