12 ms·

Best strategy for becoming a high paying/good software engineer would be to think of yourselves as problem solver and language as just one of the tool for probl

Best strategy for becoming a high paying/good software engineer would be to think of yourselves as problem solver and language as just one of the tool for problem solving. Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point.

yieldcrv 4y ago
Although true for the job, this is a bit disingenuous for getting the job market because recruiters are absolutely not thinking of you as a problem solver with language being just one of the tools.
dom96 4y ago
Precisely. Any good company won't care what programming language you are specifically proficient in. They care about how proficient you are in learning new things. I have created a lot of Nim projects and implemented much of its stdlib. My full-time job isn't using Nim, but the experience I gained through my work in Nim has helped my career significantly.
- akudha 4y ago
  Any good company The keyword here is good. Even then, this isn’t largely true. It is quite hard to convince companies to hire for a skill that you already don’t have experience in. In most cases, there are gatekeepers - those lovely recruiters who don’t know the difference between a computer and a washing machine.
  - dom96 4y ago
    if you're optimising for those then you might as well learn whatever's most in-demand and popular, probably Python. There are plenty of companies that are good enough though, for most you won't even need to talk to a recruiter.
- icedchai 4y ago
  Given two good candidates, they are going to prefer candidates who are already proficient in their tech stack. It saves time.
- nimmer 4y ago
  > Any good company won't care what programming language you are specifically proficient in True, but most companies care more about using popular language rather than an innovative one. You might get hired but you won't be using Nim at work.
bigyikes 4y ago
Yes. Lately I’ve found this to be true at my job, with the whole frontend/backend distinction. Job specialization is good. I mostly write TypeScript, and I can usually contribute the most value to the company by writing TypeScript and sticking to frontend things. Sometimes though, the fastest way to solve a problem is for me to dive into the backend, and I have no qualms with doing so. Some people on my team treat the “other side” as totally foreign, however. This leads to willful ignorance and glaring inefficiencies. For example, someone asked my senior frontend teammate a question, and the answer could be found trivially by someone with an inkling of backend knowledge. Yet, this person threw up their hands and dragged a backender into the conversation because they couldn’t be bothered to learn a single thing about the backend in the 5 years they’ve been with the company. Please just be a problem solver. Don’t be just a “backender”, and definitely don’t be just a “Nim developer”.
deleted 4y ago
[deleted]
pharmakom 4y ago
I think this is true, but writing code in certain languages (e.g. Java 8) drives me a bit crazy. It’s like running a race with your arms tied to your sides. I put certain languages in a general negatives bucket along with noisy offices, stack ranking, heavy process, etc.
- listenallyall 4y ago
  > Java 8 drives me a bit crazy (whisper voice) kotlin
  - pharmakom 4y ago
    Kotlin is nicer for sure, but… 1. Not every shop will let you use it 2. Kotlin has a bunch of the same limitations.
