201–210 of 231 posts
Earlier quoted context omitted.
The counterpoint to this is the C developer who promises they can scale up to C++ and then takes a disproportionate amount of review time to be taught not to use malloc/free/new/delete/etc.
Educate me, pkease: why no new or delete? Does C++ now discourage heap allocation or is the common practice to use smart pointers, etc.?
Earlier quoted context omitted.
I have noticed that when interviewing, the more specialized technical people often look down on full stack engineers, whereas managers are more excited about it. I consider myself full stack, but in my last role I presented myself as a frontend engineer, with some backend experience. Eventually this role just kinda expanded into both frontend and backend. Now that I do contract work, I present myself as whatever they…
I actually dislike the term "full stack engineers". "Full stack applicaton developers" is slightly better, at least it's limited to a single output (the app). I would not trust them with the design of an airplane, nuclear plant or military submarine, all of which are engineering tasks. 30 years ago, every app developer was "full stack", and the concept didn't even exist. As apps moved to the web during the dot-com er…
If you specialize in something and it stops being relevant you might have little marketable skills to contribute. This would be like putting all the eggs in the same basket.
If you are a generalist you are protected from such a scenario since you put the eggs in several baskets.
But as a generalist you might be missing specialist opportunities so, of course, it's a bit of a tradeoff.
In this sense, it can be rational to be a generalist. However, every person's experience is unique so it's hard to say that one thing is better than the other without further context.
Pro tip: you're not a generalist. A big chunk of specializing is how you package/market yourself. I consider myself a "full stack employee". I've done backend, frontend, hosted live events, some sales, marketing, a dash of HR, pretty much everything. Do I write that on my LinkedIn? Heck no. A year or so ago I looked at all the experience I had, saw I had a through-line story of how I've worked on video projects over…
I have noticed that when interviewing, the more specialized technical people often look down on full stack engineers, whereas managers are more excited about it. I consider myself full stack, but in my last role I presented myself as a frontend engineer, with some backend experience. Eventually this role just kinda expanded into both frontend and backend. Now that I do contract work, I present myself as whatever they…
Best bet is to play to the crowd from my experience. Management class: tell them how much you've done. Engineering class: tell them how well you've done something.
Being a generalist also, IMO, makes you a more effective manager for crossfunctional teams, and gives you empathetic understanding on how the sausage gets made across the board, instead of just in a single domain.
But as others have stated, you can be both a skills/technology generalist while also framing yourself as a specialist. As I alluded to with my personal history, I consider and frame myself to be a startup specialist due to my broader base of skills.
I can provide perspective from both sides of the table, to add to the wonderful comments already posted. The first few years in my career were a will-do-anything attitude. So yes, like the OP, I did a bunch of different things. A few years in, I harbored similar thoughts of feeling inadequate. A jack-of-all-trades-but-master-of-none. Especially, since I was at Google and was surrounded by the best of the best and exp…
I'm usually jealous of a specialist for about 6 months to a year. Eventually I learn enough about what they do to lose interest and become jealous of a new specialist.
Currently 35, started CS degree at 17. I've thought about some of this recently, and while I don't regret being able to jump through the tech stack, or even do a sales call or set up a marketing funnel, there are definitely a few issues that come to mind. 1) If you jump tech stacks you're going to have to spend time getting to know the layout of the neighbourhood. Avoiding jumping across ecosystems will save you time…
Anyways, your comment resonated with me and I appreciate it.
Earlier quoted context omitted.
I have noticed that when interviewing, the more specialized technical people often look down on full stack engineers, whereas managers are more excited about it. I consider myself full stack, but in my last role I presented myself as a frontend engineer, with some backend experience. Eventually this role just kinda expanded into both frontend and backend. Now that I do contract work, I present myself as whatever they…
The reason why technical people look down on full stack engineers is because they are usually just web developers. Web development is one of the easiest and over saturated areas of software development. That is not to say web development is easy, it's just "easiest." It's hard for a full stack engineer to see or admit to this because of bias, it's much easier for someone outside of web development to see it, or a mor…
To give some context here, yes, when people refer to full stack developers, they're usually referring to developers who are focused on web development, but that would also include API development, or even mobile development.
I don't think anyone thinks of full stack developers, as developers who know embedded development or compiler development, so I don't know anyone who looks down on them for not knowing these things.
> It's hard for a full stack engineer to see or admit to this because of bias, it's much easier for someone outside of web development to see it, or a more well rounded engineer to realize it.
Now obviously, the way that you put it, it's extremely difficult to say why you're wrong, because you've started by adding a bias to people who would defend it. So maybe, when you want to have a discussion about it, don't start by stating something that makes it extremely difficult to argue against it without being seen as having a bias.