If I could master coding reluctance, I could probably buy an extra hour a day.
What’s going on in the mind to cause this? I guess a latent fear of work?
How do you guys get past it? “Just do it” is always on the table as an option. Anyone have a ritual that makes this into more of a slippery slide?
In my gym sessions I learned to always start my first work set at 15 reps of the appropriate weight, I have since skipped far fewer workouts.
15 reps is a level where the weight qualifies as warmup level, yet you are still doing it to exhaustion above the intensity needed for muscle growth. Creating a win win and perfect start to the session. Also, the much heavier 8 rep sets were less of a shock to the system since my body was now primed for work.
Hopefully there is something like that for coding reluctance too.
Spend more time thinking about code before actually coding, or code in shorter bursts but more often.
coding isn’t always about writing lines. a lot of times you would be better to just sit and think about the problem for 15 mins, 1 hr, couple days, and so on. Then when you finally understand the problem or what ever you’re trying to accomplish then you start messing with the editor.
if were comparing it to a gym session where you’re going till exhaustion, the most important part of building muscle is rest. The time when you rest is the time when you’re muscles grow.
another way to see it is don’t try to go to exhaustion, because that’s its not necessary. That is the fastest way to burn yourself out to the point where you don’t even code for like 2 months.
as long as you’re doing just a little bit everyday, even if it’s watching some videos, reading documentation, or just tinkering with the some functions, that should be fine.
One of the greatest boxers in the sport once said, “I’d rather be out of shape and have fun 10/10 times than over-train even once”
Over time you’re getting more reps in if you train in small increments than if you wait to make one huge effort every day or a couple times a week, and you won’t think of it as something painful that you’re unwilling to do but have to do anyways. If it’s fun and not exhausting then it becomes something you look forward to doing and you’ll be better in the long run.
I often draw a quick schematic of the code’s logic and structure, then start from there. This drawing is intended as a starting point, It often doesn’t resemble much the definitive outcome after actually coding though.
The best part is when you have to look for any documentation or solutions for a persistent bug(which, in my case, are usually a result of my lack of understanding about a concept), hence, you may learn something new and improve from implementing your own ideas on code.
Also, when code involves more complex programming techniques such as recursion, I usually write it apart before implementing it as a method or function on the code.
You can’t code something if you don’t know the solution, algorithm, or how it will finally look (say a website design). If you open your IDE/editor as your first step, you’ll just be staring into this dark abyss of a blank screen.
Instead, maybe get a piece of paper and write notes, understand the problem, visualize the problem, and come up with a working (or probably could work) solution/algorithm on paper. Once you have it “working” or “solved” on paper, then converting that to code will be easy – since you’ll just be following this roadmap, i.e. your written solution on paper. You already know what code to write. It’s just a matter of converting it to the computer language of your choice (JS, C#, C++, whatever).
If you’re designing a website/homepage/look, you can’t code it if you don’t know exactly what it will finally look. So open up Photoshop or a graphics program, or Adobe XD and design your webpage. Once you have the colors, dimensions, look, fonts, graphic assets to use fleshed out, then it’s just a matter of looking at your finished design/screenshot and coding the appropriate html/css. The graphics screenshot will be your guide/roadmap on what html/css to code. Trust me, things will go faster if you do it this way.
Aim for a version 1 alpha, where your code just works and solves the problem. Solve the problem first. Then improve/refactor/optimize it later.