Monday, September 27, 2004
Hiring a Senior Programmer / Software Developer in Toronto
Here's my standard response to recruiters offering me senior programmers and software developers:
I'm currently looking for aggressive, smart programmers. The very first questions I always ask are, "what's the best work you've ever done? And why are you proud of it?" There's no secret to the correct answer. Candidates who love what they do are always ready to share their passion with me.
Candidates who show up for the first meeting carrying portfolios of previous work (screen shots, source code, &tc.) receive major preferential treatment. I'm amazed at the number of candidates who are carrying a résumé and expect me to conjure up in my head visions of how wonderful their work is.
Our interviewing style is thorough. Candidates will be asked to write code and solve Microsoft-style puzzles right up front. Those who show an aptitude for problem solving and excellent communication skills will be invited to meet with four to six future colleagues.
Did I mention excellent communication skills? This is a team environment where we turn ideas into software products. Being able to brainstorm with colleagues, discuss ideas, and contribute to code/design reviews is part of the job. And that means fluent use of the English language in a technical setting.
Although this can be gruelling, I can promise you that candidates who are smart and capable will get an opportunity to shine. Unlike many other firms, I'm prepared to look at candidates with a variety of backgrounds. Do you have "hacker" types that contribute to open source in your database? I'm interested! Do you have creative types who have developed software for Macintosh? I'm interested!
I know this isn't the standard "5 years of C++" type job requisition: If you absolutely must have some keywords for your database, please try:Please call or email to discuss. I'd love to work with you on staffing my team with the best and the brightest.
- "Python," "Smalltalk," "Lisp," "Squeak," "Scheme," "Haskell," "J," or "Ruby;"
- "Scrum," "Extreme Programming (XP)," "Agile," "Spiral," "Continuous Integration," "Daily Build;"
- "Spring," "Hibernate," "Aspect#," "WebObjects," or "JBoss-AOP;"
- "NextStep", "AUX," "MacOS X," or "Linux."
Warm regards,
Reginald Braithwaite-Lee
During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavour the job descriptions had, the less dangerous the company was. —Paul Graham
p.s. For your web surfing pleasure:
http://www.paulgraham.com/gh.html
http://www.joelonsoftware.com/articles/fog0000000073.html
http://www.stickyminds.com/s.asp?F=S7875_COL_2
http://www.paulgraham.com/pypar.html
Labels: jobs
Tuesday, September 21, 2004
Writing Solid Corruption-Free Code
I recently heard of some programmers struggling with mysterious data corruption issues with their application. I was struck by their similarity to something I'd seen almost a decade ago. Back then, I was building database-backed CRM applications.
Plan "A" for such applications is simple: always write good data. Plan "A" lasts about a month into any project. Once change requests a/k/a maintenance and upgrades appear, it's easy to introduce new code that writes something the old code doesn't expect, and you have corruption.
Plan "B" usually kicks in at that point. You introduce constraints at the row level, using as many tricks as your database vendor provides (triggers, &tc.) to validate data before it's written. Plan "B" lasts for two more months before the sheer complexity of your object relations weighs in. Then you find out that saving records now takes forever, and it's hard to maintain your application when a lot of the validity logic is hiding in your database.
Plan "C" now takes over. You remove most of the slowest and most complex validity checks and move them into a batch process. You add some support for rollbacks, such as a "valid" flag. You run the validity checking on a nightly basis and as part of major data imports and updates. The validity checking is now all in once place, so it serves as documentation.
A funny thing now happens. As you develop new code, you find that you can consult the validity routines to understand what consitutes a valid state for the database. If you need to add new modalities, you can add new validity routines. It's better than a UML diagram because it's executable code.
Debugging is now a cinch. Validate the database. Run some tests. Validate again. If the second validation fails, you have bugs in your code.
Two years ago I introduced this idea to a project. I asked the project's database analyst to write a validation routine for a complex application. He replied that he couldn't, the application was too complex for that. His idea was that we'd follow his meticulous plan and everything would just happen to work.
Red flag! If the DBA can't write the routine, then there's zero chance the final application will work. As it happened, it was impossible to write new code for that application. There was a complex, table-driven workflow infrastructure and nobody could ever construct a baseline set of rules and states to use for testing code. I heard that they eventually junked it in favour of an off-the-shelf solution.
So now I'm going back to the well when advising my friends.
Their application serializes a dense object graph out into binary files. From time to time it seems to do unexpected and unwanted things. Debugging seems to be 50% Voodoo and 50% thought experiments.
I'm urging them to stop thrashing and start writing some external validation routines. It hurts to do that, but I'm certain that they'll reap serious dividend both in solving their current issues and when writing new code in the future. If they have a validation routine, one of the great things they can do is set upa debug mode that validates every single write.
If nothing else, I'll wager anyone dinner for two with a bottle of wine (I'm serious about this) that the very act of wading through their data format and deciding how to write a utility that can validate their data will cause them to kick themselves at least once and say "Aha! I see a problem!"
Plan "A" for such applications is simple: always write good data. Plan "A" lasts about a month into any project. Once change requests a/k/a maintenance and upgrades appear, it's easy to introduce new code that writes something the old code doesn't expect, and you have corruption.
Plan "B" usually kicks in at that point. You introduce constraints at the row level, using as many tricks as your database vendor provides (triggers, &tc.) to validate data before it's written. Plan "B" lasts for two more months before the sheer complexity of your object relations weighs in. Then you find out that saving records now takes forever, and it's hard to maintain your application when a lot of the validity logic is hiding in your database.
Plan "C" now takes over. You remove most of the slowest and most complex validity checks and move them into a batch process. You add some support for rollbacks, such as a "valid" flag. You run the validity checking on a nightly basis and as part of major data imports and updates. The validity checking is now all in once place, so it serves as documentation.
A funny thing now happens. As you develop new code, you find that you can consult the validity routines to understand what consitutes a valid state for the database. If you need to add new modalities, you can add new validity routines. It's better than a UML diagram because it's executable code.
Debugging is now a cinch. Validate the database. Run some tests. Validate again. If the second validation fails, you have bugs in your code.
Two years ago I introduced this idea to a project. I asked the project's database analyst to write a validation routine for a complex application. He replied that he couldn't, the application was too complex for that. His idea was that we'd follow his meticulous plan and everything would just happen to work.
Red flag! If the DBA can't write the routine, then there's zero chance the final application will work. As it happened, it was impossible to write new code for that application. There was a complex, table-driven workflow infrastructure and nobody could ever construct a baseline set of rules and states to use for testing code. I heard that they eventually junked it in favour of an off-the-shelf solution.
So now I'm going back to the well when advising my friends.
Their application serializes a dense object graph out into binary files. From time to time it seems to do unexpected and unwanted things. Debugging seems to be 50% Voodoo and 50% thought experiments.
I'm urging them to stop thrashing and start writing some external validation routines. It hurts to do that, but I'm certain that they'll reap serious dividend both in solving their current issues and when writing new code in the future. If they have a validation routine, one of the great things they can do is set upa debug mode that validates every single write.
If nothing else, I'll wager anyone dinner for two with a bottle of wine (I'm serious about this) that the very act of wading through their data format and deciding how to write a utility that can validate their data will cause them to kick themselves at least once and say "Aha! I see a problem!"
Monday, September 20, 2004
The goal of QA is to provide an ongoing induction of reality
Jim McCarthy on QA:
"If QA feels its charter is to test the product that Development has created--or Development is convinced that its job is to create a product that QA then tests--some alarm bells should go off...
"QA's principal function--and it is a principal function--is to continually assess the state of the product so that the rest of the team's activities can be properly focused.
"QA's ongoing assessment is integral to the act of software creation, not an ex post facto event. Naturally, a good deal of testing and analysis is required to properly gauge status, but the goal of QA is to support the product development process by providing an ongoing induction of reality."
Labels: agile
Friday, September 17, 2004
Returning to Macintosh
When I was a teen-ager I was in love with computers. I wrote games for our school's Data General minicomputer in 16K BASIC, I hung around the University of Toronto's High Speed Job Stream writing batch jobs in Snobol, Watfor, and Lisp, and daydreamed about writing two programs that could converse with each other (an idea from a Michael Crichton book).
Things gradually became more and more familiar, more and more mundane as I drifted out of school and made the massive mistake of thinking that computers were for business applications. Then, twenty years ago, I saw Byte Magazine's Macintosh issue. The scales fell from my eyes and my passion was rekindled.
It took me a while to actually get into programming for Macintosh, but I was now hooked on the idea that computers were more than just a neat environment for puzzle-solving. Computers could actually mean something.
I wound up "making big bucks in my spare time" writing Macintosh software: one creation, Tableau, managed classified ads for PageMaker and Quark users. I still own a working Mac SE and an SE/30. Although I've used "desktop" Macs and the enigmatic Duo, I've never lost my love for the original all-in-one design with the integrated carrying handle. For years, my web site was hosted on Macintosh systems.
It's twenty years later. I've owned a Windows desk side system for more than five years, and it's fair to say I've been contemptuous of Windows the entire time. Saying that "it's popular" and "it's good enough" is like saying that everyone should eat at McDonalds. Two years ago, I bought a Toshiba Portegé Tablet Computer
, and things got better: my Tablet PC is the "first Windows computer good enough to criticize."
But I still admire Macintosh. And I finally found an excuse to buy another one.
My fiancé and I are expecting [Update: March 2007]. And that means a complete reorganization of our apartment, including moving our desk into our living room. I've been gradually relaxing my minimalist aesthetic over the years, but the idea of putting our TV, stereo, speakers, DVD player, VCR, computer, and monitor in one room was too much. As I wrestled with how to integrate as many of these components as possible, Apple announced the new iMac G5 (Now superseded by the Core Duo iMac
).
I felt a visceral desire for this system. And luckily, I had an excuse for buying one: cleaning up the living room. I contacted Anthony Lewin at Computer Systems Centre and ordered a 20" iMac. I plan to add Bluetooth, AirPort, and a USB TV tuner. I already have about half of my CDs ripped to MP3. We can play the rest and/or rip them too. Our VCR tapes can be recorded to disk, so the VCR will go too.
So I have a rationalization. But who's kidding whom? I'm buying an iMac strictly because it's beautiful and my stereo is ugly, ugly, ugly. I'm making a decision based on passion.
And it feels good.
Things gradually became more and more familiar, more and more mundane as I drifted out of school and made the massive mistake of thinking that computers were for business applications. Then, twenty years ago, I saw Byte Magazine's Macintosh issue. The scales fell from my eyes and my passion was rekindled.
It took me a while to actually get into programming for Macintosh, but I was now hooked on the idea that computers were more than just a neat environment for puzzle-solving. Computers could actually mean something.
I wound up "making big bucks in my spare time" writing Macintosh software: one creation, Tableau, managed classified ads for PageMaker and Quark users. I still own a working Mac SE and an SE/30. Although I've used "desktop" Macs and the enigmatic Duo, I've never lost my love for the original all-in-one design with the integrated carrying handle. For years, my web site was hosted on Macintosh systems.
It's twenty years later. I've owned a Windows desk side system for more than five years, and it's fair to say I've been contemptuous of Windows the entire time. Saying that "it's popular" and "it's good enough" is like saying that everyone should eat at McDonalds. Two years ago, I bought a Toshiba Portegé Tablet Computer
, and things got better: my Tablet PC is the "first Windows computer good enough to criticize."But I still admire Macintosh. And I finally found an excuse to buy another one.
My fiancé and I are expecting [Update: March 2007]. And that means a complete reorganization of our apartment, including moving our desk into our living room. I've been gradually relaxing my minimalist aesthetic over the years, but the idea of putting our TV, stereo, speakers, DVD player, VCR, computer, and monitor in one room was too much. As I wrestled with how to integrate as many of these components as possible, Apple announced the new iMac G5 (Now superseded by the Core Duo iMac
).I felt a visceral desire for this system. And luckily, I had an excuse for buying one: cleaning up the living room. I contacted Anthony Lewin at Computer Systems Centre and ordered a 20" iMac. I plan to add Bluetooth, AirPort, and a USB TV tuner. I already have about half of my CDs ripped to MP3. We can play the rest and/or rip them too. Our VCR tapes can be recorded to disk, so the VCR will go too.
So I have a rationalization. But who's kidding whom? I'm buying an iMac strictly because it's beautiful and my stereo is ugly, ugly, ugly. I'm making a decision based on passion.
And it feels good.
Labels: passion
Monday, September 06, 2004
How to reduce testing time
From How Long Should the Testing Take?:
Here's what I have noticed from my work with multiple organizations. The groups who want to decrease testing time tend to perform the least proactive work reducing the overall number of defects...Also:
"If you want to reduce testing time, create a low-defect product, test all the way through with a variety of test techniques, and use iterations, so you know at the end of 2-4 weeks where you stand with defects. The lower the number of defects and the more sophisticated your tests, the faster your testing time will be.
- A Measured Response: Useful Metrics to Give Managers Numbers to Back Up Project Hunches
- Testers and Developers Think Differently
- Test Driven Development
Labels: agile
