Resume Tip: Link to yoursite/github, not github.com/you

I look at dozens of tech resumes and StackOverflow Careers profiles a day and I’m glad that more of them have GitHub links with some code to look at. In 2011, I wrote that I thought tech applicant assessment should be more portfolio based. I described what I would be looking for as an interviewer — one point was:

I could use an orientation: I need a starting place. The bigger the project, the harder it will be to jump in and take a look around. Give me what you’d give a new contributor.

Now that I’ve been spending time in GitHub with the intent of understanding a developer, I can see that I need an overview of the whole repository. GitHub’s public profile isn’t customizable and doesn’t do a good job of describing a person’s contributions.

I recommend:

  1. Create a page with a simple URL on your own domain (e.g. example.com/github) and write a narrative that takes me through your repositories.
  2. Link to that page in your resume and in your GitHub profile.

What exactly you do on this page really depends on your specific contributions and what kinds of jobs you are applying to. I made a GitHub tour page to dogfood my own suggestion, but also because, as a consultant, I imagine that some prospective clients look at my GitHub. I decided that a reasonable organization of my page was (approximate) reverse chronological order, but that might not be right for you. If you have a particularly popular project, you probably want that at the top. If you are looking to get a job in a specific technology, you should highlight contributions using it. Most importantly, edit the list down to what someone should look at.

Another benefit of this page is that I can mix-in the non-open source parts of projects. For example, App-o-Mat is not open source, but the app template is, so I can highlight a project that you can’t even see very well on my personal GitHub page. I can also describe a contribution where the code isn’t very interesting, but context is.

Whatever your contributions, I am sure that your own organization of them will be a lot better than GitHub’s default.

Test First as a Habit

I am not a TDD zealot (or even really a practitioner), but on The App Guy podcast, Paul Kemp asked me if I had any habits to share as an app developer.  I said:

My app developing habit … is get a new passing unit test every day.  [...] that new green dot is my indication that I’ve at least added a little bit to the application.

This is a habit I started in earnest when I took B. J. Fogg’s Tiny Habits course. My tiny habit was to just run the simulator, and the best way I found of doing that was to run the tests through it. Then, writing a new test for whatever functionality I was planning next just seemed to be the perfect way to extend it.

Once I write that first test, I don’t TDD the rest of the way, but I’ve found that first test to be a good way to warm up.

Happy New Year – Favorite “Resolution” Posts

My own thinking on goals has evolved over the years to:

  1. Prefer forming processes to outcomes.
  2. Keep it simple (one physical, one mental and one social/spiritual)
  3. Monthly reassessment

So, given that, here are the two best things I read this New Year’s about resolutions:

Buster Benson’s Make Better Resolutions ends with this wonderful template:

Cultivate new or existing relationships with people who I can share my strongest interests with by doing X

My mental goal this year is to do 20 minutes of Duolingo Spanish practice every day. Per Ramit Sethi, I started 3 weeks ago.

The second “resolutions” piece I recommend is James Clear’s Forget Setting Goals. Focus on this Instead, which is a perfect introduction on why to prefer systems to outcomes.

I usually focus my physical goal around working out, but after 2.5 years of crossfit, working out is such a part of my routine, that I don’t really need to worry about stopping. This year will be about eating better, and for January I joined in our gym’s Whole 30 challenge (this is both social and physical). I will reassess in a month.

Working with both Xcode 5 and Xcode 4.6.x

You can have both versions of Xcode on a machine simultaneously.

Here’s what I did

  1. I installed Xcode5 normally
  2. I downloaded Xcode 4.6.3 from the Apple developer website and copied that into my Applications folder as Xcode_4_6.app
  3. I downloaded the iPhone/iPad iOS 7.0.2 ipsw’s from the developer website and loaded them into the 4.6.3 Organizer (Devices -> Library -> Software Images).
  4. In order to get Xcode 4.6.3 to see an iOS 7 device, you need to start Xcode 5, load a project so that it connects to the phone, and then exit Xcode 5 and start Xcode 4.6.3,  You periodically need to do this again (probably whenever you restart Xcode, but not every time you plug in the phone)

One annoyance is that both versions share Recent Projects and will automatically open projects that are open in the other one.  It’s usually best to only start one if the other is closed or doesn’t have any projects open.

I also read on StackOverflow that you can get Xcode 5 to create iOS6 apps by making a symbolic link from inside the Xcode 4.6.x app bundle to inside the Xcode 5 app bundle.

