The idea came up when I was playing guitar. I play because I like to play, no professional aspirations or anything like that, but I still put in actual practice hours. Practicing usually involves a collection of exercises that:
- Are fun to play.
- Build on different parts of fundamentals (picking techniques, arm/wrist movement, fretting hand positioning, etc.).
- Provide ways to measure progress.
And then I realized I have nothing like this when it comes to programming. I have a solid system for learning stuff (read the docs and headdesk until things work ðŸ‘ðŸ¾), but nothing when it comes to practicing. I've tried algorithm-challenge style books and websites, but frankly they're just stressful. Was hoping to hear from the Dev.to community regarding what options are available and works for y'all. 👨”💻
If more specific questions are preferred: How do you practice? How do you decide what to practice? Have you tried other methods? How is practicing different from learning? As in depth or as concise as you'd like, just happy to hear some ideas and recommendations.
Top comments (15)
There are some apps devoted to "practicing" programming, but they all kind of fall flat for me. I'd rather be hacking in a real environment. I like the idea of places like exercism.io. They may be the right thing for some, but it has never appealed to me.
So how do I go about "practicing"?
I "spike" on ideas. That is: I create a new branch that I know I will be throwing away, and just try things. I do this to try things out and to practice techniques. Sometimes I wind up running with what I'm working on, depending on its applicability, but usually I stash it. The main point is to gain practice doing things outside my usual flow, but applicable to my current environment, so the dots can be connected.
I think some people treat answering questions on Stack Overflow as "practice", and I think that makes sense. I've never gotten really into this. I find it a bit stressful. But any opportunity to mentor appreciative newbies is an amazing way to "practice".
Practice is might be considered different from "learning" in that you're taking ideas that mostly exist within your brain and are sharpening the tools. So learning something brand new is different from "practice", but tutoring someone in your own craft is "practice".
Anyway, that's my 2 cents.
I have a similar experience with Stack Overflow, in that it's a bit stressful, especially when someone downvotes your answer after you went out of your way to help. But every now and then I will stumble upon a question that will be challenging to tackle, and that's when I find it really fun and engaging.
This! I'm still learning but I like to have real world results, I don't want to sit in front of a text editor for hours with no end result. There needs to be a 'finish line' I guess.
I do programming almost everyday without any exception. It has now become a habit for me. My day doesn't end without me writing a few hundred lines of code every day. However, it was a bit difficult to start with.
You can also learn many programming languages here: hackr.io/
First of all, let me tell you that you need not practice competitive programming everyday. Some people do competitive programming and I recommend it too, but it's not compulsory.
Use sticky notes. Use it to remind yourself of what you have to do
Use a calendar to schedule important programming tasks
Earmark a few hours everyday for programming. Follow it with no exceptions.
Reward yourself of completion of programming tasks before deadline.
Taking part in contests and hackathons is a great way to practice programming
Freelancing is a great way to practice programming too. You'll get paid for programming and you'll have deadlines.
I try to follow the deliberate practice model while trying to keep the practice I'm doing relevant to either work or a hobby project. I find that if I'm just doing something to learn something, I have a hard time relating to the material and quickly find myself burnt out. However, if I can relate the material to something I'm actively doing at the time, I retain the information longer and have much more fun in the process.
For example, when I started in Python I knew I wanted to be able to write a package that followed best practices like TDD and having well manicured documentation. I broke the process of making a package into package structure, testing, software design, documentation, and distribution. I then chose a subject that interested me and built a package that solved a problem that I was currently encountering.
I then dedicated time to each topic until I felt like I had mastered enough of it that I could move on to the next item in my check list. This helped me tackle the problem in smaller, more meaningful chunks instead of getting overwhelmed by this massive project that I've embarked on
Because I love metaphors - I climbed a few hills instead of climbing a mountain.
Now that I've got several software projects behind me, when I want to practice something specific I can usually dig into my code base and find something to refactor.
My first inclination is to just say "find a project, and code!". However, it seems several responses have covered that, or something similar. I'll offer an alternative bit of advice, read.
We'd all like to be amazing programmers by simply putting our heads down and hacking away at new projects. But programming effectively, at least to me, also requires a pretty large database of knowledge and know-how you might not get without seeking it out. On some days you might otherwise be slapping a fresh 200+ lines down on some project, sit down with a book or good blog about a topic. Topics may include: Data science, AI, software architecture, database design, the list goes on with a ton of interesting topics. Also, you mentioned algorithms books. I'd strongly recommend something like this. If you find the challenge books stressful, find some that simply cover the topic in a broad scope.
Don't be afraid to code during study, it can certainty help understand some concepts. But, don't let the code become the focus. Make the topic, and reaching a thorough understanding of it, be the focus.
I think practicing programming is a little different because you have the program recorded for you at the end. Repetition is a little like refactoring, you keep tweaking things over and over until you get it to sound exactly like you want.
Lately, I've been really trying to internalize the SOLID principles. Like learning a new scale, I'll read descriptions over and over again. Then whenever I'm writing code, I try to recognize where one of the principles can be applied. This is just like noticing how particular riffs are part of certain scales.
The key to exercises is repetition. This thing is very well known as kata. You can google for it, find some standard katas, but really, anything could be your personal kata. As for me, I have two favorite tasks I use as exercises: 1. writing a new unit testing framework, 2. refactoring very old legacy project I've been working on long time ago.
Writing unit testing framework could be fun, who could ever thought of that. You can try different approaches, different systems, different implementations, combinations of solutions found in existing popular frameworks. Possibilities are endless.
I didn't write this code, I just spent some time supporting it. And honestly, I believe this is the worst code, I've ever been working with. So I always start from the same state, and try different techniques on how to make it better in some reasonable way. I learned a lot doing this.
But you can always try some standard kata: bowling game kata for example. :)
I like the idea of doing programming katas.
For example:
Attempt to TDD the 'Bowling Kata'.
Stop at 15 minutes, if you don't finish that's fine. Repeat this every day till you feel like you have truly mastered the problem.
"I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times." - Bruce Lee
I definitely don't practice programming in the ways you define it, but I'd like to think my 8 hours a day on the job are a kind of practice. I am regularly evaluating things I've read and applying them in my daily work in order to improve the software I produce.
I frequently have the opportunity return to older code and get the benefit of being able to determine if I could've done things better or if I would have done things differently (and I always feel like it could be better).
Not exactly a "practice programming" advice but what I normally do is I'd find an app that is relevant to things I want to master and takes a peek at it when I'm commuting. I recently switched to vim and needed more practice outside of work. The app I downloaded would quiz me on simple to complicated vim's commands. I personally benefit more from a lot of small short sessions of practice/learning as supposed to nailing to it for 3 hours.
Create small open source projects on GitHub, implement good unit test coverage and documentation. Make sure they are small and won't take months, but maybe hours, days or weeks of your time. You will get practice in many of the most important aspects of programming:
And last but most definitely not the least: Finishing projects and letting them be imperfect once they're good enough, or just abandoning them if they seem to be time sinks and not making any good results.
My GitHub is a perfect example of this. Over the years I've come up with almost a hundred random ideas that I found were worth working on or just fun, while testing new techniques and technologies or just improving on my existing skills.
Feel free to dig for ideas: github.com/lietu?tab=repositories
Additionally helping others can definitely make you better as well, join Stack Overflow, and maybe some channels in subjects you're interested in on the Freenode IRC network. freenode.net/