32 ms·

A common trap for people entering programming jobs

145 points by Theaetetus 4y ago

eddyschai 4y ago
Not sure what to really take from this article. If it's about what one should spend their time learning, try identify the 'timeless' things. Software design over languages, algorithms over libraries, SQL and JavaScript will probably never die.
- Theaetetus 4y ago
  Author here. I certainly have a lot of opinions about what to study more generally! This was a short note for people who are specifically trying to make it likelier that they'll succeed at a job they're about to start. Lots of people (former versions of myself included) focus too much on learning a language when studying other tools would give a higher ROI.
- jimbob45 4y ago
  Nobody will hire you for your SQL knowledge but you can be sure everyone at your new company will heavily rely on you if you know your SQL well.
  - beckingz 4y ago
    It's amazing coming at software from a data perspective, my assumption that people would know about SQL and databases is just so so wrong all of the time.
    - nijave 4y ago
      Same with infrastructure (and probably security, etc)
    - eddyschai 4y ago
      ORMs definitely don't help! In my first dev role I worked at a C# shop and everything was through Entity Framework. You can't take that skill with you if you change languages to Python, or Haskell, or whatever, but the core SQL skills to follow you around. It's worth the effort, I think (and it's not particularly hard to get semi-decent at SQL!).
- XorNot 4y ago
  In the job market right now, this seems like terrible advice: no one except Google are hiring for "algorithms" - they want a React developer, or a C#/.net developer who can pump out web APIs in it or something. Companies mostly hire for frameworks below the FAANG level.
  - georgeburdell 4y ago
    No, Leetcode has metastasized throughout startup land too. I know because I failed a lot of those interview types in the past year (but I keep trying since the pay is so good)
  - ge96 4y ago
    Every time "who wants to get hired" comes out it's always JavaScript/React/Node/Python/C++ at the top (percentage)
  - _gabe_ 4y ago
    > they want a React developer, or a C#/.net developer who can pump out web APIs in it or something. All web APIs follow the same basic pattern. The OP said: >> try identify the 'timeless' things. Software design over languages, algorithms over libraries If you understand the fundamentals of software engineering, picking up a new framework or library isn't a big deal. It's the same old tropes with some different syntax and domain language. Especially in the world of web development where you're pumping out APIs.
  - eddyschai 4y ago
    Once you get general topics it's fairly trivial to pick up new frameworks/libraries to pump those APIs out. I'm not saying algorithms for the sake of leetcode! Saying this, I was interviewing for several roles across the US and EU last April and had algorithm-based questions in almost all of them. So it's pretty useful for that reason too, even if I don't really agree with it.
    - scarface74 4y ago
      It’s trivial to learn the frameworks needed to be a competent mobile developer? Don’t get me started with the clusterfuck that is the front end ecosystem.
- snorkel 4y ago
  It’s good advice to not only learn about the tools you’re told to use but also learn about the tools that many others are using. Try to be full-stack versatile rather than just really good at one tool in the much larger process.
DantesKite 4y ago
I always like it when an essay is succinct, clear, and has a plan of action for you. Great read.
- cyanf 4y ago
  The font face is also pleasant, nice all around.
Nursie 4y ago
My experience over the last 20 years has been very varied, I would say this applies more for some languages than others - particularly C++. Also more at large, established firms than smaller startups, which are more likely to want to use modern idiomatic practice in whatever language it is. Probably until they become the established firms!
angarg12 4y ago
I'd like to somehow generalize this advice. My take is to compare proactive vs reactive learning. Early in my career I was all proactive learning. I would study languages, frameworks, tools, anything under the sun. Vast majority of these I never used or got any value out of. As I became older and had less time in my hands I had to become more tactical with my learning. I started to switch from proactive to reactive learning. Reactive learning is learning new things in response to on-the-job needs. Does my new team use Spark in Scala? Let's learn about those then. I still like to keep a thread of proactive learning where I do more exploration, just to expand my horizons and have some fun. Still I'd say nowadays my ratio of proactive vs reactive learning must be around 20/80%.
- berkes 4y ago
  One needs the other, though. Quite probable is that you are good at reactive learning, because of the basis you lay down in your time of proactive learning.
