Skip to content

Instantly share code, notes, and snippets.

@alexgleason
Last active April 1, 2016 22:31
Show Gist options
  • Save alexgleason/1d30e9447d021d8f4fc4 to your computer and use it in GitHub Desktop.
Save alexgleason/1d30e9447d021d8f4fc4 to your computer and use it in GitHub Desktop.
Programming for Humans

Programming for Humans

This article is a recollection of my struggles to understand programming, and will hopefully aid people who are new to the craft. I hope it challenges anyone with experience, too.

How code relates to the physical world

The biggest problem I faced when learning how programming works is understanding how everything relates back to life and reality. Many tutorials show you how to achieve things with programming languages, but they don't explain why those things work. At some point it becomes about memorizing commands. In order to feel comfortable I feel like you really need to see the bigger picture.

There is a range of understanding starting from the code on your computer screen, all the way down to the electrons inside of the computer that make your code work. You may want to have at least a basic understanding of every step between. Without this knowledge, you risk becoming an expert beginner, caught in a loop and unable to transcend it.

This isn't hard. Anyone can understand these things. It will take you maybe a day of research to grasp it all on a basic level.

You should understand:

  • How to write a basic program.
    • print("Hello, world!")
  • What a compiler is, and how a programming language gets made.
    • Languages are made up by people.
      • People make languages first, by drafting them on paper, then they make the computer understand the language.
    • Languages are designed.
      • Languages are designed independently from computers.
      • Languages are structural. Curly braces {} and semi-colons ; don't have anything to do with the inherent functionality of computers, they're just part of the rules of the language.
      • Technically "English" could be a programming language. But we haven't built a compiler with advanced enough artificial intelligence yet to be able to compile it.
  • How to make a compiler without a programming language.
    • Compilers are programs that take in your code, then turn them into programs.
    • These days people make compilers for new programming languages by using existing languages and their respective compiler(s).
    • As you can see, this is a chicken and egg problem.
    • The first software was created by people who programed the software directly into the hardware.
      • Everything that makes a computer work is tied to some physical action. While unseen to the naked eye, moving your mouse around causes electrons to jiggle around inside your computer.
      • Hardware programming is the basis for modern compilers. These days we've rigged things up in such a way where we can construct and transform an entire computer system using only a keyboard, mouse, and screen. But it wasn't always that way; we accomplished this by being very inventive with hardware programming to create a self-sustaining environment.
    • You can make a compiler without a programming language by physically manipulating a computer.
  • How data and actions are represented inside a computer.
    • Computers work because electricity runs through them, and we have the ability to automatically change the path of electricity under different scenarios (mainly with transistors).
    • When one of those etched copper paths of a circuit board has electricity running through it, we can call it a 1. When it doesn't, we can call it a 0. It can only be in one of two states: electricity, or no electricity. We call them 0 and 1 because it is easy to express them that way. This is the basis for binary.
    • All computer information must be represented as binary. This is because computer information is represented by whether electricity is or is not running through a specific path. It is inherent to the design of computer systems.
      • Computer software determines what to do with binary data.
        • In operating systems, the OS may check for a file extension like .jpg to determine which software to use. Try opening a .jpg in a text editor to see that same binary data represented as though it were text instead of a picture.
        • How things get represented depends largely on standards. That is, a bunch of people sit around a table and agree that "this or that" binary will mean something according to a specification that they create, and then ask everyone to implement their specification. A specification is literally a set of rules written on paper. For instance, in UTF-8 (the most widely-used specification for text), 01000001 represents the capital letter A. Because they said so.
      • Quantum computers may be able to represent data in ways different from binary, because there's more to them than "is or isn't running through a path."

How deep you'd like to delve into each of these concepts is up to you. I think it's good to always keep learning. But the important thing is to know that they're all there, so you can research them further when needed.

Writing good code

Now that you understand how code works, you need to get good at writing it. Good code is easily understood.

One of the best things a developer can be is a writer. Matt Mullenweg famously said that "Code is poetry," which I wholeheartedly agree with. It's thought that programming has more in common with language than it does with math.

The more concise you can make your code, the better. Concise doesn't mean "short." It means "using the best words possible."

  • Name your variables clearly.
  • Name your functions clearly.
  • Organize your code in an intuitive way.
  • Write your code to be read.
  • Empathize with the reader.

The reason for all this is because you will need to work communally on projects. While it's technically possible to write a giant monolith of code entirely on your own that will change the world, it's highly unlikely. Such a thing is generally unheard of and human brains don't work that way.

“A dream you dream alone is only a dream. A dream you dream together is reality.” ― John Lennon

I was never fond of group projects in school, but when you're on a team with other passionate developers you will feed off each-other. This is especially true for open source projects, which you should be aiming to contribute to as a developer. To learn more you can read my article about free culture, anarchism, and altruism.

Program intentions

This is my favorite, and it's part of what makes programming exciting to me. When tasked with a job, you can make your work extensible. That is, program the software in such a way that the way it works internally matches the intention of its existence.

Think of your creation as a simulation. An implementation of a person's idea.

The alternative of this is to write software in such a way that it meets the minimum viable requirements. In the long term, this leads to "hacks," and a codebase that is very difficult to maintain.

Programming intentions requires an open communication with whomever the software is for (or at least whoever is calling the shots), which can be a fun challenge for both parties.

Conclusion

That's it.

Copyright © 2016. Licensed under CC BY-SA 4.0. No attribution necessary.

Please email any corrections to [email protected]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment