programming in general – Technomancer

Wires and Lights

Over sixty years ago a man began a speech with “This just might do nobody any good.” and in a way he was right.

Not that pointing out the things Edward R Murrow pointed out in his speech, now famously known as the ‘Wires and Lights Speech’, did anyone harm. He pointed out a great many things about the then-new industry of television that needed addressing. He drew attention to several things that were wrong, that needed review, that would be better if done in a different way or that could be cause for consternation. He explained why he was concerned, and what direction he thought the television industry was taking, as opposed to what direction he felt it should take, and why that should be as well. Murrow was long dead by the time I was even born, let alone had heard of this speech or its importance, but it is still important today. (And it seems I’m not the only one who thinks so.)

I’ve been thinking about this speech a lot lately. Primarily because I’m looking for my first job in web development, I’m directing my career in the field, and I get to have my first shot at what that means. What goals do I want to achieve, other than of course the goal of paying my bills with a little extra for fun? I feel like I barely thought about it at all when I was first asked the question: I want to do environmental work, I want to work in ed-tech, I want to work in accessibility and make the internet safer and better and available to all. I was just old enough that I had some years of living in a world without internet before the World Wide Web came into being even in its first, very limited incarnation. So it seemed miraculous to me when we were able to reach across the world and learn new things, communicate with people we would have a hard time reaching before, or even knowing of their existence in more than an abstract fashion. Obviously Ireland or Russia or Brazil has universities and professors who teach at them, but with the World Wide Web a girl could find that university’s site and email those professors and ask, what do we know about ancient kings? This language? That traditional dress?

I still feel that way about the internet, even though it’s gotten quite a bit more dangerous in the years since. In many ways and along many axes (emotional, mental, even physical) the dangers on the internet have multiplied exponentially. But as we develop new technology and new software to pair with it the benefits of the internet have also grown. And along with both, the weight of our responsibility as those who are the architects of the modern web.

I’m still fumbling around the edges of what I think my responsibility is, as someone who can code. To make my web pages as accessible as possible, definitely, and I’m expanding on the knowledge of the code for that every day. Other aspects of accessibility, lean coding and designing cleanly but without unnecessary animation or components, I already have ingrained in me from the era of 28.8k modems. It can be difficult, I think, when one knows how to code and bend portions of the internet in the general direction of one’s will, to remember that not everyone has a fiber connection and a fast computer. Not everyone has a computer at home, or an internet connection. And if I’m going to code something that I want to reach even people with limited or no computer ability, if I can imagine someone might have to go to a library to use my website, I have to keep that in mind. And what else is my responsibility? To be careful with my language? To put nothing out there that doesn’t have some use? What defines ‘use’? Should the internet move towards being primarily functional and educational, and how much room do we reserve for frivolity? Who defines frivolity? Who decides what is worthy of a strong presence on the internet, and what can be left to bitrot?

I don’t have any of these answers. I know they are questions with increasing urgency, especially with the advance of blockchain technology and cryptocurrency. There are deep environmental and ethical concerns around this field, and arguments have been made that while blockchain technology and the so-called Web3 may have uses they have not yet proven that these uses cannot be better and more safely served with other, existing tech. And this is a debate that I feel we will have again and again, as innovations iterate and grow our idea of the web as it stands now into something new. It’s not done growing. It may have only reached its angry adolescence.

“This just might do nobody any good,” I mutter, typing these words into a blog entry. This is a debate we will have again and again, those of us who care and want to be intentional in our actions building the modern web. Many more of us will shrug and walk away, because we don’t care. We’re in this to move fast and break things, to develop, to find out what we can do next. And there’s something to be said for being unrestrained in one’s curiosity. But for me, personally, it must always be tempered by an effort to do no harm. I want to bring the wonderful feeling of having the boundaries of one’s world suddenly expanded beyond belief to everyone. And it’s up to them whether or not to use it; I just want everyone to have the opportunity, in safety.

On Language

One of the odder, the more quintessentially me aspects of my life as a web developer, as a computer programmer in general, is that I find very little difference in learning a computer language and learning a human language. This is a difficult topic to describe, and sort of a difficult topic to live through because I haven’t found anyone else who looks at it quite the same way (if you’re out there give a shout!), but it goes to the heart of how I think about programming and learning new computer languages. I don’t find them intimidating by and large; they’re another pile of things for me to learn, but I understand how they work.

