Copy As Much as You Can
For most people, learning to speak your first language came from copying your parents. The things they say and the gestures they make in certain situations. We map words to objects and do the same with phrases and reactions to feelings, and we imitate them.
In school, we’re copying notes. Whatever the teacher says or writes on the board, we’re writing it down or recording it. Sometimes it might be exactly what he/she has said or written, other times we record information in a way that we can understand later. Either way, we’re copying.
In sports, we actualize the advice that the coach gives to us. We are advised by our coach to do or not do something a certain way based on his/her own experiences. We’re being asked to copy what the coach would do.
We’re all lifelong copycats, and that’s totally okay.
Reading or watching tutorials on how to do things in tech like building apps in React is literally copying examples. Books? Just authors regurgitating personal experience on a topic that they found important, albeit a bit refined.
I can go on forever. We’re all lifelong copycats, and that’s totally okay. Yes, doing your own thing is also important, but there’s a time and place for when doing things your way is the best choice. That’s beyond the scope of this article. Anyways…
In my current job, I started out as a Software Developer in a team of people who have decades more experience than me; awesome senior engineers who I’ve had the fortune to copy.
When I started out, I was doing bug fixes which forced me to understand the ‘flow’ of how the API worked, which means my learning was mimicking the process of how data flowed through the API and which parts of the code was executed.
After growing just a bit, I was tasked with creating new features. If it was a new flag, API endpoint, API handler, service, or anything else that was common, I reviewed parts of the code that were similar and based my new code on anything I could copy.
Gamers would say that I was ‘power leveled’.
The crazy thing is that I had most or all of these things before, but I did so in my own way and with my limited experience. The important thing is that I made sure I understood the wisdom behind how things were different, why their code might have been better, and the technologies and tools behind it all. For me, doing all that took many hours beyond the usual eight hour day.
Had I tried to learn myself, I would have spent so much time, frustration, and pain to learn how to code much of the things I copied. Luckily, I put in the time and worked with a very enthusiastic and encouraging team. My experience was given such a huge boost. Gamers would say that I was ‘power leveled’.
In my experience, being the least experienced person on a team is one of the fastest ways to grow.
Copy as much as you can, there’s no harm in that. The most effective part of copying is understanding the why behind things and incorporating parts of those things that can improve your skill.
Through collaboration and basic exploration, be open to other solutions that may be different so that you can copy those ideas/solutions to improve your effectiveness. Repeat.
In my experience, being the least experienced person on a team is one of the fastest ways to grow. While I constantly wonder about whether I’m ‘good enough’ by no means do I consider myself a fake. When it comes to getting work done, I can do it. That’s the job. I’m not getting paid to grind my gears. I’m not even really getting paid to learn. I’m getting paid to code and solve problems; to make my employers money.
If there’s ever a need for me to explain my code, I make sure that can happen as clearly as possible. By coding at the same caliber as everyone else, my value as an engineer increases. I can solve harder problems and I’m exposed to more complicated problems, technologies, and tools. Just as importantly, I have the ability to identify a solution to a problem much quicker since I might have come across it before.
…I’m guilty of blankly copying solutions just to get things to when I first started learning. I still do…
Don’t be ashamed to use resources like Stack Overflow because you feel like the answer was ‘too easy’. Get your answer, use it, and spend your time building awesome stuff. Doing that is way better than being stuck on step 4 of 10 on some project just because you wanna get that answer the hard way. Complete the task at hand, not just a small portion of the tiny minuscule subtasks beneath it. Get it done.
While replication without an investment in the steps outlined above is hollow and dangerous, I admit that I’m guilty of blankly copying solutions just to get things to when I first started learning. I still do whenever I may be playing with some kind of library, open source project, SDK, etc. I’ve also worked with other Software Engineers, including those with decades more experience, who have used the same discretion to do the same thing. For the bazillionth time, get the job done.
The decision into how deeply you should look into things and retain content should come from how useful it is to get your job done, how well it serves as a solution (is it efficient? what are the caveats? long term effects? etc), and how it can make you more efficient.
I hope this helps, if you’d like to talk and ask questions directly, feel free to contact me on the Better Developer Discord channel here.