3 ms·

You don't have to design the whole thing before you implement. This applies more easily to smaller teams but there's a continuum between rapid dev and thinking

You don't have to design the whole thing before you implement. This applies more easily to smaller teams but there's a continuum between rapid dev and thinking everything out. In my game dev it took me a long time to let go of "but I need to create an elegant/clever solution that covers all my planned features rather than just what I'm implementing now". What that got me was a lot of unfinished projects with elegant solutions. When you have time to code, code. Not necessarily the first solution that comes to mind, but maybe the second. Now you can keep coding instead of being stuck. Let your mind percolate on the solution in the background while you code, and while you're doing other things later. It's amazing how many times the solution will present itself after you implement a couple different pieces that now need to tie together. Use the power of your brain's pattern recognition. Yes, you will "lose" some time in refactoring, but the truth is every project I've worked on, one-man hobby up to multibusiness teams, has had refactoring due to scope creep or "we didn't realize this would be an issue until we implemented it." It will take time to learn how much thinking vs coding to do (both extremes are bad). Final bit of advice: don't listen to the opinions of people as to what is a good or bad language. Try them out, use the right tool for the job.

godshatter 9y ago
This was one lesson I had to learn to progress faster both at home and at work. Start building now and don't be afraid to refactor later. The caveat to that is to refactor frequently as things progress. If a function is now misnamed because it's code changed too much, rename it. If your carefully thought out code structure just isn't going to work, change it now before it's a major pain to do so. Don't assume you will get back to it later, you won't. I don't know how others work, but I had a tendency to try to code the whole thing in one go. Now I build the skeleton and start fleshing it out piece by piece, with an end goal in mind. It's very iterative. Do the next thing, whatever it is, large or small. Build and test. Refactor if needed. Rinse and repeat. I have to have it roughed out before-hand, but it will almost always change a bit as I get into the nuts and bolts of it unless it's trivial. Now I adapt as I go. The design reveals itself :)

godshatter 9y ago

This was one lesson I had to learn to progress faster both at home and at work. Start building now and don't be afraid to refactor later. The caveat to that is to refactor frequently as things progress. If a function is now misnamed because it's code changed too much, rename it. If your carefully thought out code structure just isn't going to work, change it now before it's a major pain to do so. Don't assume you will get back to it later, you won't. I don't know how others work, but I had a tendency to try to code the whole thing in one go. Now I build the skeleton and start fleshing it out piece by piece, with an end goal in mind. It's very iterative. Do the next thing, whatever it is, large or small. Build and test. Refactor if needed. Rinse and repeat. I have to have it roughed out before-hand, but it will almost always change a bit as I get into the nuts and bolts of it unless it's trivial. Now I adapt as I go. The design reveals itself :)