When it comes to making improvements to your code, you repeatedly demonstrate an inability to pick the right targets. Your intuition is without connection to reality, and you waste time trying to solve problems that don’t need solving. You don’t even try to gather evidence before sallying forth on a pointless quest to fix something that isn’t broken.
You don’t have a clue and you should stop pretending that you do.
(It should be made clear that instances of “you” or “your” should be replaced with “I” or “my”. This article is written to the author. There is no suggestion that the reader has anything to learn from this article. Not at all. There is no hyperbole and no sarcasm.
Where was I were you did this interlude begin? Oh, yes…)
You don’t have a clue and you should stop pretending that you do.
Preparation
You try to improve the wrong things. Not every piece of code must have a minimal instruction or cycle count. Neither is minimal memory use, maximum generality, nor even sufficient reconfigurability essential to every project.
So, let us start at the beginning. What actual problem is this code trying to solve?
No, not “what are the inputs and outputs” – what is the problem?
You don’t know, do you?
You think you do know? Really? You’ve considered the needs of the users? The amount of precision needed? The allowable memory use? For code and data? The amount of time you have to write the code? How about the time you have to find and fix the bugs? How will you even know if there are bugs? How will the testing and validation be done? What algorithms will you use? What alternatives are there? How will you evaluate the performance? What about the API – is your user interface going to encourage more bugs later on? Does the program need to be portable? To what other architectures? Who will be maintaining it? How long is it going to take to recompile each time you change one of the many hard-coded variables you’ll thoughtlessly distribute through the codebase?
You might want to think it through.
For longer.
Maybe you should try explaining your choices to someone else – do you believe it yourself when you articulate it to a third party?
I didn’t think so. Try again.
OK, that will have to do. Thanks for trying.
Iteration
So you’ve written some code and discovered that it doesn’t actually meet some essential requirement of the problem description.
Is that essential requirement actually essential? Or just something that you’ve convinced yourself is essential? I thought so. Focus on the things that actually matter – leave the novelties and interesting distractions for your spare time.
What now? You’ve found a shortcoming? Another one? And this one actually matters? Really? Oh – you’re right. Well then – you should fix it.
Wait! What!? STOP! What do you think you’re doing?
Fixing the problem? That’s not the problem!
It’s really not.
Prove that what you’re working on is actually the problem.
You can’t, can you.
Oh, you have a hunch, you say. It’s intuition, you say. When was the last time your had an accurate hunch about a problem like this?
When? Never? Because you’ve never seen a problem quite like this one before?
That explains a lot.
Measure. Dissect. Examine. Understand the problem. Test your understanding. Go deeper. Deeper. Find the root cause.
Do you know what the problem is now? Are you sure? You may have found the cause, but aren’t 100% certain. You can do better than that.
Find what is causing the problem, not just something that looks like it might be. Did you find the cause, or just another symptom?
Do you know what the compiler is doing? Do you understand how the hardware works? Can you trace what the supporting libraries and operating system are doing? Do you have other source code and documentation you can read and learn from?
Do you actually understand the code you wrote?
Oh, you found the problem and fixed it? Excellent! Where was it? In the only place you were certain that it couldn’t be. That’s not surprising. Not at all.
Reflection
Let’s face facts: you aren’t very good at designing or implementing code to meet the actual requirements. When you start before you know the requirements, what chance do you have of meeting them?
And you aren’t very good at making improvements because you start in the wrong place. How can you make something better when you don’t understand its deficiencies?
The good thing is this: you can be better at design and iteration. Work on your habits. Look for evidence first. Don’t trust your instincts. Don’t trust the compiler too much (don’t distrust it too much, either – don’t kid yourself, it almost always makes better inlining decisions than you do). Know your platform – the software and hardware. Solve the right problems and measure. Without measurements, your heuristics are just guesses, and probably not very good ones.
Stumbling around in the dark is a terrible way to get work done – give yourself as much light and opportunity as you can to succeed.
[Photographs by Karen Adamczewski]