The iNexus

There’s a question I’ve often wondered - why do technical teams feel a need to use academic questions that only serve to test logic challenges when these have nothing whatsoever to do with the actual job?

Yes, I’m aware these can condense logic/problem-solving skills down to some degree, but ultimately they do not have a direct application to the abilities relevant to the job, which is writing code (which requires language skills, toolset knowledge, and dedication, not just problem-solving.)

I’ve interviewed with several companies throughout the years and each time a revolving series of questions about b-trees or linked lists comes up. When is the last time a practical (Mac OS X) programmer spent time coding up a linked list (I’ve yet to see one in any project I’ve worked on) and in discussing implementations and designs I’ve yet to have someone ask for the big O notation for its run time.

Yet over and over these questions come up. Do they actually serve to prove ability? I’ve had the (mis)fortune of being entirely self-taught yet I’ve been able to work on several notable projects, and build a company, without using these computer science abstracts. Does that make me an inefficient programmer? I think not. But in the eyes of interviewers, apparently so.

So here’s my take - you want a computer science degree, say so and stop taking in candidates that don’t meet that exact criteria. You want someone experienced in writing Objective-C, say so and you’ll likely get a qualified candidate with enough screening. But don’t waste time conflating the two, they are not mutually inclusive.

As I previously mentioned, CF 3.0 will include AppleScript support to enable workflows and control as never before available. To that end I can’t do it alone - if you know AppleScript and use Compare Folders I’ve got some questions.

What would I like to know?

- How you’d use it.

- What nouns & verbs you’d expect.

- What workflows or possibilities you see.

- What you can do with just the basics, and then a custom suite.

Please get back to me via inexus[at]infinitenexus[dot]com as soon as possible (practically speaking, within the next couple weeks) and together we can make a solid AS implementation for the next version of CF!

I’ve been sketching out ideas out for what lay ahead for Compare Folders after 2.6 (to be released on Monday) and I’ve got a solid list of features for 3.0. The scope and impact of these changes is also large enough that it’s going to result in the first paid upgrade for Compare Folders (let the gnashing of teeth begin.) I’ll be dedicating a large chunk of time into getting all these mechanisms in place that will make CF an indispensable part of any workflow and the past 10 revisions or so have all been gratis including major functionality overhauls.

* means the item isn’t confirmed yet

• Plugin support (first plugin: Timer from iNexus)
• Basic AppleScript support
• * Automator actions
• Difference Engine 2.0
•     Better type handling (ignore extension when ignoring type)
•     Performance enhancements
• * Differencing capability
•      Compare 2 similar items to see what content differences exist (text primarily)
•     ** Merge support to a new document [remote possibility]
• * ‘Flat’ results layout style
• “Archive Selected…” Item Action
• (the obvious) UI, performance, and stability improvements

These are the major points that have started rolling around in my head as I begin planning this next development phase and I think they’ll bear out a lot of wins. Nothing is guaranteed by my posting this list, but it should be taken as a peek inside my brain as the targeted areas start becoming visible (or already working, depending on my fingertips.)