Author Archives: Lou Franco

My next ten hours with Light Table

While reading Clojure Programming, I have been using Light Table as my repl for cementing my understanding. This is somewhat torturous, but one of the reasons I am using Clojure at all is because I want to ride the Light Table development wave — I think of it as an investment.

The big win with Light Table is the Instarepl — this is a repl editor tab where your code is continuously run and the values going through your functions are shown inline with your code. The first part of this video shows it in action:

[youtube_sc url=PsVJJp1XnzQ width=430]

My goal was to internalize the functional implementation of the Wilson Maze Algorithm and then to recreate it. Then, I implemented a maze solver (opting for a straight-forward recursion rather than the zipper-based solution from the book)

In both projects, the Instarepl-enabled iteration cycle let me explore a lot more than I might have otherwise. I was still learning during the maze-generation phase, so it still took a long time to get through it. By the time I was writing a solver, I was getting used to the language and its core functions, so that progressed very quickly.

The Instarepl is so powerful for learning that I have resisted installing a “better” clojure IDE.

 

My first three hours with Light Table

Last night I decided to bite the bullet and start to re-learn clojure with the intention of adopting it as my web stack for personal projects. I had been curious about Light Table, so I started there.

If you haven’t heard of Light Table, it’s a new IDE concept that is best seen rather than explained:

[vimeo clip_id="40281991"]

Soon after this video, they raised money from KickStarter and YCombinator, and now we’re starting to see some progress. v0.2.0 was released earlier this month.

Light Table is really rough right now — you can see the potential, and it’s totally not fair to judge it now, but here are my quick reactions (I’m totally ignoring all buggy behavior, as that’s very expected):

The Rough

  1. It’s somewhat unfriendly to start with if you already aren’t working on a clojure project. After a few minutes, I realized I really needed to get Leiningen working first, generate out a project, then use Light Table on the generated files.
  2. The app is not signed, which Mountain Lion complains about — not a huge deal, but look at their website — they are projecting a nice brand and attention to details — getting this warning makes me think “side-project”. It’s easy to fix.
  3. Error messages comes up in a pane that isn’t resizable and not big enough. With how good Light Table looks, this pane is out of place, and makes using it on something real very frustrating.
  4. It’s slow in ways that are unexpected (like saving a file)

The Polished

  1. Keyboard-oriented commands
  2. Surprisingly good text-editing
  3. The instarepl integration is slick — as is the in-editor form evaluation
  4. Very nice looking — which is part of the reason I’m picky on the more rough parts.

In the end, it was Light Table that gave me the push to go back into clojure, but I wonder if I can stick with it. The other options are worse (for me) — I can’t imagine using Eclipse, I don’t know Emacs, and the simpler editors don’t have any repl integration.

Top two reasonable feature requests

  1. Let me highlight a form and execute it
  2. Some better way to show errors (probably don’t try to put it off to the side right now)

Bias towards shipping

A few weeks ago a colleague said that I had one of the stronger biases towards shipping that he had seen. I am pretty sure he meant it as a compliment, and I took it that way anyway. In my work, I am highly influenced by the Steve Jobs quote, “Real artists ship”, and I often say that our work as product developers is to ship and get better at shipping.

That being said, it’s sometimes hard for me to remember that in my personal projects. Back in January, I started an iPhone app to help me stay motivated to stick to the Paleo diet. I blogged about that back then, and said:

I’ve been working on a way to do this (mostly to scratch my own itch), and will have more to say on that soon.

My plan was to ship in April. But, a trip to New Zealand and my duties at work left me with less time to devote to it. The project languished from March to about a week or two ago when I got a message from Apple that my right to the name PaleoViz would be revoked if I didn’t submit a binary.

With that kick in the pants, I went into full ship mode. Removing features, fixing bugs, finding what I hope are elegant solutions to thorny user interaction problems. The biggest decision I made in the bias to ship was to abandon having my own online photo sharing and am just using Twitter for that (for now). PaleoViz was reduced to its essence — a photo food journal app for paleo dieters.

