6 ms·

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,

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 the past 7ish years, and decided "I'm the frontend WebRTC guy." I identified the spots of knowledge I needed to read up on to be confident (just a few gaps here and there) interviewed at a job, and within 10 minutes into the interview my future (now current) boss said "You're the perfect fit!". Because I was. I'm the frontend WebRTC guy with some sales/marketing experience, and they needed a frontend WebRTC guy with some sales/marketing experience. Before that, I was the Frontend DevOps guy. Before that, I was the Backbone.js guy. And before that, I was the Sharepoint guy (shhhhh don't tell anyone!) If you're interested in AI, just go poke around and find something in AI. Don't sweat it. We all got plenty of time, and like you said, as long as we can center divs and set up click tracking on a Wordpress site we'll always be able to put food on the table! :)

woutr_be 4y ago
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 need, with my current contract, I was hired to do frontend, but just started looking at the backend when running into some problems or questions about the data. There's always a point where they ask you "oh, you can work on the backend too?".
- micahbule 4y ago
  Specialized technical people often look down on supposed fullstack engineers because specialized technical people value mastery over familiarity -- something a lot of FS engineers really try to be exaggeratingly proud of. While familiarity with your stack is great for cross-cutting concerns, mastery is what truly builds great software, not to mention in a timely manner. Managers are excited about FS engineers simply because if they scoop up good ones, those who really know what they're doing -- masters of several areas of their stack -- they can rotate them effectively at a fraction of a cost, if not for free.
  - cerved 4y ago
    The idea that you can't be great at very different things isn't confined to software engineering. I think it's because most people can only master one thing so they can't imagine other people working differently
    - dijit 4y ago
      To be perfectly fair though even “mastering” backend is quite close to impossible. You’ve probably heard of the 10,000 hour rule, it’s a hard and fast rule to say that it takes roughly 10,000 hours of doing something to fully master it. Maybe not true in all cases; but consider the suite of tools you have to be practicing every day to do even a single role: VCS/DVCS, shell, OS fundamentals, build-systems, networking, DNS… now we have distributed computing concepts such as kubernetes and various DSLs, then there’s your programming language(s), their standard libraries, their extended contrib libraries. Completely non-exhaustive list and we’re already closing in on 5 years working full time for each of those. The sheer hubris of assuming you can throw together a few frameworks and understand 1 or 2 paradigms and then claim you know “the whole stack” is immature and exhausting; similar to the sysadmins of yore who could read QuickStarts and claim to know how to maintain software fully. Delivering business value is definitely what we’re trying to do, but when it comes down to it: engineering is understanding; and nobody can claim to understand everything, not with a straight face. Full Stack is either: the most senior you can be or the most surface level you can be. If the former: we can’t afford you and I’m not sure how you managed to keep all your skills up to date. If the latter then specialists will need to clean up after you anyway.
      - kilburn 4y ago
        Fist, the 10,000 hour rule is false common knowledge [1,2]. Second, splitting a general role ("backend engineering") in arbitrary atomic skills doesn't make sense because there's no end to it. Backend engineering -> OS fundamentals -> Driver programming -> Hardware design -> Boolean logic -> Set theory -> and so on... Third, all engineering roles have cross-cutting concerns. You do need some network knowledge to be a "backend guy"... but also to be a sysadmin, devops, etc.. It's not like all these roles exist in a vacuum and you're starting from 0 if you switch between them. Finally, most people that think of themselves as experts in some role, language or framework end up in the "1 year of experience repeated 10 times" trap. True experts are also somewhat generalists too, because you can't built a tall knowledge without growing the base too (pun intended). [1] https://www.bbc.com/future/article/20121114-gladwells-10000-hour-rule-myth https://www.bbc.com/future/article/20121114-gladwells-10000-... [2] https://nesslabs.com/10000-hour-rule https://nesslabs.com/10000-hour-rule