To me, computer languages and human languages work in fundamentally the same way. There are sets of specific parts arranged to convey meaning and intent, shaping and acting upon the context in which they exist. All human languages have roughly the same core parts, and computer languages also have a mutually intelligible kind of logic. Both types of language share vocabulary, the parts themselves, and syntax, the order in which you put the parts to finish off the meaning you want to convey. Some languages have less rigid syntax, some have more. Some languages have a smaller vocabulary and some bigger, but as a general statement once you understand the purposes of the parts you’re arranging, learning the syntax and vocabulary becomes much easier.

For, again, a very broad generalization made over literally thousands of languages both human and computer, if you want to accomplish something in a computer language you’ll use a binary structure. By inference, computer languages will have an if-then-else structure. If X is true, do Y. If X is false, do Z. It looks different in BASIC, in JavaScript, in Java, in Python, in Ruby, but the function of the structure is the same and when you understand how an if-then-else block works and can apply that logic to your program goals, it becomes easier to simply write lines of code. Human languages are more complex than if-then-else, but they still contain the same parts: nouns, verbs, adjectives. And they still have one of a very limited set of syntaxes, primarily Subject-Verb-Object (English, Russian, Mandarin) and Subject-Object-Verb (Japanese, Hindi); although more types than those exist those make up the overwhelming majority of language syntaxes.

For a more concrete example: the first computer language I learned was BASIC. BASIC’s if-then-else structure looks like this:

IF [statement]

THEN [action, usually involving a GOTO to reference other blocks of code]

{ELSE} and so on.

JavaScript’s if-then-else statements on the other hand look like:

if (statement) then {

block of code goes here } else {

block of code goes here };

Largely, the same idea and almost identical words. I don’t quite want to say “if you’ve seen one if-then-else statement you’ve seen ’em all” because obviously there’s questions of using brackets or curly braces or parentheses, and how you address the condition to be read true or false, and so on. But knowing that if-then logic exists is a fundamental concept of computer science that, if you’re down to taking it for granted, can help you conceptualize a program before you start writing a single line of code.

I could and have gone on for an hour on the subject of linguistic similarities, especially in otherwise seemingly disparate languages. My go-to is usually the one about Russian and Irish being similar in certain ways, and how I blame the Vikings. But for a less verbose example, I was raised speaking English and Spanish both. In high school, rather than continue on an advanced Spanish literature program, I opted to learn French instead. Because I already spoke another language, and a Latinate one at that (sharing the same Latin roots as Spanish), I was already comfortable with the concept of gendered nouns, a more verbose possessive noun system, even some of the vocabulary sharing root words with Spanish. Nobody is ever prepared for French counting systems, but you get the idea. My existing skill with languages built a strong foundation to learn more languages, and has continued to do so. Similarly, my existing foundation with computer code and programming languages helps me learn new languages.

As a final note, I want to say this is also useful for more than just being a giant nerd. Having recently completed a boot camp and frozen on numerous technical challenges and live coding exercises, I got even more nervous at the thought of doing one of these for a job interview. And then I thought back to my Japanese class where, invariably, unlike the class studies and the homework, I couldn’t just breeze through. I froze, forgetting all my vocabulary except the words for “for example” and “okay.” This always happened, unless I’d spent several hours rehearsing and rehearsing my phrases and grammar on my own or in conversation with other students, to the point where it felt more instinctive than reaching back for a memory of a lesson. As exhausting as the prospect is, knowing this gives me confidence that I will eventually be able to pass technical challenges and live-coding exercises– if I do the prep work ahead of time. I can do this. I have ample proof that I can. I just have to put in the work.

Routines and Sub-Routines

Once again, started programming at an early age, developed certain habits. I don’t actually know where these habits came from. They might well have come from me getting fed up with writing a couple thousand lines of HTML to encompass all my various fan postings and whatever else I was working on at the time. I was fourteen, and it was probably X-Files related. The habits I am about to describe to you are not necessarily either best or worst practices, but they are my practices, and if you find them useful feel free to adopt them and work them into your own coding life and habits.

Commenting! I am assured by my mother, who has been programming for almost as long as I’ve been alive (as of this writing), that commenting your code is a good and helpful thing to do. Since people who are not me are now looking at my code I’ve toned down the editorializing a bit but you may still occasionally see an f-bomb in my code comments. A helpful comment both to Future You and to other people who may have reason to take a look at your code is one that concisely and clearly explains what the preceding line does. For preceding line you may also substitute preceding method, preceding block. You might also put a line of comment or three at the top of a file indicating what the file does. Basically, what I do is read over my code and after every couple sentences of saying “this code does this” I write a comment to that effect. This also helps by doing half your rubber duck debugging for you; you can read along with your comments and make sure that line, block, or piece of code does what you said it does. F-bombs and editorializing like “Once you put it in it stays in the act forever” are optional, just don’t put in so much of them that it crowds out the code and the useful comments.

