Ted’s Rants and Raves by Ted M. Young

After I wrote yesterday’s blog, I knew I’d forgotten something, but forgot what it was that I actually forgot (I believe that’s first-order forgetting). Now I remembered (actually I remembered during this morning’s run): questions. Not my questions (as the interviewer), but your questions (as the candidate). Maybe it’s inexperience, but since we (Guidewire Software; we’re hiring! — plug, plug) have mainly been hiring senior (as in experienced and skilled, not older) people, I’m amazed that I don’t get asked in-depth questions about our development process, or even about the day-in-the-life of an employee at my company. After all, you should be interviewing the company just as much as they’re interviewing you. After all, you can’t just assume that it’s a great place to work, right? I’ve made that assumption in the past, and I’m too old to put up with certain practices, such as lengthy code reviews before checking code in (I’d prefer to pair program).

So, what are some good questions to ask? I’ll supply some of the questions I used to ask when interviewing (as a candidate) and those I would like to hear in a future blog entry, but I’d rather you give some thought to the kinds of questions you should come in with. Think about what you’d want your day to be like as an employee of the company, then ask questions relative to that ideal. Obviously you’ll never find an ideal workplace, but it’s up to you to find out on which axes the company is not ideal and whether you can live with that for the next 3-5 years.

The Best Question I’ve Never Heard

OK, I’ll give you one great question that I have yet to be asked (and this is after doing 12+ years of interviewing!): how many people have you referred to the company and how many of those have been hired? My answer would be 5. That will tell you a lot about how me, the interviewer, likes the company, more than a typical question I get, i.e., how long have you worked at Guidewire. There’s a world of difference between me working somewhere for a period of time and being willing to ask people I know and respect to work at the same place.

I’ve been meaning to write this post for a while, but after some frustrating interviews, I was motivated to finally put it down into words.

We’ve been interviewing a lot lately at my company (Guidewire Software, in case you’re interested) and I’d like to offer some tips on how to do your best. Note that I’m not going to tell you "how to succeed" or "how to get the job", because that will depend on your talent and skills. What I can tell you are the things that will allow you to make the most out of those talents and skills.

1. Communicate. In fact, over-communicate. If I’m interviewing you, tell me why you’re doing what you’re doing. Don’t make me guess. Don’t make me ask.

You may be the best darn programmer around, but if you’re thinking quietly and writing on the whiteboard in total silence, and then you make a mistake (and you will!), I won’t be able to help you. Just like in school where the motto "show your work" helps you get at least partial credit, if you just showed the answer it becomes either Pass or Fail — not where you want to be. So, if you tell me what you’re going to do and why and lead me through your thinking, then I’ll be much more willing to give you some hints or help and I’m definitely going to get a better sense of how you solve problems than if you keep your thoughts inside. As an "Introvert" (on the Myers-Briggs scale), I know that this can be hard, but if you can’t do it in an interview, then how do I know you can do it on the job?

1A. Verify assumptions.

This is the "be a good listener" part of communication. Repeat back what you think you’ve heard from me and make sure that agrees with what I said. For example, saying "so some other code will instantiate my object and I don’t have to worry about that, right?" is a good thing to do, because that may be completely wrong, but at least you found out before you started.

2. Admit when you don’t know something.

It’s much better for you to say "Y’know, I’m not really familiar with X" or "I don’t know Y" than to try and fake it or muddle through. If you admit you don’t know something, it’s unlikely I’ll hold it against you (unless you say "I don’t know Java" when the position clearly requires Java and you have Java on your resume). But if you push on through when it’s clear that you don’t really know it, I’ll be concerned that you’ll do the same thing on the job and not ask for help and therefore make serious mistakes.

3. Admit when you’ve gone in the wrong direction.

Similar to #2 above, but I’ve seen interviewees bomb when they keep pressing forward with a solution that’s not working or won’t work and they know it. If you’ve followed #1, I probably wouldn’t have let you go down that road so far.

4. Check your work.

