Why is 3 days, likely with competing priorities, a reasonable timeframe to learn a new language well enough to contribute production code in your estimation?
I've had to jump into projects with unfamiliar setups and even unfamiliar languages more than a few times, and after a certain point it's all just problem solving. Like I had to fix critical bugs in an orphan rails project with next to no experience with Ruby and it worked somehow.
Are you going to write elegant, idiomatic code in the first week? Of course not. But give the task "make the system do X", 90% of coding is knowing how computers work, and the other 10% is knowing how to search on stack overflow to be able to translate what you want to do into the desired syntax.
3 days to learn how to write syntactically-valid Go or 3 days to learn how to write idiomatic Go?
Idiomatic Go has some very large differences from idiomatic Java or PHP, including things like 1) the reliance on multiple return values and early exits for error handling 2) interfaces instead of inheritance 3) plain old data structures instead of everything-is-an-object 4) goroutines 5) table-driven testing 6) complete reliance on gofmt for formatting rather than doing it manually. And that's just the stuff that I'm aware of, as someone whose primary language is not Go but worked in it for about 3 months.
My definition of a senior dev would be someone who's aware that they can't just pick up a language in 3 days and write idiomatic good-quality code, but expects that they're going to have to keep learning for multiple years to really master a language. It's the metacognition of realizing how little you know and always continuing to learn.
Really all it is is "3 days to showcase you have a working compiler, ide, formatter, can run the tests, and are familiar with the CR tools".
The rest of it is learned (hopefully quickly) through the CRs, and any senior engineer should be comfortable making a few idiomatic mistakes in their CRs that they learn from.
A person proficient in multiple programming languages absolutely knows all of the 6 concepts - it's just cases of 'aha, go allows me to do x,y,z and this is how things should be done'.
I basically learned ideomatic go in a week, by skimming over the "effective go" guide and cross referencing concepts to other languages I know -- there is really nothing inherently 'new' in Go that would require years. It's a deliberately simple language.
"code quality" is not real, it's just something software engineers like to argue about like sports.
We like to talk about how code is written, because we look at code all day. The rest of the world only cares about what your code does once it's compiled.
Senior engineers solve problems. They're not overly concerned with ticking all the boxes just so they can get a "good code" sticker.
> "code quality" is not real, it's just something software engineers like to argue about like sports.
While I do agree that many developers sometimes like to argue about "code quality" too much (and I've probably been guilty of that at times), "code quality" is definitely a real thing. I have have interacted with code bases that were a joy to read/modify, and I've interacted with code bases that made you pull your hair out at every turn (and also many levels in-between the extremes). It is not always a case of just "arguing for the sake of arguing".
Probably I am being a bit hyperbolic. I could be more precise and say: code quality is a solution you should reach for if and only if you are running into real maintainability problems.
But I strongly disagree with the sentiment that someone should not write code in a certain language, or should not contribute to a project until they know how to write idiomatically according to all the "accepted" best practices. It's a pedantic and elitist attitude which has little to do with making good software, and runs counter to the practice of learning how to use a language, which is necessarily a process involving ignorance, trial and error.
I think somewhere in the middle is a good place to start. This can be managed by limiting the scope of code a "language newbie" writes (until they get reasonably up-to-speed) -- if/when that is possible. It also helps if you have someone experienced in the language who can help point them in the right direction when they need help. That can be a challenging thing to do well. Deciding where to provide direction, and where to just let them figure stuff out on their own can be difficult. You can come off as being too picky, or just being a jerk when you were just sincerely trying to help. I think to do it well you have to be vigilant about keeping your own ego in check. It has been my experience that most people who are fairly good at something (present company included) can slip into the state of "thinking more highly of themselves than they should". That's always counter-productive, and in my experience good "mentors" (or whatever you want to call them) are the one's who excel at avoiding it.
It's never too late. I've had to pick up development on orphan projects before, and some of them are real stinkers. You can always quarantine the bad bits and start to impose a proper separation of concerns.
Code quality is very real, but the bounds you have to exceed before lack of quality start to bog down development are pretty large.
As a senior I can pretty quickly tell in the languages I write in often, when something is a smell, and if you keep repeating some code smells for a like a year you'll start seeing compounding effects on development speed. Understanding when to allow those with good reason and when to coach someone to stop doing those is an important skill for a senior imo.
But it's definitely not immediate, way more of a pernicious concern, the codebase will effectively rot until it's painful to make changes.
Eh, I've seen a number of startups sunk (as in went-out-of-business sunk) because of code quality issues. Eventually you hit a wall where every bug you fix introduces more bugs, and the product does not converge to a state where you can launch it. Then the VCs start getting impatient and you run out of money.
The point where this happens depends a lot on problem domain. If you're doing well-understood CRUD-screen database stuff but applying it to a novel business domain, you're probably not going to hit code quality issues. If you're doing heavy algorithmic, OS, financial, or networking stuff, though, where failures compound and any one bug might take the whole system down, you really want to pay up for experienced developers that have seen all the ways these systems can fail.
Oh sure, I didn't mean to suggest code quality can't kill a business. I however think like you said it's very domain dependent on how quickly that happens. I think taking on no debt wrt to code quality is impossible though and knowing how to take on that debt and pay it down to effectively meet the broader business goals without doing irreparable harm is something everyone has to contend with while being a dev.
That said, I can really only speak to web api dev, data engineering and search. I'd say out of all of those search was the tightest area with regards to quality and even then I was lucky to be working with another very talented dev. Him and I didn't run into very many issues we were unable to solve with scaling the technology even after hitting 100m pages or so and we could have kept going on scale but we were cost constrained, navigating the business side was far more challenging for us.
I'll admit as well I've been pretty lucky so far to work in situations where code quality is considered and managed and haven't yet worked somewhere where the concerns were entirely ignored or the team didn't care.
>The rest of the world only cares about what your code does once it's compiled.
People in your company (including non-engineers) definitely care, because code quality bears on how easy it is to debug problems and how easy it is to implement new features or fixes (or sometimes if a feature is even practicable).