Scrap files! The tricky part to scrap files is remembering what they were in the first place. In some projects I have only a file called “scrapcode.txt”, so it doesn’t interfere with the running of any of the parts of the project. I surround each portion of code I paste in there with something nice and eye catching, like a row of &’s or #’s, and label it. This might be “Capybara Doesn’t Like This”, or “Potential Method For Adding Object1 to Object2”; the purpose of the label is to remind me why this is there in the first place. This is a common theme in my habits, I need to be able to read, immediately, why this thing is here. Conciseness and clarity of language will come with time though.

Scrap files are useful because you might want to test out a different way to achieve a result, but you don’t want to lose the code. And you don’t necessarily want to paste it in a notepad or text file elsewhere on your computer, because what if your computer shuts down abruptly? Or what if you have to leave your desktop, you come back, you finish up what you were working on and start closing windows and come across this now orphaned text file with a bit of code in it? Did you need that? Did it serve its purpose? You may not remember! And this is vastly annoying, so I get around it (mostly) with a scrap file. I have to periodically go through it to discard pieces of code that have definitely served their purpose, but it helps keep it all in one place and relatively neat.

Dev Logs! Pretty much what it says on the tin. Having never worked as a programmer officially I can’t say if this is a required practice in most places or not, but as I’m working my way through school and the projects therein and thereof, I can say it’s very useful to me as a programmer and developer. It helps me both to figure out where I am in the process and what I’ve done, and also works as a larger medium in which to write down everything that’s happened in every version. For example, if I don’t want to write out everything I did on May 20th but I don’t want that git commit to go naked and uncommented, I can simply say “see dev log” and then I will know I wrote down an expanded list of updates, debugging, attempts or cleanups or whatever else I did.

Project Notes! This is different from dev logs mainly in that dev logs are for the day to day log of things, and that only. Project notes get cluttered enough on their own, it’s helpful to me to separate them into two files, usually md files at this point although in the past they were text files. In the old, pre 2nd millennium days. Project notes usually contain project objectives, stretch goals, if it’s an assigned project it will have the assignment requirements, if it’s an independent project I’m working on with other people it might have point of contact or contact information, it’ll have a Bug Hunt list (although if the whole thing gets to be too big, Bug Hunt definitely goes in its own file too) (we hope there aren’t that many bugs but it happens to everyone). It might also have links to specific pages that have documentation I know I’m going need later, or a rough text-based sketch of a project map.

Non computer related habits I try to get into include keeping a water bottle on my desk, taking a sip from it when I feel like it. It doesn’t have to be filled with water, obviously, but water is my drink of preference so I have a liter of it by my desk at all times. And it’s in a spout bottle because the last thing you want is to spill beverage all over your keyboard when you’re in the coding zone. In order to be kinder to my circulatory system I try to get up every time I get frustrated with my code, walk around the area or (since I’m working from home, I don’t advise this in an office setting unless they’re one of those places with ping pong tables in the work area that I’ve heard so much about) do some exercise, lift some free weights. Sometimes moving around and changing your visual perspective can also change your perspective on your code, jar something loose. Sometimes exercise increasing the blood flow can also increase the blood flow to the brain for a positive effect, and it doesn’t have to be anything a personal trainer would formally recognize as exercise. It could be putting on some music and dancing. Related to that, try not to code on an empty stomach. That doesn’t mean always be eating, but definitely remember when the last time you had a food was, and if it was more than five hours ago that’s too long. The brain runs on, among other things, glucose. Keep it topped up and it’ll be much more help to you.

These are most of the habits I’ve developed over the last We’re Not Going To Talk About It years of doing web scripting, programming, poking around in computer languages learning them for my own amusement. If you’re new to thinking about code and programming and creating things through computer logic, I encourage you to practice explaining your code to yourself and working on making it concise and clear. It doesn’t have to be in comments or any of the formats I discussed here! Being able to explain your code will help you understand the code, and will help you reassure yourself that you do understand it. Also, when you work in a team, it will help your teammates. If you’ve been doing this for a while, I hope you enjoyed my rambling descriptions of how my brain works regardless.