- laserlight 4y ago
  > Now that I do contract work, I present myself as whatever they need I realized that I should have done so for a contract work that I wasn't hired for. They told me that they were looking for someone specialized. I knew exactly that they needed a generalist, mostly because they were an early stage startup. They never hired for the “specialized” position they contacted me for, because that position shortly became obsolete.
- trashtester 4y ago
  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 era, the added complexity made some companies split their teams of entry level developers into front-end, back-end and database. Still, at that time, this "stack" was simple enough at the time that a good dev could learn the basics front-end, back-and and basic db work within a few years. So, a few years after dotcom, the "full stack dev" became popular, but really what they were delivering was the same as the app devs of the early 90s. But even within software, engineering is so much more than just making web apps or RESTful microservices behind the web apps, and the field is still grown rapidly. There is data engineering, machine learning engineering, infrastructure ("devops") engineering, operating system engineering, driver engineering, network engineering, real time system engineering, algorithm/library engineering, and I probably left most of the sub-fields out. So my main issue with "full stack engineers" is that I've met a few with (in reality) a fairly limited skillset who are quite overconfident about other aspects of software and the infra around software, who assume that the principles they follow when buildings web apps apply to all domains of software, and show a significant amount of hubris [edit] but still often failing spectacularly when trying to use their particular skillset in a somewhat different domain. I realize that this impresson of mine is based on a few bad apples. But I think there is something in this "full stack" concept that can contribute to some devs underestimating the the kinds of work that are normally not considered part of this stack.
  - woutr_be 4y ago
    In my last fulltime role, we were called “product engineers”, which I actually really liked. It highlighted that our focus was on building a product, and not necessarily on frontend or backend. Because there was so much more involved, we all also helped out with deployments, or looking through log files, or talking to the business about issues.
- deltasevennine 4y ago
  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 more well rounded engineer to realize it. Full stack isn't even the correct term for these engineers. They usually aren't truly full stack. They just "front end" and "back end", of the web development stack. AN actual "Full" stack encompasses far more. OS development, embedded development, compiler development, database development, graphics programming, are all really hard things that are missing from someone who typically refers to themselves as "full stack".
  - woutr_be 4y ago
    > The reason why technical people look down on full stack engineers is because they are usually just web developers. 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.
    - deltasevennine 4y ago
      >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. Yes, I'm referring to technical people who are specialists outside of "web development". >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. Why would i want to be told I'm wrong? People offer arguments in the belief that they are bullet proof so it's natural to say things that are harder to argue against. If you're a full stack engineer this excludes you from answering because you may be biased. I can empathize with how you feel. I guess there's two things you can consider here. Consider that you are biased and that the statement is correct. Consider that I, the person who posed the statement, is biased and wait for a programmer outside of web development who has experience working with "full stack web engineers" to respond with his own opinion. You would be biased not to consider the possibility that I am right, so strive to be unbiased.
- Aromasin 4y ago
  Echo this sentiment completely. I'm the only one in my team covering both hardware designs, software development, and sales. I'm not nearly as expert in any of these areas as my colleagues, but my manager can throw pretty much anything my way and I can run with it, and as a result generally do the best in quarterly reviews. From a managers perspective, if they can hire someone who can do 3 jobs for the price of one, then that's the best return on investment. However, an expert in an area will see through that. They know a job split 3 ways is a job 1/3rd done. I can get something working to a proof-of-concept level, but not to a scalable, problem-free one (unless given more time to work on something singularly). 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.
jhoelzel 4y ago
Kubernetes Devops guy checking in - this is the way! Also think about it from the company side: Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you?
- drewcoo 4y ago
  > Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you? Well . . . people always assume they have the answers, so they've designed an exact position to do what they think they need. But if they need it and can't fulfill the need themselves, they probably don't know what they need. The company, composed of vain people, is more likely to hire someone that solves their "exact" not-really-problem.
  - jhoelzel 4y ago
    In my opinion it's okay to not be able to pinpoint the exact problem, thats what I tried to imply by using the quotations. This is why I position myself as Consultant and Engineer, because you will know you have a problem with your cluster, and I should know how to solve it. When you are at the point, where your question is: "I need someone to fix my internal ingress-controller because traefik binds all services to the public one", you might simply need to open an issue with the developers of traefik. Yet if your problem is: "we would like to completly separate internal traffic from external traffic inside our own datacenter", you are looking for the kubernetes devops guy with the neccesairy experience.
