[claimred]

>In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career.

I've always been a bit baffled by notions like that. How in the world one becomes a professional in a foreign programming language tech in 6 months? It feels like every modern realworld battleworn programming stack (ecma, c++2x, .net, jvm w/e) is filled with nuances and quirks which, as it turns out, an engineer _must_ know about to be able to bump revenues a little bit and to call themselves a professional. Hell, even inside _one_ stack there are a lot of special interest fields. Is every C++ programmer a graphics programmer? Can a C++ programmer become one overnight? Highly doubt it.

>If a Python shop was looking for somebody technical to make them a pile of money, the fact that I’ve never written a line of Python would not get held against me.

How? How is that possible?

[NiKMic]

Because companies don't care about how 'clean' you code is, what design patterns you use or what cool new technology you are using. They just care that you manage to release quickly so the company can start making money.

So even if you don't know the best way to do things or the best pattern to use, as long as you can hack something together that works reasonably well for some time then you're good enough. Sure, it might be flimsy, break easily, unreadable etc. but if the company is making money then business is happy.

Think about it...code becomes legacy so quickly. 2-3 year old code is considered legacy, especially if it's not used/modified much. You could have spent 15% more time to make it more maintainable but it will still be considered bad code by the next guy who had to work on it because he has absolutely no idea how the code works and what it is meant to do. Chances are, it would be re-written anyway even if you spent that extra 15%. The in the meantime the company might have missed their initial release date and some potential revenue.

Not saying I agree with it but that is how it is unfortunately.

[bhldev]

Depends on the business model. If you sit on the bleeding edge all the time maybe (even if you don't you should strive for the newest possible for the skills and budget if only for retention and hiring).

But if the whole point of the company is to build some generic software that's configurable then absolutely the inside and code matters because it's a hard requirement. You could build specifically to one type of configuration but it would not solve the other. And that means generic, abstractions, reuse as part of the business case not just some nice to have for clean code.

So it very much depends. It's also possible to take it too far. As for internal release dates I have always considered them bullshit ever since I heard executives talk about how they pad the time. The more layers of management the more padding and if everyone works separately in different teams the more the padding. Developers are better off ignoring internal release dates and building the best software they think possible to not compromise on quality. They can cut scope but at the end of the day the software better work. The only thing you shouldn't ignore is warning people if it will go over time. Since 50% of software goes over time that's expected.

Either it's good or it isn't either it works or it doesn't and the timescale devs are used to (sprints, days, stories etc) don't have any bearing on reality. If it takes a month more because it has to that's how long it takes. The concept of "MVP" or feature set is totally separate from a good piece of software; once you get there you can release and iterate and improve. And it's called "minimal" for a reason if you stop there your software is sunset. The features and improvements have to keep rolling.

[shantly]

I've more than once gone from knowing nothing about a language + ecosystem to releasing something comparable in quality to the norm for the platform, in three to six months.

It's mostly about knowing what you ought to be able to do. "Where's the hello world example? Let's get that deploying so we get in a good feedback loop. This is a GUI system that's not the Web, so probably there'll be event hooks or callbacks or something, I'll go look at how I respond to a click event and that should give me a good idea. And probably I'll draw with method calls of some kind and want to organize my code in such-and-such way as a result to keep the drawing code together, but maybe they have an XML design language or some other junk, I'll go check". Stuff like that.

Or "this is a web-focused backend framework so I need to figure out the idiomatic way to interact with storage systems like databases, how & where it's best to set headers, should see if it's got some standard way to manage migrations, et c."

You know what you need to do, the right way's a Google or glance at the docs away, and a lot of it's a once-per-project thing or something that can be quickly hidden behind a simple function call or just copy-pasted as necessary and appropriate. The rest is just refs/pointers, loops, objects, recursion. Normal shit everything has.

The hard part is usually the build & packaging system, in my experience, because those are usually terrible and are usually where the big hair-pulling multi-hour-losing unproductive speed-bumps show up. Big & popular doesn't make it any more likely to be much better or easier to figure out "best practices", as described in hip blog posts versus reality (see: Javascript).

[usaar333]

Because most languages are highly similar and Google + your IDE is powerful enough to make up shortcomings. E.g If you have solid background in dynamically typed) languages (e.g. python, J's), GC static typed (Java) and lower level (C/c++ and/or one flavor of ASM), you've basically seen all ways of thinking. E.g. picking up something like Go can be done in a matter of weeks. Languages with more novel concepts though (e.g. That's memory model) will be much harder to onboard to.

> Is every C++ programmer a graphics programmer? Can a C++ programmer become one overnight? Highly doubt it.

That's different. It's the domain jump (be good at graphics) that is hard, not switching languages.

[friedman23]

> It feels like every modern realworld battleworn programming stack (ecma, c++2x, .net, jvm w/e) is filled with nuances and quirks which, as it turns out, an engineer _must_ know about to be able to bump revenues a little bit and to call themselves a professional.

I think you are overestimating how important those nuances are. The differences between Python and Ruby are not significant. The differences between Java, C#, or Golang are not significant. If you are a trained software engineer and have coded with one managed memory language, one garbage collected language, one typed language, one untyped language, one functional language and one object oriented language you have seen 99% of what there is to see. Most computer science grads should graduate having programmed C, Java, and Python