Both Elementary and Sherlock offer modern takes on the characters of Sherlock Holmes and Watson. While I watch both shows, I think Elementary is the better one. Here’s why:

Watson is more than just Holmes' biographer

In most versions of Holmes and Watson, including Sherlock’s, Holmes is the primary mover of the relationship. Watson is there as the audience’s stand-in, someone Holmes can be brilliant next to. He’s there to make Holmes more relatable, but that’s it.

Elementary’s Watson is a stronger, more complex character. She begins as Holmes' sober companion, becomes his mentee in deduction, and grows into an equal partner in solving crimes.

Holmes is a more complex character

Part of what makes Elementary’s Watson better is the fact that she manages to change Holmes. He starts the series as a recovering addict, oblivious to the feelings of others and convinced of his superiority. Unlike Sherlock’s version of the character, Elementary’s Holmes changes under Watson’s influence, becoming humbler and more sensitive to how his behavior is perceived.

Elementary’s version of Holmes is vulnerable, and knows it, something we never see in Sherlock.

Moriarty finally makes sense

I think Elementary’s portrayal of Moriarty is brilliant. The writers of Elementary managed to finally give a good explanation for the two main problems with Sherlock’s Moriarty:

1. Why doesn't Moriarty kill Holmes? I've never bought the "I admire him" argument. What criminal mastermind wouldn't eliminate a threat as great as Sherlock Holmes as early as possible?
2. Why doesn't Holmes track down Moriarty earlier? Both Sherlock and Elementary have Holmes encounter Moriarty early on without recognizing him, but only Elementary has a good explanation for why such an observant man as Holmes would have a blind spot where Moriarty is concerned.

Same-sex marriage is not a religious issue. It’s a legal one.

When you get married, you give your partner certain rights, and the two of you can act as one person. You can buy a house together and be treated as if you both owned it. If you have children together, you both get parental rights.

You get these rights because the government says you have them. No religious leader can simply point to two people and give them the ability to make medical choices for each other. The two people have to be adults, they have to decide to get married, and the person that marries them has to have been given that power by the government.

For the government to say that two people of the same sex can’t get married is like saying they can’t buy a car together. It’s an arbitrary refusal, a failure to fulfill one of the core functions of government: to enforce contracts.

I bought a new Nook Glowlight soon after it came out. I’m happy with it for the most part, but it has an annoying habit of going to a blank screen when I put it into sleep mode.

When I wake the Nook from this blank screen, it looks like it displays the book I was reading correctly, but each tap of the screen advances the text, even if I tap on the bottom to try to get to the Settings menu. Eventually the Nook freezes completely.

To fix this problem, I reboot the Nook when the blank screen first comes up. To do that, I hold the power button down for 20-30 seconds, until the blank screen is replaced by the booting up screen. I know it’s rebooting when I see the word “nook” printed in the middle, then “E-ink”, and finally the spiral of dots that means “loading”.

Hope this helps other Nook Glowlight owners!

Long before I became a programmer, I worked as an optical engineer at NASA's Goddard Space Flight Center. I was part of the Optical Alignment and Test group, which is responsible for the integration and testing of science instruments for spacecraft like the Hubble Space Telescope, Swift, and the upcoming James Webb Space Telescope.

While most of the day-to-day engineering practices I learned didn't transfer over to software engineering, I've found certain principles still hold true. Here's the first one:

The first version you build will be wrong.

At NASA, it was taken as axiomatic that the first time you built an instrument, you'd screw it up. Engineers always pressed for the budget to build an Engineering Test Unit (ETU), which was a fully-working mock-up of the instrument you ultimately wanted to launch. Since the ETU was thrown away afterward, you could use it to practice the techniques you'd use to assemble the real instrument.

And you needed the practice. The requirements were often so tight (to the thousandth of an inch) that no matter how well you'd planned it out, something always went wrong: a screw would prove too hard to reach, or a baffle would be too thin to block all the light.

No amount of planning and peer review could find all the problems. The only way to know for sure if it would work was to build it. By building an ETU, you could shake out all the potential flaws in the design, so the final instrument would be solid.

In software, I've found the same principle holds: the first time I solve I problem, it's never the optimal solution. Oddly enough, I often can't see the optimal solution until after I've solved the problem in some other way.

Knowing this, I treat the first solution as a learning experience, to be returned to down the line and further optimized. I still shoot for the best first solution I can get, but I don't beat myself up when I look back at the finished product and see the flaws in my design.

I’ve been waiting on a delivery of books for about a week now. When I got my first notice from UPS about a failed delivery (they needed a signature), I deliberately worked from home the next day so I could sign for the package.

Imagine my surprise when I went out to get the mail that afternoon and found another “failed delivery” notice on my door! I checked the UPS tracking site, and sure enough, it said the driver had “tried to deliver” the package 15 minutes earlier.

Here begins a bizarre experience in customer service.

I used UPS live chat to contact their customer service department, asking if they could have the driver swing back by, since I was home and he obviously didn’t try to deliver the package. They said they couldn’t do that, but they’d report my problem to the local branch, who would contact me by the end of the day.

