
Ask HN: Is full-stack developer is really a myth? - haidrali
I have been writing softwares for the last 4 years professionally. I used to be very energetic about learning new technologies, frmeworks etc and I used to work comfortability across UI&#x2F;UX, backend, database and deployments and trying to be full-stack developer. But after 4 years I am now realising that I can&#x27;t be equally good across all stacks and the badge of &quot;Full Stack Developer&quot; is seems to be myth as it leaves you &quot;Jack of all trades, Master of None&quot; so I am now more focused on server side development and DevOps. Please share your views on being a full-stack developer.  
Thanks
======
wu-ikkyu
What is mythological about it?

Some of us have teams that split up different functions (i.e. front end/back
end developers, DBAs) which makes one become more of a specialist on that
which they spend the most time on.

Other work set ups entail the person doing it all by themselves, which makes
them more of a generalist.

Just because you are working as a generalist doesn't mean you can't
reconfigure yourself to become a specialist, and vice versa. It just depends
on what you spend most your time on and how you divide up work between your
team.

------
jerrylives
Learn React / Redux / Angular whatever javascript bullshit that is popular
this quarter

Learn Go / Python and SQL.

Write an app using these technologies.

Congrats, you are a full stack developer.

------
samblr
Devops is kind of diminishing with advancement in docker, kubernetes and paas.
So full stack developer is not really a myth if only one sticks to one front
end tech right now. I think it's a good time to be full stack dev. Thinking of
being one beyond 5 years was probably difficult.

------
techjuice
It is very possible, I have done so for over 12 years. When you start out you
work on mastering certain levels (network equipment, switching & routing,
security, purchasing hardware for servers, workstations and other pieces of
infrastructure, programming languages to solve certain problems, programming
language internals, etc.) to creating automated deployment and security
systems across distributed architectures, to a couple of languages that you
literally develop in for 8 to 14 hours a day, even on weekends at times
(Python, PHP, Java, C, C++, Go, Rust) and add more as new ones come out to see
if they can help you in your work).

The best of the so called DevOps have deep understanding of the technology
they use (hardware, networking protocols, CDNs, programming language
internals, security issues with each language and operating environment
choice, etc.). It can be done, and specialization in many things for specific
things is a requirement for the very high paying jobs (Python, Java, C, C++,
Ruby, etc.).

As the more you know (theory and in practice due to hands on experience over
time) the more valuable you are and can make serious waves where ever you
choose to work. If you really want to get good at the systems and software
engineering sides use your favorite programming language and a new one you
have not used to fully automate all of your operations and development
deployment tasks.

This will force you to learn a new programming language (at least the core
concepts of it) and evaluate it to see if it can help improve things at work.
If it can, then you begin to get into the internals of the language and do not
forget many of the details as the start to become similar with other languages
especially since most are written in C or C++.

The hardcore engineers have the big thick books on their desks and read them
from the cover to the back on a regular basis, as we know that understanding
things at a deep level is extremely beneficial and financially rewarding. Four
years is a short period of time but if your doing heavy engineering then it is
possible to master multiple things but you have to have the time to do it
which is normally the hard part.

