Comment by Jtsummers | Hacker News Reader

Comment by Jtsummers | Hacker News Reader

Parent Full thread

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.

> You would probably not want someone with little experience in given language, to touch production codebase without review

I wouldn't want anyone, in any language, with any level experience to touch production codebase without review.

Not even K&R themselves.

So that's a ridiculous straw man.

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.

I don't want your attitude at my business.

Everyone makes mistakes. And code review is also about knowledge sharing and avoiding single points of failure in staffing.

> Not even K&R themselves.

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.

Reply on news.ycombinator.com