Posts tagged: POSTS

How do you comprehensibly explain to non-programmers the challenges of programming? Why can’t you “just tell the computer what you want it to do”?

A classic teaching tool for this is the “make me a peanut butter and jelly sandwich” demo.

Put out on the table a jar of peanut butter, a jar of jelly, a loaf of bread, and a knife. Tell them you are a robot (computer) that is physically capable of making a peanut butter and jelly sandwich, but you need instruction (programming). That’s their job.

I’ve been working as a remote software developer for over five years now. I gather that some outfits do this better than others. In case they’re useful/inspirational for anyone else, I want to highlight the key things that have made this workable for so long. The key idea: Treat your remote workers as first-class, full-fledged members of the team.

• Have a chat server which everyone is connected to whenever they are working. IRC, Slack, whatever. Logging into this server is effectively showing up at work. If your group is big, give each small team its own channel, but have a common one too. Make it OK to have random chitchat there, just like people do in the break room or hallway.
• Ask of every meeting or group event: How do remote workers participate? Encourage this mindset in all managers and anybody who arranges meetings of any sort. Stream video for presentations. Solicit questions from remotes.
• Don’t keep critical information on a tackboard, whiteboard, fridge, or other physical thing that only in-office employees can see (and change).
• If you do something fun for in-office employees, match it for the remotes. (My employer took on-site employees to see the new Star Wars when it came out; they sent $50 Fandango cards to us remotes.)
• If you can afford it, fly everybody to work together at the same location for one week a year. (If your main office is suitable, great. If not, rent, or take everybody to Hawaii or something.) My employer has done this and I consider it a crucial part of my long-term enjoyment of the job. I know the people I work with not just as nicks and avatars and work product, but as people I’ve hung out with (and worked next to) also.

First in an occasional series where I show how old I am by reminiscing about the ’90s World Wide Web.

Do you remember the Altavista search engine? I don’t mean the thing that Yahoo bought and buried. I mean the original 1990s version.

Altavista was an exciting game-changer when it arrived at the end of 1995. Web search had a lot of room for improvement. Altavista’s two standout attributes that crushed the competition (e.g. WebCrawler) were its size and its speed.

I’ve been reflecting recently on my twisty path from being a kid with a computer to being a grown-up who is (apparently) a bona fide software engineer.

My first computer was a TRS-80 Model III. It had a 1MHz 8-bit Z-80 CPU, 64KB of RAM, and two 5.25" floppy disk drives (after upgrades).

I used it to play games, write papers, and learn how to write software – mostly in BASIC, though I eventually learned Z-80 assembly language. I even got a Pascal compiler at one point, though I barely knew what to do with it.

(This is another thing I found myself writing on Quora and wanted to keep. The question was “Does Python have any scalability limitations?”)

“Scalability” is a term people like to throw around, but the less specific you are as to what you mean by it, the less substantial the answers will be. It is not a simple linear measure on which languages can be given some numerical score.

Languages and their implementations do have certain inherent performance characteristics, but in order to understand their relevance to your needs you have to get specific about your needs.

(Somebody on Quora asked about “traits that the best programmers seem to have”. Here’s what I said.)

Breadth of understanding. They are not dogmatic. They have used (at least in passing) more than one language, framework, operating system – and understand the strong points of each.

Communication skills. They can explain their decisions. They can write code reviews. They can discuss their code.

Understanding that engineering is about tradeoffs. There is never an absolute “best” answer; there are always many choices each with their own sets of pros and cons.

Last summer I switched from OS X to Ubuntu for my day-to-day work. It’s gone well. Here’s a condensed rundown of some of the things I’ve noticed.

Things I miss when using OS X:

• ctrl key on both sides of the keyboard
• one-key app switching
• System-wide package management
• ctrl-alt-T default to bring up a new terminal

Things I miss when using Linux:

• Selecting menu items by typing their first letters
• Emacs-compatible key bindings in text fields
• LaunchBar
• Consistent mic support across applications
• Full-fledged Exchange integration (still haven’t bothered to get davmail running)

Cross-platform bright spots: