Tag Archives: programming

Why I became a programmer

Yesterday was not a good day. The reasons (plural) aren’t really important for the sake of this discussion. But at 7pm, with the day behind me, and an hour and a half before my wife   was scheduled to get home from yoga, I switched over to my emacs window, and started going after a problem I’ve been poking at for 2 weeks.

The problem, which had nothing to do with my day job, was how to seemlessly add some javascript to date forms in Drupal to make them more magically. The date forms in Drupal are honestly quite dumb. You get presented with From and To, Date and Time. They are initialized to “now”. But they are 4 fields, unlinked by code. This was the easy way for the developer to write it, but absolutely frustrating for the user. Especially if you’ve used systems where the To dates move forward in time to match changes in the From dates. Set From to Jan 24th, and the To date shouldn’t still be Jan 11th. Making it also move to Jan 24th might not always be right, but it’s almost always more right than leaving it unchanged.

I had figured out how to do this with jquery, with these fields, and have a solution for one of my sites. But this is something that would make a great Drupal module. One that requires no configuration, and just makes your user’s experience better. How to get there, required banging my head a lot on internals, reading a lot of code that I thought might be examples, and not getting anywhere. Last night, frustrated with things that weren’t this problem, I went after it again, this time by brute force. After about 45 minutes of trial and error, I found a hook I could use to patch myself into the execution stream at the right point. Better yet, it seemed like this was probably the right way to do it, not some dodgey hack. By the time Susan got home, I had the shell of this module mostly working. Not releasable yet, but the minimum viable piece was now done, and the rest was about cleaning up for release.

I felt better.

There is a longer story here about how I entered College to be a PhD Physicist, and I exited to do web development for the Sydney Olympics. But the key take away was a realization, late in my Junior year, that when I wanted to relax, I went off and coded something. While I could never point to the day it started happening, I do vaguely remember realizing that my happy place, my retreat from the stress of the world, was deep inside an emacs session for hours at a time.

The fact that the thing that relaxes me, writing software, also happens to be a key piece of a quite profitable profession[1], made me a fortunate individual. Having gone to college and watched the modern internet emerge, which is an even longer story, made me doubly so.

The best piece of advice I ever got was from my friend and mentor, Eric, in college. “The key to happiness is to figure out what you’d do anyway; then find a way to get paid to do it.” Even if this wasn’t my job, I’d be writing software. It’s what relaxes me.

What relaxes you? What would you do if money was no object? Why did you become whatever you call your profession? Drop a comment below, because I’m actually quite interested.

[1] Yes, I’ve been long enough in the Software Engineering space to know programming is a small part of it (especially at a large company), but it’s still a very important part.


What is computer programming?

As this blog post on needing a programming language for regular folks is making the rounds, I realized that most people don’t really understand what computer programming is. Computer programming is about creating clear instructions. You would think that with 50,000 years of communication under our belts, we’d be pretty good at that. But, it turns out we aren’t.

Think about the last time you tried to explain something to someone, like a cooking technique. You probably demonstrated it to the person, because as humans we learn very well by example. And we should, we have an entire class of brain cells dedicated to that. Computers don’t learn by example.

You may also have tried to teach them by analogy, by explaining that this is like something else they’ve done before. Computers don’t learn by analogy.

The thing you probably did not do is write down detailed step by step instructions and leave them to their own devices. And even if you did, that’s still not quite computer programming, because computers don’t have judgement. You can follow a simple recipe because there are many things that are understood, like cut out the bad parts of the tomato, or don’t burn yourself when taking the dish out of the oven.

A computer is not a mind, even though we can make them intelligence of a sort. It takes very careful forethought to make a computer do something specific. Over time, like with any skill, it becomes second nature. But to people from the outside, it’s not. It seems like magic and mysticism.

Plenty of people think they want programming to be in English, and I can assure you that you don’t. We already have it, it’s called the Legal Code. If you’ve ever glazed over 30 words in to a legal agreement it’s because you ran head long into the challenge that English, like all natural languages, was never meant to stand on its own. Removing the ambiguities that make English a great spoken language, take a lot of care and craft, like defining the meaning of the word “is”, and using terms like heretofore. And, even all of that, still doesn’t provide something that really stands on it’s own. Legal Code can only be understood in the context of Legal precedence, and anyone that thinks they can find a loop-hole in a license without knowing the case law, doesn’t understand how the law works at all. This is why we have very specialized languages in computer programming that are very good at being explicit, and ensuring you don’t hand ambiguities to the computer.

Computer programming is a skill, like any advanced skill, that takes a long time to develop. I have friends who have deep and wondrous skills in woodworking, which amaze me. But just like computer programming, their skills were not learned in a few weekends, it was a life long love of a medium that made them the master craftsmen they are today. If you are diving into this space, rejoice, as you’ll be able to do amazing things. But just don’t throw up your hands early and complain that this is too hard. That “feeling stupid” moment means you a learning, and that your brain is expanding. And, in the 21st century, computer programming is a skill that will take you far.

