November 3rd, 2011

device

More Lytro thoughts

dervishspin mentioned wanting to capture the "3d-ness" of a scene. This sparked some thoughts about the possible future directions of this new camera technology, which seem worth a top-post:
The neat thing here is the sense that they are really on to something. This first model feels like the original iPod: a bit oversimplified, going to be frustrating in some ways, needs a lot of tweaking and tuning and a whole bunch more power. But I have a strong suspicion that in a few years, once they've evolved both the hardware and software a bit, it's going to change the whole way one thinks about photography.

Specifically on the 3d-ness -- one obvious thing to try (and I'd be surprised if they're not experimenting with it already) is a 3d version of this camera. Two lenses, both recording the complete light field like this -- I suspect there's a whole 'nother doctoral thesis on how you can stitch them together, but I'd bet that you can eventually wind up with a fully immersive image, that looks truly 3d *and* allows you to refocus. It probably could even be tuned to your specific eyes, to work better for many people than most current 3d does.

Then for extra credit, take that idea and combine it with hardware that follows your pupils and refocuses the image based on your current focal distance. Once the software is fast enough to work in perceived realtime (probably 1-2 orders of magnitude faster than their current demonstrations), you can have a "picture" that is immersive beyond anything currently possible -- you can actually "look around" the image intuitively. Now imagine giving a tour through a panoramic 3d image with your eyes, with the image refocusing and zooming based on your eye movements as you show participants around what's in the image. From what I know of the technologies, that seems like it's plausible within five years or so.

I always love it when I get that little spine-tingling sense that a bit of science fiction is about to become real...
device

Good programmers: there is no substitute

[Rant warning.]

One of the hazards of being semi-management these days is that I spend altogether too much time on the hiring process -- both writing reqs for new hires and interviewing people. And I keep being surprised by the question, "What kind of programmer do you want?"

The answer is, "A good one". All else is commentary.

If I'm hiring someone to work on the client, I keep getting questions about, "Do they need to specifically be a Flex programmer? How many years of UI programming experience do they need?" and so on, as if that's the important part. If we're looking for QA Automation Engineers, there are all these questions about, "Is it critical that they know a particular automation framework? How much time do they need to have spent on QA automation?"

These are the wrong questions. I do not, by and large, give a good goddamn about how much time someone has spent in a pigeonhole. Indeed, the more focused their career has been, the more suspicious I am of them. I have met Flex programmers who wrote the most atrocious code I've ever seen, and QA Engineers who thought they knew how to do automation because they could string lines of code together; both have been nothing but trouble.

While it is a *slight* exaggeration to say that Programming is Programming is Programming, it's not a huge one. Give me a programmer who knows what they are doing -- who is keeping up with the field and how to program *well* -- and I can confidently throw them at almost any problem. Moreover, I can be pretty confident that, after a fairly modest ramp-up time, they will probably be programming rings around the specialists who know an area well, but haven't spent the time really learning the craft of software.

Seriously: if you're in management, stop worrying about trying to hire specialists -- a good generalist programmer will, in most cases, be your best bet. If you're a programmer, don't spend as much attention learning specific libraries and such -- focus on honing your craft every day, knowing the general art of programming well, and exploring it in many forms. Good code pretty much looks like good code, whether you're writing databases, user interfaces, web servers, test harnesses, or anything else.

[/rant, brought to you by seeing the same mistakes made a few too many times]