Working Outside Your Comfort Zone
One of the key skills of a higher level developer is being able to drop into just about anything and make contributions. It's one thing to be comfortable and highly knowledgable in one specific skill or set of skills such as Ruby on Rails, but it can be quite difficult to jump into an area you have no framework for and be able to work within it.
Ruby on Rails has been my professional bread and butter since version 2.3 but recently I've had to expand my horizons a bit more often and I wanted to write down some thoughts on how I've approached this process. This is not a skill that you can ever truly master but just like anything else you just keep learning it. It's a requirement for staying relevant as technologies change and the industry progresses.
Read the documentation (all of it)
If you're starting in a new language or framework that you have no familiarity with it's worth just opening the official documentation and reading it from front to back. Of course you're not going to master everything on the first go but it will give you a good understanding of the entire breadth of the tool. You'll have some idea of the words and concepts that are commonly used and when you recognize something you'll know where to go look it up.
Alternatively, if you're someone who can get easily distracted when reading something on the internet, pick up a physical book instead. Most programming books run between $30 and $50 which is a bit on the expensive side but often companies will have a learning budget for engineers that you can use to purchase things like this that you'll be using for your job. Make sure that the edition you're buying is relatively up-to-date if the topic is something fairly new or changes very quickly.
Set it up locally (and break it)
In the vast majority of situations you're going to need a development environment set up so that you can work on the project outside of a public or production setting. Follow whatever documentation you have, whether it's a README written by past developers on the project or the "Getting Started" section of the official website, and if you have any trouble make sure to write down what happened and your solution. You can submit changes to the documentaiton with your findings. If you get completely stuck, ask someone else on the team for guidance or post to a forum like Stack Overflow.
Once you have everything set up and running in your development environment, go ahead and break a few things. This can be as simple as going into a random file and adding some jibberish that causes a syntax error but it will give you some insight into how various areas of the code can affect the product.
Read the tests
If you are jumping into a new project that has been built by other engineers you should take a look at their automated test suite. If it has been lovingly maintained, you'll get some great insight into what the most important flows and systems and how they should be operating. If it's been abandoned or doesn't een exist, consider making some of your first actions to be getting it up to speed.
Become the expert
Are there other people on your team who are also out of their element? Offer to give an overview presentation of the things you've uncovered in your initial investigations. If there are new technologies give an overview of those as well, including common commands and tools that they might need to work on them. Consider creating a runbook of your ways of working and share them with your colleagues.
Feeling comfortable outside your comfort zone is a process but it can give you the confidence and seniority you need to advance your career and become an engineer of the highest caliber. I'll continue to update this post with other thoughts I have, and if you have any suggestions or experiences of your own don't hesitate to contact me.