So, first questions: UPS can’t contact their drivers while they’re out? And the central office can’t handle customer complaints?

The local branch called - at 7:30 at night, well after close of business. They left a rambling voicemail that insisted the driver had tried to get a signature, but would try to re-deliver the next day. Alternatively, I could have them hold it, and pick it up between 8:00-8:30 am. They repeatedly mentioned I should call “the 800 number” to tell them what I wanted, but failed to tell me what the actual 800 number was.

So, second question: if complaints are handled locally, why was the local branch redirecting me to (I assume) the national office’s number?

The next day, I tweeted about my bad experience, and got a reply from the UPS twitter bot asking for more info. I emailed them my tracking number, hoping for some actual customer service. Boy, was I wrong. They sent back the same “complaints are handled locally,” response, even saying “I see the local office has contacted you already,” as if the fact that they left a voicemail made everything better.

Again, why the hell would the national office bother to find out more, if there’s nothing they can do?

So, instead of getting my package delivered - the service I paid for - I’m heading out to the UPS package center in the morning to pick up my books.

Let’s review all the mistakes here:

1) When confronted with a customer that didn't get the service they paid for, UPS never admitted wrongdoing.

This is an amateur customer service mistake.

2) Rather than try to compensate the customer for the mistake, UPS bounced the customer between different departments.

This is like watching the federal and state governments argue over who’s responsible for bad schools - they’re both involved, so why don’t they work together to fix it instead of passing blame?

3) UPS is requiring the customer to complete the service on their own.

This is like a waiter telling you to go fetch your re-fired steak from the kitchen yourself. You’d never go back to that restaurant.

I’m amazed a company like UPS could fall on its face over something as simple as delivering a package to a house with a person inside. You’d think they’d treat their core mission a little more seriously.

Instead, they’ve convinced this guy to ask for FedEx next time.

If you don’t allow your software developers to work from home, you’re not just withholding a nice perk from your employees, you’re hurting your business.

Here’s five reasons letting developers work remotely should be the default:

1. Widen your talent pool

The CTO for my current gig lives an hour away from the office, and can’t move because of his wife’s job. We wouldn’t have been able to hire him if we didn’t let him work from home. Who are you missing out on because you won’t look at remote devs.

2. Reclaim commute time

Don’t think they will? The evidence shows they do: people working from home work longer hours than people in the office.

An extra hour of work a day is five more hours a week, or almost three more work days in the month. Why throw that time away?

3. Reduce sick leave

If my boss didn’t let me work from home, he wouldn’t get those “sick hours” from me. I’d be forced into taking more time off, getting less done.

And when my wife’s sick, I don’t have to choose between taking care of her and getting my work done. By working from home, I can do both.

4. Increase employee retention

Since the competition for talent is fierce, you don’t want to lose out to another company. Letting developers work from home sends a clear signal to your employees that they’re valued and that you appreciate work-life balance. And with many companies sticking to the old “gotta be in the office” way of thinking, you’re ensuring that any offer your employees get from another company won’t be as attractive.

5. Stay focused on work done

What does matter is how much work a dev gets done: how many bugs squashed, how many new features completed, how many times they jump in to help another engineer. What you need from your developers is software for your business, not time spent in a cubicle. If they’re not producing, they should be let go. If they are producing, does it matter if they’re at a coffee shop downtown?

And if you don’t have a way of measuring developer productivity beyond hours spent at their desk, get one. You can’t improve something you don’t measure, and team productivity should be high on your list of things to always be improving.

Editing Clojure with Emacs: Ryan Neufeld

• emacs live, emacs prelude, emacs-starting-kit: for getting up and running
• bit.ly/vim-revisited - post about going back to basic editors
• bit.ly/clj-ready: ryan's version of emacs starter kit
• nREPL & nREPL.el instead of inferior-lisp
• melpa for your package manager
• have a look at the projectile minor mode for project management
• use paredit to build up clojure code trees, not just characters
• slurp and slice to add new structure: () then slurp to wrap

Ritz: Missing Clojure Tooling: Hugo Duncan

• clojure debugging tool
• nREPL: lets you connect to remote clojure VM (transport + socket + protocol + REPL)
• sits in-between your local nrepl and the remote nrepl process
• available as marmalade package
• also lein plugin: lein-ritz
• turn on break on exceptions: gives you common-lisp like stacktrace + restart options (continue, ignore, etc)
• can open up stacktrace to see local variables within the frame
• can even evaluate expressions within the frame (!)
• also pull up the source code for a frame (clojure or java)
• can set breakpoints on lines of code in emacs; view list of all current breakpoints in a separate buffer
• warning: lists appear in stacktrace frame fully-realized (will be fixed)

Macros vs Monads: Chris Houser and Jonathan Claggett

• synthread: library of macros that use Clojure's -> (threading macro) as the do
• usually pulled in with -> as its alias
• defines macros for most of clojure's control-flow code
• also has updater macros
• use for cases where pure functional code is too verbose and/or hard to read
• replaces use of state monad
• monads are infectious (end up passing them around everywhere)
• clojure 1.5 has cond-> macro
• rover example project up on github: lonocloud/synthread