bruce511 4y ago
I haven't joined a new job in over 30 years, so what do I know. But having seen quite a few come (and go) it seems to me that some context knowledge helps with getting up to speed. It's not so much that ypu come in knowing the language (most don't) but doing a bit oc research, perhaps watching some videos, all help to learn the jargon. This can mean a faster learning curve when they tell you the important stuff. Certainly the externals help. Can already use Git, know their way around SQL and SQL tools for inspecting databases, know something about database design (3rd normal form) - you don't have to know any of these, but it helps to hit the ground running. And of course you can easily find out topics that might be useful by, you know, just asking in the interview or later. What IDE, or text editor do they prefer - knowing your way around that will help you hit the ground running.
srer 4y ago
I do the opposite. Across C, Python and Go, I was prepared and had a good understanding of the languages and stdlibs before joining through reading books and working through the exercises. It worked very well for me, on joining my knowledge of the languages and their stdlibs was respectable, and I could hit the ground running and get patches accepted easily. I could also in each languages case fix weirdness they had in their code because their own knowledge had gaps. That impressed people and made a pretty good first impression. It's probably not universally true, but in my observation learning on the job much more commonly ends up resulting in sizable gaps in language knowledge. If you've got a role working in $LANG, I don't see how upskilling in $LANG before you join is a trap. It's commonly knowledge with lasting value that offers returns across jobs. I've never worked with C++, I hear hints that it's too big to actually learn and instead one must learn a subset. Maybe that's true, and the article more applies there.
- tdumitrescu 4y ago
  Agreed. Personally I'm always grateful when someone joins and brings along a good up-to-date idea of how our particular languages/frameworks are used and taught by the rest of the world. It's so easy for a big internal codebase to devolve over time into a bunch of weird patterns, and forcing some newcomer/outsider perspectives onto it is a great corrective force.
da39a3ee 4y ago
What this article says is not generally true: get a job at a decent company and they’ll want you to use their language elegantly and sophisticatedly. (My experience is with US tech companies).
brundolf 4y ago
> If it's not a company-specific language, its range of use and ecosystem are probably so big that you can't know which parts of it will be used on the job. > There will often also be rules about which parts of the language you're allowed to use, and how. > With all respect: If you learn modern, beautiful, idiomatic use of some programming language, you're probably not going to see it on the job. This doesn't resonate with my experience at all. It probably depends a lot on which languages were talking about, but the languages I've spent the most time with have pretty consistent best-practices across the industry (there may be a handful of different philosophies, but they're usually not hyper-specific to one company). I think the author is over-generalizing their experience
skybrian 4y ago
It seems like getting a copy of their coding standards (if they have them) would allow for more focused exploration than just asking which language they use.
Existenceblinks 4y ago
Absolutely hate reading job description seeing languages/libs/frameworks that aren't suitable for application the business is trying to accomplish. Apps where UI suppose to be light and fast? BAM, using the bloat view lib. Apps suppose to have minimal api surface, BAM, using unnecessary crazy query component in front of RDMBS. I just can't make myself apply for jobs these days. Bite the bullet and learn marketing bs stuff to sell my own software and no longer worrying about bullshit toolchain is probably a good trade-off.
nine_k 4y ago
Wat. Of course learn the language you're going to use. But you can't expect to make do with just one. In any case you'll face SQL; learn it. It's a language on its own, with interesting and non-intuitive concepts, a number of features, and great power. Learn bash, because you'll have to talk to the OS somehow! (Yes, even macOS. But you don't normally deploy to macOS only.) Learn some HTML and CSS, even if you're a backend developer, enough to show a simple status page for your service. Read an intro into YAML, it's not that trivial! It's useful around great many modern tools. TOML is good to know, too. These are all proper languages, worth knowing for a long time and learning. One could also say that Vi's system of commands is also a language, because it has syntax and is composable; worth knowing, too! This is on top of your language of choice; for backend or mobile development you can usually make do with just one, for web frontend you have to know enough JS, HTML, and CSS at the least, TS is a really good idea, too.
- moring 4y ago
  My job/team might be the exception to the rule, but anyways: "In any case you'll face SQL" -- there is no trace of SQL in our project. We're using a NoSQL database. This may change in the future, though. "Learn bash, because you'll have to talk to the OS somehow" -- our language to talk to the OS is standard libraries. We do have a few bash snippets to glue together the build process, but they are vanishing more quickly than they appear because everybody in the team thinks that bash is inferior to typescript. You're right about HTML+CSS, and this is a trend I've seen everywhere (replacing UIs with browser-based UIs). YAML only exists in a single configuration file, and only because the tool forces us to, as well as a second rather obscure configuration file in a sub-part of the project because another tool forces us to. The tools suck hard, they report errors in the whole file even if it is totally correct. Nobody is using vi, everybody is using either WebStorm or VS Code.
  - LanternLight83 4y ago
    Thanks for sharing! I think it is just your team. 23.3% percent of respondents indicated that they use Vim in this year's Stack Overflow[1], noting specifically: > PyCharm is used more by people learning to code (26% vs 16%) while Vim is used more by Professional Developers (24% vs 16%) [1]: https://survey.stackoverflow.co/2022/#technology https://survey.stackoverflow.co/2022/#technology
joeldo 4y ago
I think if you're going to spend time studying before you start a new job, spend that time studying whatever you find technically interesting about the job. If it was the choice of language that drew you to apply, learning about it is not going to hurt!
linuxftw 4y ago
Man, I don't identify with any of this. If the VCS is something other than git at this point, consider not working there.
- morelisp 4y ago
  p4's still incredibly common in some areas. Plenty of projects are still on hg because there's no major benefits to migration.
- thirdplace_ 4y ago
  Do you mean it's kind of like a red flag when they don't use git? In a previous life I worked at a successful 30-person company. We used SVN and just didn't think the migration to git was worth it.
- BeFlatXIII 4y ago
  Mercurial & Fossil companies wouldn't want you anyway.
duped 4y ago
This may be a hot take, but if you thing that $programmingLanguage is a discrete skill you're doing something wrong. That's not to say there's a minimum amount of knowledge to understand about $language (be it memory safety and UB in C/C++, virtualenvs in Python, auditing and setting up dependencies in node, how to set up tsconfig.json, whatever these are random examples). But the core skills of software engineering are not writing code. I feel there's going to be a point in the next 10-20 years where we establish the difference between programmers and software engineers like there is between mechanical engineers and car mechanics, electricians and EEs, contractors and architects, whatever. The line is super blurry today which is fantastic for labor since we don't have too many hurdles to get into any role, but eventually companies or governments will establish them. I think I'd be happy to be a programmer for my home stuff and hobby projects like people who like to work on their cars, but I also value other domains of expertise like people who design them - and the choice of language is an implementation detail. Over investing in any technology is bad move, when it kneecaps your ability to learn or choose others.
- pjmlp 4y ago
  Which is why in some countries Software Engineering is a protected title, with a specific set of skills to assess, and we don't go around calling ourselves "engineers" after a six week bootcamp. https://www.informatics-europe.org https://www.informatics-europe.org https://www.ordemengenheiros.pt/pt/a-ordem/colegios-e-especialidades/informatica/ https://www.ordemengenheiros.pt/pt/a-ordem/colegios-e-especi... We might still call ourselves engineers without the admission exam (which is a legal gray zone if signing projects), yet the university degree was anyway certified by the organization and the only thing missing is the exam.
  - sh4rks 4y ago
    What are those specific skills? The links you gave don't seem to say anything about that
    - pjmlp 4y ago
      5 years learning about various programming languages, OS architecture, distributed systems, graphics programming, algorithms and data structures, soft skills like project management and risk assessment, physics, math, electronic and digital circuits, among others. Start with https://guia.unl.pt/en/2022/fct/program/1053#structure https://guia.unl.pt/en/2022/fct/program/1053#structure and follow up with https://guia.unl.pt/en/2022/fct/program/1059#structure https://guia.unl.pt/en/2022/fct/program/1059#structure. Before the Bologna changes across EU, those two were a single degree.
shmerl 4y ago
Learn whatever you find interesting to learn.
KerrAvon 4y ago
I don’t think the word “common” should apply to one dude’s anecdote for one company. It’s true that C++ is very large and everyone necessarily uses a dialect of it — their own unique dialect. But learning the STL, for example, would pay dividends in most C++ shops. Outside of C++, this advice is pretty much completely inapplicable.
- bartvk 4y ago
  Exactly. Some time ago, I used Qt at a job and thus I put "Qt (C++)" on my resume. That was not a good idea since like you said, Qt is its own "C++ dialect". Same goes for Python, but to a much lesser extend. I only used Python in embedded projects. A bit of byte manipulation, drawing some plots, etc. Later I got people asking me to help them with their Django-based website, expecting me to be productive from day 1.
travisgriggs 4y ago
Sigh. I’m at the point where I could honestly care less what language/library someone knows. I’ve been working through a big pile/mess that a recently departed teammate has left me to clean up. I wish I had had more bandwidth to see what was going on. What I wish I could figure how to reliably measure when we get around to hiring a replacement: - do they care? They don’t have to agree with my opinions. We can hammer out a compromise with enough laughs. I just want them to care. Because there’s still a lot of things that even the best protocols, procedures, and practices can’t cover. - can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”? - can they and will they ask questions?? To customers, to teammates, in online forums, wherever. Or does their insecure ego prevent them from feeling the fool so that they can become the wiser? -can they be critically honest? Admit what they don’t know when debugging, avoid conclusion jumping, candidly self asses? Or do they need some form of myopia to maintain a narrative about their abilities, their contribution, their value, or the environment around them? If I could reliably convince myself that someone scored strong in these four areas, and had rudimentary programming aptitude we could just skip the rest of these “hiring/new employee” diatribes.
- ls15 4y ago
  > - do they care? They don’t have to agree with my opinions. We can hammer out a compromise with enough laughs. I just want them to care. Because there’s still a lot of things that even the best protocols, procedures, and practices can’t cover. Are their pay and their working conditions the best that the market can offer to them? > - can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”? Do they have the decision power and the salary that go hand in hand with high responsibility?
  - morelisp 4y ago
    There's a difference between being responsible and being accountable. Everyone should be responsible.
    - 4y ago
owenbrown 4y ago
This advice may make sense for some languages, but it certainly doesn’t make sense for Python. Python generally provides one and only one best way to do things. With one exception (single quotes vs. double quotes) I can’t think of any cases where my company didn’t espouse or require using regular, idiomatic Python. My company consistently preferred using expressive features do the language. For example, using list comprehension instead of for-loops. After learning Python, reading up on the frameworks used at my company (Django and Django Rest Framework) would be the next best use of a new dev’s time. This advice might be specific to Django and Django Rest Framework. Both frameworks are old, popular, and opinionated; other people have thought through the best way to do things. Understanding all the packages in the standard library is by no means a requirement, but knowing the language itself backward and forwards pays enormous dividends when debugging.
- mejutoco 4y ago
  The "one way to do it" slogan was useful when comparing to Perl (TMTOWTDI), as it highlighted different philosophies (understandable vs expressive). I think it is wrong to take it literally. There is many different ways of doing the same things in Python.
- pjmlp 4y ago
  So which "one way" do you use to format output in Python?
dukodk 4y ago
Should include metrics. I worked for a BI company where metrics was only for the CTO, not the deveolpers. The screen on the wall for the cloud team was showing the build status of another teams project. And anytime there was a problem, it wasn’t known to the team, until the CTO came to the team because someone had complained to him. Both interperting and creating useful dashboards should be part of any team.
whatever1 4y ago
Depends on what language you know. My first language was FORTRAN (and matlab) and my way of thinking was severely handicapped by the language. My code would be a typical 5,000 line routine with GOTO statements, that worked, but only I knew how to navigate that mess. After I learned C++, suddenly the non monolithic doors opened for me. I also think that people who write c++ write better code, you get to read better code and follow better practices. Python, ruby, go, rust, javascript all clicked very easily afterwards. I still have one more hill to climb, functional programming.
eric4smith 4y ago
Good points all. We are an elixir shop and we never advertised for Elixir devs. Instead we looked for people who knew Javascript and one other language. That works well. We find the people get up to speed completely in Elixir in a matter of weeks. And are quite fluent by the second month. There are a few people who just can't grok it and they were generally bad programmers in the first place. But if you're a shop with an obscure stack - never insist on someone knowing it as a condition of employment. They should know the environment well (Linux, Postgresql, Javascript, HTML, SQL, etc) and they will be fine.
bcbrown 4y ago
I mostly disagree with this blog post. I think one of the most important things to do, if you're starting a job at a company that uses a language you don't have experience in, is to ask the hiring manager what recommendations they have for learning that language. If possible, ask them to ship you the recommended 1-2 books before you start. It's true that there's languages so big that any company will use a somewhat-unique subset of the language, but that's not true of all languages. And if it is true, that's why it's important to ask someone at the company for the right resources to learn the right idioms in that language, for that company. The part I do agree with is that there will be a lot of company-specific stuff like tooling, build process, frameworks, libraries, etc. It's a mistake to think you can "hit the ground running" with a language you haven't used before at a new company, and no amount of studying will change that. All you can do is gain enough familiarity with the language syntax and common idioms that your pattern-matching facilities are already primed, so that when you look at source code you see words and sentences, not characters, if that makes sense. Use the language books as a resource over the first few months as you ramp up on the combination of programming languages, business problems/solutions, infrastructure, build tools, dev tools, etc. Don't treat pre-start book study as a silver bullet. And if your life circumstances don't give you time to do any pre-start study, don't sweat it; most good employers will give you plenty of leeway to learn on the job as long as you show increasing proficiency over a couple months. But if you have the time, resources, and inclination, absolutely do learn a new language used at a new job prior to your start date.
- Theaetetus 4y ago
  Thanks for the thoughtful reply. I address it (briefly) in a follow-up: https://www.natemeyvis.com/on-studying-for-your-upcoming-job-objections-and-replies.html https://www.natemeyvis.com/on-studying-for-your-upcoming-job.... People might not know what the code base is actually like; they have incentives to overstate its quality; and, even if they can point you to a relevant, authoritative book, that doesn't entail that the hour spent with it is better than an hour spent learning a tool.
  - bcbrown 4y ago
    I still disagree, but I think I better understand the disagreement now. I find it easiest to learn a new language by starting with the canonical beginner's book, e.g. the Pickaxe book for Ruby. I find it hard to learn tooling like CI/CD, logging/metrics, etc by reading or through personal projects, I much prefer to learn those on-the-job as necessary. It seems like it might be the inverse for you. Even if a new codebase isn't exactly 'Effective Java' quality, it's good to have that reference to better articulate to yourself exactly how the codebase is flawed.
bmitc 4y ago
Don't learn a language but learn tooling? As in learn the most likely thing to be completely tailored to a company's specific processes, undoubtedly using something you've never used before, and impossible to actually practice on at home with learning or side projects? That makes no sense, especially for a software developer.
- mkesper 4y ago
  Take Git (and good commit practices) as an example: You can benefit in every job by knowing them better.
PeterStuer 4y ago
In my experience both as a developer and later as a manager, learning "on the job" never led to a good outcome. The (implicit or explicit) deadline pressure always led to the most shallow comprehension, weak scrutiny of Googled code and 'first hit' adoption of libraries or other secondary assets, very slow error correction and a cascade of (I hate the term) "technical debt" (which in the same paradigm should be called "technical theft" as we all know no-one ever will "repay" it).
red_admiral 4y ago
Regarding the list of Version control; Testing; Deployment / continuous integration; Databases; and Log management and search: If you are studying CS at college/uni, and you're not taught these things already, then definitely go study them in your free time - people in the real world use them, and it looks good if you've at least heard of the concepts in a job interview. MIT calls this kind of thing the missing semester: https://missing.csail.mit.edu/ https://missing.csail.mit.edu/ It really shouldn't be.
sjamaan 4y ago
> Meanwhile, there is a likely source of confusion you can often address in advance: tooling. Ask about what the team uses for: Version control; Testing; Deployment / continuous integration; Databases; and Log management and search; Metrics (thanks, dukodk!). >Sometimes these will be proprietary, and sometimes they will not exist. Yes, ask this during a job interview and if they don't exist, seriously reconsider if you want to work there.
shetill 4y ago
only people that care what language you know would be low tier recruiters and companies
ravenstine 4y ago
Learning languages is overrated. Yes, get really good with at least 1 language you like, and get acquainted with languages you know you will need to use, but don't think that you must master all of them or that you can't pick them up as you go. In general, languages share fundamental features and constructs, and there comes a point where learning a new one is mostly a matter of figuring out how to accomplish something with a different syntax or paradigm. This is why taking time to explicitly learn about a language without a more precise goal can be wasteful.

145 points by Theaetetus 4y ago

Not sure what to really take from this article. If it's about what one should spend their time learning, try identify the 'timeless' things. Software design over languages, algorithms over libraries, SQL and JavaScript will probably never die.

Theaetetus 4y ago
Author here. I certainly have a lot of opinions about what to study more generally! This was a short note for people who are specifically trying to make it likelier that they'll succeed at a job they're about to start. Lots of people (former versions of myself included) focus too much on learning a language when studying other tools would give a higher ROI.
jimbob45 4y ago
Nobody will hire you for your SQL knowledge but you can be sure everyone at your new company will heavily rely on you if you know your SQL well.
- beckingz 4y ago
  It's amazing coming at software from a data perspective, my assumption that people would know about SQL and databases is just so so wrong all of the time.
  - nijave 4y ago
    Same with infrastructure (and probably security, etc)
  - eddyschai 4y ago
    ORMs definitely don't help! In my first dev role I worked at a C# shop and everything was through Entity Framework. You can't take that skill with you if you change languages to Python, or Haskell, or whatever, but the core SQL skills to follow you around. It's worth the effort, I think (and it's not particularly hard to get semi-decent at SQL!).
