Last night I got an email from a former student, and figured I’d publish my reply. Maybe it could be helpful to you!

Hey Professor Phiffer,

I hope all is well with you. Its A— from CCNY. I took a JS course with you a few years ago. I hope that this is not a bad time to reach out to you. I’m reaching out to you in regards to programming and becoming a fully fledged software engineer. I see that now JS is one of the most important languages that are being used today, and I would love to master it and programming concepts in general.

However, I’m realizing that there are a lot of flaws to the way that I approach programming, such as how to solve a simple problem. I realized it during a technical interview that I’ve had a few months back.

I know that this is out of the blue, but I’m wondering if there is any way to accurately learn how to properly program? I believe that all of these years I’ve been doing something wrong despite building out lots of websites. I was heavy on declarative languages such as HTML and CSS but never fully understood imperative programming languages such as JS and other real programming languages. Would you have any advice as to how to properly go about this?

I also truly don’t know what I’m missing as a programmer because I would love to get a frontend engineering job. Thank you for listening, and I look forward to your response Professor.

Sincerely,
A—

Hey A—,

I can totally relate to this! I think landing your first junior developer gig is among the hardest things to pull off working in tech. I crashed and burned in 3 or 4 of my first interviews, just completely red-faced and speechless, unable answer some “basic” tech question (especially the trivia kind).

The thing to realize is that you probably don’t want those jobs anyway! I bet they’re awful places to be a junior dev, they’d work you raw and not give you professional development or space to grow. So don’t get too discouraged if it doesn’t work out at first.

If you want it to happen, it will happen with time, the job market is in your favor here. It’s just a matter of finding your way to the right people. This is a largely a networking thing, and that’s probably one of the reasons grad school is still a good investment despite the crushing debt that’s often involved.

And by all means learn JavaScript, it is a super relevant tool, but it is just one tool in the toolbox. HTML and CSS are 100% real programming languages, don’t let anyone tell you otherwise. I find that mastery of CSS and the DOM is way more valuable than being a hotshot with a flavor-of-the-month JS framework.

Taking programming seriously is helpful for improving your software, but it’s also a great way to gain the confidence to interview well. Some of that just comes from doing it repeatedly, and learning from other people’s code (read the jQuery source, read the annotated underscore.js). There are also a lot of soft skills that have helped me along the way: send emails to people (you are already doing this!), buy the O’Reilly books, subscribe to blogs, listen to podcasts, get familiar with the “lore” (see: The Rise of Worse Is Better, The Jargon File, Macintosh Folklore).

Realize that some of all that (and my advice) will be somewhat outdated. You are going to have to invent a lot of the shit yourself that doesn’t exist yet, because our profession is still in the dark ages. Architecture and urban planning are decades more advanced than where we are, you are by no means arriving too late to the party.

Write your own blog posts, embrace the beginner’s mind, start going to BrooklynJS (or ManhattanJS, JerseyScript etc.) meetups—apply to be a speaker, don’t be intimidated that your talk ideas might be too basic.

And hopefully all of that doesn’t sound too overwhelming!

Dan

A good text editor is, by far, the most important tool for programming computers. There are many good options available, and each person has their own reasons for choosing one editor over another. On the Mac, popular choices include BBEdit, TextMate, and Coda. For modest needs, an editor like TextEdit.app can be sufficient, while some opt for a full-blown IDE like Eclipse or XCode. Many coders still work with a console-based editor, such as vim.

I haven’t had a Windows box in so long I’m not sure what the popular choices are any more, but in college I was an UltraEdit guy.

My text editor of choice now is jEdit, which is free and Open Source. jEdit is written in Java, so it works on both Mac and Windows, and it supports many of the same features of non-free editors. It seems to be pretty obscure though, in part because getting jEdit into a usable form takes a little bit of work. Plugins must be installed, settings must be tweaked. It uses ugly non-system native Open and Save dialog boxes, but I don't mind so much because those interfaces let you work with remote files seamlessly via SFTP (using the 'FTP' plugin).

I thought it would be helpful to share my preferred settings, to give my favorite editor a better first impression. Below are a few steps to help you get set up on a Mac or on Windows. Desktop Linux can probably also follow along and improvise where things might diverge from Mac OS X.

