Some phrases you often hear as a first year engineer are “copypasta” and “pattern-matching”. These are just ways to say “find code that achieves the same thing, copy it, and change it up to fit your needs.” It’s with good reason that this method is taught so much because it turns out this is precisely what you should do if you want to grow quickly as a junior engineer. However, there is a point at which you need to stop, or at the very least start using some new methods for continuing your growth trajectory. As an engineer struggling to continue my fast growth, I took the opportunity to ask a coworker if he had any lessons for how he approaches challenging projects. I thought it was such an informative chat, that I decided to use my blog to share this knowledge.
Pattern matching is such a wonderful tactic that once you embrace it, it can even be hard to stop. At least that’s what I’ve discovered on my engineering journey. That isn’t to say it’s not useful though! Without copying other code, you can easily miss out on common patterns and best practices that your company uses. For instance let’s say you want to add a new redux action in your codebase, you will most definitely want to see how redux is implemented in that codebase instead of just googling it and copying the sample code. As it is in my case, the implementation might be so different that you could unknowingly introduce a bug if you use the sample code instead of the copied code.
For many of you who are not yet engineers, you may not be able to fathom why you would ever need to search for another learning tool. The problem arises when you start taking on projects that are more ambiguous or that we simply have no examples of in the codebase. For instance, a coworker of mine, who I’ll name Jack for his anonymity, was working on making a web-based process more performant. We haven’t dealt with that kind of issue exactly so Jack had to investigate entirely new solutions for how to fix this bug. It turned out the solution was to use a web worker so that the lengthy process could happen asynchronously and prevent blocking the rest of the client. I thought this was a really interesting case of an engineer needing to solve an ambiguous task without examples to go off of so I decided to chat with Jack and see how he approached this.
The first thing Jack said was that pattern matching is a reasonable starting place for engineers but it won’t let you solve any of the new and unique problems a company might face. So this means you need to do some outside learning. If you’re like me, you’re probably wondering how you find learning materials outside of work because generic googling can only get you so far. It turns out that the key to finding relevant informative blogs is to find people who work in the same kind of problem space that you work in. A good example Jack gave was that if you are trying to make Mapbox more performant, you may want to look up who works at Mapbox and find their blogs if they have one. An example of one such person is Volodymyr Agafonkin who created Leaflet and now works at Mapbox and has an awesome blog going over all kinds of map-related work.
Ok, so let’s say you have decided you will start looking for some blogs to read. Well, one of three things will happen as a result of this reading: (1) it will directly help you with a specific project you have been working on, (2) it will not come in handy yet but maybe in the future it will turn out to be helpful, or (3) it will never come up again. Of course option (3) is always a possibility with reading random blogs but chances are that if you read blogs directly relating to the technologies you use at work or relating to the same kind of problem space you are in, you will eventually find that information useful though it may not be in the immediate future.
I know I’ve mentioned blogs quite a bit but it’s worth mentioning that blogs don’t have to be your only source of learning. As Jack taught me, you can even do a lot of learning and code sampling through other people’s pull requests. When you find other developers who seem to be making waves in their respective niche spaces, examining their code can be extremely informative as to what kinds of changes you can make in your own codebase and give you a hint of how to do it. Even just reading a project’s README file in GitHub can be incredibly beneficial in directing you during an investigation.
In addition to this being a means of continuing your learning, as the problems get harder, it’s worth noting that these efforts will also have the added positive effect of making you a more valuable engineer. While other engineers may be limited by the wisdom they have learned in house, a category I am sad to say I am in, you are able to share best practices other strong developers have used outside of your company. As a result, not only can you better assess how great (or terrible) your team’s common practices are and overall code smells, but you have a greater chance at making suggestions for how to improve the system (or defend it if you are actually doing what is considered “best practice”).
The last bit of wisdom Jack bestowed upon me is that at the end of the day, learning new things and experimenting requires patience because it often won’t work right out of the box. So just because you found some sample code that builds a web worker doesn’t necessarily mean the work is entirely done. At the very least though, it can offer you a new place to work from when the codebase has nothing to offer in terms of solutions.
