rc3.org

Strong opinions, weakly held

Month: September 2012 (page 2 of 2)

MG Seigler on the Apple difference

Apple’s Magic Is In The Turn, Not The Prestige

MG Siegler’s explanation of what makes the iPhone an extraordinary product. Put me in the group of people who thinks there’s an elegance to the fact that the new iPhone always looks a lot like the one you already have, but is better in many substantial ways. You get this massively different product that looks almost the same on the outside. I appreciate that.

Nothing comes to my desk that is perfectly solvable. Otherwise, someone else would have solved it. So you wind up dealing with probabilities. Any given decision you make you’ll wind up with a 30 to 40 percent chance that it isn’t going to work. You have to own that and feel comfortable with the way you made the decision. You can’t be paralyzed by the fact that it might not work out.

Barack Obama explaining what it is to be President to Michael Lewis. His predecessor put it less articulately and more succinctly when he said, “I’m the decider.”

RIP William Moggridge

William Moggridge, 69, Dies

Moggridge designed the first laptop computer and co-founded IDEO. He was also director of the Cooper-Hewitt National Design Museum, which has posted a tribute.

Coming from a background in higher-level languages like Ruby, Scheme, or Haskell, learning C can be challenging. In addition to having to wrestle with C’s lower-level features like manual memory management and pointers, you have to make do without a REPL. Once you get used to exploratory programming in a REPL, having to deal with the write-compile-run loop is a bit of a bummer.

From Alan O’Donnell’s article, Learning C with GDB. What I take away from this is that I’m not using REPLs nearly enough, especially when I’m learning new things.

Valve’s corporate culture makes the New York Times

Valve, a Video Game Maker With Few Rules

Valve gets a big feature in the New York Times. Unfortunately the article doesn’t really dig into discrepancies between the employee handbook and day-to-day life at the company. Maybe there aren’t very many, but it would be interesting to know.

Learning a language by porting from it

I’ve been experimenting with a new approach to learning a programming language — porting code from a language I don’t know to one that I already do. In this case, I’m porting Scala code to Java.

The traditional method of learning a language is to find a project and start writing code in the new language, and I’ve used it many times in the past. In this case, I’m trying to get up to speed on an existing code base written in Scala so that I can help maintain and extend it. Part of the work is learning how to write Scala, and part of it is becoming familiar with the structure and style of this code base.

I’m finding it works really well. You can’t successfully port code to another language unless your really understand how it works, and you have to learn the language to get there. In the worst case, if I port everything and I still don’t know Scala, we can just use the ported code.

You should always submit a cover letter

I look at a lot of job applications submitted via the Web and I am consistently surprised by the number of applications that I see that don’t include cover letters. The thing is, I also know a lot of people who never read cover letters when they’re processing job applications. When you skip the cover letter, you take your chances.

Here are some of the things I wonder about when I see an application that doesn’t include a personalized cover letter:

Are you applying to so many jobs that you can’t be bothered to write cover letters? We want people who want to work with us specifically. Giving me the idea that you want “a job” rather than this job does not put you on good footing.

If your résumé seems oddly suited to the role, I usually assume that you didn’t actually read the job description. You can clear that sort of thing up in the cover letter.

If your résumé is not really well written, I assume that you didn’t include a cover letter because you’re not good at communicating in writing. I put a high value on the ability to communicate in writing.

The final thing I may assume is that you just didn’t care enough to bother with the cover letter. You were provided with the opportunity to do a little extra work on the application and you skipped it. In my mind, this reflects poorly on an applicant.

When I look at an application, I look for the cover letter first. What I’m looking for is an explanation of why you’re interested in the job and how your skills map to the requirements in the job description. A paragraph or two will do. This is also your opportunity to convey your passion about the company, the work, or both.

Leaving out the cover letter requires me to use my imagination when it comes to mapping your experience to the job requirements. If that’s a no brainer, you may be able to get by with skipping it, although I don’t recommend it. If I’m looking for someone to do PHP development on a high traffic Web site and your previous job was at Yahoo doing PHP development on a high traffic Web site, you may not need a cover letter. I can figure that out. If your previous job was doing Ruby on Rails development on an academic project, more imagination is required on my part. Why leave it up to my imagination?

The cover letter is one of the only opportunities you’ll get to provide information to help make the hiring decision. Unless you customize your résumé for each job, it’s the only shot you get to tell me exactly what you want about yourself. I don’t particularly like to phone screen people. Before I schedule a phone screen, I’m going to go on the Web and look at your LinkedIn Profile if I can find it, your GitHub account if you have one, and anything else that comes up in the first few pages of a Google search.

One other benefit of writing a cover letter is that it gives you the opportunity to do some sales, by way of explaining where you are in your job search. Let’s say that your résumé is an obvious perfect fit for the job requirements. If you’re already interviewing for jobs, including that fact will likely get your résumé handled with more urgency. Indicating that you’re happy with your job but you are really interested in this job in particular can be flattering as well. This is not an opportunity the job seeker should pass on. I write this as someone who’s reviewing résumés because I appreciate it when people are thoughtful about what they’re doing.

Greg Knauss talks about health insurance

Bugged

How a bug bite led to a $28,300 medical bill. As Greg Knauss relates, anyone without health insurance faces a daily risk of total ruin. Seems pertinent given the upcoming election.

Keeping a journal to fight creeping determinism

One of the most interesting practices at Etsy is the use of blameless postmortems to learn from mistakes and create processes that prevent them from being repeated. If I could take only one thing from Etsy and implement in other organizations, it would be the concept of a Just Culture:

Having a Just Culture means that you’re making effort to balance safety and accountability. It means that by investigating mistakes in a way that focuses on the situational aspects of a failure’s mechanism and the decision-making process of individuals proximate to the failure, an organization can come out safer than it would normally be if it had simply punished the actors involved as a remediation.

One of the most important aspect of the blameless postmortem process is that it’s an effort to overcome hindsight bias. When we look back on past mistakes, it’s all to easy to make the mistake of thinking that the information we have now is the information we had when the mistake occurred. This makes it extremely difficult to analyze the mistake and prevent similar mistakes in the future.

A big part of a postmortem is constructing a timeline of what happened. When you get to the moment when the mistake occurred, the person whose action caused the mistake is asked to think back and remember exactly what they expected to happen at the time the mistake was made, so that the gap between the expected outcome and the actual outcome can be revealed and the organization can work on preventing it in the future. The key is focusing on what information was available at the time of the incident.

Lately I’ve been trying to keep a journal of the decisions I’ve made at work and what they were based on, with the thought that when I’m trying to evaluate the quality of those decisions in the future, I’ll be able to go back and see what the rationale was at the time. When you look back three months or six months on a decision you made, it’s easy to forget what information you based that decision on, so I’m trying to write it down.

Not only do I often have to explain decisions I made to other people, but I also have to review them for my own good. We’ll see if the journal helps out.

Stripe CTF 2.0 walkthrough

Stripe CTF 2.0 walkthrough

I really regret not trying it out, a number of my coworkers were pretty obsessed with it.

Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