- tinco 4y ago
  I'd rather hire someone who is effective and passionate about solving problems in a particular space. If I hire a full stack web developer, and then they burn out because I had only frontend tickets for them for half a year, that's not so nice. I don't mind rebranding your LinkedIn to make it look like you're the Kubernetes DevOps guy, as long as that means you're totally fine with working the DevOps for my Kubernetes clusters for the foreseeable future. In an ideal world we could shove around generalist developers to whatever is necessary at the moment, but the reality is each developer is a human with hopes and dreams and ambitions and not every role will fit those.
pleb_nz 4y ago
Centering a div == specialist /s
otikik 4y ago
We Share a similar Point and we hide it in a similar way. I also hide my Excel skills extremely well, they are to be deployed only on emergencies.
- dandellion 4y ago
  Nowhere in my CV does it say that I know PHP, so when I fixed a bug in an old PHP app my boss was quite impressed at how fast I got it fixed until I explained that I knew PHP, but I kept it secret because I didn't like working with it. He laughed and said next time he'd try to find someone else to work on the app.
f1shy 4y ago
One of the best pieces of advice somebody gave me, was along the lines: "if you are not interested on it, don't even think about touching it, not even with the light of a laser pointer, keep away from it, play it stupid" That was short after I started playing with sendmail configuration, and I started to be named "the expert" of sendmail... BIG mistake... So, yeah... just do not tell anybody your skills, if you do not want to use them.
- trashtester 4y ago
  There is an element of truth to this, especially if you don't have leverage. I've been there, too. Actually, there are two risks: - People (co-workers AND management) may cynically use you for the tasks that are menial, messy and boring and doesn't lead anywhere. You become the tech equivalent of a janitor or secretary. - People who see only one side of you think that that side is your only skill, not something you're able to in addition to your primary skillset. In both cases, if you decide to assume the role of a generalist but want to avoid these risks, you have to spend some effort to position yourself. These are the steps I would recommend: 1. When describing yourself, do emphasize the generalism. I tend to claim that I can do almost anything as long as it is technical, but I do some things quite slowly. In particular you need to communicate this with your manager. 2. Make sure you demonstrate the skills in the sides you have that you want to spend more time on. This means to volunteer for tasks of this type, and make sure to overperform on these tasks and market the result to decision-makers. This is perhaps the most crucial part, as it includes demonstrating an ability to show initiative and work independently. 3. Let people know that your time is valuable and costly. With managers you need to demonstrate that you can produce more value for them if they don't let you get stuck into something trivial. 4. With lazy/abusive co-workers, you may have to simply let them know that you're not the assistant they can hand over the boring part to. This may be more difficult than with the managers, especially if you're not good at marking your limits in a firm but polite manner. However as long as management want you to work where you provide more value, you can simply tell your co-workers something like "I'd love to help you with <insert menial task they prefent not to be able to do>, AGAIN, but I'm afraid I don't have much free time until Thursday from 7am-8am two weeks from now....". Or you can simply say "I'd love to help you with <same as above>, but I've been ordered to focuson <insert more interesting task>, maybe you can explain your need to my manager and have him approve this". One approach is to make it inconvenient for them, the other is to force them to admit some deficiency to management before you help them.
sph 4y ago
Don't use "full stack engineer", these days for recruiters and HR it means "knows Node.js and React", which is sad and frustrating. My Ask HN post about it: https://news.ycombinator.com/item?id=32317514 https://news.ycombinator.com/item?id=32317514
- quickthrower2 4y ago
  npm i nextjs … or whatever. Basically.
