1. Read more books. Turn off Twitter, FB, whatever, and open your Kindle app. But be picky. Don't read crap.
2. Read every day. 30 minutes minimum at the same time every day.
3. Write code that implements what you learn.
4. Write code that is more consistent. Learn to write in patterns. Use patterns that you both learn from a.) books, b.) reading other people's code, and c.) that you come up with on your own.
5. Program by using coding standards. Either your own, or if you're in a company then follow the team's standards.
6. Review what you've written. Identify alternatives to the patterns you've used. How else can feature x be implemented? What do you like about each approach? What do the experts say about each approach. Then read everything you can about various approaches to a given problem and implement as many of them as you have time for.
7. Read some code written by someone way beyond your skill level in a language you know. Take in how well they write. Pick one thing they did well, read about it, understand it, then integrate it into your coding.
8. Rewrite something you wrote at least a year ago. Can you easily find a better way to implement this code? If yes, then rewrite. If not, then read more.
9. Learn one new tool that helps improve your workflow and get to a point of daily use.
10. Speed up. Use automation to eliminate the basic coding that you already know well and that is now wasting your time. Use whatever is easy for you whether its templates, macros, boilerplate, generators or automation. Just pick one and automate away the stuff you've already learned.
In my experience it's impossible to know what "pattern" to use where in real life code into you've made and realized the mistake that the pattern solves.
sitting down and learning a bunch of patterns and then using them without a deep understanding of why they are useful is misguided, and you'll end up with dogmatic code. not that it won't help, it's just not the most important step. the most important step is to write at least medium sized code bases without putting your ego into them so that you can be savvy to your mistakes.
My recommendation is to tackle ambitious projects as an open source programmer. Do things well beyond your comfort zone and expect to fail.
The fact is that you won't get better unless you actually fail and are introspective enough both to realize you did (there are programmers out there who never realize this and I have tried, unsuccessfully, to work with them). So pick something you aren't sure you can succeed at.
The second thing is to be evaluating your development challenges as you go, be introspective, and learn from them. Every development challenge is an opportunity to get better.
The third thing to do is to start reading about cracking software and start working on cracking your own software. If you can get others to crack your software, better yet. You will learn a lot about best practices from this.
The fourth thing to do is to try to work with teams of open source developers and learn from others. I have never learned anything from someone who always agreed with me, and a friend of mine is fond of saying, if a village has two wise men who always agree on everything, the village has one more wise man than it needs.
Read more code. Edit code others have written. Maintain a wide variety of projects. Try to start your own.
Failure can be tough and sneaky: I didn't want to fail, so I Googled to see how others did it until I was sure... Then found I couldn't reach a consensus, and ended up "researching" for months. Sometimes doing it wrong isn't failing, after all, you've just found a way that didn't work-- that's progress.
Oh and reading or knowing how to do it isn't doing it. There can be quite a bit of work to doing it yourself, don't skip the exercises at the end of the metaphorical chapter ;-)
I have been working on my own code base for the last 3 years. It is constantly evolving, and requirements constantly change. I often have to revisit a piece of code I worked on 6 months ago. That is the best time to tell. If your own code doesn't make sense to you fairly quickly, it is worth refactoring. Look it and ask yourself why it is difficult to understand and what you could do to make it better.
I've worked on enterprise software and people in the company thought of me as one of the better programmers there, but when I do open-source stuff I feel like an imbecile.
I quit my job and wanted to learn and get better, but I don't know how to start.
Defense, defense, defense. Your code should be peppered with checks that should never go wrong. You should feel stupid writing them.
They will save you a lot of headache one day.
Really the only way to get better is to write stuff and ship it to someone who uses it, and you have to experience the pain of supporting it. That's when all the important lessons are learned.
The scariest place to be as a programmer is when you look back at what you did 6 months ago and still think to yourself that its pretty good. A little regret is a good, good thing.
Five years ago, I would add a new feature and 50% of the time it would be a fair bit harder than I expected, then maybe 30% of the time I would find it easier than I expected, as I had designed the code well, and it was set up for extending / reuse.
Nowadays, I am getting better. If I don't understand a bit of code I wrote a few months back, then I use it as an opportunity to look at it freshly. Why is this code crap? Why is it making what I want to do difficult? How could it be better? That's a good place to start refactoring from.
In addition to this, reading and being able to understand other people's code will provide great returns. You learn about styling, coding standards, architecture, patterns, etc that you might have never stumbled upon if you attempted to code everything yourself.
That must depend o having decent code to work on in the first place. Seeing some of the comments in the code bases I have worked on, I am not sure I was going to learn anything there.
To rephrase: write more code. months later, look back at your early code, see if it still makes any sense to you today ;-) rinse, repeat in different languages, situations or version numbers.
It amazes me that despite all the efforts made to improve programming languages, the debugging tools we're using are so clunky. I really wish more effort was made to improve them.
1. Read more books. Turn off Twitter, FB, whatever, and open your Kindle app. But be picky. Don't read crap.
2. Read every day. 30 minutes minimum at the same time every day.
3. Write code that implements what you learn.
4. Write code that is more consistent. Learn to write in patterns. Use patterns that you both learn from a.) books, b.) reading other people's code, and c.) that you come up with on your own.
5. Program by using coding standards. Either your own, or if you're in a company then follow the team's standards.
6. Review what you've written. Identify alternatives to the patterns you've used. How else can feature x be implemented? What do you like about each approach? What do the experts say about each approach. Then read everything you can about various approaches to a given problem and implement as many of them as you have time for.
7. Read some code written by someone way beyond your skill level in a language you know. Take in how well they write. Pick one thing they did well, read about it, understand it, then integrate it into your coding.
8. Rewrite something you wrote at least a year ago. Can you easily find a better way to implement this code? If yes, then rewrite. If not, then read more.
9. Learn one new tool that helps improve your workflow and get to a point of daily use.
10. Speed up. Use automation to eliminate the basic coding that you already know well and that is now wasting your time. Use whatever is easy for you whether its templates, macros, boilerplate, generators or automation. Just pick one and automate away the stuff you've already learned.
Repeat.