I would never fault someone for not being able to pick up a language and use it competently in 3 days. I understand why you use this as an example, with having samey syntax, but there is still nuance. I think the bigger indicator is you've been in the industry for 10 years and call yourself a PHP/Java dev. At this point you should have dabbled in probably 10-100 ways of solving problems depending on what your 9-5 looks like.
I recognize the value of expertise in a language. I recognize that I have touched so many different languages that any "expertise" that I might have possessed at some point has probably passed as I've missed out on new features, etc. I guess I would just expect you to be really knowledgeable and efficient in python!
So I don't think it's an issue, if that's been your job. My job exposes me to a lot of different technologies: many programming languages and endless different software that might be supporting a web application (databases, webservers, firewalls, etc.). I consider my value to be looking at problem and being able to spot 10 different possible points of failure in a system in my mind and order them by priority based on likelihood and ease of troubleshooting. And this is something that I think is only gained through experience and that's what separates me from someone who just started.
Yeah. I wouldn't even say that I'm amazing at Python, not really! Much of my time these days isn't spent writing code. But, I can still get things done quickly. I wouldn't say I'm a superstar, though.
Who said you need competence, looks like that was your own insertion, haha. But seriously is it not unreasonable to be able to write some non-deep dive code in a new but similar language in just a few days? 3 days is a long time to read and ask questions.
What purpose does it serve though? I think being able to read and understand a Go program is a better example. That does seem like a reasonable and useful ask in 3 days for a veteran PHP/Java dev, and something that is more likely to come up in practice. What is the context of the former? "Welcome to our team. I know we didn't hire you as a Go dev. You have 3 days to "be able to write Go".
I have long subscribed to "A programmer is not language specific", and I don't hire based on the languages you know. But that first task is "Here is access to the repo. Read and understand what our code does today please. I'll answer questions within reason." Acquiring the new language happens as a side effect.
If you hire someone in a language they don’t know, you expect them to learn on the job. It’s reasonable by day 3 to expect them to show some code - even if terrible.
I would say, most? Or maybe I have been really unlucky, lol! I don't think it is POSSIBLE for an employee at my current company to be productive before week 2.
Same. I've never seen anyone become proficient in a new language/platform in less than a year. Sure, you could learn Go's syntax, use it in the style of Java/PHP, and make it work, but that is not being proficient in Go and its idioms.
A year is enough time so your new language stops teaching you new things every week. I agree that superficial knowledge can be attained quickly, but learning the idioms, tooling, libraries, gotchas, performance bottlenecks, warts, etc. takes months.
Maybe six months if you're very good, but I'd wait a year before assigning a big project to someone new in a language/framework. Still wouldn't consider them a master with just one year of experience, mastery of a modern language can take years, you can always go deeper.
I would bet hard money that even an experienced developer wouldn't learn C in a year (e.g. avoid or recognize most UB and security issues) without prior exposure. I'll grant that C is pathological in that respect though.
Maybe we have different bars for what it means to learn something, but if I worked with an experienced dev who took a year to learn C (and there was an actual need for them to learn it) I'd question their claimed experience. It shouldn't take more than a few weeks to be capable of using C if you have a decent background with other procedural languages and already know the difference between heap and stack storage (so you don't make the mistake of a past colleague of trying to return data on the stack, he didn't claim to be experienced though).
Learning a language and mastery are separate things. An actual experienced dev should be able to hit "competent" in any new language within weeks so long as it's within the same family of languages they've used in the past. Procedural languages, like C, are pretty much squarely in the middle of what everyone has learned unless by some fluke they started and continued with Haskell and similar languages and never touched any of: Go, Rust, C#, Java, Javascript, Lua, Python, Perl, Ada, Pascal, Fortran, Matlab, BASIC (various forms), and a hundred other languages.
They might be able to get the compiler to accept their code, but that's not a good bar for competence in C. I personally wouldn't consider someone competent in it unless they're deeply familiar with UB and other language warts because it's too dangerous to do otherwise. UB can have nonlocal effects and "time travel" so any UB anywhere in the program legally invalidates the entire program, regardless of whether it would otherwise work. Most other languages have (wisely) decided not to carry that legacy forward.
As we all know, the subject of UB and the practical ramifications of particular instances is a topic few people could reasonably learn in weeks or even months.
There's a lot of baggage that comes with each language. I could probably learn any language at that point, but it also takes time to learn whole ecosystem, mostly used libraries and tools. You typically can't do this in week or two, because you need to actually write something and see how it feels, if there are any surprises.
You would probably not want someone with little experience in given language, to touch production codebase without review, because there are always traps that you might've not encountered in other languages.
I typically don't touch low-level programming languages, but once I had to use C to write some small adapter to communicate with some Oracle product. I did it, it worked as expected, but I would not be able to use it efficiently for complex solutions without more experience with creating and managing solutions in C.
I can also write in Go with some basic proficiency, I felt confident at one point in my abilities, but when my code got reviewed by someone specialized in Go, he would propose several improvements that did not cross my mind, because I had less experience in Go.
> You would probably not want someone with little experience in given language, to touch production codebase without review, because there are always traps that you might've not encountered in other languages.
I never said otherwise. This is part of the distinction between competence and mastery. I would not expect most people to master a new language in just weeks, but a senior developer should be able to be competent within weeks. Now, would they have a product or substantive (non-trivial) change to show after those weeks? Maybe not, that might take a few more weeks, or longer if it's larger in scope.
> I can also write in Go with some basic proficiency, I felt confident at one point in my abilities, but when my code got reviewed by someone specialized in Go, he would propose several improvements that did not cross my mind, because I had less experience in Go.
That's part of learning, but it probably didn't take you a year to learn enough Go to get something in a reviewable (if not passing review) state.
Yet it happens in many companies, when team is working on non-critical systems or in extreme cases, even on critical systems. I sometimes feel like some people in IT are detached from reality, not everything is mission critical system and not everything has high quality, because there's a lot of people in IT with all kind of background and there all kind of clients with different sets of requirements. It's business, not utopia.
This feels like a town cop enforcing strict speed limits in the couple of miles that fall in their jurisdiction. If K&R show up at your door and want to touch your production code, you just let them, bring them coffees, and ask for autographs. Even if it breaks, it would be an amazing story.
Being proficient and using it are two different things. A year to learn? What are you talking about, in a year you can get someone who never used a computer beyond a browser to learn just about any commonly used programming language. Yes, they won't be level 99999 one-man-army ninja fullstack senior engineer, but they would be able to write code.
If you had 10 years of java, you can absolutely learn how to write Go in 3 days, unless your 10 years of java is "writing CRUD in Java 6 with libraries available in 2006".
Eh—I don't know. Code a test or two and something basic with just the lang? Sure.
The whole stack? Takes about a month to get productive and about three months to really internalize. Think interned strings in Python vs symbol exhaustion in Ruby. Or serializers in Django Rest Framework working as both input validators and output generators compared to stock Rails views.
Super similar languages with lots of similar frameworks and libraries, but they have these edge cases that still crop up.
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).
In other words you're inventing some silly criteria that I'd guess you'd pass that others wouldn't. What I would say to that is that if you dismiss someone else's experience because they can't do some task you think they should be able to do rather than understanding that their experience probably brings something else to the team then that's your failing, not theirs.
For a little annecdata - I've been a dev for 25 years, with a senior level (and above) title for about 80% of that, and I reckon I'd take at least a couple of months to get to a point where I was happy with golang. I guess that makes me a junior in your opinion. However, instead of being able to get up to speed with a language quickly I bring a fantastic level of respect for users, a talent for technical writing, a belief that documentation is actually important, a sense of fun and joy in making high quality software, and a deep understanding of browser-based software. If I was looking for a new team member I'd seek out someone a bit like myself rather than someone who can learn a new language faster.
I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team. We are expected to deliver according to a plan while we keep hunting for relevant info.
I would say the second point is a lot more nuanced than stated.
This _could_ be true for some, but it directly conflicts with the stated goals of the language. Most people (that I've spoken to) would consider Go to be a simpler language, with fewer features, than other comparable languages.
The issue with Go is the implicit footguns you will inevitably hit. Starting out with Go sure feels like a super power because of the simplicity and productivity, until the code base has grown and you now meticulously inspect every single line to understand the entire context a change is bringing, because you do not trust it in isolation to be correct.
Python is also an easy to learn language, and you'll likely make correct programs quickly. Idiomatic Python, though, is a longer road. You won't feel confident to open source your code for months.
Saw a company fail because all developers were expected to master k8/helm etc. A couple of us got the hang of it well enough to get by. But almost everyone failed too.
Even those of that had it working, it was a huge time sink.
In what way were the developers expected to "master" k8/helm? In the sense of actually making contributions to the k8/helm setup, or simply using an existing k8/helm setup to provide a development environment? Was there any "expert" person on the team that everyone could ask about k8, or was everyone simply supposed to pick things up on their own?
(asking because my own team is currently moving in this direction, and I'm curious about the pedagogical challenges we might face)
Ima be facetious here and suggest that the above is meant in the sense that K8 is the ultimate leaky abstraction and you have to "master" it first before even starting starting to achieve anything with it.
And Helm is just closing the cycle of Samsara - if you really want to base your operations on string templating, just use bash lol. Or hand-written forms on paper, still faster and you still get a better idea of what's going on.
There's also the problem of many developers nowadays just not having the hacker mindset/actual high-level abstract thinking/attention span, so instead of seeing the whole of K8S as the pointless kludge it is, they only see the interface - yay, YAML, I know that language! (usually they know it from everyone's favourite "dead" tool, docker-compose; which is a gem) - and they go on to fight with it tooth and nail, with corresponding feelings of "achievement" and "mastery".
I think the "10 years PHP/Java -> 3 days Go" thing from granduncle's cousin post is meant to point out this particular paradoxical situations.
But it could hurt people's feels to say it like that so let's just let Google do all our thinking for us instead. We truly live in a gilded age of computing.
Anyone who is either insecure about their own skills, or so proud of their skills in their area that they can't face being a beginner in another area, will struggle and come up with reasons not to learn it. And they'll tell their nontechnical colleagues or managers that the idea is overengineered, or they'd add more value elsewhere, until it happens or they leave.
That's why I'm a huge fan of server-less. Let Amazon or Google handle the tough parts until your company is big enough to have to optimize for server costs.
> I am stuggling with helm/kubernetes and the new company's ecosystem where everybody is new in the team.
I can't speak for Helm, but working with Kubernetes in Go is almost uniquely difficult. Kubernetes modules are designed to be dynamic, and Go's type system doesn't make that easy, which leads to some cludge-y code out of necessity.
Plus the API is vast, and it's sometimes not clear what package you need for a particular use.
golang is a language designed for fresh graduates to write fast code without much thinking. It isn't tough at all. For engineers that never worked with CSP paradigm, or rather for engineers who only ever work with Java style OOP and concurrency, it might be weird to adjust, and they will spend 3/4 of their time bitching about how much it is easier in language X.
Usually, they will appoint a cold room for 1-1 meeting to hear what's going on. And find out whether it's hiring process or teaching process that's the problem.
You've spawned a silly thread, because mastering a language is a spectrum that takes years.
In 3 days someone should be able to fix a small business logic bug in a program in a new language, like copy-pasting a if-block to handle a new simple case, or improving an error message by grabbing a variable from context and for setting it for output, but not write a useful program.