- Aeolun 4y ago
  But I like React and Node.js. It works fine for me.
  - sph 4y ago
    I never said they're bad. I'm saying that not very long ago, full stack means from system security, administration, being proficient with databases, backend and frontend development, and at least a couple languages under the belt. These days it just means frontend and backend, in the same language, often the same framework. The same term that was used to identify senior generalist engineers with extensive experience in the field, these days is used for any junior JS dev with a couple years of experience under their belt. Not their fault, it's the recruiters fault for appropriating the incorrect label instead of creating a new one.
zhdc1 4y ago
Excellent advice!

woutr_be 4y ago

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 need, with my current contract, I was hired to do frontend, but just started looking at the backend when running into some problems or questions about the data. There's always a point where they ask you "oh, you can work on the backend too?".

micahbule 4y ago
Specialized technical people often look down on supposed fullstack engineers because specialized technical people value mastery over familiarity -- something a lot of FS engineers really try to be exaggeratingly proud of. While familiarity with your stack is great for cross-cutting concerns, mastery is what truly builds great software, not to mention in a timely manner. Managers are excited about FS engineers simply because if they scoop up good ones, those who really know what they're doing -- masters of several areas of their stack -- they can rotate them effectively at a fraction of a cost, if not for free.
- cerved 4y ago
  The idea that you can't be great at very different things isn't confined to software engineering. I think it's because most people can only master one thing so they can't imagine other people working differently
  - dijit 4y ago
    To be perfectly fair though even “mastering” backend is quite close to impossible. You’ve probably heard of the 10,000 hour rule, it’s a hard and fast rule to say that it takes roughly 10,000 hours of doing something to fully master it. Maybe not true in all cases; but consider the suite of tools you have to be practicing every day to do even a single role: VCS/DVCS, shell, OS fundamentals, build-systems, networking, DNS… now we have distributed computing concepts such as kubernetes and various DSLs, then there’s your programming language(s), their standard libraries, their extended contrib libraries. Completely non-exhaustive list and we’re already closing in on 5 years working full time for each of those. The sheer hubris of assuming you can throw together a few frameworks and understand 1 or 2 paradigms and then claim you know “the whole stack” is immature and exhausting; similar to the sysadmins of yore who could read QuickStarts and claim to know how to maintain software fully. Delivering business value is definitely what we’re trying to do, but when it comes down to it: engineering is understanding; and nobody can claim to understand everything, not with a straight face. Full Stack is either: the most senior you can be or the most surface level you can be. If the former: we can’t afford you and I’m not sure how you managed to keep all your skills up to date. If the latter then specialists will need to clean up after you anyway.
    - kilburn 4y ago
      Fist, the 10,000 hour rule is false common knowledge [1,2]. Second, splitting a general role ("backend engineering") in arbitrary atomic skills doesn't make sense because there's no end to it. Backend engineering -> OS fundamentals -> Driver programming -> Hardware design -> Boolean logic -> Set theory -> and so on... Third, all engineering roles have cross-cutting concerns. You do need some network knowledge to be a "backend guy"... but also to be a sysadmin, devops, etc.. It's not like all these roles exist in a vacuum and you're starting from 0 if you switch between them. Finally, most people that think of themselves as experts in some role, language or framework end up in the "1 year of experience repeated 10 times" trap. True experts are also somewhat generalists too, because you can't built a tall knowledge without growing the base too (pun intended). [1] https://www.bbc.com/future/article/20121114-gladwells-10000-hour-rule-myth https://www.bbc.com/future/article/20121114-gladwells-10000-... [2] https://nesslabs.com/10000-hour-rule https://nesslabs.com/10000-hour-rule
