I’ve come in contact with quite a few programming languages in my time at Atomic. My first project was built in TypeScript/React using our starter kit, and since then I’ve worked with Java, Objective C, Ruby/Rails, Swift, typescript for React Native, and most recently F#. Getting up to speed on a project sometimes requires not […]
I’ve come in contact with quite a few programming languages in my time at Atomic. My first project was built in TypeScript/React using our starter kit, and since then I’ve worked with Java, Objective C, Ruby/Rails, Swift, typescript for React Native, and most recently F#.
Getting up to speed on a project sometimes requires not only getting familiar with the project, the domain, and the deployment environment, but also the language itself. Here are a few of the steps I take when onboarding a project where the programming languages used are new to me.
The official documentation is an obvious first stepping stone on the path to understanding a new language. This can include things like quick start guides and articles of the “why choose such and such” variety. These sources often include fairly simple examples.
They won’t show you how to set up, say, enterprise-level dependency injection or fancy testing frameworks, but they’re a great way to get a high-level feel for a language. You might see “hello world” or the Fibonacci sequence, depending on whether the language leans more procedural or functional.
The Wikipedia page for a programming language can provide an awesome stepped-back view of a programming language. While official docs and getting started guides are focused on how to get going with a language and why you should choose it, the Wiki page for a language will give you a lot more unbiased context.
What languages inspired this one? How long has it been around? What problems did it try to solve? Are there any interesting details about its package management or runtime ecosystems? All of these are great details to have in mind.
My most recent new language has been F#. F# for Fun and Profit has been an amazing resource for brushing up on more advanced concepts relating to F# development. Before that, I got a lot of mileage out of Point Free while working on a Swift project.
These third-party blogs tend to dig into bigger examples and demonstrate how to start solving real day-to-day problems. They might address things like, how do I set up idiomatic dependency injection or a fancy testing library? How can I translate some code in a language I’m already familiar with into this new language?
They’re also likely to be written by folks with a huge depth of experience using the language for real applications. As such, they tend to be filled with great ideas and warnings for common pitfalls.
Reading through your own project’s existing code is always a great idea. Not only can it help you nail down a deeper understanding of the domain, but it can also help expose gaps in your understanding of the new language that you can go and fill in.
Find some syntax you don’t understand? Look it up or ask your pair. Wondering why that variable is in scope? Dig around some Ruby internals and really learn what’s going on.
Also, try to answer nuts and bolts questions like: How do we write our tests? How are the project files organized? What’s the application entry point? How does this piece of code get running from the entry point? What files deal with business logic and which files are build and configuration related?
This exercise is great for challenging the understanding you’ve developed in previous steps. With a good amount of official and third-party documentation, as well as programming language history and real working code and tests under your belt, pick something that looks a bit less than idiomatic and refactor it.
This has a number of benefits for testing your understanding of your new language as well as your project domain. Not only does it require that you read and understand the intent of an existing piece of code, but it also challenges you to apply lessons about what cleaner, more idiomatic code looks like in this language.
Learning by doing is always going to be the final step in mastering any new language. With all of the understanding built up from previous steps, grab a story off the backlog with your pair and get working. The more lines of code you read, write, and understand, the closer you are to mastering a new language.
Break some things on purpose to see if you understand how and why they’re broken. Fix them. Improve old code. Write new code. Ask for feedback from your pair and on pull requests.
I think you’ll find it useful to follow some or all of these steps when starting a project where the programming languages are new to you. Read some code, write some code, break a few things, and you’ll be crushing it in no time.
Source: Atomic Object