My latest project uses a framework that I wasn’t familiar with at the start of the engagement. It’s not the first time this has happened, but in the past, I’ve always had teammates as tour guides — at least one person on the team had worked in the codebase or with the language before I joined.
This time, I was jumping in as the technical lead, and my partner and I were both totally new to the framework. This forced me to apply my Atomic-grown fast-learner skills even more than usual, and I had more than a few moments where I learned things the hard way.
While it’s tempting to just dive in, I suggest you take time to learn about the language first. It can save you a lot of headaches and lost time down the road.
1. Learn its Strengths and Weaknesses
This one seems obvious on the surface. When Atomic goes to career fairs, we put out a whiteboard with the question, “What’s the best programming language?” Obviously, it’s a trick question. The goal is to get folks talking about the attributes of their favorite language (and to suss out whether they’ve got a more thoughtful opinion than “Java is bad”).
There’s an entirely different blog post to be written on choosing the right language for your project, but the same principles by which one might choose a language for a project can be helpful for getting to know a language. Consider:
- Does it tend to favor a particular programming philosophy?
- Are lambdas well-supported, first-class citizens, or are they a pain?
- Do arguments pass by reference or by value by default?
- How verbose is it? Would it be wise to invest in setting up snippets or autoformatting?
- How does it handle null/undefined?
- Etc.
2. Learn How it Wants to Be Used
For one of our early projects in the Accelerator, we were tasked with writing a relatively simple program in Clojure. I presented mine and was told, “It works, but it’s not Clojure.” I was peeved at first — I’d spent hours figuring out Clojure’s weird syntax!
The problem was that I’d effectively written a C++ solution, then painstakingly bent Clojure into its likeness. I hadn’t taken advantage of any of Clojure’s extensive capabilities, and I had been working around language features that existed to protect the developer.
When you’re picking up a new language, take some time to read code samples and learn how common problems are solved. Learn the language’s idioms and best practices. Working with your language will not only speed up your development process, but it will be much easier for future developers to edit and maintain your work.
3. RTFM
Most importantly, read the (fine) manual. Rather than talk this one to death, I’ll just give an example.
I worked for a few months on an app that had originally been generated from a template by CLI. We knew that we’d eventually need to add authentication to the app, but that story hadn’t come up in our backlog yet. We continued working and built a significant portion of the app, and when it came time to implement authentication, we had already established architecture around how we would handle related features.
After investing significant time into building our authentication, we learned by chance, while searching documentation, that the CLI we were using had a built-in generator for authentication endpoints, account creation, and the like. Cue facepalm. We could have used this tool from the beginning and saved not only the work but also the placeholding and planning around authentication that we’d done.
Getting to know a new language can be daunting. Hopefully, these tips help you hit the ground running!