- 62951413 4y ago
  The latest LTS version is JDK17 (e.g. records and switch expressions) and has been for long enough to be production ready. I reckon half of the people on this forum didn't even work in software when JDK8 was released. Yes, Kotlin/Scala would stop driving you crazy. No, I don't see nearly enough Bay Area companies deprecating Java in their favor for new services :( They are probably betting on the next LTS to come soon enough (with pattern matching and hopefully Loom).
thr0wawayf00 4y ago
I used to think this way and wound up completely exhausted in my career. Coming from web dev, I used to volunteer to dive into a Objective C repo to fix some random bug in a mobile app and then a week later my boss would ask me to build a big feature in that app. I'd spend a few weeks getting up to speed on the language and build the feature, and then I would never use what I learned again. My boss would ask me to dive into another tool I don't really know and the cycle would repeat ad nauseum. In hindsight, I've wasted so much time digging into tools that I've never used again. I definitely learned some good lessons and recognized some patterns along the way, but I think the "just pick it up and learn it" attitude contributes to poor code quality in a commercial context since jobs usually time-box things. I'm a fan of picking something up that I can get expert feedback from, which there again, requires expertise.
- rco8786 4y ago
  > I've wasted so much time digging into tools that I've never used again. Don’t think of it this way. Learning new tools is almost never a waste of time, you just don’t know when you’ll need the lessons learned next. But you will.
  - mmartinson 4y ago
    It's valuable to consider the opportunity cost of this compared to a deepened knowledge of an already productive tool
  - rolisz 4y ago
    It depends. Maybe the alternative is to get better at a tool you already know. Maybe you can be a jack of all trades, master of none, or you can go really deep into only 2-3 things. It depends a lot on your personality I think.
  - weatherlite 4y ago
    What lessons do I learn from learning webpack? Or whatever the new way of bundling things in FE is called now? Compare that to understanding C or UNIX. There are skills that decay much slower than others.
Nextgrid 4y ago
While the basic syntax is relatively easy, knowledge of APIs (whether standard or third-party libraries), design patterns and conventions takes time (and practice) to master regardless of skill level. Being an expert at a single general-purpose language will often make you more productive as you can focus on the business problem at hand rather than spreading yourself thin across different languages where you'll perform worse until you become an expert at them (which is unlikely for anything more than a handful of languages and even that requires working with them regularly).
- jghn 4y ago
  Deep expertise isn't as useful day to day as we often portray. With a little elbow grease one can get to a place of being more than baseline productive in relatively short order. Depending on the language I expect a reasonably good dev to be able to be "fluent" in the range of a few weeks to a few months. And it's not like they'd be useless the entire time before that happens. To me, that's a reasonable investment to make. Edit: This does require a certain persona in the space of "reasonably good dev". People who have spent their entire life focusing on a single language or paradigm are a lot less likely to be able to shift gears. People who have broad exposure to different concepts are more able to say "How do I do X in Y?" and stop fighting their new language.
  - JamesBarney 4y ago
    I've seen huge differences in productivity between people who've been working with a given stack with for years vs months. The quality just isn't even close. Recently I outsourced a project to two groups of people. A jr dev who had 2 years of experience but all of that experience was with the tech stack, and 2 sr devs (10 yrs experience) who had < 6 months experience with the tech stack. And the jr dev (who was an inferior dev in general) blew them out of the water because of the tech stack experience. And honestly in terms of raw talent I think the sr devs were better, but it just didn't make up for the lack of tech stack experience.
    - fonix 4y ago
namelosw 4y ago
I agree in general, but that might not be the whole truth. Otherwise there wouldn't be such a thing called "Perlis Language"[0]. [0] "A language that doesn't affect the way you think about programming is not worth knowing." -- Alan Perlis
spyremeown 4y ago
I don't think that strategy works best. Most of people I know that get paid very good amounts are specialists in a given framework or language, like knowing the ins and outs of PHP for example. I rather say "be a generalist on the long term and a specialist on the short term". This is all my opinion and comes from my personal experience, though. Take it with a grain of salt.
ldjkfkdsjnv 4y ago
No the best strategy is to memorize leetcode problems. All the highest paying jobs (>400k) require dictionary like recall of computer science algorithm fundamentals.
- biztos 4y ago
  Well certainly not all but that strategy, if you can pull it off, will probably get you a very high-paying job and maybe you won't have to work so hard. But that's not at all what the OP asked for. Maybe they're already making >400K slinging JS at Facebook or Google. Lots of people do!
nly 4y ago
It's a cute theory, but the reality is most employers want you to be relatively efficient from day dot. I work in a team with a codebase split 50/50 between C# and C++, and if you're not proficient in one of those then the chances of you getting hired, even if you're an incredible programmer, are slim.
- whimsicalism 4y ago
  Having a C# codebase and being unwilling to hire Java developers seems like unnecessarily constraining yourself.
  - metaltyphoon 4y ago
    Depends a lot on what type of software is b ing written. The people that keep beating the drums that Java = C# have not worked with the language extensively enough. So many things outside of basic languages constructs are different. Tooling is also a big hurdle to change too.
    - wizofaus 4y ago
      I've worked in both extensively, and there are certainly far more similarities than differences. I've put C# devs on to Java codebases and got them up to speed very quickly. But you still need to have Java pros that know all the gotchas etc. to do the code reviews.
- dnissley 4y ago
  This is a trait of an employer that I consider a red flag. If they don't understand that most programming languages are pretty similar, and can be picked up quickly by any willing person, they probably don't understand a lot of other things in regards to tech
  - hardware2win 4y ago
    Quickly=?
deleted 4y ago
[deleted]
mmartinson 4y ago
> Best strategy for becoming a high paying/good software engineer would be to think of yourselves as problem solver and language as just one of the tool for problem solving. I'm not sure becoming a high paying/good software engineer are necessarily relevant to the stated goals of the OP's question. There can be inherent reward in working with a set of less popular, well crafted tools. Yes you might grow faster as a professional by working with a group of industry best JS programmers, but working with a small team building in Elixir and moving fast without ever hitting a NaN can be a pretty rewarding experience.
zerr 4y ago
Industry gatekeepers do not agree, unfortunately.
jollybean 4y ago
This doesn't answer the question. More specifically, it's probably not useful advice. I'm a generalist in a few languages, and I'm painfully aware of my lack of 'depth' of insight into the languages I use when I'm not 'knees deep'. For some niche languages, you can't just 'read a book' and 'check stack exchange'. I think we should all be 'multilingual' but it really helps to have depth of expertise.
skeeter2020 4y ago
This feels good intuitively but is not born out by my experiences and observations. The notion that "high paying/good software engineer" are two aspects of the same outcome is wrong. To the OP, the answer is "pays beter with less demand and more risk". Example: we're struggling to find Elixir developers and thus paying a premium for good (not great) talent; we're also looking to switch to Node which will reduce our demand for Elixir devs.
- 71a54xd 4y ago
  I'm currently looking for an elixir contract gig! Feel free to email at hydratedchia@gmail.com :)
- throwawaymaths 4y ago
  Seriously, pay the premium. You'll waste the delta endlessly searching through the chaff of node developers, and then pay another cost when your node architecture needs to be de-spaghettified or your node developer decides to create another layer of tech debt by switch to using next.js from redux, or starting to use aws lambdas, etc. Etc etc.
ld_bic 4y ago
I write COBOL I work 24hrs/week I make $15k/week I also can’t center a div on a web page or do much of anything other then what I do. Specialization IMO is key to highest job satisfaction and highest salary in this industry
- greatpostman 4y ago
  Interesting, always thought high paying cobol jobs were a myth
  - ld_bic 4y ago
    IMO the only way in this industry (without having your own company or something like that) to high-paying gigs is to become more valuable to a company than company is to you. and that you can accomplish only through DEEP specialization
    - varjag 4y ago
      The downside to this of course is the breadth of your next job search (should it come to that) suffers.
      - ld_bic 4y ago
        This on the surface sounds solid but I persobally think most job searches are narrow unless you are doing “career changing” moves. How many good UI/UX colleagues do you have that are good at anything else? How many compiler developers can center a div on the page? I think this “I know a lot of things” is just something we say - terms like “full stack” developer etc… I mostly develop on a computer which isn’t connected to the internet (so no Google, Stackoverflow etc…) and I often think how miniscule fraction of “full stack” developers could perform even the most menial task in any of these “stacks” they apparently know
      - chmod775 4y ago
        If you make in a month what others do in a year, you can retire after 6-8 years and never worry about having to find another job if you play your cards right. Accounting for taxes and moderate expenses, at the end you should be sitting on close to 2m USD. That's more money than the vast majority of people make in their lifetime (after taxes). If you don't plan to live to a hundred you'll be fine even if you don't do any higher-risky investing, slowly spending it.
SeriousM 4y ago
That's a horrible advice. Knowing a language is helping you read/write the code in a good quality. Knowing the ecosystem and solutions in this language is your sellingpoint. Take any language and tell me one can be productive in no time without knowing the ecosystem around it.
- Aperocky 4y ago
  This is good advice. Within our team we use 5 different mainstream languages to accomplish different goals within our system. We handle a single service, but we manage the full stack using many different languages and frameworks. We don't have to be expert in the frameworks, we just need to be experts at what we are building. And we learn each framework to the point where we can accomplish that. The "selling point" that we value is to be able to deliver.
nickjj 4y ago
This is very true but there's still is a very big difference between knowing languages like JS, Python, Ruby or Go but then jumping into a place that uses Elixir or a niche language that's different than a lot of other popular languages. For example I took a position to do mostly infrastructure work. Most of their services are written in PHP which I haven't used since the early 2000s. I wouldn't classify myself as a PHP developer. Sometimes I find myself diving into the code to self-solve issues I have that are infrastructure related. My thought process is if I can solve a problem and it's within my scope of things to do I'd much rather just do it than add extra work to another developer on the team. In the worst case scenario someone with actual PHP experience who does the code review will offer suggestions to make the code better. I don't really know PHP but I can look around and navigate the code without issues. There's nothing that looks too foreign and the code is easy to grep to find stuff. It's also not too bad to trace code in a large app and understand the logic. There's also a massive amount of Google results for almost any problem you can think of. It really means for a lot of cases you can combine previous experience and be productive in a similar language without really knowing it. Enough to contribute real code that gets shipped to production. I ended up doing this yesterday where I added an IP whitelist address exempt config option to one of our apps. I wanted to at least toy with the idea of doing IP range detection within a CIDR block. In Python this is really easy, the standard library has functions to do this with 1 line of code. Ruby's implementation is even easier and built into the language. For PHP I had to Google around but found a pretty small custom function to use in less than 2 minutes. For Elixir? Well you have to use a 4 year old+ third party dependency or dive down into Erlang and understand pattern matching and write a bunch of code to manually do the comparisons. Maybe there's a good Elixir solution but it wasn't on the first 3 pages of Google when searching for similar terms as I did for Python, Ruby and PHP. Weirdly enough if you search for "elixir check if ip address is in cidr block range" most of the top results are StackOverflow posts for other languages. There's no contest in comparing the amount of effort it took to get a solution. I know this is 1 just example but I also know when I tried learning Elixir (and did end up writing about 10k lines of code of it) I kept running into situations that took half a day or longer to figure out while actively trying hard to learn and use the language. These problem could be fully solved in a production ready way in 5-10 minutes with Python or Ruby (and I guess PHP too) either by knowing how to solve it in an imperative way or finding nearly a perfect solution when Googling that's digestible enough to where you can fully understand it and apply it back to your problem.
itsEtai 4y ago
This attitude is a great starting point, but take caution to curate a future for yourself that you find interesting. Whatever work you do, you will forever be the person who has done that work. Next time something needs to change in that domain or language, you might find yourself talked about as a specialist! The moral is to choose and pick your projects carefully. Vocalizing your experiences with your manager goes a long way for shaping your future: like “I liked working in X and I want to do that more” and “I am glad I got to try Y, but I really didn’t enjoy it.”
ParetoOptimal 4y ago
> Best strategy for becoming a high paying/good software engineer would be to think of yourselves as problem solver and language as just one of the tool for problem solving. Some languages contort and constrain your thinking in bad or silly ways. > Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point. I find this view tends to lead to only using popular languages anyway because you don't seek out any specific language, so the effect of this belief itself is self-constraining.
checkyoursudo 4y ago
tl:dr What do I do if I just want a job that I enjoy and do not care much about the money? I do not need a high paying job for various reasons, but I still want(/need?) to do something fulfilling and wouldn't mind getting paid for it. I like research. I have been doing academic research for the past few years, so I am still considering a PhD. I definitely do not have to worry about a high salary there! But I also like plain old solving problems with programming, so I am considering going out and getting a job as a programmer (again). Since I don't care much about high pay, and I do care about enjoyment and self-fulfillment, it seems that I should be picky if I am going to look for jobs. I do not find fulfillment in high compensation, though I understand that others might. I would rather do something fun, interesting, or unusual, while avoiding features I already know I dislike. For example, I learned OOP a bit in college during my first-ever programming course (Java). It didn't stick and all I learned was that I don't like OOP. Surely this suggests I should avoid jobs/languages that require an OOP paradigm? Like, sometimes I think I should just go back and hardcore brush up on my C programming and go get a job writing C somewhere. Or see if I can translate my academic R/Python skills somewhere. Or go learn some functional language and see if I can get a job doing that. > Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point. I totally get where you are coming from. For example, many people do jobs they dislike or don't care about knowing that it enables activities/experiences/purchases they do like or care about. But really, does this not fully depend on what each person subjectively thinks "the point" is? The point for me is that I would like to enjoy all of my life, not hate my work time and only enjoy my leisure time. Maybe I'll figure it out someday.
winternett 4y ago
Agreed, there are definitely some langs that go out of their way to be overly complex, obscured, obtuse, and proprietary in nature that I totally avoid. They can lead to what I call "rabbit hole" jobs, which make it very hard to change disciplines thereafter. Now most recruiters, and even hiring managers, rarely have an idea of the nuances of development during the interviews I attend... Because usually their a buddy of executives within the company more often than being there for their capabilities or educational background. When the technical component comes, I also often get paired by another dev within the company, or a person with a technical grasp that's totally outside of what they know, so keeping my knowledge diverse, and being able to adapt to what I don't know is key in order to be worth a good salary. Adapt and improvise, manage their expectations of you, but most importantly, know how problems get solved correctly. The tools used don't matter if the house built is well done.
barankilic 4y ago
Good luck with listing "problem solver" as a skill in your resume. I don't think anybody will care about it. As an experiment, one can create two resumes with different identities where the first one is listing Nim as a skill and the other one is listing Java and Spring as skills, and apply to the same jobs. I wonder what the ratio of replies will be.
- Strom 4y ago
  If you're an actual problem solver, you don't even need a CV. Your clients will be so happy that they will recommend your services to their buddies.
LAC-Tech 4y ago
I read this advice so much as a younger programmer, but now I am in a position to say - this doesn't work. Sure think of yourself as multi-lingual and able to learn anything (which you probably are). But don't market yourself that way, especially if you're a contractor. People want someone who knows their tech stack and they want you to be productive yesterday.
baby 4y ago
I have a different approach, I have a blacklist of languages I refuse to work with (for example, Java)
mistrial9 4y ago
yeah disagree - as a high-skill consultant coming in as a problem solver, I mostly got dirty jobs that no one wanted to touch. "Pay someone to do it!" you can hear the cries. The interesting and low-touch projects got grabbed quickly by insiders. Super-problem-solver was not a good strategy in practice. This profession has a long way to go in some respects.

yieldcrv 4y ago

Although true for the job, this is a bit disingenuous for getting the job market because recruiters are absolutely not thinking of you as a problem solver with language being just one of the tools.

dom96 4y ago

Precisely. Any good company won't care what programming language you are specifically proficient in. They care about how proficient you are in learning new things. I have created a lot of Nim projects and implemented much of its stdlib. My full-time job isn't using Nim, but the experience I gained through my work in Nim has helped my career significantly.

akudha 4y ago
Any good company The keyword here is good. Even then, this isn’t largely true. It is quite hard to convince companies to hire for a skill that you already don’t have experience in. In most cases, there are gatekeepers - those lovely recruiters who don’t know the difference between a computer and a washing machine.
- dom96 4y ago
  if you're optimising for those then you might as well learn whatever's most in-demand and popular, probably Python. There are plenty of companies that are good enough though, for most you won't even need to talk to a recruiter.
icedchai 4y ago
Given two good candidates, they are going to prefer candidates who are already proficient in their tech stack. It saves time.
nimmer 4y ago
> Any good company won't care what programming language you are specifically proficient in True, but most companies care more about using popular language rather than an innovative one. You might get hired but you won't be using Nim at work.

bigyikes 4y ago

Yes. Lately I’ve found this to be true at my job, with the whole frontend/backend distinction. Job specialization is good. I mostly write TypeScript, and I can usually contribute the most value to the company by writing TypeScript and sticking to frontend things. Sometimes though, the fastest way to solve a problem is for me to dive into the backend, and I have no qualms with doing so. Some people on my team treat the “other side” as totally foreign, however. This leads to willful ignorance and glaring inefficiencies. For example, someone asked my senior frontend teammate a question, and the answer could be found trivially by someone with an inkling of backend knowledge. Yet, this person threw up their hands and dragged a backender into the conversation because they couldn’t be bothered to learn a single thing about the backend in the 5 years they’ve been with the company. Please just be a problem solver. Don’t be just a “backender”, and definitely don’t be just a “Nim developer”.

deleted 4y ago

[deleted]

pharmakom 4y ago

I think this is true, but writing code in certain languages (e.g. Java 8) drives me a bit crazy. It’s like running a race with your arms tied to your sides. I put certain languages in a general negatives bucket along with noisy offices, stack ranking, heavy process, etc.

listenallyall 4y ago
> Java 8 drives me a bit crazy (whisper voice) kotlin
- pharmakom 4y ago
  Kotlin is nicer for sure, but… 1. Not every shop will let you use it 2. Kotlin has a bunch of the same limitations.
62951413 4y ago
The latest LTS version is JDK17 (e.g. records and switch expressions) and has been for long enough to be production ready. I reckon half of the people on this forum didn't even work in software when JDK8 was released. Yes, Kotlin/Scala would stop driving you crazy. No, I don't see nearly enough Bay Area companies deprecating Java in their favor for new services :( They are probably betting on the next LTS to come soon enough (with pattern matching and hopefully Loom).

thr0wawayf00 4y ago

I used to think this way and wound up completely exhausted in my career. Coming from web dev, I used to volunteer to dive into a Objective C repo to fix some random bug in a mobile app and then a week later my boss would ask me to build a big feature in that app. I'd spend a few weeks getting up to speed on the language and build the feature, and then I would never use what I learned again. My boss would ask me to dive into another tool I don't really know and the cycle would repeat ad nauseum. In hindsight, I've wasted so much time digging into tools that I've never used again. I definitely learned some good lessons and recognized some patterns along the way, but I think the "just pick it up and learn it" attitude contributes to poor code quality in a commercial context since jobs usually time-box things. I'm a fan of picking something up that I can get expert feedback from, which there again, requires expertise.

rco8786 4y ago
> I've wasted so much time digging into tools that I've never used again. Don’t think of it this way. Learning new tools is almost never a waste of time, you just don’t know when you’ll need the lessons learned next. But you will.
- mmartinson 4y ago
  It's valuable to consider the opportunity cost of this compared to a deepened knowledge of an already productive tool
- rolisz 4y ago
  It depends. Maybe the alternative is to get better at a tool you already know. Maybe you can be a jack of all trades, master of none, or you can go really deep into only 2-3 things. It depends a lot on your personality I think.
- weatherlite 4y ago
  What lessons do I learn from learning webpack? Or whatever the new way of bundling things in FE is called now? Compare that to understanding C or UNIX. There are skills that decay much slower than others.

Nextgrid 4y ago

While the basic syntax is relatively easy, knowledge of APIs (whether standard or third-party libraries), design patterns and conventions takes time (and practice) to master regardless of skill level. Being an expert at a single general-purpose language will often make you more productive as you can focus on the business problem at hand rather than spreading yourself thin across different languages where you'll perform worse until you become an expert at them (which is unlikely for anything more than a handful of languages and even that requires working with them regularly).

jghn 4y ago
Deep expertise isn't as useful day to day as we often portray. With a little elbow grease one can get to a place of being more than baseline productive in relatively short order. Depending on the language I expect a reasonably good dev to be able to be "fluent" in the range of a few weeks to a few months. And it's not like they'd be useless the entire time before that happens. To me, that's a reasonable investment to make. Edit: This does require a certain persona in the space of "reasonably good dev". People who have spent their entire life focusing on a single language or paradigm are a lot less likely to be able to shift gears. People who have broad exposure to different concepts are more able to say "How do I do X in Y?" and stop fighting their new language.
- JamesBarney 4y ago
  I've seen huge differences in productivity between people who've been working with a given stack with for years vs months. The quality just isn't even close. Recently I outsourced a project to two groups of people. A jr dev who had 2 years of experience but all of that experience was with the tech stack, and 2 sr devs (10 yrs experience) who had < 6 months experience with the tech stack. And the jr dev (who was an inferior dev in general) blew them out of the water because of the tech stack experience. And honestly in terms of raw talent I think the sr devs were better, but it just didn't make up for the lack of tech stack experience.
  - fonix 4y ago

namelosw 4y ago

I agree in general, but that might not be the whole truth. Otherwise there wouldn't be such a thing called "Perlis Language"[0]. [0] "A language that doesn't affect the way you think about programming is not worth knowing." -- Alan Perlis

spyremeown 4y ago

I don't think that strategy works best. Most of people I know that get paid very good amounts are specialists in a given framework or language, like knowing the ins and outs of PHP for example. I rather say "be a generalist on the long term and a specialist on the short term". This is all my opinion and comes from my personal experience, though. Take it with a grain of salt.

ldjkfkdsjnv 4y ago

No the best strategy is to memorize leetcode problems. All the highest paying jobs (>400k) require dictionary like recall of computer science algorithm fundamentals.

biztos 4y ago
Well certainly not all but that strategy, if you can pull it off, will probably get you a very high-paying job and maybe you won't have to work so hard. But that's not at all what the OP asked for. Maybe they're already making >400K slinging JS at Facebook or Google. Lots of people do!

nly 4y ago

It's a cute theory, but the reality is most employers want you to be relatively efficient from day dot. I work in a team with a codebase split 50/50 between C# and C++, and if you're not proficient in one of those then the chances of you getting hired, even if you're an incredible programmer, are slim.

whimsicalism 4y ago
Having a C# codebase and being unwilling to hire Java developers seems like unnecessarily constraining yourself.
- metaltyphoon 4y ago
  Depends a lot on what type of software is b ing written. The people that keep beating the drums that Java = C# have not worked with the language extensively enough. So many things outside of basic languages constructs are different. Tooling is also a big hurdle to change too.
  - wizofaus 4y ago
    I've worked in both extensively, and there are certainly far more similarities than differences. I've put C# devs on to Java codebases and got them up to speed very quickly. But you still need to have Java pros that know all the gotchas etc. to do the code reviews.
dnissley 4y ago
This is a trait of an employer that I consider a red flag. If they don't understand that most programming languages are pretty similar, and can be picked up quickly by any willing person, they probably don't understand a lot of other things in regards to tech
- hardware2win 4y ago
  Quickly=?

deleted 4y ago

[deleted]

mmartinson 4y ago

> Best strategy for becoming a high paying/good software engineer would be to think of yourselves as problem solver and language as just one of the tool for problem solving. I'm not sure becoming a high paying/good software engineer are necessarily relevant to the stated goals of the OP's question. There can be inherent reward in working with a set of less popular, well crafted tools. Yes you might grow faster as a professional by working with a group of industry best JS programmers, but working with a small team building in Elixir and moving fast without ever hitting a NaN can be a pretty rewarding experience.

zerr 4y ago

Industry gatekeepers do not agree, unfortunately.

jollybean 4y ago

This doesn't answer the question. More specifically, it's probably not useful advice. I'm a generalist in a few languages, and I'm painfully aware of my lack of 'depth' of insight into the languages I use when I'm not 'knees deep'. For some niche languages, you can't just 'read a book' and 'check stack exchange'. I think we should all be 'multilingual' but it really helps to have depth of expertise.

skeeter2020 4y ago

This feels good intuitively but is not born out by my experiences and observations. The notion that "high paying/good software engineer" are two aspects of the same outcome is wrong. To the OP, the answer is "pays beter with less demand and more risk". Example: we're struggling to find Elixir developers and thus paying a premium for good (not great) talent; we're also looking to switch to Node which will reduce our demand for Elixir devs.

71a54xd 4y ago
I'm currently looking for an elixir contract gig! Feel free to email at hydratedchia@gmail.com :)
throwawaymaths 4y ago
Seriously, pay the premium. You'll waste the delta endlessly searching through the chaff of node developers, and then pay another cost when your node architecture needs to be de-spaghettified or your node developer decides to create another layer of tech debt by switch to using next.js from redux, or starting to use aws lambdas, etc. Etc etc.

ld_bic 4y ago

I write COBOL I work 24hrs/week I make $15k/week I also can’t center a div on a web page or do much of anything other then what I do. Specialization IMO is key to highest job satisfaction and highest salary in this industry

greatpostman 4y ago
Interesting, always thought high paying cobol jobs were a myth
- ld_bic 4y ago
  IMO the only way in this industry (without having your own company or something like that) to high-paying gigs is to become more valuable to a company than company is to you. and that you can accomplish only through DEEP specialization
  - varjag 4y ago
    The downside to this of course is the breadth of your next job search (should it come to that) suffers.
    - ld_bic 4y ago
      This on the surface sounds solid but I persobally think most job searches are narrow unless you are doing “career changing” moves. How many good UI/UX colleagues do you have that are good at anything else? How many compiler developers can center a div on the page? I think this “I know a lot of things” is just something we say - terms like “full stack” developer etc… I mostly develop on a computer which isn’t connected to the internet (so no Google, Stackoverflow etc…) and I often think how miniscule fraction of “full stack” developers could perform even the most menial task in any of these “stacks” they apparently know
    - chmod775 4y ago
      If you make in a month what others do in a year, you can retire after 6-8 years and never worry about having to find another job if you play your cards right. Accounting for taxes and moderate expenses, at the end you should be sitting on close to 2m USD. That's more money than the vast majority of people make in their lifetime (after taxes). If you don't plan to live to a hundred you'll be fine even if you don't do any higher-risky investing, slowly spending it.

SeriousM 4y ago

That's a horrible advice. Knowing a language is helping you read/write the code in a good quality. Knowing the ecosystem and solutions in this language is your sellingpoint. Take any language and tell me one can be productive in no time without knowing the ecosystem around it.

Aperocky 4y ago
This is good advice. Within our team we use 5 different mainstream languages to accomplish different goals within our system. We handle a single service, but we manage the full stack using many different languages and frameworks. We don't have to be expert in the frameworks, we just need to be experts at what we are building. And we learn each framework to the point where we can accomplish that. The "selling point" that we value is to be able to deliver.

nickjj 4y ago

This is very true but there's still is a very big difference between knowing languages like JS, Python, Ruby or Go but then jumping into a place that uses Elixir or a niche language that's different than a lot of other popular languages. For example I took a position to do mostly infrastructure work. Most of their services are written in PHP which I haven't used since the early 2000s. I wouldn't classify myself as a PHP developer. Sometimes I find myself diving into the code to self-solve issues I have that are infrastructure related. My thought process is if I can solve a problem and it's within my scope of things to do I'd much rather just do it than add extra work to another developer on the team. In the worst case scenario someone with actual PHP experience who does the code review will offer suggestions to make the code better. I don't really know PHP but I can look around and navigate the code without issues. There's nothing that looks too foreign and the code is easy to grep to find stuff. It's also not too bad to trace code in a large app and understand the logic. There's also a massive amount of Google results for almost any problem you can think of. It really means for a lot of cases you can combine previous experience and be productive in a similar language without really knowing it. Enough to contribute real code that gets shipped to production. I ended up doing this yesterday where I added an IP whitelist address exempt config option to one of our apps. I wanted to at least toy with the idea of doing IP range detection within a CIDR block. In Python this is really easy, the standard library has functions to do this with 1 line of code. Ruby's implementation is even easier and built into the language. For PHP I had to Google around but found a pretty small custom function to use in less than 2 minutes. For Elixir? Well you have to use a 4 year old+ third party dependency or dive down into Erlang and understand pattern matching and write a bunch of code to manually do the comparisons. Maybe there's a good Elixir solution but it wasn't on the first 3 pages of Google when searching for similar terms as I did for Python, Ruby and PHP. Weirdly enough if you search for "elixir check if ip address is in cidr block range" most of the top results are StackOverflow posts for other languages. There's no contest in comparing the amount of effort it took to get a solution. I know this is 1 just example but I also know when I tried learning Elixir (and did end up writing about 10k lines of code of it) I kept running into situations that took half a day or longer to figure out while actively trying hard to learn and use the language. These problem could be fully solved in a production ready way in 5-10 minutes with Python or Ruby (and I guess PHP too) either by knowing how to solve it in an imperative way or finding nearly a perfect solution when Googling that's digestible enough to where you can fully understand it and apply it back to your problem.

itsEtai 4y ago

This attitude is a great starting point, but take caution to curate a future for yourself that you find interesting. Whatever work you do, you will forever be the person who has done that work. Next time something needs to change in that domain or language, you might find yourself talked about as a specialist! The moral is to choose and pick your projects carefully. Vocalizing your experiences with your manager goes a long way for shaping your future: like “I liked working in X and I want to do that more” and “I am glad I got to try Y, but I really didn’t enjoy it.”

ParetoOptimal 4y ago

> Best strategy for becoming a high paying/good software engineer would be to think of yourselves as problem solver and language as just one of the tool for problem solving. Some languages contort and constrain your thinking in bad or silly ways. > Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point. I find this view tends to lead to only using popular languages anyway because you don't seek out any specific language, so the effect of this belief itself is self-constraining.

checkyoursudo 4y ago

tl:dr What do I do if I just want a job that I enjoy and do not care much about the money? I do not need a high paying job for various reasons, but I still want(/need?) to do something fulfilling and wouldn't mind getting paid for it. I like research. I have been doing academic research for the past few years, so I am still considering a PhD. I definitely do not have to worry about a high salary there! But I also like plain old solving problems with programming, so I am considering going out and getting a job as a programmer (again). Since I don't care much about high pay, and I do care about enjoyment and self-fulfillment, it seems that I should be picky if I am going to look for jobs. I do not find fulfillment in high compensation, though I understand that others might. I would rather do something fun, interesting, or unusual, while avoiding features I already know I dislike. For example, I learned OOP a bit in college during my first-ever programming course (Java). It didn't stick and all I learned was that I don't like OOP. Surely this suggests I should avoid jobs/languages that require an OOP paradigm? Like, sometimes I think I should just go back and hardcore brush up on my C programming and go get a job writing C somewhere. Or see if I can translate my academic R/Python skills somewhere. Or go learn some functional language and see if I can get a job doing that. > Thinking of yourselves as someone who is a writer of a certain programming language is self constarining and missing the point. I totally get where you are coming from. For example, many people do jobs they dislike or don't care about knowing that it enables activities/experiences/purchases they do like or care about. But really, does this not fully depend on what each person subjectively thinks "the point" is? The point for me is that I would like to enjoy all of my life, not hate my work time and only enjoy my leisure time. Maybe I'll figure it out someday.

winternett 4y ago

Agreed, there are definitely some langs that go out of their way to be overly complex, obscured, obtuse, and proprietary in nature that I totally avoid. They can lead to what I call "rabbit hole" jobs, which make it very hard to change disciplines thereafter. Now most recruiters, and even hiring managers, rarely have an idea of the nuances of development during the interviews I attend... Because usually their a buddy of executives within the company more often than being there for their capabilities or educational background. When the technical component comes, I also often get paired by another dev within the company, or a person with a technical grasp that's totally outside of what they know, so keeping my knowledge diverse, and being able to adapt to what I don't know is key in order to be worth a good salary. Adapt and improvise, manage their expectations of you, but most importantly, know how problems get solved correctly. The tools used don't matter if the house built is well done.

barankilic 4y ago

Good luck with listing "problem solver" as a skill in your resume. I don't think anybody will care about it. As an experiment, one can create two resumes with different identities where the first one is listing Nim as a skill and the other one is listing Java and Spring as skills, and apply to the same jobs. I wonder what the ratio of replies will be.

Strom 4y ago
If you're an actual problem solver, you don't even need a CV. Your clients will be so happy that they will recommend your services to their buddies.

LAC-Tech 4y ago

I read this advice so much as a younger programmer, but now I am in a position to say - this doesn't work. Sure think of yourself as multi-lingual and able to learn anything (which you probably are). But don't market yourself that way, especially if you're a contractor. People want someone who knows their tech stack and they want you to be productive yesterday.

baby 4y ago

I have a different approach, I have a blacklist of languages I refuse to work with (for example, Java)

mistrial9 4y ago

yeah disagree - as a high-skill consultant coming in as a problem solver, I mostly got dirty jobs that no one wanted to touch. "Pay someone to do it!" you can hear the cries. The interesting and low-touch projects got grabbed quickly by insiders. Super-problem-solver was not a good strategy in practice. This profession has a long way to go in some respects.