XorNot 4y ago
In the job market right now, this seems like terrible advice: no one except Google are hiring for "algorithms" - they want a React developer, or a C#/.net developer who can pump out web APIs in it or something. Companies mostly hire for frameworks below the FAANG level.
- georgeburdell 4y ago
  No, Leetcode has metastasized throughout startup land too. I know because I failed a lot of those interview types in the past year (but I keep trying since the pay is so good)
- ge96 4y ago
  Every time "who wants to get hired" comes out it's always JavaScript/React/Node/Python/C++ at the top (percentage)
- _gabe_ 4y ago
  > they want a React developer, or a C#/.net developer who can pump out web APIs in it or something. All web APIs follow the same basic pattern. The OP said: >> try identify the 'timeless' things. Software design over languages, algorithms over libraries If you understand the fundamentals of software engineering, picking up a new framework or library isn't a big deal. It's the same old tropes with some different syntax and domain language. Especially in the world of web development where you're pumping out APIs.
- eddyschai 4y ago
  Once you get general topics it's fairly trivial to pick up new frameworks/libraries to pump those APIs out. I'm not saying algorithms for the sake of leetcode! Saying this, I was interviewing for several roles across the US and EU last April and had algorithm-based questions in almost all of them. So it's pretty useful for that reason too, even if I don't really agree with it.
  - scarface74 4y ago
    It’s trivial to learn the frameworks needed to be a competent mobile developer? Don’t get me started with the clusterfuck that is the front end ecosystem.
