During the semester I often follow a regular pattern. I get an assignment in one class, it takes a long time, then I need to catch up on some other assignment. I start late on that one, which causes me to start late on another and so on. It snowballs until, well, basically the end of the semester when I’m scrambling to get it all done so I can pass my classes.
The latest assignment in this snowball is one in which I needed to mimick the behavior of the bash shell. For those of you not familiar with bash: have you ever opened up the terminal (in Linux or a Mac) or the command line (in Windows)? It’s usually a black window with nothing but text. The way it works is that you type a command, for example in the linux terminal:
steve@StevesNotebook:/$ echo potatoes are my friends
and then the command is executed.
potatoes are my friends
echo parrots what you just typed, but there’s lots more to it. Anything you can do in graphical user interface can be done by typing commands in the terminal. If you get good at it, you’re going to get things done much faster than if you used a mouse.
Even though the assignment didn’t ask us to make a fully featured terminal, it was still a big project, which I started late. Starting late was mistake number one. Mistake number two was due to my tendency to pursue whatever I’m interested in at the time at the expense of getting things done. I had been learning a bit about compliers and testing so I decided to make my own testing language for this project.
Mistake number two, after realizing writing an entire new language for a class assignment was a stupid thing to do, was to continue testing my code after it was due. The assignment was past due, but I was still taking my sweet time testing every new feature I added to the program.
Writing automated tests for your code sounds like a good idea, and it is. But when you’re past deadline, in school or in industry, you need to do things as quick and dirty as you can. Get it done. Test it manually. Yes the resulting code may not be that great. Yes your program might break for some small percentage of time. Yes it might run more slowly than it ought, but it will be done. If you have time later, you can fix it then.
I’m still learning that perfect is the enemy of done. I’m also still learning that I need the discipline to do tasks in paralell even if one of them is due very soon. Otherwise I’ll keep putting myself in this position.