I expect it to be approved by the end of August, if you are a paleo blogger and want a review copy, let me know.

Interview question advice: What’s the difference between an interface and an abstract class

I met a recent CS graduate last week who was wondering the right way to answer “What’s the difference between an abstract class and an interface”. In his case, the question was in a Java context, but this applies to C# (and other .NET languages).

Here are the keys to answering a question like this:

1. You need to actually know the correct and complete technical answer

I’m not going to get into a detailed analysis of the difference. There are a few StackOverflow answers that are worth reading if you don’t understand. I will say that this question is fairly basic, and if you don’t have a firm grasp of the answer, you should do more than just read some websites — write code that uses interfaces and abstract classes and really try to internalize the difference. Look at examples of both in the standard library and think about the difference it would make if an interface was changed to an abstract class or vice versa.

2. Understand why the interviewer is asking the question

If I ask this question, it’s usually during a pre-screen. Since I believe the question is basic, I just want to make sure that the candidate meets a minimum qualification to be asked hard questions. Given that, I expect a fairly quick and smooth delivery of the answer. I never need perfection, but I don’t expect much struggling with this concept.

But, the real reason I ask questions like this is to see how the candidate explains technical concepts. I want to see that they know how to organize their thoughts and express themselves clearly. Nearly every programming job ad says something about spoken and written communication being important; it’s on the interview that you show that you have this skill.

3. Be able answer beyond the basics

You should know the mechanical differences like syntax and limitations of each, but if you stop there, you have only given a minimally correct answer.

A better answer follows this basic recipe

  1. Explain how they are the same (differences are only interesting if there are similarities)
  2. Explain the mechanical differences
  3. Explain when one is better than the other — then explain when the other is better
  4. Give concrete examples from your work or the standard library. Pick an example where the choice isn’t obvious, and work in your best project.

By the way, this works for any “What’s the difference …?” question.

Blogging follows doing

This year when I set my goals, I added in a monthly renewal on the last weekend of each month to reflect on how I was doing. I just completed one a few days ago.

On my physical goals related to diet and exercise, I am doing fine. My social goals like volunteering are also doing well. But, I am having a big problem on my goals related blogging/writing and personal programming projects.

I thought it would be easy to just write a blog entry to get out of the rut. When that failed, I thought, “start small — start with a tweet”. Even that was kind of difficult — I didn’t feel I had anything to write about. I could always tweet a new job opportunity in Western Mass. or link a jobs-to-be-done article, but in terms of an original tweet, I had nothing.

Looking over my previous non-linking, non-retweets, I did see a pattern — if I actually did something interesting, I usually had something to say about it. Armed with that, I decided to just tackle a couple of easy projects — the latest was upgrading my harddrive, which was worth a tweet shoutout to iFixit.

None of these things are worth a blog entry, so I have to get cracking on bigger things. The key for me is that I don’t think it’s worth opening up my CMS to blog until I have done something on one of my personal projects.

The other takeaway is that forcing myself to do some monthly reflection on my goals helped me to get out of a rut, so that’s something that has to stay.

What I look for when I hire

I recently wrote this in an e-mail to an ex-colleague who was looking for advice on hiring:

Here’s what I look for when I hire:

#1: I worked with them before and I know them to be great
#2: Someone I trust (who is a #1 for me) says they are a #1 for them (worked with them and says they are great).

After that, it’s been luck — I’ve actually been thinking about this a lot lately — getting a little better