snorkel 4y ago
It’s good advice to not only learn about the tools you’re told to use but also learn about the tools that many others are using. Try to be full-stack versatile rather than just really good at one tool in the much larger process.

DantesKite 4y ago

I always like it when an essay is succinct, clear, and has a plan of action for you. Great read.

cyanf 4y ago
The font face is also pleasant, nice all around.

Nursie 4y ago

My experience over the last 20 years has been very varied, I would say this applies more for some languages than others - particularly C++. Also more at large, established firms than smaller startups, which are more likely to want to use modern idiomatic practice in whatever language it is. Probably until they become the established firms!

angarg12 4y ago

I'd like to somehow generalize this advice. My take is to compare proactive vs reactive learning. Early in my career I was all proactive learning. I would study languages, frameworks, tools, anything under the sun. Vast majority of these I never used or got any value out of. As I became older and had less time in my hands I had to become more tactical with my learning. I started to switch from proactive to reactive learning. Reactive learning is learning new things in response to on-the-job needs. Does my new team use Spark in Scala? Let's learn about those then. I still like to keep a thread of proactive learning where I do more exploration, just to expand my horizons and have some fun. Still I'd say nowadays my ratio of proactive vs reactive learning must be around 20/80%.

berkes 4y ago
One needs the other, though. Quite probable is that you are good at reactive learning, because of the basis you lay down in your time of proactive learning.

