1. In Software Development, Nothing is Real

    Posted 2015-07-08 08:42 PM GMT

    Thinking Image

    Photo by: https://www.flickr.com/photos/wadem/

    In my book, Learning to Program, I use a lot of metaphors and analogies. I compare runtimes and interpreters to player pianos and piano players (pianists?); I compare arrays to a bunch of cardboard boxes; I compare data structures to the Simpsons. I love analogies, and I use them all the time to better understand the world, but I use them in software more than anything else. I am not alone. On a daily basis, software developers build pipes, trees, graphs, and objects, but none of them are real. In software development, nothing is real.

    Object Oriented, but Without Objects

    I don't know that I have ever been as confused as when I first tried to understand Object Oriented Programming (OOP). As a new developer, I understood an "object" to be something real—something that can be held, touched, or at least seen. A keyboard is an object, a mouse is an object, a CRT monitor is an object. But now I was learning that objects in programming are not really objects, but the idea of objects. And a class is a generic version of an imaginary object—the idea of an idea.

    Then, as if I wasn't already confused enough, the tutorial I was reading used the example of a Dog class with a bark method and an eat method. See, a dog is a real object, and barking and eating are real things that real dogs really do. So, are these software objects real objects or not? Is object oriented programming just for programming robots? Is this tutorial teaching me to build a robot dog?

    Honestly, I don't blame the tutorial for my confusion. Programming concepts can be hard to grasp, especially for those of us clinging to reality.

    It's All in Your Head

    Everything we do in programming is in our minds. Everything is an idea; nothing goes beyond the conceptual. Even code is just a codified representation of the idea; bugs are where the idea and code diverge. All of the analogies, the metaphors, the koans, the whiteboard drawings, the notebooks sketches, and rubber ducking are attempts to make the ideas in our heads more concrete and more understandable. So, if you think programming is hard and confusing, just know it's all in your head. And that's exactly why it's so hard.

  2. Commit Messages

    Posted 2015-06-26 04:53 PM GMT

    Much has been written and said about commit messages. My intention with this post is to write a short and clear summary of what makes a good commit message.

    1. A commit message should be short and clear. If the description needs to be long and confusing, the commit is probably too large.
    2. A commit message should be in the present (not past) tense. Describe what the commit is doing, not the work you did. A past-tense commit message is also arrogant, because it implies that you think your code is so certain to be merged that you can describe it as if it has already happened.
    3. A commit message can be funny, given the humor does not make unclear the meaning in the message. The robots are not being programmed by robots; let your personality show.
  3. How I Learned Human-Computer Interaction at a Law Library

    Posted 2015-04-03 08:31 PM GMT


    My first programming job was working in the systems department of the BYU Law Library. I worked on a wide variety of projects, including installing Firefox on law professors' computers and writing Perl scripts to process huge and disgustingly poorly formatted Oracle reports. But my favorite projects by far were building web applications for law students and library employees to use. This story is about one of those web applications.

    Every semester the library circulation manager has to create a work schedule for all of the circulation employees. There are 2 desks that must be manned from 6:00 AM to 12:00 AM, books must be reshelved at regular intervals, and various other roles must be filled. Undergraduate students fill all of these positions, and students can't work while they have class. No student can close one night then open the next morning. More tenured student employees get more desirable shifts. If a student wants to work 12 hours per week, that student should not be scheduled for more than 14 hours, nor less than 10 hours. Shifts are diced up in 30 minute increments, with the minimum length of 2 hours and maximum length of 4 hours. I could keep going, but I think the point is quite clear: this was a system with numerous conflicting constraints. The process of creating the work schedule would generally take the circulation manager about 2 months (i.e. half of a semester).

    The Challenge

    I was a new, overly confident programmer, certain that the computer could solve any problem. I saw the two month process of papers, spreadsheets, frustration, and tears, and I knew there was a better way. During the spring of 2009, I took on the challenge. In less than 2 months, with the assistance of Object Oriented PHP, I created a web application that would create and display a fully compliant schedule. Bursting with pride, I ran from my windowless room down the 2 flights of stairs to the circulation manager's office. The 2 month process was about to become a 15 second process (again, I was a new programmer, and I had never studied algorithms; all things considered I think 15 seconds was pretty good). I was jubilant as I watched her click the "Build the Schedule" button. The computers had won!


    Then my jubilee ended. She spent less than 10 seconds looking at the schedule my program had made, then she said, pointing at the screen, "These two can't work together. They wouldn't get anything done." My face fell, but I was not defeated. My mind quickly scanned the possibility of adding employee compatibility to my model when I heard, "Oh, Anne is probably too shy to work the front desk. Unless Jess or Brandon is doing shelving at the same time..." Now I knew that I was beat (but still not defeated). In theory I could make an employee model detailed and accurate enough to handle these new constraints, but I knew these two new constraints were just the beginning and not the end. My program worked in a cold, mechanical sense, but it lacked a human touch.

    The Lesson

    I returned to my desk with a completely different view of the role that computers should play in our lives. In the five minute interaction I had with the circulation manager, I learned two important lessons:

    1. Computers work best when they are used to assist us (humans) in the tasks we are trying to perform. Calculations, data transfer, and even data analysis are perfect jobs for computers, but human decisions should be left to humans. A computer may sift through the many applicants for a job to surface the most qualified candidates, but a hiring manager would be loath to relinquish the interviewing and final hiring decision to the computer.
    2. Humans enjoy doing work. People want the satisfaction of doing work more than they want the free time available by having computers do the work for them. Even if a computer can do a job as well as (or better than) a human, there are certain tasks that humans don't want to give up because the work is so satisfying.

    I reused the Object Oriented code I had written for the fully automated schedule builder to create a schedule building interface that the circulation manager could use to add a human touch to the process. As far as I know, the rewritten program is still being used today.

  4. How the Web Works

    Posted 2015-03-24 05:00 PM GMT

    I love the Web. I have loved the Web for a long time, from online chat rooms and Flash Games in the 90's to Gmail, Facebook, and Wikipedia in the early 2000's to my current role as a professional Web developer. The Web has changed the way we shop, the way we watch TV and movies, the way we work, the way we read the news, the way we socialize, the way we find jobs and show our work experience; in short, the Web has changed the way we live. Considering the fundamental role the web now plays in our lives, I believe we should all have at least a basic understanding of how it works.

    The Internet is More Than Just the Web

    The Web is a part of the Internet, but there is much more to the Internet, and the Internet is much older. Email, instant messengers, SSH, BitTorrent, and ftp are a few examples of applications of the Internet that are not a part of the Web (or at least they weren't originally).

    The Web is a collection of interconnected documents that can be requested using HTTP, and are generally viewed using a Web browser. In recent years, the Web has grown beyond a simple collection of documents to a collection of interconnected applications. Though the terms are sometimes used interchangeably, the Web is not the entire Internet (but it's probably the best part).

    What You See

    HTML, hyperlinks, and Web Pages

    Sir Tim Berners-Lee

    The documents that make up the Web are written in a specialized format called HTML. HTML and the Web were originally proposed in 1989 by Tim Berners-Lee (pictured above) as a way to link together academic articles. HTML (Hypertext Markup Language) is the language that allows documents to be linked together using hypertext (AKA hyperlinks, AKA links). HTML contains both the content to be displayed and a description of the content. Web browsers us CSS to decide how things on a web page look and JavaScript to decide how things on a web page act.

    Where it Comes From

    Servers, HTTP, and URLs

    A server is a computer that stores the HTML documents, ready to be "served" to anyone who asks for them. Requests for Web documents are made over HTTP (Hypertext Transfer Protocol) using URLs (Unifrom Resource Locators). When a server receives a request, it looks for the HTML document associated with the given URL. Modern web servers often create the HTML document as it is requested (e.g. the Facebook feed is different every time you see it, but the URL is the same).There are different types of requests for different purposes. The most commonly used types of requests are GET and POST. An easy way to remember what GET and POST do is to think of a blog.


    A GET request is a request to retrieve or "get" some data from the server. When you want to view a blog, you make a GET request.


    A post request is used when you want to send or "post" some data to the server. When you want to "post" an entry on your blog, you make a POST request.

    How it Gets From Here to There

    IP Addresses, DNS, and routing

    Every device that is connected to the Internet is assigned an IP address, which is a really big number that identifies the device. (Side note: we made so many Internet connected phones that the really big number wasn't big enough, so we had to switch to IPv6). When you try to go to www.google.com or www.linkedin.com, the Internet doesn't know to which server to send the request, because the Internet only knows about IP addresses, not google.com. When you send your request, the first place the request goes is to a DNS (Domain Name System) which is like a big phone book that maps domains like google.com and linkedin.com to IP addresses like and

    Once the IP adress is found, the request bounces through a bunch of routers before finally finding the server. Routers tend to send requests in generally the right geographic direction, depending on a number of factors including other network traffic. Eventually the request will reach the server, and the entire journey usually takes less than 1/10 of a second. The request is sent with a return (IP) address, so the server knows where to send the response.

    Browsers Bring it All Together

    When you type "cnn.com" in your browsers address bar, the browser makes a GET request, which does a DNS lookup to find cnn.com's IP address. Then routers shepherd the request to the correct server. The server finds the document that is being requested and sends a response, which is routed back to the computer (or phone) that made the original request. When the browser receives the response, it processes the HTML, CSS, and JavaScript (and makes additional requests as necessary) and displays the webpage. With so many steps and so many places where things could go wrong, it may seem like a wonder that the web works at all. But it does, and now you know a bit more about how.

    If you are interested in learning more about the Web, computers, and programming, check out my book, Learning to Program.

  5. Everything is Obvious Once You've Figured it Out

    Posted 2015-02-20 06:48 PM GMT


    I was having a conversation with a coworker recently about how to create a pull request on GitHub. This coworker is an excellent developer, but he hasn't had the opportunity to work on any GitHub projects. At first it seemed strange to me that anyone would not innately understand the GitHub workflow. But then, as I explained what I seemed to know instinctively about branches, remotes, origins, and upstreams, I realized that the GitHub workflow is neither intuitive nor straightforward. I had learned bits and pieces of it over time from friends and coworkers, online videos, GitHub's documentation, and experimentation. Now that it has become a part of me, it seems obvious.

    Everyone is New at Some Point

    Don't be intimidated because everyone else seems to know so much more than you. No one was born understanding complex data structures, Git, the US tax system, or any of the other overly complicated things we humans have come up with. Even Wayne Gretzky had to learn how to ice skate. Even Michael Phelps started by blowing bubbles in swimming lessons. If you're having trouble learning a concept, just imagine Michael Phelps flapping and kicking wildly across the pool, and hang in there. You'll get it.

    Over the next few weeks, I will be writing about the aspects of web development that seem obvious to me now, but did not always. If you have any topic suggestions or recommendations let me know. If you would like to start learning to program, check out my book.

    Note: The title and content for this post were inspired by the book Everything is Obvious

  6. Out in the Wild

    Posted 2014-12-02 09:41 PM GMT

    Learning to Program, cover image

    About two years ago in a conversation with my friend Seth McLaughlin I mentioned that I had been thinking about writing a book about learning to program. Seth is a good friend. He is also very honest, so when he didn't laugh in my face I took it to mean he thought that I really could write a book.

    As of a few weeks ago that book, Learning to Program is officially available, out in the wild. I am really excited, but also quite nervous. With this book, I have put myself and my knowledge out there in the public eye to be scrutinized and judged. I wrote my first line of code less than 7 years ago. I have never taken programming course (unless Udacity counts, and I think it does). Now I am out there telling the world how to learn to program.

    I don't know everything. I did a lot of studying for this book, to make sure my understanding and explanations were as close to the truth as possible. I continue to learn every day. I am probably not the most qualified person to write a book on programming, but I was willing and the book needed to be written. I hope it can help make learning to program enjoyable instead of painful.

  7. JavaScript First

    Posted 2014-11-06 07:15 PM GMT

    About 3 years ago I was interviewing at various companies for web development jobs. I kind of like interviews. You get to work on bite-sized problems that can usually be solved in an hour or less. There is almost always a "right" answer, no matter what the interviewer says. You just have to figure out how they want you to answer (I like standardized tests for the same reason, but that's another, even more boring story).

    My intention today is not to write about interviews, though. I want to write about one interview question that I got "right", and how wrong I really was. The questions was:

    When starting a new project or page, what do you build first? HTML, CSS, or JavaScript?
    The "correct" answer was HTML, because HTML gives the page a structure upon which you can build the visual appearance (CSS) and interaction (JavaScript). I think this answer was valid when JavaScript was used primarily to add whiz bang to a static web page. But, we have moved on from those days, and JavaScript has grown up. Today when you are starting a new project, build JavaScript first.

    The Console Test

    At the most recent LinkedIn Hackday, I worked with a few other developers and a designer to build a JavaScript version of Minesweeper. Due to the time constraints of hackday, we all needed to be writing code as quickly as possible. We identified the different modules of a Minesweeper game, and we all started working. Because there wasn't a pre-built UI, the JavaScript in our modules had to be written without any DOM interaction. When all of these modules were complete, we had a complete working version of Minesweeper without a UI. You could, in theory, play an entire game directly from the JavaScript console. With all of that in place, building and updating the UI was a piece of cake.

    The idea of playing a game of minesweeper from the JavaScript console got me thinking about a concept that I call "The Console Test". Everything that your Web Application does, you should be able to do it in the console. If your application is a todo app, you should be able to create new todo items and makr items complete from the console. If your app is an email client, you should be able to send, flag, archive, and delete messages from the console.

    The UI Layer

    If your JavaScript passes the Console Test, building the UI layer will be relatively simple. Event listeners just call the methods that you have already been using in the console. The DOM is just a reflection of the JavaScript. Because the UI is independent of the application logic, changes to one do not affect the other.

    The idea of keeping UI and application logic separate is not new (whether you call it MVC, MVVM, or something else). However, the Console Test provides an interesting measure of how independent the application logic really is.

  8. Don't Just Learn to Code; Learn to Program

    Posted 2014-03-06 09:45 PM GMT

    Paint by number

    There has been a lot of excitement lately about learning to code. As a part of "Hour of Code", Khan academy, code.org, and codecademy all have tutorials that help you code up some sort of app within an hour. I love the excitement and the push to make programming more accessible to more people, because it certainly didn't feel accessible to me when I was teaching myself to program.

    I was recently reading an article on Medium about how easy it is to learn to code. The article promotes the same excitement as the "Hour of Code" program, but something about it didn't sit right with me. The author argues that you already know how to code, because code is just a series of instructions. I don't really disagree: we all know what "if" and "while" mean. However, "IDE", "parse", "compile", "interpret", "execute", "invoke", and "runtime" are not really so familiar, but they are just as important for making your code do something. This article that claims that learning to code is easy starts with a "simple" code example that includes such difficult concepts as "dependency management", "static data types", and "return values".

    In my opinion, you will be much better served by learning to program rather than learning to code, and there is a subtle, but significant difference between the two. Writing code is just one part of creating a program. Websites like codecademy do a great job of teaching you how to code, but you can't really apply those coding skills when you leave the codecademy website unless you learn how to program. It's a lot like trying to learn to paint using paint-by-number. You will have learned how to put paint on a brush and apply that paint to a canvas, but you haven't learned to choose paint type, choose colors, mix paints, stretch canvas, or any of the other skills you need to actually create your own painting. The paint-by-number kit has done all of this hard work for you. Similarly, online coding tutorials handle all of the hard parts for you. They give you a place to write your code, set up an environment for you to execute, and give you a place to see the results. Without these foundational skills, you will never be able to create your own programs. If you can never create your own programs, what's the point of learning to program?

    When I taught myself to program, I was often frustrated because I was trying to learn to code without learning to program. To this end, I am writing a book that teaches the the foundations of learning to program.

    Don't just learn to code; learn to program.

  9. Learning to Program: the book

    Posted 2014-03-06 09:28 PM GMT

    I am writing a book. After years of kicking the idea around, months of working and re-working an outline, and a few more months putting together a proposal to send to publishers, I am actually writing a book. The book will be title "Learning to Program: Absolute Beginner's Guide", and it will be published by Pearson. I am writing the book I wish I had when I was learning to program.

    What will be covered?

    The book will teach the skills you need to learn how to program in any programming language. You will learn about:

    • how software works
    • the tools you need to write, debug, and test software
    • how to write good code
    • how to find answers when you get stuck

    Thrroughout the book you will build a Chrome Extension to make your Facebook feed a bit more fun. As you learn new concepts in the book, you will apply those concepts to the Chrome Extension. By the end of the book you will have a real working program that you can share with your friends.

    What programming language will be used and why?

    Almost all of the examples in the book are written in JavaScript, but the book isn't about JavaScript. It doesn't teach any JavaScript-specific techniques. I chose JavaScript because JavaScript is the language of the web and I believe that programming the web is one of the most rewarding ways to learn to program, because programming the web is very visual.

    Will you be a pro when you are done reading?

    Learning to program takes a lot of practice, and you shouldn't expect to be a pro after reading one book, even this book. This book is about building the foundation that you need to become a great programmer. You will not be a pro yet, but you will be headed in the right direction.

    If you have questions about my book, send them my way.

  10. The Possibility of Prayer

    Posted 2014-02-10 06:07 PM GMT

    I have never doubted that prayer is real. I realize that to some such a conviction may seem strange or outdated, but prayer is an integral part of my life. Even though I don't doubt the reality of prayer, I have always had to rely on faith when it comes to prayer's practical feasibility. How can a single Being listen to millions (or even billions) of prayers simultaneously? And even more, how can that Being send a personalized response to each of those prayers? Like quantum physics, I know that it is real, but it is beyond my capacity to understand.

    I am satisfied with my limited understanding; I know that prayer works, and I don't feel the need to understand how. However, I have an inquisitive mind and I believe in the teaching power of metaphors to improve my understanding of difficult topics.

    I remember as I was first learning how the Internet works, the power of servers was remarkable to me. I began asking questions like, how can a single computer listen to so many requests simultaneously? How can that computer send a personalized response to each of those requests? These questions seemed so familiar.

    Google Search responds to over 1 billion queries per day, which is over 11,574 queries per second. And that doesn't include the requests to Google for personal email, calendar information, documents, news, or many other things. Each request to Google receives a personalized response.

    Handling such a large volume of requests is truly an amazing feat. I don't intend to argue that God uses algorithms and load balancing to efficiently scale the answering of prayers, nor that the power of Google's servers approaches (or even compares with) the power of God. However, the fact that man has created a system capable of delivering personalized responses to over a billion requests per day certainly says something. If we can build Google, certainly God can answer all of our prayers. God is more powerful than Google.