The first time you have to jump a language for a new project is one of the most frightening parts of being a developer. I previously had to jump between languages for pet projects and solo projects, but I never had to start a large scale project from the ground up in a language I’d never touched before. It was definitely an intimidating prospect, but it was the only way to push forward in my career, so I pushed myself as hard as possible.
There may not be an objectively best or worst method to approaching a new language, but with the stress of the deadlines, I approached everything wrong at first. Our project was to be done in C#, which is arguably a Java dialect, and pretty much my least favorite style of languages. I decided to put down my preconceptions of the language and just go with the flow. I learned a lot about learning a language on the fly. It’s not easy, and it can be painful depending on the deadlines.
The traditional approach didn’t work for me. I had to relearn how to learn a language so I could come up to speed. Then I had to figure out ways to apply my new knowledge, and make sure that what I did was a help rather than a hindrance. Touching on some of the tangentials helped make the whole process more efficient. These techniques primarily apply if you have already learned a language, but can be useful for the first real project too. Real life code is hugely different from the theoretical.
Applying Traditional Learning
It helps me to approach a new programming language like learning a new language. I don’t just want to know how to do something, but why it works. Programming languages tend to be easier to become “fluent” in due to the fact they’re largely made to interact with a rule-based machine.
The traditional method of breaking down the language alone didn’t work for me. I didn’t have time to jump from “Hello World!” to if statements and on. I had to go from knowing very little about the language to where I was functional. It didn’t take me long to realize that the traditional approach was wrong for this type of scenario. The tighter the deadline, the tighter the noose on systematic learning.
Coming Up To Speed With The Language
One of the most important things is to get up to speed on the language in some way. This means starting with the systematic approach on one hand, but also focusing on learning specific tricks to make the current project functional. You don’t want to be dead weight throughout the whole thing.
The first thing I did when working with others was to sit and observe while working on the basics on my own otherwise. What was the team using and why? How were they approaching problems?
This phase meant I could learn some of the key structures we’d use while also learning the workflow of the project. This process is akin to preparing for a trip to a foreign country for business. If you’re going to work on a financial merger, you probably don’t need to learn how to talk about farm tools. By observing what we were working with, how, and why, I was able to laser focus on what we needed the soonest.
Walking Before You Run
As you observe, you need to start working on learning to read the language. You may not be able to write much of anything consistent at this point, but the sooner you can read, the sooner you can begin taking apart what is being done. This allows you to begin writing documentation down the line, but also to get started with testing segments of code. By learning to read the language quickly, I was able to make sense of what we were doing with our project plan, why, and focus on the next steps so I could skip coming up to speed on components which were complete. There was no point learning how to interface at SQL since the scaffolding for database access and classes had been completed previously.
By learning to make sense of what had been done, understanding the principles of coding in general, and by targeting key pieces, I was able to begin contributing much sooner than if I had tried to follow tutorials or a book, or if I had focused on learning to write code from the get-go. I didn’t need to know about file I/O or SQL at this point, I needed to know how to work with REST and JSON. Focusing all of my effort on what was needed most by the team meant that while I learned and they finished up other pieces, I could contribute with boring unit testing and bug tracking.
Beginning to Apply Yourself
My goal in the project was to be dead weight for as short a time as possible. By helping with boring tasks in the beginning, I got myself time to come up to speed with parts of the language, and time to come up with the speed with the language. I tried to learn both practical and theoretical parts in tandem. Knowing the typing of C# was just as important as knowing random code snippets.
This part of the process is a bit like cramming for a foreign language before a trip. You have to learn the grammar and vocabulary to understand what the phrases you memorize mean, but if you only learn grammar and vocabulary, you neglect what you need to know now. Memorizing a bunch of words by themselves is as useless as internalizing the grammar without knowing how to say “restroom”. Theory needs practice to create pragmaticism, and practice needs theory to create authenticity.
Monkey See, Monkey Do
The first thing I contributed was boiler plate code and testing code. These are usually the least desirable tasks and the most repetitive tasks, so it helps the team and it helps you internalize what you’re doing. I spent days working boiler plate methods and classes to fit different pages as necessary. Throwing testing code in and verifying bug behavior and similar also provides a tangible benefit to the team and is easy to learn to do quickly.
This is where you start putting the real code into the project slowly. As you get past the cut, paste, edit segments (tweaking a method to fit a similar button on a different page, or throwing a verification class into a different spot and editing it), you may begin to notice small bugs and things which you can fix. Once I hit this point, I started shoring up small code things which had been overlooked or which had become “to do” items.
Making Your Code Count
By working on both theoretical pieces as well as the practical, I learned more and more how to implement new features. I started with things which were similar to reduce the learning curve. The other important piece to the puzzle is knowing how to research problems.
Each language has its own peculiarities and idioms. If you ignore these, you run the risk of your code being less efficient than it can. For instance, with C#, you have arrays, Lists, and Dictionaries (among many, many others). What’s the difference and what are the use cases? If you don’t know about the List or Dictionary type, how would you find them? Knowing how to research is just as important as what you research.
Data structures and algorithms are important. Both quicksort and bubble sort have their places. Each feature of the language is going to be similar and have its ideal use cases. Some things will just work out to being more efficient than others for the task at hand, and you have to know how to tell with a limited scope of knowledge.
Learning to Not Rock the Boat
Even if the project’s best practices don’t make sense, now isn’t the time to question them. Assuming your team is competent, there’s going to be a good reason things are the way they are. Even if this ends up not being the case, learn to stay your lane and not rock the boat for your first projects.
Soft skills are worth their weight in gold. Get the experience under your belt, learn where a potential inefficiency is, and rectify it when you know what you’re doing overall and can pick your battles. If you start swinging too soon, you run the risk of getting disqualified.
Some of the inefficiencies in my team were things like “a C-suite member demanded it be put this way”. Was it the best reason? No, but the man signing the paychecks kept signing the paychecks. You can’t run until you can walk, and you can’t focus on efficiency until you can work in some capacity. Focus on the needs of the team and the project since you’re learning as you go.
If there is a gross inefficiency, approach it diplomatically and inquisitively. Deadlines and stress can throw a wrench in the process. Ask why it was done a certain way and explain why you feel it might be inefficient. Maybe it’s something in the language you just don’t know, maybe it is a shortcut that was necessary, maybe it was just a negligent oversight. Don’t burn your bridges finding out you’re wrong though.
Focusing on the Process
Depending on the timeline of the process, you may not fully come up to speed by the end. You might run out of tasks to do in the interim for coding. I know I did when things got too out of my depth.
This is where you want to work on debugging and testing code as well as helping with writing better documentation. These are all tasks pretty much no one wants to do, so you get to be a team player, but more importantly, these are all tasks which will help you confront your understanding of the code. Teaching (via documentation) can help reinforce your learning, testing helps you see how things work.
As you get further out of your depth, focus on the process while continuing to work on learning bits and pieces for the language (if you plan to continue working in it). One of the first products I started ended up with improvements because of new tricks I learned as I continued to work on the language. Focusing on the process meant learning faster, helping more, and interfering less.
The Next Steps
Whether you want to (or need to) continue using the language, how long the project has taken, and how much you’ve had the chance to learn will affect what you do next. As you learn the technologies used in real projects with your team and fill in the holes in the theories, you’ll be able to better focus on new techniques and libraries which can help with the next project. If you worked on interfacing with a REST API this time and learned to work with JSON, work on using SQL next time.
Get more exposure and immersion with the language while continuing to approach the theory. If this is your first project or one of your first projects, consider learning to implement data structures and algorithms in your new language. Learn the basics of lists, queues, stacks, sorts, etc. so that you can have the kernel behind all languages and become a better coder overall. Having something to say is just as important as knowing how to say it.
Begin building a reference in your new language of code you can easily reuse. This doesn’t necessarily mean code that’s ready to go for the next project, but things which show you how to approach a problem. Like how a class makes something easy or how it organizes data? Use it as a scaffold for your own code.
Learn from and save code to streamline your learning. As you progress, most of these older snippets become less and less relevant as you internalize the language, but you’d be surprised at what ancient code you may dredge up and reuse. Keep these as you progress and apply them when relevant.
Feature image by Free-Photos from Pixabay