Javascript to Scala: Migration of a Self-Taught Engineer

After about a year of coding professionally, I bravely and stupidly thought I could make the jump from Javascript to Scala. I had no experience in Java. I had no CS degree. And I had never done server-side programming before.

If I was a reasonable person, I probably would have taken a gentler approach. I might have taken the advice of one of three senior developers: one said to learn Java first, one said to learn CS fundamentals first, and one said not to do it at all. It was that third bit of advice that made me want to do it more.

If you are similarly crazy, this article may be for you.

Scoping Requirements

This story starts as most programming stories do: There was a problem to be solved and no one to fix it. In my past life as a front-end developer, I would sometimes find a UI bug with no cause in sight and raise it to the team. The Scala developers would identify it as a back-end issue, use lots of words I didn’t understand, and tell me they’d fix it. Then I’d wait.

It would take hours or days before I got an update. The Scala developers had their own backlog of work to complete, and they prioritized planned feature work over ad-hoc bug fixes. That meant I had to wait for subsequent development sprints for my requests to be picked up. There was also a lot of back-and-forth required between the back-end engineers and me to share the full context of the issue before we could arrive at a proper solution. Without the big picture of how the front-end worked, the back-end team could usually only offer band-aid fixes that failed to mesh with the greater whole. The situation wasn’t helped by the departure of our Tech Lead, who typically brokered those conversations.

I didn’t want to wait anymore, and I didn’t want to settle for “good enough.” So, I went to my manager and got approval to put this crazy plan in gear and work towards becoming a Full-Stack Scala Engineer.

Test Case Development

The first 6 months were terrible. Have you ever heard of the Dunning-Kruger effect, where overconfident people overrate their skills? Well, at least they have the benefit of confidence. I was the opposite - I felt like an idiot, and I was worse than I thought.

The departure of our Tech Lead proved to be the biggest obstacle out of the gate. I got into Full-Stack Development because we lacked a Tech Lead to drive integration, but I needed a Tech Lead to learn Full-Stack Development. And Tech Lead is a difficult position to fill, so I knew it would be a while before the company could find the right mix of expert and mentor.

Back then, my two main resources were my company’s #scala Slack channel, and Programming in Scala, the big white book by Martin Odersky, the founder of Scala. The Slack channel was friendly, but I was too junior to properly frame questions about the problems I was having. The Odersky book was technically comprehensive, and he promised his readers that his book was meant to serve as a tutorial and that no specific knowledge of programming languages was required. However, I found the book to be more of a deep-dive reference than a beginner's guide.

I tried researching online articles, but none of them helped. They were meant for mid-career professionals and CS graduates who understood concepts like concurrency, Important:deadlocks, and object-oriented design. They were meant for Java developers and type-system academics.

It wasn't all bad, though. The type system really clicked for me. I loved the type arguments, generic types, higher-kinded types...the whole gamut. I even loved working with the Future and Either types that seem to drive everyone crazy. The collection library is insanely expressive, and has a method for your every need. Putting the two together, I could now play Type Tetris. This was a milestone for me, and genuinely the main focus of my learning during these months.

However, the good parts didn’t make up for my lack of conceptual knowledge, and I had to learn that the hard way. When it came time for my annual performance review, I went in feeling confident and asked when I would be getting my title changed to Full-Stack Engineer. (Protip: Don’t do this.) My Engineering Director politely informed me I still had a lot of ground to cover.

For example, in my happy frenzy in learning types and collections, I had neglected some very important basics like logging. I legitimately did not understand how loggers worked. I didn’t understand why you needed multiple levels of logging. I didn’t understand why the logger was a mix-in trait, or how mixing in even worked. I didn’t know how to build APIs or connect to databases. I had learned some Scala, but I didn’t learn Full-Stack Development.

Approvals and Controls

And so, my director set a goal for me. If I could spend 70% of my sprint points towards full-stack development for 3 consecutive sprints, then the company would revisit my title change. At the time, I was still spending half my efforts on UI tasks. The other half was dabbling in Scala, web server tasks, and data integration. It was time to really focus on learning Full-Stack Development effectively, not erratically. This more structured approach was exactly what I needed to get over the proverbial hump.

Testing

Focused, structured learning got me on the right path, but the real turning point came when the company hired a new tech lead who saw the value in mentoring those of us that were still junior but trying to grow.

At the time, I still had a lingering paranoia that I was lacking certain foundations (like knowing I didn’t really understand monads), and I was fearful that what I thought I knew was actually wrong (like how Futures technically aren't monads). Before having a mentor, I was convinced that everything would fall into place if I could understand one particular concept, which sent me down rabbit hole after rabbit hole.

With a proper mentor, the difference was night and day. I could finally get advice that was customized to my specific issues supporting our Insurance line of business. I was now getting personal guidance on what to learn next and, more importantly, what not to worry about just yet.

I also found some resources that were more beginner-friendly. Instead of the authoritative Odersky Scala reference, I went for his online Cousera course. The online course gave me building blocks for foundational learning, like the evaluation model or the distinctions between by-call, by-reference, and tail recursion. I was learning the stuff that mattered, in a way that made sense to me. For example, I found Underscore.io’s Essential Play books to be the perfect blend of recipe and concepts in an approachable style for developing web framework knowledge.

Release

Bit-by-bit, I got better. I built services to query databases. I built APIs. And yes, I learned what logging was. I hit my first sprint target of 70% full-stack work. And then my second sprint. And then my third.

Management had senior developers review my code, and it passed. My title change was submitted to HR, and in October of 2019 (about 1 year and 1 month from the start of my journey) I officially became a Full-Stack Scala Developer.

Lessons Learned

If I could recommend one resource for Scala to my younger self, it would be Hands-On Scala by Li Haoyi. I gave it a skim recently, and it’s exactly the kind of resource I would have strived to write for others.

For faster learning, I recommend installing the Scala REPL tool, Ammonite, also by the same author. You can test out Scala syntax in your terminal as if it were an interpreted scripting language like Python or Javascript.

For the wider ecosystem of Scala libraries, I recommend Underscore.io’s ebooks. I can personally attest to Essential Play as a supplement to the official Playframework docs, and I’m currently making my way through Essential Slick.

Blog posts should wait until after you’ve familiarized yourself with the language and ecosystem. When you get there, check out Li Haoyi's blog—seriously, this guy is amazing.

Check out Coursera's Functional Programming in Scala (mentioned above) for lectures by the Scala creator himself, Martin Odersky.

But most importantly, find a company that will help you through the growing pains. Switching engineering tracks is a lot like migrating code. The process takes careful planning, quality assurance, and constant evaluation. It takes a team to make that happen, and I wouldn’t have made nearly as much progress without the people at QOMPLX.

We are hiring!