MORE ON CODING PAGES

CODING PAGES

Well, it's been a couple of days, and now I have a few basic rules.

First, here's what I found.

1. Programming is fun (let's get that out of the way).
2. Programming is complex, even small tasks.
3. There's a tendency to analyze too much.
4. There's a need to be correct - make it work.
5. The urge to look something up should be avoided.
6. Fear of running incomplete code - to see what breaks.

PROGRAMMING IS FUN

There's something exciting, after having spent a lot of time to learn a programming language, to write something and see it work. Even writing stuff in Excel VBA can be very interesting.

Programmers tend to take the long way home, just because you can. Like motorcyclists, if you really love riding, then you'll take the long bumpy route.

So, in the case of Excel, given a column of numbers to add, it's easy to use the built-in Excel SUM() function, but then, once in a while, to remove the monotony and have a little fun, why not dive into the VBA developer's area and write your own sum function?

OK, not everyone does it, but for some people, learning a programming language, if it is fun can help in their jobs. I can quickly think of engineers, data scientists, and accountants. The numbers people.

For coding pages, a good limbering exercise is to use the Python urllib.request library to count the number of anchors on a web page.

PROGRAMMING IS COMPLEX

But then so is writing. You had to learn the entire alphabet, and learn how words, sentences and paragraphs work before you could write anything sensible.

With programming, the language is the language of logic. It's not difficult, but mistakes are frustrating since they are silent and not so obvious.

However the key item in the coding pages is to exercise a specific skill until it becomes something automatic. You don't even think about it. You can literally program in your sleep. And if you really like the programming language, all the better since basically, syntactically, many of them are similar. Where they differ is in the platforms and toolsets they provide to make your job easy.

As an example, I use Python and the Flask framework. And for the display part, I use Twitter Bootstrap. And for data storage, I use SQLite - and occasionally MySQL. Right there, I had to learn a lot of different technologies to write a simple tool that does nothing. But the more I practise using these tools, doing simple work (for example post a form and save the results) the better I get at more complex tasks. Because I'm not hindered by the simple ones.

It's sort-of like typing. If you're a touch typist, then the work of typing is easier since you can now concentrate on the content, and not stare at the keyboard. You can stare at the screen instead. However, if you cannot touch type, your focus is on the keyboard and you often look up, to make sure that what you are typing matches what your fingers are hitting. I've noticed people who finger type banging away at the keyboard and nothing is happening on the screen.

Coding Pages reduce the complexity by making sure that the simple basics are well covered.

ANALYSIS PARALYSIS

There are multiple ways to put up a form in Python Flask. You can use the <label> tag for the label, and <input> tags for the text boxes. You can also use a <span> tag with a bootstrap class to format the label. You can also use an <input> tag with the "submit" type to put a button on the screen to submit the form, or you can use a Bootstrap <button> tag to put up a submit button and check when it's clicked. You can also choose to write some validation code in Javascript before the entire form is sent to the server, or add some restrictions on the controls so that requirements are met.

All this can make you just stop doing what you are doing to think of the method, because you want to pick the right one. Analysis paralysis. Like a food menu that has everything under the sun. Ten pages of chicken dishes, twenty of beef, and an encyclopaedia with all the various vegetable dishes available. You spend more time leafing through the menu and even after you've placed your order waste even more time wondering if you ordered the best dish. Similarly with programming, you select a method, code, code, code and then go back still wondering. While the main intention of the coding pages is simply to type and move forward.

I'm organizing my coding pages by date, multiple exercise. Some are not complete because when I'm tired, even after 20 minutes, I stop. Working or not. And I don't come back to fix it. It's forgotten. An exercise to be thrown away.

THE NEED TO BE CORRECT AND MAKE IT WORK

In real life, of course it has to work, and it has to work most (or all) of the time. But with the coding pages, if you get stuck, this is not the time for new things. Really, this isn't the time for new explorations. You've simply overcommitted on the exercise.

For the past few days all I've been practising is setting up (manually) a Python Blueprint app. This is an App that is split up into multiple modules. Not very difficult, in fact, there's no need to do this manually, you can create a template once and for all, and whenever you need this feature, simply copy the feature.

Same thing with forms and other things, and I will get there. But the main point of the exercise is to stimulate muscle memory. The enjoyment and the productivity is in the doing and if you constantly looking at reference material, you'll never get the work done. So it's good to be good at some things and knowing these things has extended benefits. You will code more enjoyably when you are looking for things and you'll get over the habit of constantly stopping to check if you are right.

This is why we don't write a lot of code before we run the application to test it. But for small applications, this is a habit to be broken. You should be able to code a full blueprint app, with forms and a database without running it once. Of course it will crash due to silly mistakes when you eventually run it, but at least you're on the move.

Typing lots, and assuming that you are on the right path is key to these pages. Very similar to Julia Cameron's morning pages where she tells you not to stop writing. I think she actually tells you not to lift the pen off the page, but I stop and wiggle my fingers to rest them.

Last point. Ultimately you may run the app and it simply has too many errors and continually crashes. My advice is to move on. Close that chapter, there are lessons learned in moving along.

THE URGE TO KEEP LOOKING THINGS UP

OK, this one's a 50-50 thing. The Python find() function works on strings to look up substrings in them. Like many functions, it's an object function, so it works on it's object. You may forget if it's a function or maybe part of a package (like the string import), So you may be stuck and look it up.

The find function takes as an argument the thing (substring) you are looking for. So something like:

x = "my home is in Nairobi".find('Nairobi')

That expression will return the position of the word "Nairobi" in the string "my home is in Nairobi"

It's the same as:

s = "my home is in Nairobi"

x = s.find('Nairobi')

But you can also do:

x = s.find("Nairobi", 10)

This tells the function to start looking at position 10, but, but give you the absolute position of the substring, not the relative position from where you started.

So you're looking at find, and you may be tempted to keep looking up what does it really do.

My advise is just to guess, and then when your program crashes - as it may - you can figure it out later and then won't be in a pickle. Just keep coding.

When I was using the urllib library to scan web pages, I had imported urllib - and I knew that the method I needed was urlopen() under urllib.request. I just didn't import urllib.request. I thought that importing urllib alone was enough, since I could then use the entire path urllib.request.urlopen() to get the web page.

The program crashed and I learned.

It's mostly small things like these where I keep stopping. Like what's the correct way to specify a blueprint? And how about the blueprint templates, where do I put those? And how do I know that they are actually working?

THE FEAR OF INCOMPLETE CODE

This may be the toughest one. Walk away when you are tired. Don't have to finish. When you're tired, you've actually done enough. As long as you don't get tired in the first fifteen minutes. I say that a good exercise is about 30 minutes, and possibly top out at an hour. Don't spend more than an hour, that's too much time simply for an exercise.

Like going to the gym. Go. Do an hour. Three or four times a week. Getting better daily, not a destination, but a journey.

The coding pages are a journey, even if you don't see the results immediately, they're there. It's like the Morning Pages. They've had subtle but continuous influence and even if I don't produce high class, top grade, quality manuscripts, the work is there. And it's at least there in body, something that I can look at and tell that it's growing.

So open your code editor. Think of something quickly - create a form with a few fields to store an encrypted message. Store the encrypted message and then retrieve it. That's not a lot of work, don't use military grade encryption. In fact, create a Caesar shift function, easily broken, even by a ten year old. The point is coding. The writing.

And even if it does not compile and work, but you've been at it for at least 20 minutes, it's time to move on.

SUMMARY

1. Think of something you know how to do in your programming language of choice. Something that takes input and gives some sort of output.
2. Create the folders, and empty files you need.
3. Write, write, write. Write everything and don't compile.
4. Compile
5. Take a few minutes to smile (if it works), or fix a couple of things.
6. Refactor, if you think you overshot the target (gave yourself too much work).
7. Close up, take a walk.