9 ms·

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?

• revskill 4y ago
  Just a JIRA task for next sprint with 2 points assigned !
• tikhonj 4y ago
  The trick is that Go isn't a new language, it's an old language with a new coat of paint.
  • nostrademons 4y ago
    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.
    • skohan 4y ago
      "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.
      • nocman 4y ago
        > "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".
        • skohan 4y ago
          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.
          • lupire 4y ago
            By the time you have real maintainability problems, it's too late to improve code quality.
            • skohan 4y ago
              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.
          • nocman 4y ago
            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.
    • yazaddaruvala 4y ago
      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.
      • lupire 4y ago
        None of that is "3days" . That's all the negative days before you start using the language. I could do all those setup things in N days without ever learning any programming language.
        • yazaddaruvala 4y ago
          I think you’ve misread / misunderstood the original post. “3 days into the job”
      • 8note 4y ago
        That sounds like a description of the team onboarding process, not the engineer doing the onboarding. Any engineer should be able to do this because the team has written good wikis and has working build tools, tests, etc
    • deleted 4y ago
      [deleted]
    • fisf 4y ago
      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.
• skohan 4y ago
  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.