Update (6/14): My friend Nick has a good complementary piece to this over on his blog.

When is a number not a number

There is a standard Rookie mistake in website development when storing people’s information. A phone number, looks like a number, so people think they can use an integer to store it. The problem is that integers, as implemented on most modern computer systems and environments, have a maximum value of 2147483647. The results of this:

Somewhere in Dallas, some poor bastard is wondering why his phone rings off the hook with calls for the Nevada Division of Mental Health & Developmental Services, the Jackson County Florida Chamber of Commerce, a yacht club in New York…..

It’s even funnier because I’ve got a friend that ran into the same issue when working on a project as an undergraduate, it happens more often than you think.

Programming is Hard

This is a great essay about not beating yourself up for feeling stupid when you try to learn something new in programming:

The problem is that while you’ve uncovered a wonderful world that makes coding seem so approachable and fun, you’re unknowingly making a giant leap by thinking it’s somehow also easy.

This might not seem like a big deal, but it’s huge. Every single time (and this will happen constantly) you come across a concept that seems foreign or difficult or even just unintuitive, instead of thinking “It’s OK. Programming is hard.” you’re going to be thinking “This is supposed to be easy. What’s wrong with me? I must be stupid.” These feelings will keep you from seeking help or pushing through to discover why things work the way they do, and that is what’s stupid.

Programming is not always intuitive, it’s inherently complex, and it’s challenging. Once you start feeling like you’ve gotten a handle on it, you’ll learn something new that will make things seem even more complex for a while. Your level of stupidity is certainly up for debate, but not being able to program without long hours of steady practice is not an indicator of intelligence one way or the other. The discomfort is normal, so get over the self-consciousness now and fight it whenever it appears in the future.

I agree, I wish I had this advice when I first entered the field. It took me the better part of a decade to come to the same realization, that you felt stupid because you were really learning a lot of new and unfamiliar stuff. It makes you grow as a developer, and as a person, and is also probably fending of future brain degradation in the process. My most recent experience was relearning the math for Where is Io.

I spent days just trying to understand what should be a simple coordinate transformation, so much so that I almost gave up the project multiple times for being too hard. But the problem was, I knew someone else had figured this out, so it couldn’t be beyond me. A few weeks of banging my head against the table eventually got me past that. It would have been easy to just walk away, it was a hobby project after all, but pushing forward and overcoming the challenges made it that much more rewarding on the other side.

Steve Yegge: Wikileaks To Leak 5000 Open Source Java Projects With All That Private/Final Bullshit Removed

Many Java developers have vowed to fight back against the unwelcome opening of their open source. League of Agile Methodology Experts (LAME) spokesperson Billy Blackburn says that work has begun on a new, even more complicated Java build system that will refuse to link in Opened Source Java code. The new build system will be released as soon as several third-party Java library vendors can refactor their code to make certain classes more reusable. Blackburn declined to describe these refactorings, claiming it was “none of y’all’s business.”

Guy Faulkner, a 51-year-old Python developer in Seattle, was amused by the Wikileaks announcement. “When Python developers release Open Source code, they are saying: Here, I worked hard on this. I hope you like it. Use it however you think best. Some stuff is documented as being subject to change in the future, but we’re all adults here so use your best judgment.”

Faulkner shook his head sadly. “Whereas Java developers who release Open Source are code are saying: Here, I worked hard on this. I hope you like it. But use it exactly how I tell you to use it, because fuck you, it’s my code. I’ll decide who’s the goddamn grown-up around here.”

Which is even funnier because I was having exactly this conversation last night at the HV Programmers Meetup.

Programming in Arial

Want to get a geek roiled up?  Tell them you develop code in proportional fonts.  The comments on that article are a text book example of irrational geek argument try to get the higher ground.

Remember, there is one wholely optimal way to develop code, just like there is only one best editor, and only one best programming language.  Your decision of best would in no way be defined by the preferences of the skilled people you looked up to when you first learned this whole software development thing.

For the record, I prefer Arial.

Talent vs. Practice

This is a really great blog post on Talent vs. Practice:

I am sick of hearing people say, “Oh, I love your code, I wish I could do that.” You can. The only reason you can’t is because you don’t practice enough. I used to think that I wasn’t smart enough. I was jealous of those that did crazy code stuff that I couldn’t even comprehend. Then, one day, I ran into something I did not understand and instead of giving up, I pushed through. I sat there in front of my computer for hours and wrestled with class and class instance variables.

That day was a turning point for me. It was the last time I thought that whether or not I was successful depended on my talent or intelligence. It really comes down to hard work people. Ever since then, I have attacked each thing that I do not understand until I understand it.

