It comes down to asking “Why?”

December 17, 2018 Uncategorized No comments

It never ceases to amaze me how many things I’ve read, learned, and internalized that can be boiled down to simple, related concepts.

I started writing this blog post with the intent of talking about principles vs. rules. That comes up a lot when someone is asking me about the “proper” way to write a user story. I often simply tell them that user stories are just a reminder to have a conversation and that one of the agile principles is “…interactions over processes and tools.”

But that got me thinking of a conversation with somone that was unhappy about things in our coding standards. He’d heard a podcast give the opposite advice and, when he asked someone on the team about it, they responded “that’s been the rule since I started here.” Throughout the conversations that followed, I realized that neither of them knew the reason we implemented the rule: we felt it was better to have a standard than not, but didn’t really have an opinion on the details, so we just picked one from the internet. It meant the rule was open to change if someone made a compelling case for it.

All of that got me thinking about the emphasis we put on WHY comments (compared to WHAT), the phrase “strong opinions, held weakly” and the client request vs. implementation details.

Reflecting on all that, I’d put all of this under the umbrella of “asking why.” It is important to understand why you’re doing something, such as following a rule, building a feature, or trialing a new piece of software. That will give you the ability to ask smart questions, challenge assumptions, and ultimately proceed in the best way.

I Don’t Care

August 22, 2018 Management No comments

At a previous job, one of my management mentors always took umbrage when someone asked me a question and my response was “I don’t care.” It took me a bit to understand that, when he heard me say that, he understood it as “this isn’t important, why are you bothering me?” He’d remind me that I did care about the results of the decision.

Thinking about it again recently, I started to clarify the situations where I use that phrase as shorthand for what I really mean.

I Don’t Have a Strong Preference

I’ll often see developers get locked in a heated, extended debate over the best way to implement some feature. Often times, when I’m asked to weigh in as the “tiebreaker” I’ll ask each person how much they care about the decision. If one person is passionate and the other is only playing devil’s advocate, the person who cares a lot should move forward with their idea.

I Trust You to Handle the Details

As a manager, I shouldn’t be making day-to-day decisions about implementation details. If I ask one of my directs to write a job posting, I’m not effectively delegating if I then nitpick their output or require them to ask me specific questions about every bullet point. That doesn’t mean I don’t review their work — I just remember to ask myself “is this important to change or just my preference” before asking for revisions.

I Don’t Own This Decision

There are times when someone will ask me my opinion on something and I don’t want to give an answer because it isn’t my decision to make. I want to avoid people later saying “but Jon said we should…” when in was only spitballing. An example might be the best way to design a user experience for our newest app. I’m happy to brainstorm with the team, but the product owner is the ultimate decision maker and should be present.

Communication is about the listener. Sometimes you might use a terse, flippant-sounding phrase as a shortcut for what you really mean. Take the time to articulate; people will appreciate the insight.

Nobody Asked You: What books have you gifted the most often?

February 2, 2017 Nobody Asked You No comments

This post is part of a series where I answer questions frequently asked by interviewers on various podcasts or other medium. Although nobody asked me, I often find myself thinking about the answers.

What books have you gifted the most often?

This question comes up on almost every episode of Tim Ferriss’ podcast when he’s interviewing someone for the first time. It is an interesting question because I’ve recommended a lot of books to folk, typically in response to a specific question or goal they’re working on. But taking the initiative to gift the book to someone feels more like I’m saying they need to read it for one reason or another.

Clean Code by Robert C. Martin

At both my previous and current jobs, I’ve run book clubs that focused on this book. It has always led to great conversations around the various topics within. Even if the team doesn’t necessarily agree with a particular recommendation in the book, the discussion itself is worth it. It is essential that everyone is on the same page when it comes to topics like meaningful names, comments, and error handling.

You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.

Managing Humans by Michael Lopp

Unlike most management books, this one is specifically geared towards the software industry. And yet it still espouses the same basic principle: it’s all relationships and results. This book puts a humorous twist on many situations a new manager will encounter. The author’s software background makes the material relatable to those who were developers and are now transitioning to management.

My definition of a great manager is someone with whom you can make a connection no matter where you sit in the organization chart.

His Majesty’s Dragon by Naomi Novik

Naval dragons during the Napoleonic Wars. What else do you need to know?

Too Hard … Until It Wasn’t

January 19, 2017 Interviewing No comments

My team is always looking for ways to improve the interview process. We want to avoid the perils that come with whiteboard coding but still evaluate the candidate’s coding skills. Usually during the process, we come away with a clear “heck yeah!” or “no”. But occasionally we just can’t tell. After reading The One Method I’ve Used to Eliminate Bad Tech Hires, we decided to add a paid, take home exercise as part of the interview for these candidates.

We added this step last in the interview process. It seemed fairest to answer all the candidate’s questions about the company and the position before asking them to spend four hours (albeit paid) writing some code for us. Rather than trying to reinvent the wheel, we used the exercise from the article:

Create a single page app that lets me enter movies in my home movie collection, store them in offline storage and search through them. I want to search by Genre, Title & Actors.