How to Sneak Clojure into Your Rails Shop: Joshua Bellanco

• and improve your rails hosting along the way
• chief scientist at burnside digital (based in portland)
• if this was 2006, we'd be talking about sneaking rails into your java shop
• learn from rails: better to ask forgiveness than permission, use clojure whenever it's the right tool for the job, don't be afraid to show off your successes
• step 1: convince them to use jruby (better tooling, better performance, java ecosystem, plenty of hosting options)
• step 2: torquebox for deployment (benefits of jboss)
• step 3: go in with clojure and start using immutant overlay (gives jboss, torquebox, jruby); lein immutant run runs both ruby and clojure apps
• step 4: openshift (open source heroku from redhat)
• step 5: make clojure and ruby talk to each other (hornetq + torquebox/immutant messaging libraries)
• step 6: show off!
• example project: memolisa: sends alerts and confirmation when alert is read; rails for users + groups, clojure for the messaging

clj-mook: Craig Brozefsky

• library for testing web apps
• persistent session, default request params, html parsing
• motivated by shift from ring to immutant

RxJava: Dave Ray

• open-source implementation of M$ Reactive Extensions
• operators for creating, composing, and manipulating Observable streams
• sketch up at daveray/rx-clj
• also: netflix/rxjava

VMFest: Toni Batchelli

• goal: make virtualbox behave like lightweight cloud provider
• instantiate multiple vms from the same image
• wrap the OOP api of virtualbox with a sane clojure one
• has hardware dsl
• one step further: little-fluffy-cloud -> RESTful interface for vmfest
• visaje: build VMs from data

shafty: Chris Meiklejohn

• basho technologies: erlang and js, with some clojure
• functional reactive programming library
• based on flapjax, implemented in clojurescript
• implementation of core API from flapjax
• FRP: authoring reactive programs without callbacks
• FRP: event streams and behaviors

swearjure: gary fredericks

• subset of clojure with no alphanumeric characters
• exercise in extreme constraints
• integers but no floats
• true and false available

Evolutionary Art with Clojure: Alan Shaw

• clevolution: partial implementation of paper on genetic programming
• converting s-expressions to images
• using self as filtering function: delete the images he doesn't like
• want to move to true evolutionary: use function to weed through the images, allow cross-breeding between s-expressions
• clisk, clojinc, clevolution

Simulation Testing with Simulant: Stuart Halloway

• example-based tests: setup, inputs, outputs, validation
• originally built as tool for testing datomic
• no language indirection: it's about using clojure and datomic
• write model for what will happen to the application, then writeup actions to take against the system
• can speed up time in simulation, so don't have to wait for 6 mo for 6 months of results to go through
• stores db with test results *and* the db tests ran against
• can find and diagnose bugs by querying db after tests run
• use clojure.data.generators to generate random test data (ints, vectors, maps)
• github.com/stuarthalloway/presentations/wiki
• contact at @stuarthalloway to have come out to speak at company or group
• even working through the model of users and use is a good exercise; good way to validate the assumptions you're making about the system

Winning the War on Javascript: Bodil Stokke

• catnip: beginners clojure editor in browser
• originally used coffeescript because cljs was immature and hard to work with js objects
• currently working on converting catnip to cljs
• error: another clojurescript testing framework, built around asynchronous testing

PuppetDB: Sneaking Clojure into SysAdmins' Toolkits: Deepak Giridharaghopal

• ops has a lot of entropy: spooky action at  distance: devs or admins logging in to one of many servers and mucking around without telling you
• lack of predictability ruins automation and abstraction
• problems with previous software in Ruby: not fast, only one core, mutable state everywhere, runtime compatibility a problem
• solution: puppetdb in clojure for storing and querying data about systems
• used CQRS: command query responsibility separation -> use different model to update then to read info
• send commands to a /command endpoint, which queues the command for parsing and processing
• build command processing functions as multi-methods switching off of the command and version sent
• can also turn on live repl, to connect to running code and hack
• queries have their own AST-based syntax; sent as json, built as vector tree
• can ship the whole thing as a single uberjar, with built-in db, etc

Securing Clojure Web Services & Apps with Friend: Chas Emerick

• authentication & authorization (who are you? what are you allowed to do?)
• options: spring-security (java, not recommended), sandbar, ring-basic-authentication, clj-oauth2
• most common: roll your own
• wrote friend to have a common auth framework
• uses ad-hoc hierarchies for roles
• add workflows to specify how to authenticate a request that doesn't have authentication yet
• friend-demo.herokuapp.com for multiple demos with source code
• recommend using b-crypt over sha

FRP in ClojureScript with Javelin: Alan Dipert

• event stream: sequence of values over time
• behavior: function that updates according to changing values from event stream
• reactive evaluation: holds off on evaluating until all values are available
• similar to spreadsheet formula evaluation (!)
• FRP maintains evaluation order despite lack of all values at once
• current FRP in clojurescript: FlapJax
• javelin: abstract spreadsheet library for reactive programming with values
• everything contained in the "cell" macro
• web app has single state at any point in time, contained in the "stem cell"
• everything in app either in stem cell or derived from it

