Hi! I'm Matt "Breakpoint" Heck. You may know me as "Theodore" from the web series "Aperture R&D" (in which case I assume that's the point in the credits at which YouTube had to pause to re-buffer). Presuming nothing falls victim to arson during post-production, In a little under a year, you might see me in a film and a few other odd detours. If you lived on the Central Coast around, oh, 2001-2003, you might know me for doing stand-up comedy. If you've been to Burning Man over the last few years, you might have seen a 15,000 cubic foot helium airship I helped stick 200 feet over the Nevada desert with a Tesla coil concert under it. It's even VAGUELY possible you know me from my (cough) "music" with The Braindead Monkeys, featuring such classic tracks, god help me, as, "Terrorism!". And, if you clicked on the wrong link somewhere, there's a very outside chance you might even have read some of my short science fiction, in which case I'm very sorry, I didn't mean it, and they all lived happily ever after right after a thorough memory wipe, which I would offer you if I could.
However, in as much as I am ever actually cited or referred to anywhere, it's always from something I wrote (essays or code) in my professional capacity as (primarily) a software engineer. Far more people have used the touchscreen jukeboxes I did for Ecast, or the MPEG decoders I helped write for Xing (or, certainly, the DeCSS keys that were apparently lifted from them), or even the video games beta release I worked on, then are probably ever going to recognize my face or my voice, let alone my name. But even then, what DO people remember my name from? A few off-hand emails about Qt vs wxWindows (now wxWidgets) I wrote a long, long time ago, but which apparently had a larger effect than I had any right to expect. In other words, I am remembered for writing something that was really merely a step or so above a private message.
So, now that you know where I'm coming from, let me give you my take on a few things-- because "Silicon Valley" and "Hollywood" are going to overlap more and more, not less, and the overlap is cultural as much as it is technical. I spend some of my social time with other engineers, actors, writers, stand-up comics science fiction anthology editors, and makers (I helped run TechShop for a year or so). They all have one thing in common: burnout is a problem.
I would propose that practically everything you do in this world for love or money will fall somewhere on an equilateral triangle that we might label "Compensation", with these three vertices: * Pay * Fame * Satisfaction
Somewhere on that triangle is a very specific spot where YOU would be happiest, and it probably isn't dead-center. Likewise, somewhere on that triangle is a spot where YOU are RIGHT NOW, and that is the sum of everything you are currently doing, and everything you have done.
Now, I'm not talking about your whole life, here-- hopefully your marriage isn't done for fame or money-- but I am talking about your (supposedly) 9-5 job, plus the "consulting" work that may or may not really reimburse you for the time you put into it but is damn cool, plus the hobbies and projects you participate in because you really, really want to.
The simple fact of the matter is that the vast majority of the time, the things we would like to do for pay, fame, and satisfaction do not do all three of those things. Often, they only do one of them. Worse, sometimes you go negative in a category. But the thing to realize-- and this can be maddeningly frustrating to try to explain to people who are more comfortable in (or more easily satisfied with, moo) their lives-- is that those things you do that you can't figure out why in the hell you bother? Those things that you still do even though it seems like they're just not worth it? We do a lot of those things to make the sum of EVERYTHING we do a little closer to where we'd like to be on that triangle.
Man, you sure don't see this kind of attitude in a small company. You can only get away with it in an environment large enough for people to hide. Like aerospace! Or academia. I can assure you that this is exactly the kind of thing managers dread: employees intimidating each other out of peer review. As a rule, MANAGERS DON'T REVIEW CODE. Mangers review PROGRESS. If progress sucks, they will try and figure out what's wrong. But if they're not reviewing code, and the employees are tight-lipped about each other, than one or more of the following happens:
0) The company ignores the problem, then goes broke because unmaintainable code means permanent fire-fighting. This is what usually happens.
1) Resources get added. If this isn't actually needed, but is being used to "code around" problem people, this is going to cause serious initial slowdown while they get trained. Which your good programmers don't have time for. So guess who gets stuck training the new guy. And guess what that means.
2) Code reviews! Oh, the humanity. Watch tempers flare as the shit finally flies through the air, after years of stifling deeply-held opinions instead of discussing them with your peers! Someone will either quit or get fired, so code quality will improve. Morale, however, will go straight in the toilet.
3) Coding standards. This is your best bet, in my opinion. You go into a room _without_ anybody's code, and all gradually develop some standards and best practices. This should take about a week and it is damn well worth it. It takes all the ego out, because everyone reaches the standards by collaboration. It also means that when people "complain" about code, they have specific things to cite, and specific reasons the complain about them. This is the best way to avoid peer-to-peer fights, because everything dilutes in the team. And if you have one person who is constantly fighting the _entire team_? Well, you had better re-evaluate whether you want that person _on_ your team. This solution should result in a _short_ written document, and should not be an excuse for out-and-out nitpicking. (HINT: Use a stopwatch to see how much time people try to spend arguing about brace and bracket placement, and kill the issue quickly with a vote.)
4) Peer-programming gets added. This is popular lately, and man, this is one place managers really better earn their pay. Careful balancing of the mix of peer programming and solo time, and careful pair selection, is required to slowly teach better habits. I recommend doing this AFTER the coding standards document, so that it "guidance" doesn't seem arbitrary or egotistical.
Oh, no-- you have it completely backwards!
His _manager_, after all, isn't likely to have to _maintain_ that code-- his co-workers are. Likewise, they have to deal with the security problems that invariably fall out of code nobody else can understand due to a lack of proper documentation and descriptive coding practices. So it most definitely is _his problem_.
However, if we put the two of you together, you can start to see the correct solution, which is that he should be telling his manager to _fire the guy_.
Without looking at the paper in detail (things to do today, I'm afraid) I'd have to agree that this doesn't sound like anything new. I worked in video compression about, oh, ten years ago, and I remember it being explained to me as already fairly well established that:
1. The eye makes tiny, constant movements referred to as "tremor".
2. While the iris reacts to total constant light levels over time, the rods, cones, and optic nerve work to transfer transition data, primarily, to the visual cortex-- like other nerve activity, steady-state levels are of lesser importance than transitions, and seem to be processed slower.
3. If a sharp edge or feature is focused on the retina, tremor will cause rods and cones to move onto and off of that edge or feature, causing a sort of pulse train for the optic nerve and visual cortex.
4. This seems to account for things like conflicting results when early graphics researchers were trying to figure out the minimum acceptable frame rate for a flight simulator: We detect motion of edges and large objects at extremely high rates (I have heard 120-160 frames/sec equivalents), color (at all) at lower rates, texture features at even lower rates, and so on. This is why 24 frames per second can be either adequate or jarring, depending on what's in the scene and how things are moving.
One thing to share for sure, though: the physiology and related science of visual perception is absolutely, positively fascinating. Utterly rewarding stuff to read about-- you'll see it everywhere, once you learn some. Anybody the least bit interested in optics or graphics-- programmers, photographers, and videographers, sure, but even gamers-- should get a kick out of studying perception.
I take it all back. Whatever Ballmer's getting paid, he's earned it.
Cripes.
I wonder how many more pieces of embarrassing, early-career moments are out there, their stars secretly hoping they are lost forever, but in fact just waiting to surface on the vast expanse of the Internet......enough to support Compfused, et al, it seems.
Slashdot Mirror
Hi! I'm Matt "Breakpoint" Heck. You may know me as "Theodore" from the web series "Aperture R&D" (in which case I assume that's the point in the credits at which YouTube had to pause to re-buffer). Presuming nothing falls victim to arson during post-production, In a little under a year, you might see me in a film and a few other odd detours. If you lived on the Central Coast around, oh, 2001-2003, you might know me for doing stand-up comedy. If you've been to Burning Man over the last few years, you might have seen a 15,000 cubic foot helium airship I helped stick 200 feet over the Nevada desert with a Tesla coil concert under it. It's even VAGUELY possible you know me from my (cough) "music" with The Braindead Monkeys, featuring such classic tracks, god help me, as, "Terrorism!". And, if you clicked on the wrong link somewhere, there's a very outside chance you might even have read some of my short science fiction, in which case I'm very sorry, I didn't mean it, and they all lived happily ever after right after a thorough memory wipe, which I would offer you if I could.
However, in as much as I am ever actually cited or referred to anywhere, it's always from something I wrote (essays or code) in my professional capacity as (primarily) a software engineer. Far more people have used the touchscreen jukeboxes I did for Ecast, or the MPEG decoders I helped write for Xing (or, certainly, the DeCSS keys that were apparently lifted from them), or even the video games beta release I worked on, then are probably ever going to recognize my face or my voice, let alone my name. But even then, what DO people remember my name from? A few off-hand emails about Qt vs wxWindows (now wxWidgets) I wrote a long, long time ago, but which apparently had a larger effect than I had any right to expect. In other words, I am remembered for writing something that was really merely a step or so above a private message.
So, now that you know where I'm coming from, let me give you my take on a few things-- because "Silicon Valley" and "Hollywood" are going to overlap more and more, not less, and the overlap is cultural as much as it is technical. I spend some of my social time with other engineers, actors, writers, stand-up comics science fiction anthology editors, and makers (I helped run TechShop for a year or so). They all have one thing in common: burnout is a problem.
I would propose that practically everything you do in this world for love or money will fall somewhere on an equilateral triangle that we might label "Compensation", with these three vertices:
* Pay
* Fame
* Satisfaction
Somewhere on that triangle is a very specific spot where YOU would be happiest, and it probably isn't dead-center. Likewise, somewhere on that triangle is a spot where YOU are RIGHT NOW, and that is the sum of everything you are currently doing, and everything you have done.
Now, I'm not talking about your whole life, here-- hopefully your marriage isn't done for fame or money-- but I am talking about your (supposedly) 9-5 job, plus the "consulting" work that may or may not really reimburse you for the time you put into it but is damn cool, plus the hobbies and projects you participate in because you really, really want to.
The simple fact of the matter is that the vast majority of the time, the things we would like to do for pay, fame, and satisfaction do not do all three of those things. Often, they only do one of them. Worse, sometimes you go negative in a category. But the thing to realize-- and this can be maddeningly frustrating to try to explain to people who are more comfortable in (or more easily satisfied with, moo) their lives-- is that those things you do that you can't figure out why in the hell you bother? Those things that you still do even though it seems like they're just not worth it? We do a lot of those things to make the sum of EVERYTHING we do a little closer to where we'd like to be on that triangle.
Or at least, we SHOULD.
Now, I will readily assure you that
Man, you sure don't see this kind of attitude in a small company. You can only get away with it in an environment large enough for people to hide. Like aerospace! Or academia. I can assure you that this is exactly the kind of thing managers dread: employees intimidating each other out of peer review. As a rule, MANAGERS DON'T REVIEW CODE. Mangers review PROGRESS. If progress sucks, they will try and figure out what's wrong. But if they're not reviewing code, and the employees are tight-lipped about each other, than one or more of the following happens:
0) The company ignores the problem, then goes broke because unmaintainable code means permanent fire-fighting. This is what usually happens.
1) Resources get added. If this isn't actually needed, but is being used to "code around" problem people, this is going to cause serious initial slowdown while they get trained. Which your good programmers don't have time for. So guess who gets stuck training the new guy. And guess what that means.
2) Code reviews! Oh, the humanity. Watch tempers flare as the shit finally flies through the air, after years of stifling deeply-held opinions instead of discussing them with your peers! Someone will either quit or get fired, so code quality will improve. Morale, however, will go straight in the toilet.
3) Coding standards. This is your best bet, in my opinion. You go into a room _without_ anybody's code, and all gradually develop some standards and best practices. This should take about a week and it is damn well worth it. It takes all the ego out, because everyone reaches the standards by collaboration. It also means that when people "complain" about code, they have specific things to cite, and specific reasons the complain about them. This is the best way to avoid peer-to-peer fights, because everything dilutes in the team. And if you have one person who is constantly fighting the _entire team_? Well, you had better re-evaluate whether you want that person _on_ your team. This solution should result in a _short_ written document, and should not be an excuse for out-and-out nitpicking. (HINT: Use a stopwatch to see how much time people try to spend arguing about brace and bracket placement, and kill the issue quickly with a vote.)
4) Peer-programming gets added. This is popular lately, and man, this is one place managers really better earn their pay. Careful balancing of the mix of peer programming and solo time, and careful pair selection, is required to slowly teach better habits. I recommend doing this AFTER the coding standards document, so that it "guidance" doesn't seem arbitrary or egotistical.
Oh, no-- you have it completely backwards! His _manager_, after all, isn't likely to have to _maintain_ that code-- his co-workers are. Likewise, they have to deal with the security problems that invariably fall out of code nobody else can understand due to a lack of proper documentation and descriptive coding practices. So it most definitely is _his problem_. However, if we put the two of you together, you can start to see the correct solution, which is that he should be telling his manager to _fire the guy_.
Without looking at the paper in detail (things to do today, I'm afraid) I'd have to agree that this doesn't sound like anything new. I worked in video compression about, oh, ten years ago, and I remember it being explained to me as already fairly well established that:
1. The eye makes tiny, constant movements referred to as "tremor".
2. While the iris reacts to total constant light levels over time, the rods, cones, and optic nerve work to transfer transition data, primarily, to the visual cortex-- like other nerve activity, steady-state levels are of lesser importance than transitions, and seem to be processed slower.
3. If a sharp edge or feature is focused on the retina, tremor will cause rods and cones to move onto and off of that edge or feature, causing a sort of pulse train for the optic nerve and visual cortex.
4. This seems to account for things like conflicting results when early graphics researchers were trying to figure out the minimum acceptable frame rate for a flight simulator: We detect motion of edges and large objects at extremely high rates (I have heard 120-160 frames/sec equivalents), color (at all) at lower rates, texture features at even lower rates, and so on. This is why 24 frames per second can be either adequate or jarring, depending on what's in the scene and how things are moving.
One thing to share for sure, though: the physiology and related science of visual perception is absolutely, positively fascinating. Utterly rewarding stuff to read about-- you'll see it everywhere, once you learn some. Anybody the least bit interested in optics or graphics-- programmers, photographers, and videographers, sure, but even gamers-- should get a kick out of studying perception.
I take it all back. Whatever Ballmer's getting paid, he's earned it. Cripes. I wonder how many more pieces of embarrassing, early-career moments are out there, their stars secretly hoping they are lost forever, but in fact just waiting to surface on the vast expanse of the Internet... ...enough to support Compfused, et al, it seems.