Learning to Code
When I first learned to program, it was easy to know where I was going and how to get there. Everything was laid out and there was a logical progression to take. It’s easy to progress with a structured course but what happens when you reach the end? What happens when you’re all out of tutorials? When you reach that stage, there are a few paths you can choose to take. You could decide you don’t know enough and opt for learning more through other tutorials and books. Another option, the one I took, was to build something. It’s challenging. It will take way longer than you think and it probably won’t be all that good, but the learning process is invaluable.
Why you should build something?
There’s only so much you can learn from tutorials and books. A tutorial has been carefully crafted to smooth out the rough edges. Its aim is to guide you through quickly and to show progress quickly. There might be some allusions to obstacles you’ll face but then it’s back on the path well travelled. Tutorials are great, I enjoy them but it’s important to flex your problem solving and coding ability in a practical sense. That’s where building something real comes into play.
Building something from nothing is an awe-inspiring experience. It tests your ability to recall what you know but more importantly it asks difficult questions. When the path is unknown, the journey will take longer but you’re bound to learn a lot from the path you take. You’ll come across challenges that can and have been solved by others and it’s up to you to decide how to tackle it. Nobody’s holding your hand. You’ll learn how to integrate these solutions into your own work. Most importantly, you’ll develop your reasoning which will inform future projects and allow you to appreciate good solutions when they present themselves.
A common learning pattern when learning to code is using a built-in data structure like a Stack. You start off learning the basics on how to use it and appreciate its elegance. You’re then tasked with creating your own implementation. You gain a good understanding and appreciation of your everyday tools. How does this relate to building your own projects? The thing you’re building is a similar problem on a much larger scale. If you’re building a clone of Twitter, there are myriad challenges you have to face and you can decide how to approach them individually. You could make use of libraries for many of these but you could also take the reimplementation route for more of a challenge.
How do you start?
Starting can be the hardest thing. I find myself procrastinating by doing all the work around the thing I actually want to do. It’s a habit I’m trying to break but I think everyone has a habit of procrastinating instead of taking the first step. One way to start is to stop procrastinating, so let’s take a look at three truths that will help you get out of your procrastination rut.
There is no right time
It’s easy to get into the trap of making the excuse that everything has been done or there isn’t a good time to do it. You might come up with excuses like these:
- I can’t make something like Instagram, it’s too complex
- I don’t have enough time right now, I need a few months of uninterrupted time
- I’m not ready yet, I just need to do some more tutorials
The perfect conditions don’t exist. The right time doesn’t exist. You don’t know enough, and that’s okay. Taking the next step and building something tangible is scary and difficult but it’s infinitely rewarding. You have to find whatever time you can and dispel the thoughts of lack-of-preparedness.
There is no perfect stack
I used to get stuck in a cycle of learning about technology stacks and the best tool to use in a particular situation, to a much lesser extent I still do today. There are so many tools, frameworks, libraries and technologies that exist in the world today. They all have their own unique capabilities and trade-offs. They all compete with each other in vying for a programmers attention. Alongside each of these technologies, there exists champions, they shout from the top of the techno-blogosphere that their favourite technology is the best. Don’t be tempted. Temptation leads to rewriting your app forever in the hope that some problem will disappear all the while never releasing anything. The perfect tech stack doesn’t exist, there are more difficult ways of doing things and their are easier ways to get things done. Do some preliminary research, choose something and then execute.
There is no right way
You’ve picked your stack. You’ve started. You’re well on your way to building something great but then it hits you, questions start entering your mind.
- Am I doing this right?
- Should I be using a library here?
- Is this how everyone does authentication?
When you think to yourself — there must be a better way, there probably is. That’s okay. Unless the thing your building is mission critical or a professional contract, it’s probably fine. There are lots of ways to do things, some solutions are more elegant, more performant or more ‘best practice’ than others but don’t disregard your work in search for the perfect abstraction. Sometimes it’s not as important as you think is, and besides, software is malleable. There’s nothing stopping you going back and fixing things when it’s no longer fit for purpose.
Throughout your career as a software engineer, you’ll be constantly learning and improving. You’ll come across different ways of doing things, better abstractions and more elegant patterns. If you’re waiting for a moment in time when you know everything and can create the perfect codebase, you’ll be waiting forever. The pace of change is faster than you can keep up and you just have to accept it and move on. The best method is to learn what you need to know and slowly expand your expertise as you’re building. It also pays to get a little help.
Where to look for help?
When you’re building something on your own, anything is possible. You’re no longer constrained by the guardrails of a tutorial but you can also lose some much-needed guidance. A core skill of a software engineer is to know when and where to look for help.
Documentation
Good documentation makes or breaks a library/framework/tool, from a helpful quick start in the readme to code examples in the wiki. Reading documentation is an important skill that will allow you to dig your own way out of a hole when you’re having trouble. The official docs can be an invaluable companion to your programming journey and should be the first port of call. If you find there’s a lack of docs or they don’t answer the questions you need answered, there’s always a programmer’s next best thing.
Stack Overflow
It can get a bad rap sometimes but Stack Overflow is one of the most useful resources for when you encounter the unexpected. I find it most useful for errors no matter how obscure, if you’re encountering it then it’s likely other people have too. You’ll have to use your best judgement when evaluating the answers but there is often a helpful community to ensure answers are valid and thorough. Take the time to understand the answer rather than just copy-pasting the code and you’ll do just fine. If you particular quandary hasn’t come up anywhere and you need something more immediate then you might need to dig a little deeper.
Discord/Forum
When you need something more instantaneous or you want to get answers from the best most well informed, forums and discord are often the best places to turn. Many frameworks/libraries/tools and technologies have dedicated forums and discord servers set up precisely for working through difficult problems. They’re also great for getting to know engineers who might be struggling with the same things you are. This sense of community can help accelerate your learning. And for a little more community, nothing beats face-to-face communication.
Meetups
If you have the opportunity, in-person meetups can be great for learning about new topics in your domain and getting some time mingling with other like-minded devs such as yourself. They come in many different shapes and sizes, from mini-conferences with speakers and Q&A panels to informal gatherings at a café. Look around at what meetups are available where you live and make the most of them. I’ve been to a few in the past where you can work through your project with an expert which helped me with a new framework I’d just started learning. It’s also an opportunity to learn more about the ecosystem you’re in and what others are doing. If there aren't any meetups near you, then you might need to rely more on other resources.
Articles/Videos/Tutorials
Part of my daily reading, viewing and learning still comprises of articles and videos. Tutorials are a great way to break into a topic with minimal effort and get acquainted with a new technology. Articles can help expand your mind and provide a bit of context around the decision making involved when building software. You can glean some real insight from industry experts that’s difficult to get without a one-on-one. To stay up to date with current trends, get insight into how others tackle problems and create innovative solutions, conference videos are ideal. Going to a conference can be a fun experience and an opportunity to meet people in-between fascinating topics. When you can’t do that, watching videos is still great and much lighter on the wallet.
What do you do now?
If it wasn’t obvious already, start building something.
Tutorials can take you to a point but if you never make your own things then your progress will be stunted. You can continue watching tutorials but use them to supplement a project. Building something is invaluable. It’s challenging and unknown. It’s amazing but awesome. When your faced specific challenges, it’s amazing how far you’ll go to solve those problems and how much you’ll learn along the way. There is no perfect time, perfect tech stack or a perfect way to go about it but that’s okay. Once you start, things will make work out and you can always ask for help along the way.
Thanks for reading, if you found this interesting — you might enjoy, “The most important tool I use everyday that Computer Science didn’t teach me”.
The title image contains illustrations by drawkit.io
Top comments (0)