laserlight 4y ago
> Now that I do contract work, I present myself as whatever they need I realized that I should have done so for a contract work that I wasn't hired for. They told me that they were looking for someone specialized. I knew exactly that they needed a generalist, mostly because they were an early stage startup. They never hired for the “specialized” position they contacted me for, because that position shortly became obsolete.
trashtester 4y ago
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 era, the added complexity made some companies split their teams of entry level developers into front-end, back-end and database. Still, at that time, this "stack" was simple enough at the time that a good dev could learn the basics front-end, back-and and basic db work within a few years. So, a few years after dotcom, the "full stack dev" became popular, but really what they were delivering was the same as the app devs of the early 90s. But even within software, engineering is so much more than just making web apps or RESTful microservices behind the web apps, and the field is still grown rapidly. There is data engineering, machine learning engineering, infrastructure ("devops") engineering, operating system engineering, driver engineering, network engineering, real time system engineering, algorithm/library engineering, and I probably left most of the sub-fields out. So my main issue with "full stack engineers" is that I've met a few with (in reality) a fairly limited skillset who are quite overconfident about other aspects of software and the infra around software, who assume that the principles they follow when buildings web apps apply to all domains of software, and show a significant amount of hubris [edit] but still often failing spectacularly when trying to use their particular skillset in a somewhat different domain. I realize that this impresson of mine is based on a few bad apples. But I think there is something in this "full stack" concept that can contribute to some devs underestimating the the kinds of work that are normally not considered part of this stack.
- woutr_be 4y ago
  In my last fulltime role, we were called “product engineers”, which I actually really liked. It highlighted that our focus was on building a product, and not necessarily on frontend or backend. Because there was so much more involved, we all also helped out with deployments, or looking through log files, or talking to the business about issues.
deltasevennine 4y ago
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 more well rounded engineer to realize it. Full stack isn't even the correct term for these engineers. They usually aren't truly full stack. They just "front end" and "back end", of the web development stack. AN actual "Full" stack encompasses far more. OS development, embedded development, compiler development, database development, graphics programming, are all really hard things that are missing from someone who typically refers to themselves as "full stack".
- woutr_be 4y ago
  > The reason why technical people look down on full stack engineers is because they are usually just web developers. 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.
  - deltasevennine 4y ago
    >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. Yes, I'm referring to technical people who are specialists outside of "web development". >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. Why would i want to be told I'm wrong? People offer arguments in the belief that they are bullet proof so it's natural to say things that are harder to argue against. If you're a full stack engineer this excludes you from answering because you may be biased. I can empathize with how you feel. I guess there's two things you can consider here. Consider that you are biased and that the statement is correct. Consider that I, the person who posed the statement, is biased and wait for a programmer outside of web development who has experience working with "full stack web engineers" to respond with his own opinion. You would be biased not to consider the possibility that I am right, so strive to be unbiased.
Aromasin 4y ago
Echo this sentiment completely. I'm the only one in my team covering both hardware designs, software development, and sales. I'm not nearly as expert in any of these areas as my colleagues, but my manager can throw pretty much anything my way and I can run with it, and as a result generally do the best in quarterly reviews. From a managers perspective, if they can hire someone who can do 3 jobs for the price of one, then that's the best return on investment. However, an expert in an area will see through that. They know a job split 3 ways is a job 1/3rd done. I can get something working to a proof-of-concept level, but not to a scalable, problem-free one (unless given more time to work on something singularly). 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.

jhoelzel 4y ago

Kubernetes Devops guy checking in - this is the way! Also think about it from the company side: Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you?

drewcoo 4y ago
> Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you? Well . . . people always assume they have the answers, so they've designed an exact position to do what they think they need. But if they need it and can't fulfill the need themselves, they probably don't know what they need. The company, composed of vain people, is more likely to hire someone that solves their "exact" not-really-problem.
- jhoelzel 4y ago
  In my opinion it's okay to not be able to pinpoint the exact problem, thats what I tried to imply by using the quotations. This is why I position myself as Consultant and Engineer, because you will know you have a problem with your cluster, and I should know how to solve it. When you are at the point, where your question is: "I need someone to fix my internal ingress-controller because traefik binds all services to the public one", you might simply need to open an issue with the developers of traefik. Yet if your problem is: "we would like to completly separate internal traffic from external traffic inside our own datacenter", you are looking for the kubernetes devops guy with the neccesairy experience.