Here’s what I look for:

  1. They must program on the interview — I don’t care which language, but I want to see something.
  2. I want to see evidence that they have set and met long-term goals — ones that take perseverance — not just ones that are what they are paid to do for work, but something that augments that (or even something unrelated). So, leading and completing a big work project is not what I am looking for, exactly, because you don’t have a choice to do or finish them, and there are rewards all along the way (your paycheck)
  3. Along those lines — self-improvement — learns about new tech, languages, etc. Tries to build things on their own.
  4. Community involvement — could be twitter, a blog, going to dev groups or even stuff totally unrelated to tech (volunteering, etc) — if not, it’s nice if they have broader interests (music, art, etc). There are a lot of user-generated content outlets out there (StackOverflow, CodeProject, GitHub, FooCamps etc. — do they contribute to any of them)
  5. Some evidence that they read our company’s website, the blogs of our employees, twitter feeds, etc. I can’t understand why people don’t prepare for interviews — but I take it to mean that they don’t prepare for anything.
  6. Must be able to write — I want a nice cover letter that is a convincing argument for why I should hire them.
  7. Some evidence that they care about their work and are self-critical
  8. They must be experts in something — I don’t care what it is, but whatever it is that they are doing, they must know it deeply. If they have been web-programmers for 5 years, I should be able to ask any question I want to about HTTP life-cycle, JavaScript debugging, etc. They can’t have total blanks on the core stuff they are supposed to know.
  9. For very entry-level, I teach them something simple in one context, and then later ask questions where they need to apply that knowledge.
  10. They must explain things to me that I don’t know, and I have to be able to understand it.
  11. I’m looking for go-getters — so, I like people that reach out to me (I am easy to find) — that follow up after interviews — do more than what is expected in the interview process.

GPL for Portfolio Pieces

On my Atalasoft blog I wrote that I thought programming job applications should become more portfolio oriented, and

that means working code that I can run, and access to all of it. Probably the best thing is a running website and a github repository. If the software is hard to run, then a video walkthrough or screenshots are acceptable substitutes.

To learn more about what I want this to be like, I am starting to prepare a portfolio for myself.

One issue is that it’s important to decide what license to apply to it. If you don’t decide, then the default license is all rights are reserved, and the code isn’t very usable by anyone else. Since this code is meant just to show others what I’ve written, I guess it could be ok, but I actually don’t mind others using the code.

Another issue is that I intend to post code for projects that will be for sale (iPhone apps). If I put a permissive license, like BSD or MIT on it, then I run the risk of anyone being able to compete with me with my code and my permission.  But, not open sourcing real code would be against the whole point of making a portfolio. Fake code doesn’t represent programmers well.

I think Zed Shaw has the right idea about using GPL, not so much the why, but in what ways GPL helps authors.

Using GPL, I get these benefits

  1. Use of the code requires attribution
  2. You can’t put GPL code in the App Store
  3. I can still grant BSD licenses on a case by case basis, and perhaps only on portions. To do so requires the developer to get in touch with me
  4. Likewise, I can still choose to sell or give away commercial licenses, if I am contacted.

To me, github and the entire idea of a portfolio is to make code more social. GPL helps maximize that.

Take a Picture of What You Eat

I recently discovered Time Management Ninja, and love the tips on it. A post from last month was about how taking photos can improve productivity:

Photos capture information that you cannot get via written notes. Taking pictures of an object or a document can provide more insight that simple notes.

The important thing is the ease of capture. Taking a photo is so easy that you’ll actually do it.

I just started keeping a fairly detailed food journal on paper. I have tried to do this on phones before, but they are just way too slow — even though the apps have access to tons of nutritional data, I really didn’t care about that — I just want to know a few things, like what it was, how much I had, and basically how healthy was it. A picture pretty much gives me the first two instantly, then I want to just tap a rating.

And, it’s effective. In 4-Hour Body, Tim Ferriss [1] cites a study that looked at photo food diaries:

Dr. Lydia Zepeda and David Deal of the University of Wisconsin–Madison enlisted 43 subjects to photograph all of their meals or snacks prior to eating. Unlike food diaries, which require time-consuming entries often written long after eating, the photographs acted as an instantaneous intervention and forced people to consider their choices before the damage was done. In the words of one participant: “I was less likely to have a jumbo bag of M&Ms. It curbed my choices. It didn’t alter them completely, but who wants to take a photo of a jumbo bag of M&Ms?”

