4 ms·

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 t

by borplk 14y ago

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.

timc3 14y ago
Nonsense. You just need to have a huge amount of experience which can be gained which takes time.
- borplk 14y ago
  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.
  - mdonahoe 14y ago
    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.
mdonahoe 14y ago
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!
borlak 14y ago
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.

by borplk 14y ago

timc3 14y ago

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

borplk 14y ago
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.
- mdonahoe 14y ago
  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.

mdonahoe 14y ago

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!

borlak 14y ago

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.