SQL and core.logic Killed my ORM: Craig Brozefsky

• uses clojure for analysis engine looking for possible malware actions
• core.logic engine takes observations and creates IOCs (indications of compromise) + html
• observations: wrapper around core.logic's defrel
• IOCs: severity + confidence, explanation, suggested remediation
• the reasoned schemer: handed out to all their analysts to explain logic programming to them so they can use the system

Macros: Why, When and How: Gary Fredericks

• macro: special function that takes form as argument and returns a form
• run at compile time
• can always be replaced by its expansion
• when writing macros, helps to know what you want it to expand to
• use macroexpand-1 to find out when it's going to return
• cannot pass macro to higher-order function (not composable at runtime)
• macros can make code harder to read; person reading code has to be familiar with macro expansion to really know what your code is doing
• tolerated usage: defining things, wrapping code execution, delaying execution, capturing code, DSLs, compile-time optimizations (hiccup produces as much html as possible at compile time)
• avoiding macros: get more familiar with higher-order function usage and paradigms
• writing tolerable macros: use helper functions, naming conventions, no side effects
• syntax-quote (backtick): like quote on steroids, gives you multiple benefits when used in a macro

Domain Driven Design in Clojure: Amit Rathore

• read the book from eric evans
• Lot of oop design principles carry over
• shoot for 3-4 lines of clojure code per function
• validateur, bouncer, clj-schema (validation)
• if code confusing, demand simplification
• make temp namespaces explicit: zolo.homeless
• domain: business-important logic, not the API, not services, not validation, not talking to the db, just the stuff business people care about; should be pure
• if you don't need it now, don't build it

RESTful Clojure: Siva Jagadeesan

• liberator, bishop: libraries to help build proper REST APIs in clojure
• use the status codes: 1xx - Metadata, 2xx - success, 3xx - redirect, 4xx - client error, 5xx - server error
• 405: method not allowed
• 409: conflict
• 404: resource not present
• create returns Location header with location of new resource, in addition to the 201 (created) status code
• even better: also return a set of links to related resource (rel = self) and transitions (rel = cancel)
• allows client to be loosely coupled from API
• client doesn't need to know how resources move through the system (transition logic)
• REST means using multiple URIs, HTTP status codes, and Hypermedia

Clojure in the Large: Stuart Sierra

• def'ing refs and atoms at the top level is basically global mutable state via singletons, please avoid
• recommend using constructor functions to *return* the state variables you want to use, then pass that state along to each function
• easier to test
• explicit dependencies
• safe to reload when working at the repl
• thread-bound state also bad: assumes no lazy sequence returned in function bodies, hides dependencies, and limits caller to using one resource at a time
• prefer passing context around to functions
• can pull resources out of it
• use namespace-qualified keys for isolation
• isn't confined to a single thread
• still need to cleanup at the end
• more bookkeeping
• true constants are fine as global vars (^:const)

Pedestal: Architecture and Services: Tim Ewald

• alpha release from relevance of open-source libs
• use clojure end-to-end to build RIAs
• demo: hammock cafe: clojurescript apps communicating to same back-end using datomic store
• 2 halves: pedestal-service, pedestal-app
• ring limits: bound to a single thread's stack
• interceptors: map of functions, has enter and leave for processing requests and responses
• can pause and resume along any thread
• pushed to be as ring-compatible as possible
• use of long polling and server-side events (requests that come in slow and last a long time, get updated as more data comes in)

Design, Composition, and Performance: Rich Hickey

• take things apart
• design like bartok (embrace constraints, use harmonic sense)
• code like coltrane (constant practice, keep harmonic sense)
• build libraries like instruments (design for players, able to be combined with other things)
• pursue harmony

For about 8 months now, I’ve been working every Sunday morning with a good friend of mine building rewryte.com. It’s our own little web app, a tool for giving writers automatic feedback on their writing.

We’re trying to go beyond grammar checks and spellcheckers, to answer questions like:

• Are my sentences too long?
• Are the words I'm using too specialized for my audience?
• Should I submit this story as horror or science fiction?

I’ve changed jobs a lot over the past few years. I knew it would raise eyebrows each time I applied for a new position - they’d ask themselves how long I’d stay with them - but I told myself it was because I was looking for the perfect job, so it was ok.

I’ve realized the perfect job just isn’t out there.

There’s something wrong with every job. The dress code is too formal. The boss won’t let me work from home. They’re not using my favorite language. They’re not promoting me. They don’t give enough vacation hours. The codebase is old and crufty. Etc.

The trick is to find a perfectible job, not a perfect one. A job with a boss and a team that’s flexible enough so that you can improve the job over time.

After all, my interests will shift over time. Even if I found the perfect job for what I want to do now, I’ll grow out of it in a few years. And then where would I be? Leaving the perfect job, and torturing myself over it.

Better to find a job with a few rough edges that I can smooth out over time. As long as I go in with my eyes open, I won’t be disappointed.