We also made it clear to the candidate that we didn’t want them to force themselves to use the programming language, frameworks, or libraries that we do. We wanted to see their best work made with the tools they were comfortable with.

And for the first full year after we added this to our interview process, no one was able to complete the exercise and ultimately get hired. In most situations, they simply didn’t implement the functionality as requested. Other folks didn’t follow the technical requirements. One person went so far as to tell us that they couldn’t get their environment set up in four hours to even begin. We were starting to worry that the exercise was more flipism than anything else — we already knew we didn’t want to hire the candidate and were just using the exercise to back that up.

Then someone completed it.

Not only did they meet all the functional requirements, but they completed the “offline storage” technical piece in a way that it would be easy to refactor to use a database later. We hired them and they’ve quickly became a strong contributor to the team. They later asked what was the “trick” in the exercise because it seemed so simple.

There’s no trick. As I’ve previously discussed, some people have degrees or jobs in programming but simply can’t.

Too Easy … Until It Wasn’t

January 5, 2017 Interviewing One comment

Back when I started interviewing, I read many articles including Jeff Atwood’s describing the now ubiquitous FizzBuzz. My team and I all thought it would be a good thing to add to our interviews because the truth is always in the code, right?

I’ll be honest, the first ten or twenty times I asked a candidate to complete FizzBuzz during an interview, I felt sheepish about it. It seemed too easy and a bit like we were going through the motions. Sure, everyone has a slightly different approach and a few of them felt wrong, but everyone completed it. My colleagues and I began to question whether or not it was worth it. Were we learning anything about the candidates by having them complete it?

Then we ran into our first candidate that simply didn’t know where to start. He assured us that he understood the request but couldn’t see that a loop was the answer. And then it happened again. And again. The most notable example was from a candidate who was a referral. A member of our team recommended that we hire this person and yet they couldn’t complete FizzBuzz. We let the candidate take the code home and they ultimately still couldn’t send us a working example.

I’ve always tried to give people the benefit of the doubt in terms of nerves during an interview. This has grown into my general disdain of whiteboard programming. On a day to day basis, we all have time to consider a problem, write some throwaway code, Google a few ideas, and then implement a working solution. All without being judged every step of the way. This is why my current hiring process involves a small take-home coding exercise instead. It isn’t much more complicated than FizzBuzz and yet it continually manages to filter people out.

I highly recommend you include something like1 FizzBuzz in your technical interview process. It will be easy for most people. But when it filters someone out, you’ll be happy to have spent a few minutes up front.

1. FizzBuzz is too well-known now. I’ve had candidates tell me they learned it in school as part of interview prep. Additionally, if you use a popular example like Uncle Bob’s bowling kata, you’ll find that people will submit code copy and pasted from GitHub. Instead, write your own exercise and test it with members of your team. Code Golf is a good place to find inspiration.

Security Questions are Insecure

November 3, 2013 Security No comments

I’m sure it is an example of the Baader-Meinhof Phenomenon, but I’ve seen quite a few comments lately about people having their eBay, Facebook, or other online account “hacked” by their parents. One such example came from this month’s issue of Psychology Today:

One morning I woke to discover my bank account overdrawn by thousands of dollars. In a late-night shopaholic moment she’d hacked both my Paypal and Ebay accounts–easily answering my security questions like “in which hospital were you born?” and “what’s you mother’s maiden name?”—and bought more antique French dishes than we could ever eat off of.

As the author states, her accounts were compromised because common security questions are, inherently, things that other people know. We like to believe that the people who know this information about us won’t use it and that the “evil hacker” somewhere on the internet won’t have access to it. Neither of these things are true. You can only tell so many different websites your mother’s maiden name before one of them is hacked and that answer is forever associated with your email address.

How to Protect Yourself

  • Lie. As long as you can remember the answer, make one up.
  • Some websites allow you to set your own question. This is a simple solution, as you can pick a question and answer that is both unique to that site and limits the number of other people who know the answer. Just avoid picking question and answer combos that are from your favorite movie or TV show. Scripts are readily available online and easily Google-able.
  • Treat the answers to security questions like one more password. Select another strong password and use it instead of the real answer.

Use A Password Manager to Handle Security Questions
I’m a big advocate of using a password manager, like KeePass, to generate strong passwords and keep track of them. You can also use these programs to “answer” security questions and record your made up answers.

KeePass makes this easy with the “Advanced” tab attached to each entry. You click “Add” and then you’re able to enter any other values to keep track of. There’s even a option for “Enable in-memory protection” which treats the answer as sensitive and masks it out in the preview screen.

My high school mascot was really a walrus...

My high school mascot was really a walrus…

When I use this option to track my answers to security questions, I also use KeePass to generate the answer. This is as simple as clicking on “Tools” and then “Generate Password List” where a list of several secure answers will appear on the “Preview” tab. Some websites limit what you can type in the security answer, so you may need to generate a password without any special characters to use it as an answer.

Conclusion
Even if you are vigilant about choosing strong passwords, answering common security questions honestly can often weaken the safety of your online accounts. To protect yourself, treat security questions like one more password field. As always, this is made easier by using a password manager to generate and track your passwords.

