The ability to learn new skills is important for everyone to have down to a science, in my opinion. New skills are an asset. They make you more interesting, well-rounded, and employable. I genuinely love learning new skills—especially those that I can teach myself. That is partially why I took so well to computer programming. Self-teaching at my own pace made computer programming more enjoyable. Generally speaking, it is now possible to learn how to code for free and on your own time. This makes the career path to software development much more accessible (and quicker). But what happens after you’re already considered a “software developer?”
Soon after starting at Detroit Labs I was placed on a project in which the learning curve was steep. There was a lot of “ramping up” I had to do to get up to speed with everyone else. After a few months on the project, I rolled off and found myself with a lot more “free” time. My primary thought at the time was: “what do I do in the interim?” I felt that I was lagging behind because I hadn’t been keeping up with the latest tech. I must have failed myself while I was working on the project because I didn’t learn Kotlin and Haskell and Machine Learning all while I was trying to actually do my job.
Oh…and I forgot to become a React Jedi to boot.
What were my next steps supposed to be? How was I going to catch up?
In retrospect, it seems that many of my worries were fueled by fear of not growing quickly enough. Perhaps I would be exposed as an impostor if I weren’t well-versed in 40 different programming languages and at least conversational in some of the most complex topics in artificial intelligence right. now. So rather than getting overwhelmed, I made (a semblance of) a plan. What did I do? Here it is:
0. Take a break
It is easy to fall down the “I have to do this now” rabbit hole. In my experience, however, rarely does this attitude produce anything fruitful in the long-term. Mental exhaustion is a thing and burning out does happen. By giving yourself a mental break—or pacing yourself, at the very least—you’ll prevent yourself from burning out and be a more productive developer because of it. Besides, knowing a little bit of everything in the short-term won’t help you as much as learning one thing well (but more on that later).
1. Start from the beginning
This one may seem pointless to some. Yes, although you might have already thought you were done with the fundamentals after finishing your 300-hour “zero to hero” development boot camp course, there is always more to learn. Revisiting official documentation, retrying helpful tutorials, and (I cannot stress this one enough) reading books will help re-establish those fundamentals you learned as a wee little baby developer.
Now that you have more experience, you might even gain more clarity on lower-level concepts by starting again from the beginning. Besides, with the ever-evolving nature of technology, revisiting fundamentals is a good habit to start anyway. By doing so, you give yourself a better chance of unlearning old tricks and opting for new ones.
2. Stick to something
Don’t bite off more than you can chew. Don’t try to perfect a bunch of things at once in an attempt to stay current.
This is often easier said than done and is perhaps one of my biggest flaws as a developer. As I mentioned before, I am susceptible to creeping thoughts in my mind telling me that I am losing relevance if I’m not dabbling in everything at the same time. I fear that I’m not growing quickly enough so I opt to take on more than is necessary. Learning rapidly and in bulk can be impressive in the short-term and add to your skillset. However, an important point here is that while your quantitative knowledge is increasing, the quality of that growth lags behind.
Rather than attempting to become a jack of all trades overnight, I believe it is best to stick to one thing for a while and become really good at it. I guarantee the concepts you learn in your specialty will have parallels in almost everything else you learn. Additionally, your knowledge will build cumulatively as you learn new skills over time. Since the quality of your growth will be more balanced, you will also become a more well-rounded developer in the end.
3. Improve your efficiency
This next step is important to enable you to work quicker as a developer and, consequently, to make your time more valuable. This does not have to be strictly programming-related either. Improving your efficiency can simply mean improving your workflow. One way that I try to improve my workflow is by identifying better methods to get myself “unstuck.” This often means taking advantage of more opportunities to move on to another task if I’m spending too much time on debugging. Doing so allows me to stay productive and gives me time to refresh my brain before coming back to an issue.
Another way to improve your efficiency—and, consequently, your team’s efficiency—is to form habits to write cleaner code and refactor it. Get better at writing more straightforward and readable code so that you and your team can quickly grasp what’s happening in the codebase in a shorter amount of time. You and your team will be glad you did.
My last bit of advice to improve your efficiency is actually pretty underrated, in my opinion: Google better. That is if you use Google. I mean, if you’re a Bing person you can do that, too, but I digress. Just get better at searching for answers. It’s an important part of being a developer and solving nebulous problems. A few ways to improve your search for solutions include (but are not limited to):
Use specific search terms.
Specificity is key when researching issues you encounter with code. It saves time and headaches. There are often dozens of reasons why your issue might occur. Including keywords that are unique to your programming environment and tools will likely yield better search results—and, ideally, a viable solution.
Use the search engine’s operators and filters.
Search operators and filters are very powerful tools which help narrow down your search results. For example, the minus “-” operator can be rather handy when you want to exclude certain terms from appearing in your search results. As an iOS developer, I often use the minus operator to omit Objective-C or Swift results if I only need answers specific to one of the two languages. Here is a nice list of operators you can use with Google.
Verify the solutions before implementing them.
I think we’ve all been there—perusing Stack Overflow for answers to your latest problem and, finally, seeing that big green check mark next to an answer with 200+ upvotes. You try to make that solution work for you and, after realizing that it was probably overkill, you find that it didn’t work anyway. You go back to the thread on Stack Overflow and see fellow programmer iLikeTurtles left a comment underneath with 633 upvotes: “Not the right answer. See tortoisesAreCooler’s answer below.” You scroll down and see that their answer is more relevant to your situation and is more recent. You implement it and it works.
This probably doesn’t need much more explanation, but to summarize: verify that the solutions you find are still relevant. Verify that they are correct solutions and not just accepted solutions. A common solution is not necessarily the right solution. However, don’t be afraid of some non-destructive trial and error if you’re having a hard time verifying the solutions. A little bit of sleuthing ain’t hurt nobody.
4. Solicit feedback
Giving feedback is a crucial part of improving as a developer and teammate. Feedback is a must. It is more than just a code review. However, it is important that you solicit and receive feedback as well as you give it. In fact, you should solicit feedback frequently. Feedback can be taken in many forms—one of which is a code review. However, you should also focus on receiving feedback on your non-technical abilities.
Soft skills are just as important as technical skills. For example, assessing your communication with your team is vital to understanding what works and what to improve. Some advice I recently received regarding feedback is to ask the questions you don’t want answered. These are the questions you probably need answered. Three questions that are usually hard for me to ask are:
- Where do my development skills need work? Do you have any recommendations on how to improve?
- How can I improve my communication individually and on the team? Is there a specific time you recall where I could have communicated better?
- Is there a time when I “dropped the ball?” What could I have done differently?
I really don’t like this saying because I don’t think it’s entirely true: “you’re only as good as your weakest link.” But I think that its fundamental meaning can be applied here. When you can find areas that need improvement, especially when identified by your team, it is important that you take steps toward making those improvements to make you a more effective teammate. I recently posed these questions to one of my teammates. I felt that the questions focused on where I thought I was weakest at the time. Hopefully, you can use these questions in some capacity the next time you solicit feedback.
Furthermore, you should solicit feedback from people with less experience than you. Their input is equally as important as more experienced teammates. If you’re doing a code review and a less experienced developer finds something unclear, it might be an opportunity to refactor your code to make your intent clearer.
Feedback builds trust between you and the rest of your team. I believe that integrating feedback into your individual workflow (as well as your team’s culture) will ultimately make you more resilient and help you grow as a developer. However, soliciting feedback is often learned and not innate. It is admittedly pretty scary to make yourself vulnerable and open to criticism in that way. But like any other skill, I believe it is important that all developers learn how to effectively share feedback and use it as an asset.
…I just realized I need to get better at soliciting feedback.
The Wrap-up: Did It Work?
Following these steps didn’t make me an amazing developer god overnight (not claiming to be one now, either). By no means have I perfected all of these ideas. However, I have noticed small improvements over time which serve to keep me motivated and make me more effective. Whether you take this advice or not, I hope that you find value in my experiences and perspective. If you find yourself struggling with your growth as a developer, I implore you to use these steps or perhaps make your own plan for improvement. Hopefully, it will help you as much as it helped me.
