6 ms·

I get better at coding by coding. No, really. You can read all the books, blog posts, open source code samples you want, but nothing will substitute writing co

I get better at coding by coding. 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.

pen2l 9y ago
I think I "read" about programming for something like 15 years (books, blogs, HN, proggit, irc chat) 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.
- albertgoeswoof 9y ago
  > 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
  - deleted 9y ago
    [deleted]
- ybalkind 9y ago
  Do you mind sharing your age? Also, what programming language/s do you code in and what level have you reached? Finally, how did you actually start coding?
  - deleted 9y ago
    [deleted]
darepublic 9y ago
Code reviews help a lot with that. At my current company we don't review so I've found myself getting complacent
- SatvikBeri 9y ago
  I've found this too - I work much better when I know someone I respect will read my code.
  - darepublic 9y ago
    Yes. Being able to give an opinion about code or code design and back it up with reasoned arguments (as opposed to dogmatic obedience) is part of becoming a good dev imo
    - cdevs 9y ago
      Agree, I think code review also helps yank out that laziness in that code that we thought we didn't have time to make more readable. Send the code back and make them push their code to a better level before putting it live. I've noticed UX problems in code reviews from people who should know better, we just get lazy and think "working" is good enough.
cdevs 9y ago
This sounds right but in reality I think something is missing if you end up isolating what you know and just keep coding. I worked with a guy who programmed for 5 years and wrote the same crappy code he wrote 4 years ago. If you don't know you're doing something wrong because even though you are solving problems the hard way to you you're still solving problems. If you are always pushing yourself and reading you learn there is a better way.
rmdundon 9y ago
I would add that it's also a iterative process: code, review, learn, and code some more. A continuing process
rightos 9y ago
Yes, not just experience is important, but experimental experience. I learn so much less at work than I do on personal projects simply because I don't experiment as much. Unfortunately the realities of time and effort have caught up with me and I don't get to put nearly as much time into personal projects.
AnimalMuppet 9y ago
I get even better by coding with others. As I look at their code, as they comment on mine, I learn more than I would simply by working by myself.
leetbulb 9y ago
This. I have a large directory containing side projects that will never and were never intended to see the light of day; solely built for the learning experience. 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.
bjourne 9y ago
This is exactly right. Practice, practice hard and hard practice. Then some more practice. People don't like that answer because they want to get good by watching Youtube videos. It doesn't work.

pen2l 9y ago

I think I "read" about programming for something like 15 years (books, blogs, HN, proggit, irc chat) 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.

albertgoeswoof 9y ago
> 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
- deleted 9y ago
  [deleted]
ybalkind 9y ago
Do you mind sharing your age? Also, what programming language/s do you code in and what level have you reached? Finally, how did you actually start coding?
- deleted 9y ago
  [deleted]

darepublic 9y ago

Code reviews help a lot with that. At my current company we don't review so I've found myself getting complacent

SatvikBeri 9y ago
I've found this too - I work much better when I know someone I respect will read my code.
- darepublic 9y ago
  Yes. Being able to give an opinion about code or code design and back it up with reasoned arguments (as opposed to dogmatic obedience) is part of becoming a good dev imo
  - cdevs 9y ago
    Agree, I think code review also helps yank out that laziness in that code that we thought we didn't have time to make more readable. Send the code back and make them push their code to a better level before putting it live. I've noticed UX problems in code reviews from people who should know better, we just get lazy and think "working" is good enough.

cdevs 9y ago

This sounds right but in reality I think something is missing if you end up isolating what you know and just keep coding. I worked with a guy who programmed for 5 years and wrote the same crappy code he wrote 4 years ago. If you don't know you're doing something wrong because even though you are solving problems the hard way to you you're still solving problems. If you are always pushing yourself and reading you learn there is a better way.

rmdundon 9y ago

I would add that it's also a iterative process: code, review, learn, and code some more. A continuing process

rightos 9y ago

Yes, not just experience is important, but experimental experience. I learn so much less at work than I do on personal projects simply because I don't experiment as much. Unfortunately the realities of time and effort have caught up with me and I don't get to put nearly as much time into personal projects.

AnimalMuppet 9y ago

I get even better by coding with others. As I look at their code, as they comment on mine, I learn more than I would simply by working by myself.

leetbulb 9y ago

This. I have a large directory containing side projects that will never and were never intended to see the light of day; solely built for the learning experience. 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.

bjourne 9y ago

This is exactly right. Practice, practice hard and hard practice. Then some more practice. People don't like that answer because they want to get good by watching Youtube videos. It doesn't work.