1. 25
  1.  

  2. 8

    This article felt like a bucket of cold water poured on my head.

    You can’t model our language learning as a walk forward. You have to think of it as walking in the wrong direction against a treadmill as the landscape changes and makes our old knowledge archaic. And if you measure your marketability and value to a company in terms of the techs you currently know, you’ll spend a career running the wrong way on a treadmill to keep up.

    Ok, that’s both obvious and a surprise, why haven’t I noticed this already?

    The conclusion is also a surprise, but something I can easily accomplish, so I’m suddenly wishing I could put more than one up vote on this article. I can become an expert at solving specific problems! I know how to do that!

    1. 8

      I like a lot of the ideas in this article, but one disconnect I have is that I don’t think “polyglot” is equivalent to the “experience tuple”. In my thinking, polyglot doesn’t mean “PHP, Ruby, Java, C#”; it’s “PHP, OCaml, J, Rust”. Polyglotism is all about learning new languages that are completely different from what you’re used to, where as little of your programming knowledge transfers over. It’s about how many different ways you can contort your brain into a pretzel, not the number of languages you know.

      In that mode of thought, polyglotism doesn’t directly help with my job. I’m might be able to convince people to switch from Ruby to Python, or Python to Go, but no way in hell am I convincing people to switch from Ruby to SML/NJ. Nor am I ever going to be able to write a server in Mathematica. But each language makes me feel like an idiot again and teaches me different lessons, and often those lessons help me improve as a programmer. There have been a few projects at work that were a lot easier because I was able to approach them from a different perspective, even if that perspective came from hacking on LaTeX.

      1. 5

        Sure I get that, but in the context of the article it doesn’t matter - since its still just a “problem transformer” question and not a “problem solver” question. Of course some problems are easier to solve with one piece of tech over another. But why not lean on the solving part rather than the tech part? Don’t pitch it as that you are a LaTeX expert, pitch it as that you are a publishing workflow expert (or whatever problem you were solving with LaTeX!)

        1. 2

          That’s the goal of polyglotism for me: not transforming problems between languages but taking lessons from different languages to solve problems without translation. The reason to learn, say, Haskell isn’t because you can break a given problem into “use Ruby” vs “use Haskell”. It’s that Ruby and Haskell approach problems in very different ways. And regardless of the problem domain, being able to think in different ways makes a lot of problems easier to solve.

          One example: I’ve dabbled in J a little, nowhere near enough to be comfortable with it (although it’s on my list for a deeper dive), but enough to recognize a few things that were new to me. One of them is the obverse, the idea that functions should have a corresponding function that ‘cancels it out’ (like an inverse but not mathematically rigorous). So if f is the function and f^:_1 is the obverse, f^:_1 f x = x.

          I’ve never done anything really cool with obverses in J, but I’ve taken the ideas and used it to improve my Ruby on Rails. One testing trick I’ve found is to write an obverse to your function and check they cancel out. I don’t think I would have used that without prior exposure to J.

          1. 6

            I think the author meant something different by “problem”. Example problems are:

            • Our company is really bad at following up with leads.
            • Our e-commerce site cannot withstand the extra traffic on Black Friday.
            • The features we’re producing are constantly buggy.

            From this perspective “the code is unreadable” isn’t a problem (but it may make changes take longer and be more expensive which is a problem). People use software we write not to enjoy the beauty of our code design choices, perfectly named variables, and low cyclomatic complexity. They use it to save time, entertain themselves, make money and do a ton of other things.

      2. 6

        I don’t think the problem the author is writing about has anything to do with being a polyglot. Would knowing a single language/framework/technology (i.e. not being a polyglot) solve the issue? No.

        The problem is that people, not only programmers, think in terms of inputs not outputs. They think about what they do, instead of the results they deliver to the client, customer, or employer.

        For example, do surgeons provide operations or improved health? I won’t weak up one morning and exclaim “What a wonderful day for appendectomy!” An operation is the cost I need to pay for improving my health. The same applies to dentists: I don’t go there to enjoy my dentist’s monologue! (although she’s really likable!)

        Conclusion: stop thinking about the things you do. Think about what it helps users achieve. If you’d like to read more about specialization for developer then I greatly recommend you check out what my friend Philip Morgan does (look for Resources at the bottom of the page).

        1. 1

          This is one of the most sobering article I’ve read in a long while. It’s cold, it hurts but it feels so right.

          1. 1

            The one piece that I think is missing from this picture is that experiencing true diversity of languages expand the set of problems that you can actually solve, rather than just translate. It’s also worth pointing out that finding the set of problems that you are actually good at solving is not likely to happen super early in your career, and it is worth exploring different problems and programming tech as you go.

            Also worth bearing in mind is the business value of each bit of tech you come across. Parsing comes in handy when you get a wonky data format you’re trying to ingest, for example. Knowing how to write concurrent servers from Go or BEAM can have good applications for sync or chat based applications.