I’m amazed (or dismayed) at the number of folks who write a bunch of code on a whiteboard and don’t read through it to see if they missed anything. Take a few minutes to read through your code and make sure there’s at least not anything obviously wrong. Pretend you’re the computer and execute your code.

5. Know how to write tests.

Seriously. In Java, main() methods with System.out.println()s are not tests (this isn’t 1996, y’know). One test for your code is not enough. 3 tests for 4 different classes is not enough. Naming a test "testValidation1" and "testValidation2" is going to make me wonder about how you name things (whiteboarding is a bit different, which I’ll talk about in a bit). In an interview I won’t push you to do TDD, but you have to know how you would test your code, since that’s as much part of the job as writing the code in the first place.

6. Know how to whiteboard.

Don’t write out every single little thing on a whiteboard. It’s perfectly fine to say "and then I just do more of the same here" or "normally I’d give this a name such as testWhenUserLoginFailsAnAuditLogEntryIsCreated, but I’ll just write testLoginFails". Time is of the essence in an interview and you don’t have time to write compilable code. As long as you’re following tip #1 and communicate well, you can take a lot of shortcuts on the whiteboard.

There are other things, but if you follow these tips, especially #1, the rest is up to your ability to actually program.

If you’ve followed my tweets, you already know that I’m participating in the November PragProWriMo, or the Pragmatic Programmers Writing Month. It’s not a contest or anything, but it is an opportunity to start writing what might become a book, or just a series of blog posts.

Note that these are not really blog posts, or even self-contained tidbits, but just what I’ve happened to write on that day. So, while you can feel free to comment, I’ll not really be paying attention to the comments and certainly expect things to not be well-written, let alone make sense without additional context. This is simply a way to allow people to see my writings as soon as they’re written and nag me if I miss a day of writing.

Day 1

Fluent Testing

ATDD, or Acceptance Test-Driven Development is one of the more recent techniques in developing software. The idea is to use code-based acceptance tests instead of English-based specifications or requirements. While it seems that English accetpance tests would be easier to write, in fact, they are more difficult to write well. It’s quite hard to be precise in a natural language where words are often ambiguous. For example, in this English-based acceptance "test"

* Filter searches on the Account number and the Policy number

The context here is a text field for a "filter" that limits the records that are shown. This simple statement can be interpreted in different ways. Before reading my interpretations, think about how many ways you could interpret it.

1. Text entered in the filter text field is used to search in the account number field, the policy number field or both.
2. The text is searched for in both the account number and policy number fields and must be found in both in order for the record to appear.
3. The filter text is used to search in the account number field, and if no records are found, then search in the policy number field.

You might be thinking that this is obvious and should have been stated more precisely when this requirement was discussed. However, it’s very difficult to always express the intent of requirements with enough precision on a consistent basis without missing something, or contradicting some other requirement. Even if you do end up with sufficient precision, you’ll likely end up with a 300 page requirements document that, I guarantee you, will end up being interpreted differently than from how it was intended. Since the whole point of agile development using story cards is to discuss these details (as in a "token for conversation") on an as-needed basis, how do you make sure that the developers don’t forget the details as they’re developing the code? The answer is executable acceptance tests.
The problem I’ve seen in coming up with a good form for executable acceptance tests (no, I won’t call them EATs) is that in trying to formalize the English, you end up with something that is close enough to English that people understand the intent, but not quite enough like English so that people find it hard to write. The solution here is a fluent testing API. Something that is not only precise, but can be executed against production code once the code has been written and, going with the ATDD technique, use by developers _while_ they’re writing the code. For example (using JUnit in Java):

  public void sortByInvoiceDatesIsVisibleOnlyWhenGroupingByInvoiceAndByItem() {
    openCreateDirectBillPaymentPage(account)
      .groupByInvoice()
      .aggregateByItem()
      .assertSortByInvoiceDatesIsVisible("Sorting by invoice should be visible for Group By Invoice Aggregate By Item");
  }

