Learn by example — 7 pieces of code you have to read
The more that you read, the more things you will know.
The more that you learn, the more places you’ll go.
- Dr. Seuss
OK so first let me apologize for that awful click-bait title. But hey — it got you here didn’t it? I do promise that I’ll try to keep it short and that I’ll include a list of links to some amazing code ;)
So why did I lure you here? Because writing code is hard. There are so many things that make up good code, that you are almost bound to get something wrong. That is — your code will work, but will it scale? will it be secure? is it easy to read? will it need to be re-written in a month when the product manager (or the CEO) decides to change the product on it’s head?
Dealing with those concerns —making decisions and juggling trade-offs — is what a developer does. It’s much more then just writing code — it’s mostly deciding how to write it. There are so many tools developers use these days (to minimize mistakes, to facilitate team work, etc.), but when it comes to making decisions — we are back to the same tools engineers in any field have been using for millennia — logic, knowledge and experience. But unlike engineers in many other domains, software engineers have something amazing at their finger tips — open source software.
Yeah, you knew that already. You use OSS all the time. The first thing you do when you have a problem to solve is npm install the-solution --save. But if you are building something worth the while and working on an original idea — especially if you are managing to focus on solving your own unique problem — it’s definitely not an easy task.
What I’m aiming for is not only using OSS like modules & libraries — but learning from OSS software. And until we can discover how to eat up new knowledge the way Neo learns Kung Fu in The Matrix — our best way of learning is good old reading.
Read what exactly ?
OK, you’re down with reading. You read books, you’re constantly reading README.md files and documentation, and you even read some blog posts on Medium :) But let’s take that one step further. Read code. Really read it. Go through the whole thing and understand how other applications are built. There are endless ways of solving a problem in code. Read more then one. Maybe even more than two! Allocate time for this as part of your technical design process. Make an effort in order to find the ways other people have solved a similar problem you’re facing. So without further ado — here is a list of 7 examples:
See how people are actually using stuff:
- Angular-UI using Angular to create UI-Bootstrap
- React-Bootstrap using React
- anders94 using Express to create his awesome blockchain demo
- Let’s Encrypt’s static website built with Jekyll
- How Google use Go to access GitHub
- MatterMost build their open source Slack alternative using React and Go
- How MediaCenterJS does client/server for it’s OSS media center desktop application
- libhive (hey that’s me!) using Dynamo DB (OK that’s number 8 :)
Those are just examples of examples
Try to dig in, GitHub has some awesome search features. Invest time into learning this way. You’ll be surprised at how much you can learn from another person’s implementation to a similar issue, and reading more will make you a better writer — even if some of the things you read are “bad” code — learning from other people’s mistakes is faster & cheaper then repeating those mistakes.