New Gig, New Tools

May 12, 2013 Personal Updates No comments

I’m going to be temporarily putting my work with Seven Languages in Seven Weeks on hold so that I can explore some new PHP tools. I’ve accepted an offer at a new company, staring later this month, and want to devote some time to learning the tools they’ve picked out. For starters, we’ll be using Zend Framework 2 for the application that I’ll be focusing on.

I have experience with the original Zend Framework but, when ZF2 and Symfony 2 released, went the Symfony 2 route instead. Looking through the Getting Started with Zend Framework 2 tutorial, I see things that are similar to both frameworks that I’m familiar with. That’s one of the awesome things about the PHP-FIG: cross pollination.

I definitely intend to return to the exploration of new languages, but I want to be able to hit the ground running on this new project. Stay tuned.

Io, Io, it’s off to work we go

April 28, 2013 Languages No comments

The second language covered in Seven Languages in Seven Weeks is Io. If you’re like me and enjoy Googling for help learning a new language, this one is tough. The only real sources of information about Io seem to be the official website and answers to the questions raised in this very book. As of this writing, there’s only 39 questions tagged with “iolanguage” on StackOverflow (compare to Ruby’s 71,477).

That being said, Tate picked Io because he “struck JavaScript because it was too popular and replaced it with the next most popular prototype language…” He also indicated that he had a much stronger understanding of how JavaScript worked after learning Io.

One thing I struggled a bit with is that most commands in Io read backwards compared to what I’m used to from other languages, but not always.
# PHP
print "Hello, World!";
echo "Hello, World!";
# Io
"Hello, World!" print
write "Hello, World!"

In the first example, Io is sending the message print to the sequence “Hello, World” while, in the second example, the sequence is being passed to the write method as an argument. Loop constructs also can work from both sides.

# 0..9
for (i, 0, 9, i println)
10 repeat (i, i println)

Tate does spend a section talking about how Io is powerful when building a domain-specific language. Like Ruby, Io let’s you replace any built in functionality with new versions. For example, in one of the daily lessons, the book has you replace the built in division operator (“/”) with one that returns zero if the divisor is zero.

Overall, I felt that the real meat of this section was in the first lesson, while the other days were merely code exercises. I found this section severely lacking compared to the one on Ruby, which is Tate’s “native” language. I won’t know if that is a criticism of the book or just this section until I finish the next.

Ruby == Mary Poppins

March 31, 2013 Languages No comments

Prior to reading Seven Languages in Seven Weeks, my exposure to Ruby was very limited. In a “hands on” sense, my only experience was installing Graylog2, a log management package. It is written in Ruby and I needed to work with Rake to get it installed. This wasn’t hard as PHP’s Composer draws heavy inspiration from Rake.

Other than that, my knowledge of Ruby was what I gleaned from the occasional blog post that hit the front page of HN comparing PHP and Ruby. Most of them focus on syntax and how much less code you have to write in Ruby to accomplish the same thing.

Bruce A. Tate explains this as syntactic sugar, “those little features that break the basic rules of the language to give programmers a little friendlier experience and make the code a little easier to understand.” And, throughout this chapter, I was able to really see that mentality shine. From tools to easily list the methods available on an object, to the names of boolean methods ending with a question mark, it really felt like a language in which clean, readable code is easy to create.

I found all of the examples and self-study challenges easy to complete probably, in part, because Ruby is a loosely-typed, object-oriented language just like PHP. Thanks to their well-written API documents and StackOverflow, anything I needed to look up was easily found.

In the last few pages of the chapter, Tate touched on the weaknesses of the language. I knew that performance was a concern as, years ago, the Penny Arcade folks were bemoaning their Rails site. On top of that, I worry that Ruby might lend itself to easily creating “clever” code that’s hard to debug and change. Tate really emphasizes Ruby as a tool to get your product to market which lets you worry about scaling issues later; this was the case for Twitter, which started out as Ruby and then rewrote core parts of their application in Scala.

Seven Languages in Seven Weeks

March 23, 2013 Languages One comment

I always recommended Teach Yourself Programming in Ten Years to junior developers as a path to expand their skills. With some gentle prodding from a friend, I’ve decided that it’s time to take some of my own advice and focus on one of the recommendations from that article:

Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).

My professional work has been almost exclusively with PHP and JavaScript. I did a number of VB projects during school and there’s always a few tools you need to use or modify in other languages, but my experience with Ruby, Python and Perl doesn’t extend much beyond configuration, compiling and installation.

Recently I read through a good bit of Learn You a Haskell for a Great Good but I feel like I need a resource that’s more dedicated to teaching me what makes the language different and what it excels at, rather than an API reference guide. Enter Seven Languages in Seven Weeks by Bruce A. Tate.

I Will Take you Beyond Syntax
To really get into the head of a language designer, you’re going to have to be willing to go beyond the basic syntax. That means you’ll have to code something more than the typically “Hello, World” or even a Fibonacci series.

The book covers Ruby, Io, Prolog, Scala, Erlang, Clojure and Haskell which gives an amazing smattering of different typing and programming models. I’m really looking forward to working through the programming examples and challenges in the book.