Ask HN: How do you get better at coding?
I'm trying to get insights from developers for a school project on how they get better at coding.
The survey below contains just 6 simple questions to answer. Or just answer here. THANK YOU!
https://goo.gl/forms/emc16fdMC8UkTYYh1
72 comments
[ 2.7 ms ] story [ 128 ms ] thread+1 for reading other people's code. I'll build on that by adding:
- by learning to make your own code readable
- by working with people who want to make code reviews a priority
2. Dive in head first knowing a ton of research will need to happen
3.
4. Profit
2. Use Anki for difficult memorization
3. Use mindmaps for difficult concepts
4. Practice Coding
5. Sleep and Exercise for mental health
I've also found a low carb high fat diet helps me focus a lot more ymmv .
No, really. You can read all the books, blog posts, open source code samples you want, but nothing will substitute writing code.
I maintain a handful of side projects as well as write code daily for my job. Plus, I love it. Also, my side projects usually encompass something I have no idea how to do, which quickly elevates my skill level. I love learning, so it works for me.
I started actually coding seriously and properly the past 1-2 years. Easily learned a hundred-fold more by doing it, literally.
I think too often I told myself I'm "not good enough to make something serious". And you know -- it was probably true. But that doesn't matter. Just start, things will fall into place, sometimes you'll fail, sometimes you won't. It's just the only way really.
it's not true, most "serious" things aren't that difficult or complex
Generally speaking, when I discover some interesting technology, I attempt to implement it in whatever language I am currently trying to improve my skills with, regardless if it's not the best environment. A good example of this was implementing the Ethereum VM in PHP. After just a few weeks of tinkering, some takeaways were learning the best and fastest ways to interact with binary data in PHP, improving my mental model of state machines, improving my debugging skills, learning how JIT compilation works, handling "big numbers" properly and caveats between several available libraries, etc...
A few important rules that have proven successful for me:
1. If available, your first iteration should be built purely following a specification (e.g.: RFC, whitepaper, yellowpaper), otherwise, if you have enough domain knowledge and understanding of what the program should actually do, build it without any reference, but allow an exception for researching (when required) very specific problems such as determining the best sorting algorithm for some function. Performing either of these will challenge and improve your ability to carry out the SDLC.
2. Hand-in-hand with #1: Don't start testing against (or even looking at) other reference implementations until at least iteration two. Whichever iteration this lands on, it'll likely be your first major refactor and will be the most time consuming, but most satisfying step. You will discover things you've (supposedly) done right (awesome++), things you've done wrong (learning++), and maybe even novel solutions to problems that end up being noteworthy contributions to the community (really awesome++++).
3. For lack of better phrasing: Focus on the specific task of the program or library. For example if your project is multiplayer netcode, you will of course need a game engine of some sort to capture a realistic state from, feed the data to, display it, etc. Sure, go ahead and write a simple game engine, but as cool as it is, don't focus on that...just get it to do what you need for your netcode! Game engines are cool and so are other subsystems of multiplayer games, but don't get distracted. This example is being used because multiplayer games are complex and meticulous and spending too much time on each subsystem may lead to burn-out or disinterest for what should be a far smaller project.
4. Don't worry (too much) about the language or environment being used. Unless you're planning on the project materializing in to a product, the sole intent should be becoming a better programmer, which requires only one language and a fresh project. Learning a new language isn't going to immediately make you better at programming, although there are plenty of benefits in learning new syntaxes and paradigms. Plus, you may always use your newfound domain knowledge as motivation to pick up the appropriate language and/or platform.
5. Never be intimidated.
1. If I'm learning a new language, I pick a topic I know well and try to apply it in the language. Typically the first pass is nonidomatic, and I iterate as I learn more about the language. 2. If I'm learning a new algorithm, I use a language I know really well. 3. If I'm learning a new framework, I pick a smallish project and dive in.
Most of it is throw away, and I've found that takes a lot of pressure off.
If you spent most of a day on something, nobody is going to notice an extra twenty minutes to fix it up a bit more. Especially if it means fewer production issues with that code. On a sane project the interesting problems are given to the most reliable people, not the fastest. So look at th code one more time than you deem necessary.
Try to look at it the way someone else will or the way you will in six months when you touch it again. Do the commit comments match the code? Can you tweak the code a bit to make it mean what you said? Then do it.
Bouncing off ideas, war stories, snippets, learning and sharing alternative ways to solve problems. Priceless.
Years of accumulating minor improvements based on real projects I actually worked on have compounded.
2. Rewriting, rewriting, rewriting
3. Trying new languages for fun (I ported a LAMP website to Node to learn about node+express)
I'll add one extra on top of that: it's important to practice on real, complete, non-trivial programs that actually do something. Ideally it'll be a large project because that will give you practice in working with other people, API design, refactoring, testing, debugging, and reverse-engineering.
Tinker a lot and don't be afraid to make your own mistakes (and learn from them once you've recognized them).
On #2, for example, if you are working on a todo list backend in python, try to find existing solutions for todo list backend in python. Then you can see what others using in their solutions and try to bring them into yours.
I understand, this approach is not applicable for everything but I have found lots of gems this way.
Only when you get stuck and cant figure something out with your current knowledge set, should you venture to look at others solutions.
Or after you have completed your solution and are curious about what others have done. You might find a library that makes your life way easier, but had you started out using that library, you wouldn't have the best understanding of the nitty gritty details.
I will admit sometimes I get a little ambitious with what I want to do and end up looking at other solutions to see just how complex we have to go.
2. Try to learn the underlying technologies thoroughly. For example, try writing a simple C compiler and linker. That will teach you about a lot of things that a lot of the programming world sits on top of.
That worked for me.