Because perfecting your job is just a different type of engineering.

I’m a little obsessive about the tools I and my co-workers use. If I come into a company and they’re still on svn, I push to get us switched to git. If people have to login to a remote server to develop on via a slow internet connection, I figure out how to get a local VM install to do everything we need, and share it with everyone.

So when my current company started experiencing pains with PHP, and the other devs talked about switching languages, I immediately thought of persuading them to switch to Clojure.

Why Clojure? It’s fast. It’s code is compact but still readable. And it’s got the power of Lisp.

I got permission to build some internal tools in Clojure, and set to work. I thought it was just a matter of time before the other devs would “see the light” and start switching over to Clojure.

Nine months later, we’re still building everything in PHP. No one’s even looked at my Clojure code. Beyond some jokes about Python, there’s been no further movement toward switching languages.

I’ve failed.

But why? In order to document my mistakes, so I and others can learn from them, here’s what I did wrong:

No Expertise

As a result, those internal tools I built were full of bugs when they launched. When I got pulled off of working on those tools and back to working on the core company applications, those bugs stayed - for months - without being fixed.

My co-workers' first experience with Clojure was of a buggy, slow application that didn’t do too much. That first impression was hard to shake, even after I went back and fixed bugs and improved the apps.

No Designer

No Maintenance

I documented everything they told me, capturing it in Jira tickets, and then sat on them for months.

Why? I’d been pulled off of internal tools to doing other application development. So instead of being able to iterate with my users, constantly improving the application, they had to wait a long time before they saw any changes. I lost what goodwill I’d had to start with, because I didn’t respond to their needs.

No Training

I was certain that some of them would peek at the Clojure code, just to see what it was like, and then start asking questions. I told myself this was the natural, organic way to start spreading Clojure knowledge around the organization.

I was dead wrong. The other developers had a hard enough time deciphering PHP code from 2 years ago; they weren’t going to spend time trying to read my stuff too. Especially since it was buggy. And slow. And hard to use.

Conclusion

Your first 30 days with a company can be nerve-wracking. Your boss is watching your performance, trying to decide if he made the right choice. Your co-workers are trying to learn if you’re going to be a helpful member of the team or just dead weight.

All that scrutiny gives you a golden opportunity to make a great impression.

Here’s four ways to make sure they’ll be glad to have you on board:

1) Go in Early

I know a lot of developers are night owls, but for the first 30 days, you should make an exception. Come in earlier than you normally would, but stay as late as everyone else does. You’ll show everyone you’re serious about the job, and aren’t afraid of work.

Even if you shift your schedule back to a normal one after the first 30 days, you’ve gone a long way to reassure your colleagues that you’re here to help them out.

2) Update Documentation

Was the system setup process well documented? If not, fix it. If documentation doesn’t exist yet for something you’re supposed to learn, create it. Your boss will notice, and you’ll be helping future employees get up and running faster.

3) Ask Questions

It’s one thing to learn how a company does things. It’s better to learn why they do them the way they do.

Look for areas where they don’t have any reason to back up how they’re doing something. If you can find a better way of doing it, pitch it to your boss. You’ll show him you care about the quality of your code, and you won’t have to step on anyone’s toes.

4) Stay Calm

You’re learning a lot of new things, and trying to stay productive at the same time. Don’t rush yourself. Most employers don’t expect their employees to start seriously contributing until they’ve put in 90 days. You’re going to be slower than normal, but that’s ok. Take the time to really learn all the nooks and crannies of the system you’ll be working in now, so you can contribute more later.

You’ve landed a good job. You negotiated a high salary, plenty of vacation days, and flexible work hours.

Congratulations. But don’t stop thinking about your career just yet. Now that you know your way around your current programming language, it’s time to learn another one.

Here’s why:

1) Languages go obsolete

Every programming language becomes obsolete at some point. COBOL isn’t used for new software anymore. Whatever language you’re using now will be obsolete, or at least on the downward trend, in 5-10 years. You don’t want to end up chained to one company (or worse, laid off from said company) with only an obsolete language on your resume.

Pick a language that looks to be on the upward curve, and learn it. Think of it as insurance against the future.

2) Languages express best practices

When someone creates a new programming language, they’re codifying a certain style of programming that they consider to be the best. After all, if Guido Van Rossum thought functional programming was the best style to work in, Python would have been a functional language.

One of the easiest ways to get deep into someone else’s ideas about the best way to program is to learn their language. Consider the learning experience a conversation you’re having with the language creator, trying to learn how they think programming should be done.

You’ll probably agree with them on some things, and disagree on others. Take the things you like - the parts of the language that make some best practices easier - and find ways to incorporate them in the language you’re currently using.

3) Languages don’t do everything well

Most of the general-purpose programming languages we’ve got are actually really good at just one or two things, and terrible at others. PHP is a great scripting language, but pushing it to express a complicated DSL leads to code that’s hard to read and painful to write.

Picking up a new language gives you a larger toolbox to draw on, so when it comes time to build that internal website, or reporting system, or distributed image processing software, you’ll be able to use the best language for the job.