3 Tips for Making Sure an Ad Hoc iOS Build Will Work

If you build iOS apps and send the IPA to others to install, there are a few simple checks you can do before you send it that will make sure it will work.

  1. Go into your Build Settings and set the “Validate Built Product” to Yes — that way you won’t be able to build if your provisions are wrong. This is the default for new projects in recent versions of Xcode, but check it to make sure.
  2. Open the IPA that was created. It’s a bundle, so copy and rename the extension to .zip. Then look for the mobileprovision XML file.  You should see the device UDID that you intend to send it to.
  3. Always increase the version # of any build that leaves your machine.  If you don’t do this, iPhone Utility or anything else can decide to offer a cached version instead. If you have a good place in your app to show the version, do it.

If #1 above causes you not to be able to build, then use Apple’s Provisioning Troubleshooting guide.

If the device isn’t listed in the mobileprovision file, then make sure it’s added to the provision in developer.apple.com’s certificate area.  Regenerate it and download it once it’s right.

Even if you are using a system like TestFlight, you should follow these tips. TestFlight can’t make an invalid app work, and it can’t fix an IPA that doesn’t have all of the device UDIDs in it.  All it does is automate over-the-air IPA installs (which is great), but it still operates within the confines of the app distribution system.

Communicating Salary in Job Postings

This is part of my continuing series on applying Jobs-To-Be-Done product design theory to the problem of recruiting. In my first installment, I explained the concept and gave some idea of applying JTBD to recruiting would mean:

In their workshops, Bob and Chris teach how to find out why people switch from one product to another by interviewing people that have done it already. How many of us have interviewed our recent hires to find out why they switched from their old job to ours, how they found out about it, what happened in their lives to cause them to want to switch jobs? If we did that, I think we’d find that we’re advertising in the wrong places, not emphasizing the right strengths, and generally not making the applicants know that we meet their hiring criteria.

Next, I wrote about the problem of hiring passively looking developers, where the key question I addressed was: “What would you do to your recruiting efforts if you wanted to hire people that aren’t looking for a job?”

Following along that vein, and again, using JTBD techniques, let’s talk about “progress making”. Essentially, people switch (products, jobs, houses, etc) because they are trying to make progress in their lives. In order to design products that make people switch to them, we need to know what kind of progress our users are trying to make.

In this case, it’s pretty uncontroversial to say that our potential applicants are looking to make progress in their compensation, or, if they are willing to trade that against other things, they have a lower limit.

Salary, for a potential job switcher, hits all of the forces of progress making.

  • They are pushed toward switching by the feeling that their current job doesn’t value them enough;
  • they are pulled toward switching by a job that pays more;
  • they are pulled back from switching by familiarity with their current pay structure and raise schedule;
  • they are pushed away from switching by anxiety that other jobs won’t pay as well (or have less potential for future salary growth).

Dissatisfaction, aspiration, allegiance, and anxiety: to get someone to switch we need to address all of these, and increase the first two while lowering the other two. (learn more about the forces from JTBD Radio).

Our potential applicants have total knowledge of their current salary, so to help people realize they will make progress, they need to know what we are offering. For the passive looker, who is not willing to invest much in each opportunity, the risk of early filtering is high. The unknown feeds the anxiety component and does nothing to drive aspiration (the two forces our offer directly controls), so they won’t associate “progress making” with your job description.