It’s true, this test only checks that the "Sort By" selection element is visible, depending on various combinations of other selections ("Group By" and "Aggregation"), but it’s also very explicit under what conditions it should be visible and, most importantly, is not that much less readable than if it were written in English. It’s hopefully clear that after opening the "Create Direct Bill Payment Page", we "group by invoice", then "aggregate by [invoice] item", and finally, the check (assert) that the "Sort By" element is indeed visible. The string passed to the assert is the failure message, and helps describe _why_ the assertion should be true.
There’s an additional feature that puts this over the top, and that’s an IDE’s ability to provide a list of choices of methods that are available on each object, aka, code completion. This allows the executable acceptance test author to be guided by the code completion of methods that are available at each point. This turns out to make test writing much easier than if it were an /external DSL/, because the choices are constrained by the objects that you’re working with, i.e., on the DirectBillPaymentPage, the IDE will "tell you" that you can do "groupByInvoice" and "aggregateByItem" by showing those methods as auto-complete options.

The Art of Lean Software Development, 1st Edition
by Curt Hibbs; Steve Jewett; Mike Sullivan

From O’Reilly Media, Inc.
Published February 2, 2009
ISBN-13: 978-0-596-51731-1
Pages: 144

Looks like I’ve been doing a lot more Twittering (see http://twitter.com/jitterted) than blogging the last couple of months. One thing I like about Twitter is it allows me to write down short (<=140 chars!) thoughts or ideas that don’t warrant a full blog posting. Now that I’ve "saved up" a bunch of thoughts, I can go and write more about them.

Note that my twitterings (tweets) are 95+% about software, development, agile, etc., and very little "ooh, I just saw a cute puppy" or "I’m hungry" — that’s just not the way I want to use Twitter.

I’ve been reading lots about Kanban ever since David Anderson talked about his experience at the Nov 3rd (2008) BayAPLN meeting. On the Kanban developer email list, a new book on the topic was announced, "Scrumban", so I immediately went over to Lulu.com and purchased it. I’ll probably start reading it next week as it’ll be pretty quiet in the office.

In the meantime, if you’re at all interested in (or practicing) Agile, I highly recommend also reading about how Kanban is being applied to software development. The email list is a good place to start, as is David Anderson’s blog and articles.

The presentation "slides" are here: http://www.tedmyoung.com/EasingIntoAgile.pdf.

Note that the content is licensed under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Question, comments, criticism, etc., are always welcome.

I don’t know about you, but I’ve got code in my code base that still uses arrays and we need to move them to Lists. Sounds like fun, huh? Well, a new refactoring in IDEA 8.0, Type Migration, is going to help a lot in this task. The other feature that blew me away during the EAP was the Data Flow To This… command, which lets you see how the variable you’re looking at got its value all the way back through the method chains. This is really useful when you’re trying to figure out, say, why the value is null and where it got set that way.

Examples and screenshots on these coming soon. 

Yeah, IDEA 8.0 has been out almost a week, but I’ve been so busy with the Code Camp preparations, I didn’t have time to focus on it.

I’ve been using 8.0 since the first Early Access builds, and it’s been a very solid product all the way through. There were some regressions in the way things were "painted" (causing background colors to not work properly in some cases) that I’m betting has to do with the fact that IDEA 8.0 ships with the 1.6u10 release of the Sun Java VM. Those bugs are fixed and I’m happily using 8.0 on its 30-day trial until I get my 7.0 license upgraded. I’m bummed that I didn’t win the JetBrains raffle at the Code Camp, but oh well.

I’ll be posting thoughts and information about the new 8.0 features over the next few weeks. 

If you attended my "Easing Into Agile" or "Building Better Tests in Java" sessions at the Silicon Valley Code Camp 2008, I’d love to hear any feedback, compliments, constructive criticism, and any questions that you might have thought of. The code camp eval for the Agile session is here: http://tr.im/yqi and the eval for the Builders session is here: http://tr.im/yqm. I also encourage you to leave a comment here if that’s more convenient.