4) Languages lead to jobs

This one almost goes without saying. You can’t land a Ruby job without learning some Ruby. You need to know C++ (or Objective-C) to work in the games industry. If you want to switch from web development to scientific computing, learning a new language is your best bet.

5) Languages teach programming fundamentals

Do you know what a monad is? How about S-expressions? Learning a language that’s radically different from what you normally work in (say, Haskell for Python devs) can teach you new programming concepts. You’ll learn new ways of thinking about programming, and new ways to approach traditional programming problems.

In the end, learning a new language (or several languages) is all part of becoming a mature, experienced developer. If you want to prepare for the future, expand your programming horizons, and keep a secret weapon (or two) in your dev toolbox, then you should learn a new language.

With the market for developers so fierce, we can afford to be a little more careful about where we work.

Over the years, I’ve interviewed at several companies. Whenever we got to the part of the interview where they asked what questions I had for them, I had plenty of stuff to ask about their tech stack, but not as much to ask about their working environment. Here are 10 questions I wish I’d asked at every interview:

1. How many hours a day do you require from your developers?

You’d be surprised how many places expect more than 40 hours. If they want you to work 45 or 50 hours a week, it’s best to know that up front, so you can negotiate an appropriate salary.

2. Do you allow working from home? How many of your developers work from home at least once a week?

A lot of companies will say they allow working from home. If they’re actually committed to it, though, they’ll be at least one or two developers taking advantage. If no one works from home, it’s because it’s discouraged by management, or they don’t really have the infrastructure (VPN, etc) in place.

3. What is the timetable for getting vested in shares?

A critical question for startups. They’ll usually ask you to take a lower salary in exchange for shares. But if those shares take 5 years to become vested, you’re looking at a long wait for a risky payoff. Do you really want to sacrifice money in the bank for that long? Best to make an informed choice.

4. Do you have “office hours” you like your developers to keep? What are those?

Most places are flexible, but have some sort of core hours they want you to keep. These may not fit your natural schedule (I’m personally a morning person, but I know a lot of developers that prefer to code at night).

5. What’s your leave policy? Are Vacation and Sick Days lumped together? How many do you give a year?

Several startups are offering unlimited leave these days. It makes sense; if you’re a salaried employee, paid per year to get a job done, does it matter how many sick days you took?

If they won’t go unlimited, consider bargaining for increased vacation instead of a higher salary. You’ll thank yourself later.

6. What’s your process for changing internal tools - e.g., if you were to change version control systems, how would you go about that?

Over the life of any piece of software, your tools are going to change. Is this dev team ready to handle that?

7. Do you allow developers any time to work on open source projects, or just projects of their own for the company?

You’re going to want to spend time on your own stuff, whether to try out a new language or keep your skills up to snuff. You’ll probably want at least some of that to be open source work, so you can show future employers your coding prowess without violating NDAs. If your new job won’t let you invest in yourself, will they pay for training or conferences to compensate?

8. What’s your employee review process? How often do you do employee reviews?

Ideal would be reviews after 30, 60, and 90 days for new employees, with everyone else getting evaluated every 6 months. You need the feedback an employee review can give, and they should want to hear from you.

9. Do you do code reviews? How often? What’s the process?

Feedback, feedback, feedback. One of the fastest ways to grow as a developer is to have other people read and comment on your code. Frequent code reviews mean the team is committed to getting better.

10. Do you do project reviews? What’s the process? Alternate: How is the performance of the dev team as a whole measured?

Another feedback question. Again, you’re trying to see if the team is serious about getting better.

These questions won’t cover everything, but they’re areas we developers often forget to check when looking for a new job.

Both Amazon and Barnes and Noble claim their ereaders will sync where you are in your books between the different devices (iPad, Android phone, PC or Mac) you might be reading on. Amazon’s works in the background, without a hitch, but Barnes and Noble’s (Nook) takes some finesse to get working.

I nearly pulled my hair out in frustration trying to figure out why the last read page in my books wasn’t syncing between the Nook software on my iPad and the Nook software on my Android phone. I looked in the Settings for both devices, trying to find something that said “sync” and might have been turned off, but no luck.

Here’s how to get them to sync:

1. Whenever you finish reading on one device, instead of just closing out the software (or putting your device to sleep), go back to your "Home" or "Library".
2. Look in the upper-right-hand corner of your Library screen. You should see a pair of curved arrows. Touch those arrows to force your device to upload its information (last read page, new bookmarks, etc) to B&N's servers.
3. When you open your second device, make sure you start out on your Home/Library screen, and hit the same arrows. This will force the device to pull the latest information from B&N's servers (including the last read page you just uploaded).
4. Open the book on your second device. It should jump to the last read page from the first device.

Ever since I gave away my trusty Macbook, I’ve been pining for a new computer. The iPad purchase helped, but let’s face it: I’m not going to be able to do any programming on that thing.