tinco 4y ago
I'd rather hire someone who is effective and passionate about solving problems in a particular space. If I hire a full stack web developer, and then they burn out because I had only frontend tickets for them for half a year, that's not so nice. I don't mind rebranding your LinkedIn to make it look like you're the Kubernetes DevOps guy, as long as that means you're totally fine with working the DevOps for my Kubernetes clusters for the foreseeable future. In an ideal world we could shove around generalist developers to whatever is necessary at the moment, but the reality is each developer is a human with hopes and dreams and ambitions and not every role will fit those.

pleb_nz 4y ago

Centering a div == specialist /s

otikik 4y ago

We Share a similar Point and we hide it in a similar way. I also hide my Excel skills extremely well, they are to be deployed only on emergencies.

dandellion 4y ago
Nowhere in my CV does it say that I know PHP, so when I fixed a bug in an old PHP app my boss was quite impressed at how fast I got it fixed until I explained that I knew PHP, but I kept it secret because I didn't like working with it. He laughed and said next time he'd try to find someone else to work on the app.

f1shy 4y ago

One of the best pieces of advice somebody gave me, was along the lines: "if you are not interested on it, don't even think about touching it, not even with the light of a laser pointer, keep away from it, play it stupid" That was short after I started playing with sendmail configuration, and I started to be named "the expert" of sendmail... BIG mistake... So, yeah... just do not tell anybody your skills, if you do not want to use them.

trashtester 4y ago
There is an element of truth to this, especially if you don't have leverage. I've been there, too. Actually, there are two risks: - People (co-workers AND management) may cynically use you for the tasks that are menial, messy and boring and doesn't lead anywhere. You become the tech equivalent of a janitor or secretary. - People who see only one side of you think that that side is your only skill, not something you're able to in addition to your primary skillset. In both cases, if you decide to assume the role of a generalist but want to avoid these risks, you have to spend some effort to position yourself. These are the steps I would recommend: 1. When describing yourself, do emphasize the generalism. I tend to claim that I can do almost anything as long as it is technical, but I do some things quite slowly. In particular you need to communicate this with your manager. 2. Make sure you demonstrate the skills in the sides you have that you want to spend more time on. This means to volunteer for tasks of this type, and make sure to overperform on these tasks and market the result to decision-makers. This is perhaps the most crucial part, as it includes demonstrating an ability to show initiative and work independently. 3. Let people know that your time is valuable and costly. With managers you need to demonstrate that you can produce more value for them if they don't let you get stuck into something trivial. 4. With lazy/abusive co-workers, you may have to simply let them know that you're not the assistant they can hand over the boring part to. This may be more difficult than with the managers, especially if you're not good at marking your limits in a firm but polite manner. However as long as management want you to work where you provide more value, you can simply tell your co-workers something like "I'd love to help you with <insert menial task they prefent not to be able to do>, AGAIN, but I'm afraid I don't have much free time until Thursday from 7am-8am two weeks from now....". Or you can simply say "I'd love to help you with <same as above>, but I've been ordered to focuson <insert more interesting task>, maybe you can explain your need to my manager and have him approve this". One approach is to make it inconvenient for them, the other is to force them to admit some deficiency to management before you help them.

sph 4y ago

Don't use "full stack engineer", these days for recruiters and HR it means "knows Node.js and React", which is sad and frustrating. My Ask HN post about it: https://news.ycombinator.com/item?id=32317514 https://news.ycombinator.com/item?id=32317514

quickthrower2 4y ago
npm i nextjs … or whatever. Basically.
Aeolun 4y ago
But I like React and Node.js. It works fine for me.
- sph 4y ago
  I never said they're bad. I'm saying that not very long ago, full stack means from system security, administration, being proficient with databases, backend and frontend development, and at least a couple languages under the belt. These days it just means frontend and backend, in the same language, often the same framework. The same term that was used to identify senior generalist engineers with extensive experience in the field, these days is used for any junior JS dev with a couple years of experience under their belt. Not their fault, it's the recruiters fault for appropriating the incorrect label instead of creating a new one.

zhdc1 4y ago

Excellent advice!