In an effort to avoid writing my first tutorial, I found something I wanted to investigate beforehand. What is it that makes someone switch to or learn a new programming language, like Go? What comes before ‘Hello World’?
(Skip if you don't want spoilers)
- At different stages and levels throughout your career, your reasoning for choosing to learn a programming language can change.
- At the Junior level, it could be your first one. You may desire something that's quick to access and use, has easy to understand resources and can get you on the employment ladder.
- At the Senior level, your time and focus could be stretched to different things, not only in work, but in life. Having trust that the language has a strong community backing and doesn't require you to dig into reams of difficult documentation can make the choice easier.
- At the Staff level, your decision to ask a team to switch to another language could affect the hiring focus and culture, so you need to consider not only the technical trade-offs, but the people trade-offs as well.
On With The Show
This week I talked to two developers about the different stages in their career that led them to switching to another language.
I’ve affectionately dubbed them ‘Blue’ and ‘Red’, because of my younger self's love of Pokémon.
Blue is a Senior Software Engineer, who had their start in the tried-and-true University Computer Science trinity (C++, Java and C#), switched to Ruby, transitioned to Go and has now transitioned back to Ruby, the traitor.
Red is a Staff Engineer, probably. (I forgot to ask). They’ve recently had to decide whether it would be worth it to move their backend systems to use Rust, instead of Node.js. This included convincing the engineers at the company, who worked on those systems, to use Rust as well.
We’ll be looking at Junior, Senior and Staff level positions.
Now, to define quickly what each of those levels are, I believe it’s something like this:
New to programming, haven’t been working professionally long and feel nervous about asking for help because they don’t want their colleagues to think they’re useless. (Don’t worry, that feeling never goes away)
Have reached the point where they receive a constant barrage of ‘Senior Software Engineer’ LinkedIn in-mails and have conquered their imposter syndrome enough to apply to the ones they’re interested in.
Ditto, except their decisions may have a greater effect on the direction of the technologies used at their company.
Now we’ve got a bit of facetiousness out of the way, let’s get down to business. I’ll be quoting and referencing two engineers at different stages of their careers in the next few paragraphs.
What might a Junior Developer look for before writing ‘Hello World’?
Ease of Accessibility
One thing that stuck out to Blue when transitioning to Ruby for the first time was how easy it was to start coding. They looked online for a way to Try Ruby and there was a website where, without even installing anything, they could experiment and do a walk-through tutorial.
I had the same experience with Go and the Go Tour, (although I didn’t finish it, at the time). But, it gave me the confidence to go off on my own and start building a project.
To Blue, "Ruby felt liberating" when compared to the languages they knew, because it was so different and weird compared to the structure of Java and C#.
Due to the mix of open source and, "actually good documentation", they felt confident to pursue the switch. It also helped that they had friends who they could work on a project with, who were going through the same switch.
I never would’ve picked up Go, if it wasn’t for the community. Especially that early in my career. Learning a new language felt like a really enormous commitment and I needed a level of reassurance to feel that it would be a good idea. I knew I had meetups, easy-to-understand documentation and guides, to fall back on if I ever felt stuck.
Early in Blue’s career, the technical benefits and usage of a language didn’t matter. It was about getting onto the ladder. Where they were living, there were very few Java-based jobs on the market. It didn’t really matter that Ruby was good for Web Development, as this early in Blue’s career, they were open and eager to get stuck in anywhere. They weren’t sure what they’d make out of the career and just wanted to find out what the market was like.
When I picked up Go, I didn’t even know what microservices were and concurrency was a module I failed at university. What concerned me was if I could get hired using the language. And I really doubted that back then. I don’t think I'd met any ‘Junior’ Go Developers at the meetups I was going to which definitely knocked my confidence in my ability to get hired.
What might a Senior Developer look for before writing ‘Hello World’?
Easy to Learn/Pick Up
At this level, both Blue and Red shared sentiments that learning and switching languages is less of a big deal. Most mainstream languages have several similarities.
They develop into being tools, which are good at some things and not good at other things. You bring a hammer for a nail, and a duck for a pond. However, that doesn’t mean they’re going to drop everything and start learning C, just because, in theory, it might be the best tool for a job.
In fact, that’s what helped with Red’s decision to try out Rust. It’s a low-level language, which is what they needed for the project, but comparatively to C, it was more user-friendly, "C with loads of guard rails".
Although Blue believes, the more languages you know the easier you can pick up other languages, they aren’t in their 20s anymore. The languages they choose to learn will be ones they pick more carefully. Ones that, if they commit to, won’t make them obsolete in a few years.
In Blue’s case, they’ve now gone back to Ruby. There is still the learning curve as over the years a lot has changed in the Ruby space, but the familiarity made it an easier choice to switch back. Blue also mentioned how their understanding of a new language (Go) is helping them look at Ruby differently.
A healthy community allowed Blue to make a confident decision to switch. It lessens the risk, and can make the job more enjoyable. Blue has taken an active part in both the Ruby and Go community, though sadly they might not make it to Gophercon UK this year. But they promised to come to a few London Gophers, so they are forgiven.
What might a Staff Engineer look for before asking their team to write ‘Hello World’?
For Red, it started with a bottleneck. Now I won’t pretend to understand what they were working on or what the issue was, but let’s just say they needed to query a database 100,000 times per second and the Rust proof-of-concept proved to be 10 times faster than the current Node.js solution.
Cool, so time to switch right? Well no, there was another important factor.
I asked Red why they chose not to use Go, because Go’s my hammer and everything’s a nail.
They’d thought about it, and loved Go, but it wouldn’t have been a good fit. Not only had nobody in the company used Go, a lot of the engineers at Red’s company were already dabbling with Rust in their ‘free day’ (A day engineers, at their company, get every week to explore and experiment with literally anything).
Blue had similar comments as well, "Choose a technology and any tool, it all comes down to people". Think about the people you’re working with now and in the future.
If there aren’t that many people on the market using the language you want to switch to, you might end up killing your project, as there will always be a steady supply of people who decide to move on to new things, but there may not be the reverse if what you’re working with is too niche.
Community was still important, but at this level another angle was brought to my attention.
Blue believed that languages have different cultures surrounding them. As in, there are certain languages that work better in the fast-pace of a start-up, compared to a company that has a more traditional corporate structure and history.
For Red, they strongly believe their company culture enabled their success when switching to Rust. They had a C-level person who not only codes, loves it and was learning Rust, just like their engineers. Having top-down support for learning and moulding a culture of curious and passionate engineers, enabled their company to innovate constantly.
Red’s engineers would never have been able to discover the benefits of Rust without being given the free time to experiment. And, they’d never be able to learn the new language without being given the free time to study, learn and, if they were so inclined, go to different conferences and meetups.
And thus we’ve reached the end.
Now, I really should’ve thought of a grand wrap up or point, but this time I don’t think there is one.
The purpose of this post was just to walk through some reasons people with different skill levels may decide to try out a new language. I know my reasons have shifted over the years, and a big part for me is the community aspect. I can’t deny that I’ve learnt most of what I know from others and can only hope that as I move forward, I’ll able to pass some of that knowledge on.
I mean, to be fair we haven’t even covered those brave souls who choose to pick up and support a language prior to it being remotely popular. They’re just out there contributing for the fun of it.
And Blue and Red would probably add that doing so would help your growth as an engineer, but so would a couple of push ups and high heels.
Anywho, thanks for reading and good luck out there! See you next week.
P.S - Inspired by the interviews I decided to open the C++ book for the first time since I was 19 and realised the very first page is likely what turned me off going further. (I think the person who gave it to me 'out of the goodness of their heart' just wanted it gone 😂).