The real moral of this story, stop talking about things you wish you could do, just knuckle down and do them.  It’s hard work, but it’s the way you make an impact.

Programming with Constraints and my adventures with Drupal

I’ve finally wrapped my head around the blocks, views, and content construction kit model for Drupal, which we’re going to be using for the upcoming relaunch of the Poughkeepsie Farm Project website (you can see the work in progress here).  It took a number of days to make a mental breakthrough that let me understand what it was that Drupal wanted me to do to get results.  The big break through was getting that custom content types is really what I wanted and then how to use views to display them correctly.

The exercise was one of programming with constraints.  As a veteran software developer, I’m used to getting a blank page where I can happily build up features from scratch. That has the advantage of the end product doing exactly what I want, but has the disadvantage of having to do everything from scratch.  While from scratch is often satisfying, it’s also often really tedious.  By the time you’ve written your 3rd password reset system for a web application, you’ll feel that way as well.  Life is too short to keep repeating yourself.

The alternative is something like the drupal approach.  Start with a lot of the application done, and just complete the pieces you need for the project.  As a veteran software developer, I’ve been there too.  I’ve come into many a project late in the development cycle, and had to work inside the constraints that are already there because of decisions made in the past.  These decisions might have been based on money, expertise, timing, politics, or any number of other reasons.  At the end of the day it doesn’t really matter, you just have to accept what is, and figure out how to work with it.

Building on top of a framework like Drupal is like being brought in late on a project, where the rest of your team is the drupal community.  They made decisions on how things will work, and you just need to figure out what those were, and if you can work constructively inside those contraints.  It’s a different skill than the “from scratch” skill, but is just a valuable.  The real world has a lot more half finished projects out there than blank slates.

People love to complain about frameworks, especially tech folks, because they feel the constraints are hampering their productivity.  As any tech person knows, when you switch up what you are working on substantially, you go through the “wow I’m stupid” phase again.  Your output suffers, and you feel like you are never making any forward progress.  It takes weeks to months to get familiar enough with the new skill set, and actually start creating anything of value.  No one likes to feel stupid, so a very standard reaction is to lash out at the tools, say they are the issue, and go back to your comfort zone.  You get a lot of hating in tech on exactly that.  But not all frameworks or tools are bad, and writing things off as evil because you never invested the time to understand how they work are as silly in web frameworks as they are with compound miter saws and belt sanders.

At some point in the next couple of months I’m going to write up my own “getting your head around drupal” blog post, because I have to admit I did it by brute force.  Eventually I got enough insites to start getting productive.  It took a while.  I’ve been actively working on the farm site since september, and did a whole drupal layout back in the sprint just to kick the tires.  But overall, this was definitely worth it, and I’m quite happy with the output levels I’m getting now.

A novel aproach to addressing open source usability

I was just doing my morning catchup on RSS feeds with trusty Liferea, and ran across ingimp in my freshmeat feed, which has a rather interesting idea.

The standard method for usability testing in proprietary software is to pay to bring in a bunch of people “off the street” while your product is in beta, sit them down in front of your program, and give them a list of tasks to accomplish. You record the whole thing. Then you go back and figure out how long each of those tasks took, but more importantly, what sort of mistakes people made. When asked to Enable Grumocks, what menu did they guess grumock controls would be in?

While this is all good and fine for people with a bucket of money, in open source, something like this really can’t happen. Ingimp is a modified version of gimp (not a plugin), that provides transmits back to a central server what you are doing with gimp. This lets them get a snapshot of users as to what kinds of images they most often modify, which tools are most often used, etc. From their website:

Who uses GIMP? What do they use it for? What size images do they work on? How many layers do they have in their images? What tools do they use? How frequently do they use the software?

These are all important questions to consider during design. However, precise answers to these questions are generally unknown for the GIMP. While usability studies of the GIMP exist, and mailing lists and bug tracking software host ongoing discussions regarding the GIMP’s design, it is difficult to characterize how the GIMP is actually used in the real world, on a day-to-day basis.

ingimp is an instrumented version of the GIMP designed to gather this information, with minimal effort required. Just use ingimp as you would the normal version of GIMP and it will automatically collect information about how you use it — the commands you use, characteristics of your documents (number of layers, image width/height, etc.), and so on. When you quit the application, your usage data is sent to this website where it is publicly available for anyone to analyze.

ingimp is part of human-computer interaction (HCI) research at the University of Waterloo investigating new forms of sustainable open usability. In particular, our goal is to research new tools that assist open source projects in their efforts to make more usable software, without creating significant new overhead to end-users, developers, or other project members.

Unfortunately their instrumented version is still Gimp 2.2, and I’m on a 2.3 build in my distro. Perhaps after the next stable series I’ll give it a go.