https://nytimes.wd5.myworkdayjobs.com/en-US/Tech/job/New-Yor...
https://nytimes.wd5.myworkdayjobs.com/en-US/Tech/job/New-Yor...
https://nytimes.wd5.myworkdayjobs.com/en-US/Tech/job/New-Yor...
There’s a lot of value in building tools that fit the domain and workflow perfectly well. It’s expensive in the short term but in the long term saves a lot of time and money.
It takes a 'team' to provide any sort of professional level of support for an organization of their size. If the one-person "CMS/tech wizard" decides to stop working, or die, or get sick, or take an extra 4 hours to be with their family, the entirety of the NYT operations should just say "oh well, we'll just wait around for a while until we find our next one person to be our tech saviour"?
For backend specifically, on the CMS team there's this job https://nytimes.wd5.myworkdayjobs.com/en-US/Tech/job/New-Yor... or a fun one with the cooking team https://nytimes.wd5.myworkdayjobs.com/en-US/Tech/job/New-Yor...
That said, aren't you using C++ as a proxy for other needed skills though? Many Python programmers are not exposed to concepts like vtables, or they do not know how a linker works(or why it is even needed). Heck, many won't have done manual memory allocation or manipulated pointers.
Funny that you mention linkers, as they’re a bit of a minefield. Lots of the behaviour of linkers is platform (and implementation) dependent, I.e. are you building a shared library or an exe on windows or linux, and there are different gotchas for all of them. We wouldn’t expect people to know al of those things, but it definitely helps when it comes up, and you don’t have the same problem (ODR violations come to mibd) in many other languages...
A shop that says it requires years of experience in a particular language is probably making their own hiring situation more difficult than they need to.
C++ for example is definitely a sharp language that takes some time to adjust to, and experience in C will help.
However: I think any competent programmer with a few years of experience would be able to gain basic proficiency in a month or two and probably daily-level-mastery in 6-12 months.
I say this as someone who had 10+ years in Java and only passive experience in C. I've managed to become mostly proficient in C++14 in about a month of full-time learning. After 10+ years of programming, I can pretty quickly adapt to the C++ way of thinking about things. I don't think I'm alone in this style of learning a language, and many hiring teams seem to agree.
No language is inherently "better" than another. They are each useful for specific cases, and understanding more languages means understanding their contextual strengths and weaknesses.
I work in games on gameplay and engine code.
It should be.
Picking up language X is very easy for most values of X (more esoteric ones excluded). After you know a few (and the more diverse the set, the less new concepts you'll see), picking up a new one is quick. If it is something like Go, it's a weekend's worth.
Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time. If you are a solo developer, or if the entire team is ramping up at the same time, then it is bad.
But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not? They may even bring new skills to an otherwise homogeneous group.
I always let the interviewee pick the language during my interviews. Usually it is something like Javascript or Python. Sometimes it is Bash. I keep waiting for the day someone will offer to do it in Scheme, Haskell, Elixir, Prolog, D, Rust, even Ada. Pseudocode is actually fine too, unless I have a reason to think the individual lacks programming experience.
Whatever you do, DO NOT brand yourself as a X developer, if X is a programming language. I can understand specializations like machine learning. But languages? It's a mere tool, and you need more than one in your toolbox.
It really depends on how much time you have to wait for a new hire to ramp up before they are useful. If you need immediate help, then hiring someone who doesn't even have experience with your programming language is a complete non-starter. If, on the other hand, you are hiring for the long term and can afford to pay a ~3-month tax for a good engineer for (hopefully) several years, then you are correct and the ramp-up cost becomes pretty insignificant. But don't make the mistake of thinking that this is an exception to the rule—what languages you know absolutely does matter to any company needing to get work done now.
I disagree. If you know Y and you're learning X, it depends much more on the value of Y. If Y is Lisp you will be quite successful at learning any X. If Y is something like C or assembly language, then you will not (it's always easy to spot the C guy who just started using Python etc.)
Yeah. As in years. This stuff also changes all the time so requires perpetual learning.
>But languages? It's a mere tool, and you need more than one in your toolbox.
It's not a mere tool and languages are more than just trivially learned syntax. They are the umbrella under which a panoply of tools, approaches, ideas, priorities and culture aggregate.
Sure, you specialization isn't necessarily always the optimal approach and sure there are benefits to the cross fertilization of ideas across community lines. However, being a jack of all programming languages, master of none probably means you'll suck more than a specialist at a lot of stuff.
Moreover, some ecosystems plain suck and avoidance is the sign of a good programmer. Statistically, you're probably a worse programmer if you've used a lot of PHP and better if you've learned rust/F#.
Absolutely, which is why I didn't stop at "I am a developer". That "who is good at Python" bit is definitely important.
However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad. That will put a lot of companies off hiring you (companies that believe in a 'best tool for the job' approach anyway, and those are the ones you probably want to work for).
If a company didn't hire me because they idiotically interpreted "I am a python developer" to mean "I would try to build a rendering engine in python" then I'd say that's probably a bullet dodged.
I'd interpret it as "I don't build rendering engines but I build other stuff for which python is a good fit", but maybe that's just me being weird.
The trope about great programmers being people who reverse binary trees in their sleep and being able to swap ecosystems at the drop of a hat needs to die. Great programmers specialise.
You aren't honestly trying to sift out clueless prospective employers out by their ability to parse a title, are you?
The advice here is to put focus on ability to write software, and experience using python as a tool to do so, rather than implying that your ability is limited to python.
What parent was trying to explain is that an individual is not defined by a specific subset of his/her experience.
Just as fluency in Spanish does not make me Hispanic, experience in python does not make me a "python developer". That title puts focus in the wrong place.