bruce511 4y ago

I haven't joined a new job in over 30 years, so what do I know. But having seen quite a few come (and go) it seems to me that some context knowledge helps with getting up to speed. It's not so much that ypu come in knowing the language (most don't) but doing a bit oc research, perhaps watching some videos, all help to learn the jargon. This can mean a faster learning curve when they tell you the important stuff. Certainly the externals help. Can already use Git, know their way around SQL and SQL tools for inspecting databases, know something about database design (3rd normal form) - you don't have to know any of these, but it helps to hit the ground running. And of course you can easily find out topics that might be useful by, you know, just asking in the interview or later. What IDE, or text editor do they prefer - knowing your way around that will help you hit the ground running.

srer 4y ago

I do the opposite. Across C, Python and Go, I was prepared and had a good understanding of the languages and stdlibs before joining through reading books and working through the exercises. It worked very well for me, on joining my knowledge of the languages and their stdlibs was respectable, and I could hit the ground running and get patches accepted easily. I could also in each languages case fix weirdness they had in their code because their own knowledge had gaps. That impressed people and made a pretty good first impression. It's probably not universally true, but in my observation learning on the job much more commonly ends up resulting in sizable gaps in language knowledge. If you've got a role working in $LANG, I don't see how upskilling in $LANG before you join is a trap. It's commonly knowledge with lasting value that offers returns across jobs. I've never worked with C++, I hear hints that it's too big to actually learn and instead one must learn a subset. Maybe that's true, and the article more applies there.

tdumitrescu 4y ago
Agreed. Personally I'm always grateful when someone joins and brings along a good up-to-date idea of how our particular languages/frameworks are used and taught by the rest of the world. It's so easy for a big internal codebase to devolve over time into a bunch of weird patterns, and forcing some newcomer/outsider perspectives onto it is a great corrective force.

da39a3ee 4y ago

What this article says is not generally true: get a job at a decent company and they’ll want you to use their language elegantly and sophisticatedly. (My experience is with US tech companies).

brundolf 4y ago

> If it's not a company-specific language, its range of use and ecosystem are probably so big that you can't know which parts of it will be used on the job. > There will often also be rules about which parts of the language you're allowed to use, and how. > With all respect: If you learn modern, beautiful, idiomatic use of some programming language, you're probably not going to see it on the job. This doesn't resonate with my experience at all. It probably depends a lot on which languages were talking about, but the languages I've spent the most time with have pretty consistent best-practices across the industry (there may be a handful of different philosophies, but they're usually not hyper-specific to one company). I think the author is over-generalizing their experience

skybrian 4y ago

It seems like getting a copy of their coding standards (if they have them) would allow for more focused exploration than just asking which language they use.

Existenceblinks 4y ago

Absolutely hate reading job description seeing languages/libs/frameworks that aren't suitable for application the business is trying to accomplish. Apps where UI suppose to be light and fast? BAM, using the bloat view lib. Apps suppose to have minimal api surface, BAM, using unnecessary crazy query component in front of RDMBS. I just can't make myself apply for jobs these days. Bite the bullet and learn marketing bs stuff to sell my own software and no longer worrying about bullshit toolchain is probably a good trade-off.

nine_k 4y ago

Wat. Of course learn the language you're going to use. But you can't expect to make do with just one. In any case you'll face SQL; learn it. It's a language on its own, with interesting and non-intuitive concepts, a number of features, and great power. Learn bash, because you'll have to talk to the OS somehow! (Yes, even macOS. But you don't normally deploy to macOS only.) Learn some HTML and CSS, even if you're a backend developer, enough to show a simple status page for your service. Read an intro into YAML, it's not that trivial! It's useful around great many modern tools. TOML is good to know, too. These are all proper languages, worth knowing for a long time and learning. One could also say that Vi's system of commands is also a language, because it has syntax and is composable; worth knowing, too! This is on top of your language of choice; for backend or mobile development you can usually make do with just one, for web frontend you have to know enough JS, HTML, and CSS at the least, TS is a really good idea, too.

moring 4y ago
My job/team might be the exception to the rule, but anyways: "In any case you'll face SQL" -- there is no trace of SQL in our project. We're using a NoSQL database. This may change in the future, though. "Learn bash, because you'll have to talk to the OS somehow" -- our language to talk to the OS is standard libraries. We do have a few bash snippets to glue together the build process, but they are vanishing more quickly than they appear because everybody in the team thinks that bash is inferior to typescript. You're right about HTML+CSS, and this is a trend I've seen everywhere (replacing UIs with browser-based UIs). YAML only exists in a single configuration file, and only because the tool forces us to, as well as a second rather obscure configuration file in a sub-part of the project because another tool forces us to. The tools suck hard, they report errors in the whole file even if it is totally correct. Nobody is using vi, everybody is using either WebStorm or VS Code.
- LanternLight83 4y ago
  Thanks for sharing! I think it is just your team. 23.3% percent of respondents indicated that they use Vim in this year's Stack Overflow[1], noting specifically: > PyCharm is used more by people learning to code (26% vs 16%) while Vim is used more by Professional Developers (24% vs 16%) [1]: https://survey.stackoverflow.co/2022/#technology https://survey.stackoverflow.co/2022/#technology

joeldo 4y ago

I think if you're going to spend time studying before you start a new job, spend that time studying whatever you find technically interesting about the job. If it was the choice of language that drew you to apply, learning about it is not going to hurt!

linuxftw 4y ago

Man, I don't identify with any of this. If the VCS is something other than git at this point, consider not working there.

morelisp 4y ago
p4's still incredibly common in some areas. Plenty of projects are still on hg because there's no major benefits to migration.
thirdplace_ 4y ago
Do you mean it's kind of like a red flag when they don't use git? In a previous life I worked at a successful 30-person company. We used SVN and just didn't think the migration to git was worth it.
BeFlatXIII 4y ago
Mercurial & Fossil companies wouldn't want you anyway.

duped 4y ago

This may be a hot take, but if you thing that $programmingLanguage is a discrete skill you're doing something wrong. That's not to say there's a minimum amount of knowledge to understand about $language (be it memory safety and UB in C/C++, virtualenvs in Python, auditing and setting up dependencies in node, how to set up tsconfig.json, whatever these are random examples). But the core skills of software engineering are not writing code. I feel there's going to be a point in the next 10-20 years where we establish the difference between programmers and software engineers like there is between mechanical engineers and car mechanics, electricians and EEs, contractors and architects, whatever. The line is super blurry today which is fantastic for labor since we don't have too many hurdles to get into any role, but eventually companies or governments will establish them. I think I'd be happy to be a programmer for my home stuff and hobby projects like people who like to work on their cars, but I also value other domains of expertise like people who design them - and the choice of language is an implementation detail. Over investing in any technology is bad move, when it kneecaps your ability to learn or choose others.

pjmlp 4y ago
Which is why in some countries Software Engineering is a protected title, with a specific set of skills to assess, and we don't go around calling ourselves "engineers" after a six week bootcamp. https://www.informatics-europe.org https://www.informatics-europe.org https://www.ordemengenheiros.pt/pt/a-ordem/colegios-e-especialidades/informatica/ https://www.ordemengenheiros.pt/pt/a-ordem/colegios-e-especi... We might still call ourselves engineers without the admission exam (which is a legal gray zone if signing projects), yet the university degree was anyway certified by the organization and the only thing missing is the exam.
- sh4rks 4y ago
  What are those specific skills? The links you gave don't seem to say anything about that
  - pjmlp 4y ago
    5 years learning about various programming languages, OS architecture, distributed systems, graphics programming, algorithms and data structures, soft skills like project management and risk assessment, physics, math, electronic and digital circuits, among others. Start with https://guia.unl.pt/en/2022/fct/program/1053#structure https://guia.unl.pt/en/2022/fct/program/1053#structure and follow up with https://guia.unl.pt/en/2022/fct/program/1059#structure https://guia.unl.pt/en/2022/fct/program/1059#structure. Before the Bologna changes across EU, those two were a single degree.

shmerl 4y ago

Learn whatever you find interesting to learn.

KerrAvon 4y ago

I don’t think the word “common” should apply to one dude’s anecdote for one company. It’s true that C++ is very large and everyone necessarily uses a dialect of it — their own unique dialect. But learning the STL, for example, would pay dividends in most C++ shops. Outside of C++, this advice is pretty much completely inapplicable.

bartvk 4y ago
Exactly. Some time ago, I used Qt at a job and thus I put "Qt (C++)" on my resume. That was not a good idea since like you said, Qt is its own "C++ dialect". Same goes for Python, but to a much lesser extend. I only used Python in embedded projects. A bit of byte manipulation, drawing some plots, etc. Later I got people asking me to help them with their Django-based website, expecting me to be productive from day 1.

travisgriggs 4y ago

Sigh. I’m at the point where I could honestly care less what language/library someone knows. I’ve been working through a big pile/mess that a recently departed teammate has left me to clean up. I wish I had had more bandwidth to see what was going on. What I wish I could figure how to reliably measure when we get around to hiring a replacement: - do they care? They don’t have to agree with my opinions. We can hammer out a compromise with enough laughs. I just want them to care. Because there’s still a lot of things that even the best protocols, procedures, and practices can’t cover. - can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”? - can they and will they ask questions?? To customers, to teammates, in online forums, wherever. Or does their insecure ego prevent them from feeling the fool so that they can become the wiser? -can they be critically honest? Admit what they don’t know when debugging, avoid conclusion jumping, candidly self asses? Or do they need some form of myopia to maintain a narrative about their abilities, their contribution, their value, or the environment around them? If I could reliably convince myself that someone scored strong in these four areas, and had rudimentary programming aptitude we could just skip the rest of these “hiring/new employee” diatribes.

ls15 4y ago
> - do they care? They don’t have to agree with my opinions. We can hammer out a compromise with enough laughs. I just want them to care. Because there’s still a lot of things that even the best protocols, procedures, and practices can’t cover. Are their pay and their working conditions the best that the market can offer to them? > - can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”? Do they have the decision power and the salary that go hand in hand with high responsibility?
- morelisp 4y ago
  There's a difference between being responsible and being accountable. Everyone should be responsible.
  - 4y ago

owenbrown 4y ago

This advice may make sense for some languages, but it certainly doesn’t make sense for Python. Python generally provides one and only one best way to do things. With one exception (single quotes vs. double quotes) I can’t think of any cases where my company didn’t espouse or require using regular, idiomatic Python. My company consistently preferred using expressive features do the language. For example, using list comprehension instead of for-loops. After learning Python, reading up on the frameworks used at my company (Django and Django Rest Framework) would be the next best use of a new dev’s time. This advice might be specific to Django and Django Rest Framework. Both frameworks are old, popular, and opinionated; other people have thought through the best way to do things. Understanding all the packages in the standard library is by no means a requirement, but knowing the language itself backward and forwards pays enormous dividends when debugging.

mejutoco 4y ago
The "one way to do it" slogan was useful when comparing to Perl (TMTOWTDI), as it highlighted different philosophies (understandable vs expressive). I think it is wrong to take it literally. There is many different ways of doing the same things in Python.
pjmlp 4y ago
So which "one way" do you use to format output in Python?

dukodk 4y ago

Should include metrics. I worked for a BI company where metrics was only for the CTO, not the deveolpers. The screen on the wall for the cloud team was showing the build status of another teams project. And anytime there was a problem, it wasn’t known to the team, until the CTO came to the team because someone had complained to him. Both interperting and creating useful dashboards should be part of any team.

whatever1 4y ago

Depends on what language you know. My first language was FORTRAN (and matlab) and my way of thinking was severely handicapped by the language. My code would be a typical 5,000 line routine with GOTO statements, that worked, but only I knew how to navigate that mess. After I learned C++, suddenly the non monolithic doors opened for me. I also think that people who write c++ write better code, you get to read better code and follow better practices. Python, ruby, go, rust, javascript all clicked very easily afterwards. I still have one more hill to climb, functional programming.

eric4smith 4y ago

Good points all. We are an elixir shop and we never advertised for Elixir devs. Instead we looked for people who knew Javascript and one other language. That works well. We find the people get up to speed completely in Elixir in a matter of weeks. And are quite fluent by the second month. There are a few people who just can't grok it and they were generally bad programmers in the first place. But if you're a shop with an obscure stack - never insist on someone knowing it as a condition of employment. They should know the environment well (Linux, Postgresql, Javascript, HTML, SQL, etc) and they will be fine.

bcbrown 4y ago

I mostly disagree with this blog post. I think one of the most important things to do, if you're starting a job at a company that uses a language you don't have experience in, is to ask the hiring manager what recommendations they have for learning that language. If possible, ask them to ship you the recommended 1-2 books before you start. It's true that there's languages so big that any company will use a somewhat-unique subset of the language, but that's not true of all languages. And if it is true, that's why it's important to ask someone at the company for the right resources to learn the right idioms in that language, for that company. The part I do agree with is that there will be a lot of company-specific stuff like tooling, build process, frameworks, libraries, etc. It's a mistake to think you can "hit the ground running" with a language you haven't used before at a new company, and no amount of studying will change that. All you can do is gain enough familiarity with the language syntax and common idioms that your pattern-matching facilities are already primed, so that when you look at source code you see words and sentences, not characters, if that makes sense. Use the language books as a resource over the first few months as you ramp up on the combination of programming languages, business problems/solutions, infrastructure, build tools, dev tools, etc. Don't treat pre-start book study as a silver bullet. And if your life circumstances don't give you time to do any pre-start study, don't sweat it; most good employers will give you plenty of leeway to learn on the job as long as you show increasing proficiency over a couple months. But if you have the time, resources, and inclination, absolutely do learn a new language used at a new job prior to your start date.

Theaetetus 4y ago
Thanks for the thoughtful reply. I address it (briefly) in a follow-up: https://www.natemeyvis.com/on-studying-for-your-upcoming-job-objections-and-replies.html https://www.natemeyvis.com/on-studying-for-your-upcoming-job.... People might not know what the code base is actually like; they have incentives to overstate its quality; and, even if they can point you to a relevant, authoritative book, that doesn't entail that the hour spent with it is better than an hour spent learning a tool.
- bcbrown 4y ago
  I still disagree, but I think I better understand the disagreement now. I find it easiest to learn a new language by starting with the canonical beginner's book, e.g. the Pickaxe book for Ruby. I find it hard to learn tooling like CI/CD, logging/metrics, etc by reading or through personal projects, I much prefer to learn those on-the-job as necessary. It seems like it might be the inverse for you. Even if a new codebase isn't exactly 'Effective Java' quality, it's good to have that reference to better articulate to yourself exactly how the codebase is flawed.

bmitc 4y ago

Don't learn a language but learn tooling? As in learn the most likely thing to be completely tailored to a company's specific processes, undoubtedly using something you've never used before, and impossible to actually practice on at home with learning or side projects? That makes no sense, especially for a software developer.

mkesper 4y ago
Take Git (and good commit practices) as an example: You can benefit in every job by knowing them better.

PeterStuer 4y ago

In my experience both as a developer and later as a manager, learning "on the job" never led to a good outcome. The (implicit or explicit) deadline pressure always led to the most shallow comprehension, weak scrutiny of Googled code and 'first hit' adoption of libraries or other secondary assets, very slow error correction and a cascade of (I hate the term) "technical debt" (which in the same paradigm should be called "technical theft" as we all know no-one ever will "repay" it).

red_admiral 4y ago

Regarding the list of Version control; Testing; Deployment / continuous integration; Databases; and Log management and search: If you are studying CS at college/uni, and you're not taught these things already, then definitely go study them in your free time - people in the real world use them, and it looks good if you've at least heard of the concepts in a job interview. MIT calls this kind of thing the missing semester: https://missing.csail.mit.edu/ https://missing.csail.mit.edu/ It really shouldn't be.

sjamaan 4y ago

> Meanwhile, there is a likely source of confusion you can often address in advance: tooling. Ask about what the team uses for: Version control; Testing; Deployment / continuous integration; Databases; and Log management and search; Metrics (thanks, dukodk!). >Sometimes these will be proprietary, and sometimes they will not exist. Yes, ask this during a job interview and if they don't exist, seriously reconsider if you want to work there.

shetill 4y ago

only people that care what language you know would be low tier recruiters and companies

ravenstine 4y ago

Learning languages is overrated. Yes, get really good with at least 1 language you like, and get acquainted with languages you know you will need to use, but don't think that you must master all of them or that you can't pick them up as you go. In general, languages share fundamental features and constructs, and there comes a point where learning a new one is mostly a matter of figuring out how to accomplish something with a different syntax or paradigm. This is why taking time to explicitly learn about a language without a more precise goal can be wasteful.