If you haven't gotten the memo by now, there's some pretty big changes heading toward ULib and ULX, and a lot has already been changed. Today, I'm going to give you a brief look into the method behind my madness. You'll find out what processes go on behind the scene when I make a large code change.
Idea Generation:Ideally, get someone who has some clue as to what you're doing and bounce ideas around with them. You want quantity over quality here, just throw out as many ideas as you can think of, no matter how outlandish. You can write these down if you want, I tend to just remember anything that I particularly like. In my experience, the best ideas come when there's food nearby. It's good to have some energy while doing this, but don't let yourself get too distracted or go down too many rabbit trails.
Breaking it down:Any ideas that you think are worthwhile go into a bin at this point. Now you need to dig through this bin, consider each idea on its own merit (freestanding of all other ideas you may think are cool). You generally want to think about the following while looking at each task:
- What are the dependencies behind this idea? Anything else I'd have to code to make this? Can I reuse any of my previous work for dependencies here?
- If the dependency requirement is large, is there any value in making the code powering this idea reusable? (A lot of people push that you should always make code reusable, but I think it's more of a balance between what you think you'll need this for down the road and the amount of time you have)
- How can I prototype this code to test it as quickly as possible? Should I code a throwaway prototype, or something I'll build off of later? (I can't say enough how valuable it is to get your idea into code form as quickly as possible. You can't always foresee everything involved with building something, and the sooner you know, the less time you pursue perfecting something that won't work anyways.)
- How can I modularize this idea? What modules will be the most difficult? (you often want to code these first) How can I minimally implement each module so I can get testable code as soon as possible?
- Depending on your resources available or your design goals, you want to consider drain on CPU, memory, storage, your time, maintenance of this code, and pollution of code space, etc. In general, I try to stick with the philosophy that the best code is no code at all. Is the code you will write for this really going to be worth the use of resources?
How much weight you put on each of these points will vary between projects and the importance of an idea. You'll want to either remember or write down how you're going to break up an idea into modules. You should now have a pretty good idea of what ideas you're going to pursue and how you're going to do it.
Make a task list and live by it:I have trouble keeping all the bits and pieces I need to do in my head, so I grab some paper and write away at this point. Here's two pages from my current notes for the changes coming to ULX and ULib:
It's not neat, but it's there. That's the important thing. When you finish a task, cross it off. There's something oddly satisfying with being able to cross a task off, and being able to look at your task list and see what you've completed versus what you have left to do. Having these papers handy means you can also get quick notes written down, which is also something that should be done while coding.
Keep yourself interested in the code you're writing and care about it:In order to make good code, you must care about it. You must treat it as if it were your child: you want the very best for it. It's not something that's haphazardly done and forgotten the next day.
The 'how' in caring for code varies person to person. If I find my interest in something dropping, I tend to work on something else for a while so I can generate new ideas for the original project. Call it an attention stamina, if you will; it works best for me if I don't keep forcing myself to do something I don't want to do. You can also introduce an extra level of 'fun' in code while you work on it. Write some amusing code that you'll remove before it hits production. For example, in my current working code for an upcoming ULib feature, I have the following...
if self.restrictedTargets and not table.HasValue( self.restrictedTargets, target ) then
return false, "you must have super cow powers to target this person"
end
There's some history behind why I wrote this, but the bottom line is that I get a little laugh every time I look at this code. It makes me happier, which makes my programming better. It's something I'll change once I feel I'm ready to push the code to the public, so no one has to know about my odd habits.