1. Start by downloading and installing the latest stable release, use either the Windows Installer or Mac OS X package
2. Download and unzip my baseline configuration: jedit-mac.zip or jedit-win.zip (these have different default fonts and keyboard bindings defined in startup/startup.bsh)
3. Launch jEdit once to generate some default settings, and then quit (on Windows you may also need to close the jEdit Server from your system tray)
4. Make a backup of the default settings folder, found in /Users/[username]/Library/jEdit on Macs or C:\Users\\[username]\\.jedit on Windows 7, just rename the folder to jEdit.bak or .jedit.bak (note: your Library folder is hidden by default in Mac OS X 10.7 Lion)
5. Copy my baseline configuration folder where the default one was (in your Library folder on Macs or in your home directory on Windows)
6. Launch jEdit again, it should look a lot nicer!

Some notes about what’s different in this configuration:

• Nicer color scheme and default font (via the Editor Scheme plugin)
• FTP plugin for seamless remote file management (use a path like sftp://user@hostname/path/to/directory)
• Tabs UI instead of a drop-down to switch between files (via the BufferTabs plugin)
• Project Viewer plugin lets you browse files from the sidebar
• XML plugin provides handy HTML auto-completion, indentation, and entity conversions
• SuperAbbrevs plugin lets you set up macros for frequently used code snippets (for example type 'a', then shift-tab, set a macro for hyperlinks like <a href="$1">$end</a>—now you can type 'a' followed by a tab and save yourself some repetitive typing)

You also get things like multi-line tab indenting and regular expression search/replace out of the box. Of course you'll want to tweak your own setup further depending on your needs, so be sure to explore the preferences and browse the extensive list of plugins. One thing that's also worth pointing out is that jEdit listens on a random network port when you start it up to determine if other copies of the editor are running. When I first saw this it made me wonder if I should worry that my editor had been hacked, but apparently this is normal behavior and can be disabled.

In a pair of recent posts, Andre Torrez outlined an idea for solving the “how do I get photos from my iPhone onto a website” problem. I like this idea, and I’d happily install this hypothetical Community Camera app if anyone ends up developing it.

The central mechanism for Andre’s idea is a new URL protocol camera: (similar to http:, mailto: or ftp:) that a simple camera application could claim control over. One such built-in protocol on the iPhone is sms:, which lets you easily direct users to send an SMS message. For example, clicking on this link (with URL sms:+12125551212) would switch you over to the SMS application with the phone number already filled in. Here is a handy list of other iPhone-supported protocols. But if you’re not reading this on an iPhone, pressing that link will probably give you an error message.

One of the good design aspects of hyperlinks is they’re not always expected to work, the web is chaotic and broken links are relatively harmless. So it’s certainly okay to offer these links even if they won’t work for everyone. An improved design would allow web applications to detect whether or not a given protocol can be used. That way I could write some JavaScript code to check whether camera: or sms: links are supported, and make the process much more seamless for users. As far as I know (correct me if I’m wrong), such a mechanism doesn’t exist yet. It exists! See update below.

The email workaround

One workaround solution, used by many web applications including Flickr, is to provide a special email address that allows you to upload photos as an attachment. The benefit is that every computer with a browser supports email links, smartphones and otherwise. The downside is the unwieldy sequence of steps you have to follow. In the best case scenario, a user has already saved the web app’s special email address to her contacts:

1. Switch to the Camera app, take a photo or find the one you want from your library
2. Press the “utility button” and choose “Email Photo”
3. Fill in the email address from contacts and press send
4. Switch back to the browser and wait for the attachment to be received by the web app

A number of factors complicate this process, starting with the initial messaging. The natural thing to say is “Email a photo to upload,” linked with a mailto: URL protocol. But on the iPhone you can’t attach photos from the Mail app, it only works from the Camera side of things. So that “Email a photo” link should probably go to a page that explains the process outlined above, including the important step zero “add our special email address to your contacts.”

Email uploading requires that you’re willing to read a bunch of steps, understand them, and follow them. Additionally, the web application is left with no button that initiates the process and no way of giving feedback about whether it worked or not. If you reload the web app and you see your photo, then it worked. If not, maybe you’ll get a email bounce message. It’s a process that works okay for experienced users, poorly for novices, and that fails ungracefully.

Plus there is the implementation challenge of receiving and parsing email, which is kind of a pain in the ass. As an alternative to Andre’s plan, if somebody wants to write a general purpose email-to-upload service, I would find that pretty useful. Or does this exist already? I haven’t looked very hard.

Compare those steps above to the camera: method (including step zero, “install the Community Camera application”):

1. Press the “upload photo” link, with its “camera:” URL protocol
2. Using the native app that appears, take a photo or choose one from your library
3. When finished, the app switches you back to a page that has useful feedback

This is a better user experience, but it does require that someone go and write that native camera app (and that I install it). And unless there’s some way of checking for camera: support, even this will require some additional explanation.

Multimedia Messaging Service

Yet another solution can be found in SMS, or its more advanced permutation MMS (Multimedia Messaging Service). Using the sms: protocol mentioned above, I could create a link to sms:email@example.com that behaves almost exactly like the email upload method, while avoiding some of its complexity. On the iPhone, you can attach photos from the Messages app, and you can send MMS messages to an email address. And since there’s a link that initiates the process, it allows web apps to give some feedback on the page in response to a click event.

The downside to this method is that it requires the user to have a mobile plan with reasonable rates for sending MMS messages, and could fail ungracefully for users who aren’t fully informed about their mobile plan.

In any case, writing all this up has made me realize web browsers should let you detect whether a given URL protocol is supported. Browser makers, please build that into your next release!

Update: Andre tweeted a clever trick for detecting URL protocol support! Here’s how it might work in PHP:

<?php

// This will only work if the sms: protocol is supported
header('Location: sms:email@example.com');

// If not, fall back on this other page
echo '<html><head><meta http-equiv="refresh" content="0; url=sms-not-supported.html" /></head></html>';

?>

This is an essay I wrote for a one-off newspaper published by the Trade School folks. I haven’t found any trace of it online, but I bet a PDF version will materialize at some point.

An unusual book was published in 1974 called Computer Lib/Dream Machines. It has an oversized magazine format and two front covers. The two sides read inward to the center page, each side rotated 180° to the other. On the Computer Lib side, above a crudely-drawn clenched fist, reads the subtitle: You can and must understand computers NOW. I like the imperative nature of the phrase, even all these years later.

The book isn’t written by a computer scientist. Its author, Ted Nelson, isn’t a “technical person” so to speak, he has degrees in sociology and philosophy. He is a kind of über-generalist:

People keep pretending they can make things deeply hierarchical, categorizable and sequential when they can’t. EVERYTHING IS DEEPLY INTERTWINGLED. In an important sense there are no “subjects” at all; there is only all knowledge, since the cross- connections among the myriad topics of this world simply cannot be divided up neatly.

Nelson also coined the term “hyptertext” and continues to work on Xanadu, an ambitious (but tragically unpopular) hypertext system technically still in competition with the World Wide Web. I think of him, fondly, as the web’s crazy uncle. I appreciate his open resistance to the conventions of the web, even if my own career building websites is largely based on those conventions.

It’s hard to overstate the ubiquitous role the web now plays in our lives. The undergraduates I teach have grown up with access to Facebook and Google, these things must feel timeless to them. However, the internet as a whole is a fairly recent creation. It’s the result of very deliberate choices reflected in infrastructure and code. It’s easy to overlook how that hardware and software actually operates on our data.

As Lawrence Lessig has argued in Code, “we can build, or architect, or code cyberspace to protect values that we believe are fundamental. Or we can build, or architect, or code cyberspace to allow those values to disappear.” Setting aside Lessig’s unfashionable use of the word cyberspace, his point is an important one. It’s echoed more recently by Douglas Rushkoff in Program or Be Programmed:

Throughout the twentieth century, we remained blissfully ignorant of the real biases of automotive transportation. We approached our cars as consumers, through ads, rather than as engineers or, better, civic planners. We gladly surrendered our public streetcars to private automobiles, unaware of the real expenses involved.

Like global warming and urban sprawl, the dangers of centralized, corporate control over our mediated lives might seem daunting, inevitable even. It’s tempting to simply make due with those tools already at hand, to let professionals make the hard decisions about the software we rely on. The principle of intertwingularity suggests otherwise—your individual preferences and knowledge are fundamentally connected to the technologies where they become manifested. The capacity to write code is deeply intertwingled with what that software can produce.

Granted, the progress you can expect to make learning to program computers will be slow. It may take years before you build anything close to useful. Even so, the patterns of thought developed through understanding code will help you better negotiate the strange currents of our hypermediated world. The important first step is understanding why so that you will want to find out how. The second step is deciding on a project to undertake. The rest is a cyclical process of typing, befuddlement, and exhilaration when you finally understand how it works.