[ASIDE: I know why we don't list salary in job postings, but I would say that whatever those reasons are need to be balanced against wanting to make our job attractive to top developers, which we believe are not actively looking for a job. So, if we accomplish "having a good starting point for negotiation", but not "attract top developers to applying for our job", we failed.]

To alleviate anxiety about your offer, I would try social proof, a lossy communication channel, or possibly a transparent salary ladder.

For social proof, get candidates via referrals from your employees. People will make a judgement about your salary scale based on what they know about their contact.

By lossy communication channel, I mean a way to communicate salary possibilities such that the candidate gets an idea, but knows that it might be wrong and doesn’t interpret it as an offer. One way to do this is with a 3rd party recruiter — you give them a range, and they will leak it to the applicant, who will have skepticism for anything a recruiter tells them. You could try 3rd party ads that “estimate” a salary or write up truthful descriptions in something like GlassDoor or other salary reporting places.  No one thinks those are definite, but at this point, they just need some idea.

A third option is to have total transparency and a completely non-negotiable salary ladder. This is what union and government jobs do (so it has a bad rap), but I’ve seen tech companies try it — here’s a really old post from Joel Spolsky about Fog Creek’s compensation and here’s a very recent article about Buffer’s compensation policy. Both use a formula based on mostly objective criteria.

Your goal is to throw something out there to alleviate anxiety enough to get them to contact you.

Addvertisements

You rarely see an ad that is so good that it would be missed if it was removed. It’s not easy, but if you want to shake things up a little, look at one of the publications you advertise in and think about what it’s missing, then buy space and add it.

My favorite example of this is the PC-Lint “Bug of the Month” ads that ran in Dr. Dobbs and C++ Report. These were essentially the puzzle section of these magazines, and I used to spend time engaging with the ad each month. Solving the puzzle gave you a visceral understanding of what the product did.

You have to be careful. The other way you see this tactic being used is to make fake content that tries to trick the reader into thinking they are reading another article. I never think it’s a good idea to start off a relationship with such a blatant lie.

The better way is to be clearly an ad, but still have compelling content.

Some ideas

  1. Puzzles, like PC-Lint did. The trick here is that solving the puzzle should be a little like using the product. Just putting a Sudoku in your ad space probably isn’t going to cut it.
  2. Comics. For example: SourceGear ran a serial comic a few years ago.
  3. Pure educational content — don’t make it look like the publication, instead make it the text of your first auto-responder. It should deliver value
  4. Information. I’d look to Kinvey’s Backend-as-a-Service ecosystem map — I don’t know if they advertise it, but if they did, I would probably tear it out. If it was updated more often, I’d eagerly await the magazine it was in to get an updated copy.

The key is that it should add value to the content it’s delivered in. Hence: the addvertisement.

No Pixel Left Behind

I’ve been running iOS7 for a few weeks now as I refresh the look of my apps.  Habits is kind of getting there, but I’m trying to internalize the design lessons of iOS7.  Basically, my mantra is, “no pixel left behind”, which means

  1. If I can change the color of a pixel with no loss of semantic meaning, make it the background color
  2. If I can add meaning with space and grouping, do it, and remove more pixels
  3. If I can add meaning with color, do it
  4. It’s ok to have “brand” colors, but use them only when you need contrast

Here are some other lessons

  1. Prefer to reveal more UI rather than navigate
  2. Make gestures feel like they are moving a physical object (e.g. use pan instead of swipe)
  3. Prefer fewer words, but use enough to not be distracting

Habits 2.02 should be ready in a week with these lessons applied.

The 0-Liner

If you want to show off the power of your programming language, nothing works better than a cool one-liner (or even better, a code tweet).

I have to program in a few different languages, of varying degrees of power, and one thing you start to notice is the 0-liners — the code that just doesn’t exist.

An obvious example is how garbage collection (or ARC) gets rid of memory management. Here are a few more examples:

In Objective-C, nil sinks messages. This means that in a lot of cases, you don’t have to check for nil and “the right thing” happens automatically.  If you send nil a message, it’s a no-op, and if you need a return, you get 0 for scalars, nil for objects, 0-filled structs, and undefined for anything else. You still consider the nil case, but you usually don’t need to write any code.

This is a real example of a language completely implementing a design-pattern, in this case Null-Object. You can get similar behavior by using this pattern. Clojure does even better by letting you implement a protocol on nil to provide implementations for its functions called with nil. But, neither of those are 0-liners.

I don’t use F# (or Scala), but my understanding is that when Some/None discriminated unions are used in computation expressions, the computation will end and return None if some part of the expression returns None.  This is a classic 0-liner, if I’m right.

async in C#/F# (and go blocks in clojure’s core.async and go) rewrite sequential looking code to actually be asynchronous with callbacks.  Miguel de Icaza covered this recently in his post, Callbacks as our Generation’s Go To Statement.

Just like in the Go To days, or the days of manual memory management, we are turning into glorified accountants. Check every code path for the proper state to be properly reset, updated, disposed, released.

In this case, only go and clojure are true 0-liners, as you still need the await keyword in C# (and let! etc in F#) to indicate a blocking call.

clojure’s BigInt contagiousness turns your overflow checks into 0-liners. If this is a possibility in your integer algorithms, it’s worse than null checks.

What’s your favorite 0-liner? The nice thing about them is that they don’t use up any of your 140 characters in a tweet.