The LSP Revolution

Remember the days when you had to look for plugins for your editor to support your favourite programming language? Or even the language that isn’t your favourite, but which for some reason you need to write in? Well in case you didn’t notice, those days are gone. They aren’t “long gone,” but the are gone. I thought they weren’t gone, but they are. Gone. For real. Because there’s LSP.

Continue reading “The LSP Revolution”

How not to interview software engineers

  1. Don’t ask them to do an overly time-consuming assignment, unless you’re going to pay them. If they need to spend more than a couple of hours and you expect the solution to ship a full suite of tests, you’re doing it wrong.
  2. Live-coding is fine, but tell them in advance. Some people get very stressed during those interviews, so make sure they can prepare, technically and emotionally (also they may need a drink or seven, which I think is totally fine).
  3. Don’t make the live-coding or any technical interview into a dick contest. It’s meant to test your candidate’s coding and thinking, and to be a discussion about technology, programming, and software design. You’re not there to prove the interviewee wrong or to show them who’s smarter.
  4. To that point, try not to make it about a particular programming language or a particular technology. Make it generic, skills are transferrable. (There are exceptions of course).
  5. Don’t come to the interview unprepared. Have a plan for what you expect from that interview and, ideally, tell it to the interviewee.

See? Not that hard, or at least it shouldn’t be. It’s unbelievable that only few companies are able to heed to that advice. Remember that if you’re a software engineer involved in recruitment, you have a say about the design and execution of this process.

Be an agent of change! 🙌

Yes, I’ve been interviewing recently. I went through many interviews. I am astounded how many companies fail miserably at recruiting.

VS Code

The best, most entertaining and immortal topic in software engineering is back! Editor Wars!

After reading Roben Kleene’s blog post I realized that I’ve been using VS Code all-day every-day for over a year now. I’m not willing to admit it because in my mind I’m a die-hard (n)vim user, but the reality is this: VS Code is brilliant. Kleene makes many great points about key ingredients of VS Code’s success (popularity/MS backing, plugin ecosystem, client-server architecture), and you should read his post.

Then today I read about “modernizing” Emacs, I saw the discussion on HN, and this comment in particular made me think:

I think VSCode is more than yet another editor, it’s more than what Textmate and Sublime were. There are two major reasons.

Continue reading “VS Code”

dotGo 2019

A couple of weeks ago I went to Paris to attend dotGo (thanks, MessageBird!), one of the biggest Go conferences in Europe. dotGo lasts only one day, and it’s single-track, but it’s a solid offering with great organization, excellent venue and awesome talks. I realize I sound like a dotGo commercial, but as a former academic I remain amazed at how much better professional conferences are, and in the case of dotGo we’re talking orders of magnitude.

Not all of the dotGo 2019 talks were brilliant, but I see even that as an advantage; it’s easy to make a good conference by putting an all-star speaker line-up. It doesn’t allow for younger, less known people in the community to present anything, though, and I think dotGo organizers’ decision to present a mix of established engineers and newcomers was very successful. They also succeeded in having a variety of topics, and many of the talks weren’t necessarily Go-specific. Sure,

Continue reading “dotGo 2019”

Go vs. Scala

One of Go’s features is that it doesn’t have an excess of features, and frankly, I think that feature is undervalued.

There’s an interesting discussion on Quora about the differences between Golang and Scala.

As a former academic with tendencies towards functional programming, I used to be very tempted by Scala.1 It offers all the functional goodness without the exoticism of Haskell, and came with reasonably good tools and frameworks. Like Clojure, it’s a functional language you can actually do some work with.

The problem with Scala is, the more advanced you get, the more complicated (unreadable?) your code becomes. I remember that back in grad school the dude who was able to doodle the craziest and mathematically most challenging solution to some problem in Haskell was someone everyone looked up to. But it turns out in the “real world” simplicity always trumps virtuosity and sophistication, which is one of the many reasons I love Golang so much. A language with no “magic,” good concurrency support, great documentation and community that compiles into machine code and runs faster than Python? Yes, please.

Read the whole Quora thread, though, there’s a lot of interesting stuff there.

  1. This is not to say that I don’t like Scala. I really do, it’s just that my love for it is, hm, not as unconditional as it used to be. 

Lazy evaluation

Every time I try to advertise functional programming to non-functional programmers, one of the key features I mention is lazy evaluation. ‘You can have infinite lists! How awesome is that?’ And every time I actually need or want to use this great feature, I end up evaluating some infinite data structure and killing my SBT or GHCi.

Turns out one has to be careful with awesome. Especially the infinite kind.

Easy way to remove unwanted/broken Haskell packages (Cabal is not a package manager, remember?)

Managing Haskell libraries/packages is a huge PITA, because you can’t easily resolve dependencies, can’t easily delete old/broken versions of packages, simply because Cabal is not a package manager. This sucks, that’s why every now and then what I have to do is to purge all my conflicting packages, and here is the easiest way to do it:

ghc-pkg check --simple-output | xargs -n 1 ghc-pkg unregister --force

After that you can simply cabal install any package you need.