The researchers concluded that photographs are more effective than written food diaries. This is saying something, as prior studies had confirmed that subjects who use food diaries lose three times as much weight as those who don’t.

I’ve been working on a way to do this (mostly to scratch my own itch), and will have more to say on that soon.

[1] Ferriss, Timothy (2010-12-14). The 4-Hour Body (p. 60). Crown Archetype. Kindle Edition.

Systems not Tactics

Today I was reminded about why I find Ramit Sethi personally motivating:

What you are seeing here is the game being played around you. Clueless people look at random tactics. They jump on the fad diet, the shiny budgeting software, the fanciest productivity tool. Smart people see behind it and realize any individual tactic is just a random tactic — but the SYSTEM of testing different approaches is profoundly important.

A lot of what he writes about is not just learning some technique, but implementing an automated system that forces you to apply something positive (even if not ideal).

For example, the video in the post explains how having a personal trainer forced him to meet his fitness goals because the cost meant that he would never miss an appointment, and the trainer’s advice was clearly better than him winging it. In his financial advice book, I Will Teach You to be Rich, he showed how to use automated savings and investment tools to make sure you save. Automating will beat your best intentions every time.

This resonates with me because, as a programmer, automating is second nature, but coming up with ways to automate your life are hard. Some things that worked for me:

  • CrossFit — It’s cheaper than a personal trainer, but not cheap. The payment is automated, so it motivates me to go, and the results have been amazing. Like a personal trainer, the workout regimen is also automated — just show up and do what they tell you.
  • Food Journaling with consequences— At my CrossFit box, I joined a club where we have to food journal or get punished with hard exercises. We also agreed to eat well, but journaling is the part that makes me stick to it, because we have to show our journal at the meeting. Sometimes I just pre-write the whole day in the morning, and just follow it — then my eating is automated — I can’t snack, because I didn’t write it down. Also, the meeting is automated, and the members hold me to my commitments.
  • (total self promotion) My iPhone app, Habits –It helps me remember to do some simple things like call my mom more regularly. I also useTraxItAll to track progress towards my goals. Finally, idonethis.com automatically sends me an email each day to ask me what I got done — I now have a nice calendar where I can see each day’s accomplishments.
  • Putting planning activities on my calendar — I made it a 2012 goal to spend time on the last weekend of each month to plan out the next. I put these dates in my calendar as if they are meetings, so I don’t schedule anything else.

Unlike a computer, we aren’t forced to follow our programs, but figuring out ways to automatically generating feedback, reminders, and motivation will help you stick to your plan.

Job seeking advice from a 16 year old

A couple of weeks ago I called my “little brother” Josh for his birthday (we’re in BB/BS). “Guess what I got,” he said, “a job at Big-Y”

His sixteenth birthday was the first day that he was eligible to work, so it’s pretty amazing that he (1) got his working papers already and then (2) actually got a job. It’s tough out there for young job seekers (not to mention everyone else), so Josh must have been lucky or connected.

Not exactly.

Josh has been really determined to get a job. So much so, that he went to Big-Y a few months ago and filled out an application even though he wasn’t qualified yet. He has an awesome resume, so the manager told him to come back when he turned sixteen.

“What?” you must be thinking, “How does he have an awesome resume? I thought you said that he couldn’t work”

Sure, he couldn’t work, but he could volunteer. Josh has been volunteering hundreds of hours a year since he was 11. He has served food at the community center, worked parades as a junior Lion cub, helped out at the local Food Pantry, was a member of his high school’s Key Club, and we have done a few BB/BS volunteer activities together — last month we helped artisans move in their wares for the BB/BS Annual Winter Craft Fair.

I asked him why he volunteers so much, and he said that he had a blast, met great people, and wanted to get used to working several hours a week for when he was able to get a job.

If you know any teenagers who aren’t old enough to work, but will want to when they can, you might want to share Josh’s advice. I told him he should teach a class.