Become an Olympic coder

Image by 5132824 from Pixabay

Coding, like any other skill, requires practice, if you don’t use it every day, your coding chops will go numb. And if you expect to be great, then it’s not just about coding every day at work, that’s not enough, you need to make coding your life. Think of Olympic athletes, they don’t just train a few hours every day, they live for their sport, they train 8 to 10 hours every day, and then they compete. They’re obsessed with finding their weak spots and perfecting them.

If you want to be an “Olympic coder”, then you have to see the practice of writing code in the same way. Writing different versions of Hello World examples will stop giving you the results you’re looking for very soon, so what can you do then?

Especially if you’re starting your career, trying to break out of tutorial hell, this might seem like too much. But it’s not difficult, you just have to know where to look for ideas.

Reproduce projects from others

You need to practice coding, and when you don’t already have a project idea for you to develop, the best alternative is to copy some else’s.

Careful, I’m not telling you to clone their repo and look at their code. And I’m not saying review their code and see how they’re doing whatever it is they’re doing.

No, what I’m saying is: pick a project you like, maybe even a library you’ve been learning about, and try to reverse engineer their internal logic.

This is even better than writing your own, original project, because you already have the detailed documentation describing how everything works. So it’s just a matter of figuring out how to write it.

For example, if you’re a Node.js developer, write an express-like framework, and duplicate Express’ API. Or if you’re a Go developer, write a clone of Kingpin by reading their docs.

The aim here is not to create a project for anyone else to use, in fact, you won’t even use it in the future. But by going after an actual project, you’ll be faced with hard problems to solve, some of them even unexpected. And that is where your coding will jump to the next level. These projects will get you out of your comfort zone, and into the unknown, which is where growth happens.

Contribute to OpenSource projects

Getting into Open Source might sound like the way to go at first glance, but it can also be hard to do once you realize there is no pre-defined way of getting into it.

The easiest way and usually, my recommended way of going about it, is to find one of the projects you’ve been using for a while and look for its repo. If it’s Open Source, it’ll have a public repo, most likely on Github. They have a great search feature, so maybe you can start there.

Once you’ve found it, check their main ReadMe, which should be visible and rendered right there on the home page. If they’re actively looking for help of any kind, they’ll be advertising it somehow and it should give you the details of what you need to do.

If there is no mention of contributing there, here are some other signs of an active repo that you can contribute to:

1. The issues section has new issues, and several different people are actively answering them (i.e, it’s not just one person doing everything).

2. There are issues tagged as “best first issue”, or “looking for help”. These are common tasks on repositories that show a great level of organization. They show there is an active community working on helping people to contribute.

3. There are many Pull Requests open and being reviewed.

4. There is a “Contributors” list, either on the ReadMe file, or on a separate file on the root of the project (usually named “contributors.md”)

If you spot any of these signs, feel free to get in contact with the owner of the repo, asking for two things:

1. Permission to contribute. Granted, the fact that you want to contribute is great, and it should be something that makes them happy. But it’s also important to show the proper level of respect recognizing this is not your project, and that you’re there to help.

2. What’s the protocol when it comes to contributing. Again, this is not your project, and different project maintainers might want to follow different protocols. Ask for them, this is another sign of respect towards the work they’re doing. And it’ll improve the chances of your contributions actually being taken into consideration.

If you’re given the information you need, and there is no issue open that you feel you can work on, some good first contributions might be:

1. Adding missing details to the documentation or correcting typos. Granted, while it doesn’t look like much, it’ll help you understand the process and how Pull Requests work.

2. Adding or extending unit tests. This can be as easy as adding 3–5 lines of code but you’ll get a taste of what it’s like to contribute code to the project. You’ll also learn a bit about how it works, unit tests can give you great insight into the internal logic.

Work on personal projects

Finally, the last way is to work on your own personal projects. The first thing I said here was that you don’t have to work on your own projects, you can work on someone else’s. And while that is true, having a passion project definitely helps too.

Running your own project, can help you understand quite a lot, and I’m not only talking about coding:

Planning

There are devs who start a project with a very basic idea of what they want to create and there are others who spend a few weeks planning the whole thing. Either way, planning will have to be involved in the creation of your own personal project if you expect to have a release version anytime soon. Otherwise, you can run into issues such as:

• “Scope-creep hell”, where you keep adding new features because they seem relevant to the first version. Most likely end result: you get bored.

• The “Hopping-driven-development” syndrome. Where you just hop from one idea to the next, turning your creation into a bonafide Frankenstein, where no two features make sense together.

• The “neverending 10%”. Here you fall prey to the 90–10 rule, where the first 90% of the project takes 10% of the whole time, while the last 10% takes up close to 90% of the project’s time. This is not only due to terrible planning, but also very discouraging, especially if you’re working on it alone. It can feel like you’re moving slower than usual, like you’re not making any headway. And that can lead to you getting bored and abandoning the project.

I would argue that the last one is probably one of the main reasons why developers abandon their personal projects before they’re done: the lack of project management experience and thus, the unexpected 90–10 rule. If you’re aware of it, you can plan around it, but otherwise, it’s just going to eat your motivation away.

Feedback

Making your code public can be scary, but unless you’re working on a private project, you’ll be publishing your code for others to review.

That leads to people thinking they can either tell you how to write better code, or just highlight the problems they’ve encountered. They can both be very constructive experiences or heartbreaking ones. It’s up to you.

Knowing how to take feedback, even if it’s in the form of an insult to your ability, is a highly valuable skill. If you’re capable of understanding that there is something to be gained from a negative comment, then you’ve made progress.

And the same goes for positive comments, when other devs highlight what they liked about your project and your code can tell you what you need to double down on.

Perseverance

Anyone can start a side project, but very few can actually finish it. That’s a fact of our dev life, and when you start one, you should be aware of it.

And by finishing, I mean, releasing a version that is production-ready, for anyone to use, with the proper documentation and maybe even, a website or some form of marketing campaign around it.

That involves a lot more than just coding, and that is what makes it so hard, yet, rewarding once you’ve done it. The gold pot at the end of the rainbow that is your project idea is real, there is a lot of experience to be gained by working on your own project, but it’s hard work, and it requires effort and perseverance.

If you’re not willing to put in the work, you’ll only gain part of the benefits.

Coding

Yes, coding is also one of the things you’ll improve while finishing your own project. Of course it is, you have to code to finish it and while coding, you’ll get to test new things, new ways of doing things, and you’ll learn quite a bit during this journey.

However, it’s not all about code, you’ll pick up other related learnings on your way, such as best coding practices, architectural patterns, you’ll find new tools and modules that didn’t know before. The list can go on, but the point is: taking your idea all the way to 100%, will expose you to a lot of activities and experiences that while they’re related to coding, don’t involve writing code.

Taking your coding skills to the next level is not easy, it takes time, and it takes work, but anyone can do it, even you. Stop reading tutorials, the time for learning is over, now it’s the time for doing.

Do you have any ideas to add to the list? What do you do to work on your coding skills?