I knew I was going to install Linux on whatever I bought, so I thought I’d cut out the middle man and buy one direct from System76. They’ve been making laptops and desktops with Ubuntu pre-installed for a few years now, and their reviews have been positive. So I swallowed my trepidation at buying a laptop without test-driving it in the store first and ordered one of their Pangolin Performance machines.

After two weeks, here’s what I think (in brief):

What’s Good

• Ubuntu: I didn't have to do any configuration out of the box, or hunt down any extra drivers. Nice.
• Speed: Ye gods, is this thing fast. Transferring my entire music collection (a good 20 GB) from my backup drive took just 15 minutes. It's good to know the i5 processor + solid state drive were worth it.

• Keyboard: In a word, terrible. It's shifted to the left of the center of the screen, so I'm always twisted in my seat if I'm trying to type on it. The keys are more widely spaced than is comfortable, making my fingers work more to type anything. The spacebar also refuses to recognize most key-presses. Altogether it feels cheaply made, and is really frustrating to type on.
• Customer Service: Not so helpful. I emailed System76 support about my spacebar problem. Their solution? "Press it closer to the center" Well, thanks, guys, but if I can only get a space by hitting a single spot on the space*bar*, it's not much use to me, is it?
• General Build: Cheap. The "Ubuntu key" is just a regular key with a tacky sticker on it (placed off-center, no less). The laptop won't turn on unless you hit the power button at the exact right angle for the exact right amount of time. The whole thing feels shoddy.
• Wifi: Maddeningly drops connections at random. Had to connect the laptop to ethernet to get reliable internet access. Sort of defeats the purpose of having a laptop, IMHO.

I’m close to returning it and just buying a Macbook. It might cost more, but at least I’ll know it’s solidly built.

Update 12-15-2010: Finally convinced system76 to let me ship the computer to them for a keyboard replacement. Hopefully this’ll fix the spacebar problem and make the laptop worth keeping.

Update 12-27-2010: They fixed the keyboard! Got the laptop back just before Christmas, and the spacebar works normally (as does the rest of the keyboard). Definitely keeping the laptop now. Thanks to system76 for coming through with hardware support.

30 days ago, I broke down and bought an iPad.

I know, I’ve ranted and raved against Apple’s unfair closed-source system. And yes, I hated the shopping experience my first time out.

But lugging around my netbook + my Nook so I could read books and check email and read pdfs and read The Economist online started bugging me. Doubly so when I realized there were some ebooks I could only get from the Kindle store (damn you, DRM!), but neither my Nook nor my netbook could read Kindle books (Linux, it so happens, is the one platform Amazon’s Kindle software doesn’t run on). So I had to read Kindle books on my phone (Android), Barnes and Noble books on my Nook, and pdfs (Linux Journal - why do you guys cling to the old pdf format?) on my netbook.

Needless to say, this drove me batshit after a while.

So I trudged down to the Apple store to try out the iPad again.

And guess what? My experience was much better this time. There was plenty of software installed on the demo units for me to try out. The staff answered all my questions, and actually seemed to care about selling me one.

I picked one up, and after 30 days I don’t miss the Nook or the netbook at all.

I can read all my books, from every store. I can push my pdfs into DropBox and read them with GoodReader. I’ve even started jotting down notes for a few short stories in Elements, again using DropBox to sync up the files between my Nook and my desktop.

Oh, and I’ve also picked up a few games. Plants vs Zombies HD is almost worth the price of admission on its own.

Can I program on it? Nope. Is it annoying that iTunes can’t play my .ogg files? Hell, yes.

But you’ll have to pry it from my cold, dead hands before I’ll give it up.

I recently picked up Programming Clojure and started working through it, trying to wrap my head around this new variant of Lisp.

Installing clojure itself was pretty simple (sudo apt-get install clojure, since I’m using Ubuntu), but I had a hard time figuring out how to make the clojure contrib libraries available from the clojure REPL (I kept getting errors about the clojure-contrib classes not being on the classpath).

Here’s how you do it: start the clojure REPL with an extra argument pointing to where you’ve installed the source files for clojure-contrib. For example:

clojure -cp /home/rontoland/Code/clojure-contrib-1.1.0/src

Since the clojure-contrib libraries are used throughout the book, I put the above code in a small script and saved it in my /usr/local/bin folder as clojure-repl, so I don’t have to remember the longer command.

A few months ago, when Apple bought Lala.com, I didn’t panic. I thought Apple’d integrate Lala.com’s store into iTunes, rebrand the site, and keep things rolling.

I was wrong:

Dear Ron T.,

The Lala service will be shut down on May 31st.

In appreciation of your support over the last five years, you will receive a credit in the amount of your Lala web song purchases for use on Apple’s iTunes Store. If you purchased and downloaded mp3 songs from Lala, those songs will continue to play as part of your local music library.

That’s part of the message I got in my inbox this morning. Apple’s shutting Lala.com down, and offering me “credit” in the iTunes store as compensation.

Fuck you, Apple. I bought music from Lala.com because I didn’t want to buy it from your store. I had a choice, and I exercised it. But you just can’t understand that, can you?

I will never buy anything from the iTunes store. I will never throw my money away on songs in your proprietary format.

