JFIF``C     C   <" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( aOPmRR&CfڹU@ cq_'[>ӗT !ͷ'hTabx-kym>w{$/akD\HS_U"4cMy|SIZY|auz)5ċ ^|rDBnus1 rId+WGցXu'i<0\ׁ|gx]ԼcuXiү$M#H;{S4g.a; ^/K+?O]6xyƌ$߰D#r8ϗ Num'ZkmmCNHchyVmD6'wV6[#h]t˽Z ,E< \Z㭜[][[_*UmNW%W*eb8鿴~iw^0K|X 6-D3Zη*ZZgpj=\᫸-=N KR7$p>QVR$rnɤ_*\GuYiVNVR4a!H x^Z~h^7Gsޱ4%l oاWT%h]<8:t AhR# G" f>{+;=Οh,P/[9(BT7%wfOtEkNwt3] :+?.e$(RI9\W>&aomd+*n7n [NE'(PWCe+Ɠ8

First: Principles

Discussion of agile principles, online communities, rss feeds, and anything else that might appeal to a software developer located in Bloomington, Indiana.

 My Photo
Name: Ben Fulton
Location: Bloomington, Indiana, United States

Thursday, October 26, 2006

The Guerrilla Guide to Interviewing

Joel's latest article on interviewing is up. It makes some good points, although he continues with the down-to-the-metal idiosyncracy that I posted about last year. But here are the things that I thought were really good points:
  • Hire/No-Hire . Make a decision. If you don't know, the answer is No Hire. I've run into this before when interviewing an entry-level guy for a position that required more skills than that. We recommended he be hired for Support instead. I'm not sure that that wasn't the right decision, but as a principle I like this one.
  • You want people who are smart, and who get things done. Joel describes people who fail at one or the other, and I think I've worked with most of them before.
  • A programmer should understand pointers, and recursion. Joel comments that a lot of people are coming out of school without learning a language that requires pointers, which is a problem. Less so with recursion. He says that pointers are an aptitude rather than a skill.

At the end he says, confidently,

If your resume and phone-screening process is working, you’ll probably have about 20% hires in the live interview.

True at FogBugz, no doubt. I've not really seen it here in Indianapolis, where the local talent pool is so small. But you never know, we might get lucky!

Want a job at an up-and-coming medical imaging company? Drop me a line!

Labels: , ,

|

Wednesday, October 25, 2006

Bloggers are people too

Ordinarily for me, reading and writing blogs is an intellectual exercise. I'm more comfortable and interested in discussing software processes, languages, testing than I am with the emotional appeal of the typical network news sob story. So when worlds, and cars, collide, I find it affects me especially. I envision my own five-year old son coming home from his karate class and I feel like crying. Good luck to you, Nick and Josh.

Labels: ,

|

Tuesday, October 17, 2006

IQAA: Regression Testing

Dr. Hanna's Practice #8: Perform regression testing that is based on impact analysis. The first practice in the list that you can't just nod your head at, since you have to have a good idea of what regression testing is (I do) and what impact analysis is (I didn't.) But I did like Practice #7: Testers should attend design and code reviews. It's not something I had heard before, but it's obviously a good idea if you are interested in faciliating communication within your company.

So what should a tester do at a code review? Primarily they will want to come up with test ideas; examine the code paths; ask how each one can be exerci