Interview with a Rock Star – Stephen Haberman
This is the first in a series of posts, asking questions to experienced software developers in Omaha. Our first rock star is Stephen Haberman. Stephen leads the Omaha Java User Group and is the owner of Exigence, a custom software service provider. He started out building webpages as a hobby, graduated to content management systems, and now enterprise line of business applications. He enjoys both discussing and implementing high-quality software systems.
1. If you could only read 3 blogs/rss feeds, which ones would you choose?
HackerNews and Jonas Boner’s twitter feed (@jboner).
2. What’s your favorite development book?
Patterns of Enterprise Application Architecture and Domain Driven Design
3. What’s the best advice you’ve been given or would like to give to junior developers?
When starting out, find a job that will let you do lots of small, 2-4
month projects. You’ll get to try things, see what does and does not
work, and start over with a new codebase every few months. Enterprise
projects, while fun and challenging, don’t get to start over every 2-4
months, so they are not a good place to learn.
4. What’s the worst mistake you’ve made in development?
Not picking up automated testing sooner.
5. What common or accepted industry practice do you despise the most and why?
Dependency injection. It adds more complexity than it is worth.
(…just one?)
6. Do you think developers should be specialists or generalists and why?
I think it depends on their personality–both are needed.
7. What’s the future of software development?
I don’t know.
8. What’s one of the most effective questions for a job interview with a developer?
I don’t know about a question, but the most effective interview technique
I’ve seen is a pre-screening all applicants with a technology-specific,
~20-30 question test. It sounds impersonal, but it makes the interview
process much more bearable. Kudos to Justin Graver of PayFlex for
introducing me to this.
9. Are there any technologies, paradigms, or implementations you avoid and why?
COBOL. Other than that, I think most technologies have a niche they work
well in, assuming they are applied correctly.
10. What, if anything, is unique about how you approach a problem?
When discussing business problems with users, I like to start at the
scenario level. This means talking about a specific instance of a
business problem, e.g. “Bob adds Book ABC to his cart, checks out, has
$10 tax added, pays with Visa”.
Scenarios are eventually generalized into use cases, which have more of
the conditional logic that your code will implement. But, in my
experience, when the programmers and users are trying to get on the same
page and there is not a lot of shared understanding or shared language,
the high-level use cases are too much to communicate right away, so for
me it’s been easier to start with the lower-level details first.
I also like to start with the simplest scenario I can think of, and then
add slight variations on it, and get feedback from the users on each
variation. For example, start with “Book ABC and $10 tax”, ask the user
“Why $10″, “because Bob is from Utah”, then your next scenario is
“Okay, what if Bob was not from Utah”, and keep repeating like that.
Each of these scenarios that are flushed out and vetted by the business
users can also make great acceptance tests if someone is paying
attention and writing them down.
11. What’s the difference between a good developer and a great one?
Caring and attention to detail.
Having both doesn’t necessarily mean a programmer is great right now,
but it means they’ll find the techniques, practices, and experience to
become great.
12. If you could interview a developer who was far more experienced than you, what would you ask him/her?
Can I work on your next gig?