1. 24
  1.  

  2. 12

    There’s an important point that is hinted at but I didn’t see directly addressed: the criticality of the project. The typical advice is to use what you know and that’s great advice for critics projects, things that matter. Use Java or PHP if you want because the tech stack isn’t nearly as important as the business outcome.

    But if this is a casual project or experiment (whether a side project, hobby, or even an internal tool at your company), then the choice doesn’t matter. Use whatever you want, even if it’s new. Because the tech stack is far more important than the business outcome. Take the chance to learn something new.

    1. 16

      I think the best time to experiment with new languages on the job are for non-critical internal tooling. Tools that make things more convenient, but if they broke people would still be able to work.

      1. 5

        tech stack isn’t nearly as important as the business outcome.

        This is a common sentiment. I disagree. PHP and Java are slower and harder to write and manage than other options. I would 100% use Clojure, because the business outcome is important and an easier tech stack makes all the difference.

        1. 2

          I’m not sure you’re disagreeing with the statement, really? I would argue that having something which is easy to work with and to maintain is an important part of having a good business outcome.

          Whether people at a particular shop find Java, PHP or Clojure to be the easier tech stack is another question, mind…

          1. -1

            If the business outcome is important, I would never choose Java - why even consider a tool which has null??

          2. 5

            The flip side of this is that for extremely critical projects the choice becomes important again. I use dynamic languages day to day but if lives were at stake I would want something with good static analysis tools.

            1. 4

              Nice in theory [1]. Way back in 2013, 2014, I was asked to look into SIP. It’s mainly a text protocol with your standard response, headers and body structure. So I used what I knew, Lua and LPEG, to play around with the SIP protocol. I even got the program to parse SIP messages and push them into our backend [2]. Unbeknownst to me, my manager deployed my “proof-of-concept” to production. It’s now a critical piece of our infrastructure (the other components are all written in C or C++).

              [1] In theory, there’s no difference between theory and practice. In practice, there is.

              [2] Which at that point, only supported CDMA via SS7.

            2. 3

              Yeah, exploring a new tech stack is pretty fun, but for me at least, to do anything beyond a trivial programming project these days usually requires deep knowledge of a programming language/framework. Nowdays, to even entertain the idea of using a different language or framework I’d like it to be at least 5-7 years old with plenty of documentation and examples. so by the time I get around to it, and learn enough of it to be useful. It’s already the old tech stack. I think it’s mostly because I write complicated medical software though.

              1. 3

                Ouch. So should we just suck it up and use what we know?

                I was with this until the “No” after this question.

                “Yes” is (almost always) the right answer here. The cavalier-ness about this is so wrong. There are better ways to combat boredom than to knowingly make a sub-optimal technical decision that in all likelihood will have year+ long consequences.

                The article had already established what’s actually going on:

                They are watching people give talks about other languages… So you’re saying we’re just chasing a new shiny object? Yep.

                Perhaps instead of learning this shiny language that makes them feel cool but won’t change anything about their deeper knowledge, they could combat their boredom by expanding their knowledge of what they already know, and learning things that actually matter – e.g., that working effectively with simple and “boring” tech on a high-performing team delivering valuable products to the business and customers will be way more fun than the shiny thing.

                1. 2

                  Someone has to irrationally pitch new technology and use it so that new paradigms get tested and formed.

                  Also, it might be not the lowest risk road but for me, choosing none mainstream technology has often worked very well. It gets to be a problem if you revisit your choices too often for too little cause.

                  1. 2

                    Be careful - Turning a new project into a learning opportunity for your team can be the greatest mistake you make as an engineering manager.

                    It depends on the situation of course. But it is not a given that combining a new project with a new stack will result in success.

                    In my opinion There are better and less risky ways to broaden your skills and look beyond what you know today.

                    Never stop learning. Never stop moving forward.

                    1. 1

                      I couldn’t agree more. Encouraging your team to try a totally new language, framework or paradigm for an actual production project that has anything like a deadline puts all kinds of not particularly constructive pressure on the learners.

                      Better to have some kind of 20% time or such that’s scheduled but has very squishy metrics around deliveries, and encourage people to play with new stuff there where the consequences of failure are non existent.