Lala.com’s ease of use, free access to every song in the catalog, cheap prices and web-based portability were far superior to the iTunes store. You couldn’t compete with that, could you, Apple? So you bought it and killed it.

Fuck you.

Finished reading Just a Geek. Surprisingly, my experiences and feelings toward NASA parallel Wheaton’s feelings toward Star Trek in many ways: the feeling that I need to prove leaving was the right decision, the odd mix of guilt, excitement and nostalgia I feel whenever I see someone I used to work with, the worry that something went horribly wrong with my life and I’ll never get it back on track.

It’s good, then, to see that Wil has grown into an acceptance of his past and his decision. I feel like I’m still somewhere in the middle of the story, with a sense that I can and should let go of both the image of myself that working at NASA gave to me, and the dreams I originally left NASA for. But I can’t bring myself to drop them, yet.

That’s not to say I can’t dream new dreams. I know I should, and I’m trying hard to, but I’ll be damned if both dreams–NASA Engineer and Novel Writer–aren’t hard to wake up from.

This weekend, a friend of my wife’s was gushing about how her church had just started a program to help the poor in Uganda: they take unwanted clothes from Ugandans, ship them over to the US so her church-members can sew them back together using Christian-themed patches, sell the clothes to people in the US, and then send most of the proceeds back to poor Ugandans.

“Why not help the Ugandans setup a factory to do the clothes repair in Uganda, so they can sell the clothes to other Ugandans (or ship them themselves) for a profit?” I asked.

She looked at me like such a thought had never entered her mind. Why wasn’t I proud that her church was helping the poor, helpless Ugandans?

Because they’re not helpless. Because teaching someone to fish is always superior to giving them a fish. Because what her church is doing is not helping anything other than their own sense of self-righteousness.

Christians in the 19th century were a progressive force: they pushed for the abolition of slavery, they setup workshops for the poor, they endowed schools and universities teaching up-to-date science and technology.

The current crop of Christian evangelicals could not be more different from those charitable pioneers: they want to take rights away from homosexual couples, cheer when Muslims are discriminated against, and want science muzzled.

So here’s my challenge to any evangelical, fundamentalist Christian: What are you doing to make the world more free, to add to the body of human knowledge, to increase the prosperity of your fellow man?

I was going to write up a list of the differences between my three careers (optical engineering, writing, and programming) and post them here, but then I realized what all my differences had in common: they were changes in the way people thought of me.

As a NASA employee I was awe-inspiring, as a writer people envied me, and as a programmer I’m mundane but very very useful.

Is that all a career is to me? A set of other people’s opinions?

What I should talk about is what each career taught me.

How NASA showed me how much human engineering can accomplish, while humbling me by forcing me to realize that decades-long projects are too long for me.

Writing made me appreciate how hard it is to tell a good story, because my own efforts were far short of what I needed to keep steady writing work.

And programming took me back to my days learning BASIC on a Commodore-128, while schooling me in how hard it is to run a company, to compete with other businesses and succeed.

But I keep thinking that’s using the present to justify the past. What I’d like to know is: was I right to leave NASA, at the time I left it?

I’m reading Wil Wheaton’s Just a Geek, for two reasons: because I’ve enjoyed his blog, and wanted to check out more of his writing. And because I’m hoping he can help.

If you don’t already know, Just a Geek is Wil’s book about his shift from being “That Guy Who Used to be on Star Trek” to the writer, blogger, and all-around geek Wil Wheaton.

Here’s a guy who went from working on a show with millions of adoring fans, to being an out-of-work actor struggling with his bills, to a popular writer who’s given keynotes at PAX and has done hilarious cameos on The Guild and Big Bang Theory.

And here’s the thing: he quit Star Trek. He wasn’t fired, they didn’t replace him with someone else, he walked away. Walked away from certain success to an uncertain future. He writes about how that decision haunted him, like my decision’s been haunting me.

You see, I used to work at NASA. And not as a janitor or maintenance guy. I was an optical engineer, responsible for putting together instruments for the likes of the Hubble Space Telescope and the James Webb Space Telescope. I was paid really well to do really challenging work with brilliant people.

But I quit. Five years after I started working as a wide-eyed college kid, my wife and I picked up and moved to Arkansas, leaving all that behind.

And I’ve been wondering if I made the right decision ever since.

So I’m reading Just a Geek, hoping Wil’s story will help me feel better about my own past, that learning how he grew beyond working on and then leaving Star Trek will help me put my own demons to rest.

‘Cause some nights I still dream that I’m back there at the Goddard Space Flight Center, working to expand our knowledge of the universe.

Me: Hey, iPad! Mind if I install this cool KoboBooks app I’ve heard so much about?

iPad: Sure thing! Just gimme your iTunes password.

Me: I don’t have an iTunes account.

iPad: No account, no software.

Me: Ok…Let’s just fire up mail.google.com, so I can check my email.

iPad: Nope.

Me: No?! I can’t check my email?

iPad: Sure thing! Just enter your .Mac password…

Me: Screw this. I’m buying a netbook.