ThatSoftware<Dude>

Musings of a .NET Developer, CTO, Tech Enthusiast

There's this twitch that many programmers have. It can't just be me, I'm sure. In which they'll write a few lines of code, and then Ctrl + S and run their code to see the immediate result. It feels great. You get instant feedback to your current line of thought. Or, more commonly, you'll get an error and get distracted immediately and spend the next 30 minutes Googling a particular JavaScript error that one has ever seen before.

The effect of this, while dopamine inducing, is that it will completely take you out of focus and direct your thoughts elsewhere. Which is a problem when trying to get into the zone. You can think of it like reading a book and having to stop every page to take notes on it. Sure you'll have these great notes to look at later, but you'll have missed the entire purpose of reading.

Code first

More than likely, once you figure out what your next step is in your project, you'll have an immediate idea as to how to accomplish it. You won't know how you know it, but you'll just know it. For example, I was working on a Tetris clone recently, and when it came down to moving the shape downward to the ever loving floor, I had an idea on how to do so. I would keep track of the top-left coordinates and use it as an offset to calculate the next position. Easy enough.

I typed the first for loop , with a few console.log's, just in case I had forgotten what a for loop was. A few variables were wrongly spelled, so I went back and corrected and ran it again. More variables misspelled. Two things happened at this point.

1. I questioned my existence and why for loops are so difficult.

2. I lost track of my thoughts and the for loop became unusable.

So the for loop was fixed, but now its purpose lie hidden within other random thoughts of syntax. The original train of thought had derailed essentially. And when it came back, it was quickly disposed of again after another set of console.log's and test runs.

Test later

It's actually funner to test a fully functioning system than it is to test a few lines of code that are a precursor to said system. And debugging in itself is something which shouldn't be interrupted in itself. It will require research and multiple tabs and a different type of mindset. By saving your testing to the very end, you're going to be spending a fair amount of time fixing bugs and such. But you'll have your algorithm out and in place. You'll be testing your original idea, and not fragments of said idea.

Programming isn't difficult per say. But it does require a mind that can synthesize a virtual solution. As someone speaks "can you build a payment...platform...that...takes..user input..", you're already building it in your mind. And there's no difficulty in that, if you're a programmer. But it does require some level of concentration where each word is turned into it's corresponding logical function.

Takes practice

If you're one of these code, test, code, test programmers, then it is going to take some time to get used to becoming a code -> test kind of person. It feels unnatural at first. You don't know if what you just typed works or not, and in the back of your mind, you kind of know that it doesn't. But that's alright. You keep typing anyway. Until you can't type anymore. Then, that's your signal to go in, run your code and see if the mess that poured out functions or not.

It's a common sense practice, I know. But I've known few programmer's that actually put it into practice. Mainly older more senior level programmers. Hours of compilation aren't unheard of in a project. In the end, you might actually spend the same amount of time regardless of which path you choose, but you're code will be 100% different. And more importantly, you'll have had a 100% different experience depending on which route you choose.

So don't take my words for it. Try it out for week or for a day and see how you feel. See if it's natural or not to consciously type broken code that will be fixed later, but just not now now. The more you get used to it, the less errors you'll make, and the more you'll actually enjoy the coding part of a project. So go use these words, or not, to make something fantastic and something useful for our society. Or something fun at least.

If you enjoyed this, or other posts, consider buying me a cup of coffee . It is always appreciated.

Click/View Comments

About Walter G.

Walter G. is a software engineer with over 10 years of professional experiecne. When he isn't blogging or being a CTO he enjoys coding randomly complex things that he hopes many people will get a chance to use one day.

Questions/Comments

"sometimes you have to delete, to find your answer"
Copyright © 2017 ThatSoftwareDude.com
humans.txt