Asynchronous reviewing software systems really help. I've found that when things get busy, they get busy for different people at different times, and it can be hard to get the full value of somebody's attention when they're in the pressure cooker.
I really enjoyed using Code Collaborator on a recent project, as the flow was more compatible with everybody's schedule throughout the project. I could do a commit, select a reviewer (or reviewers), and an email would be generated with a link. When the reviewer HAS TIME, they can log in to the system, see what the review queue has for them, and let them get to the meat of the differences, leaving comments/questions in the system as meta-data (NOT the all-too-standard in-the-code/* what is this never initialized?!?! */ comment). When I in turn log in (when I HAVE TIME), I can see this feedback, and if I comment further, the dialog is scoped right at the change. If I do a follow-up commit, Code Collaborator was good at maintaining the dialog for the new differences...
In any case, I found the system to be valuable, and a lot of it seemed to be the asynchronous nature of it. Not having to schedule meetings was key.
If you can get a job doing QA work for a software company, that can be an excellent education. In your interview when you discuss your interests/ambitions, let it be known that you are interested in learning as much as you possibly can about the overrall process of software developement.
If you can prove yourself a capable technology team member, you may get tapped to entry level development work (possibly at the same pay initially as QA, and done as ancillary work to your core work). You'll already be familiar with the project, the process, and the players. If you've got the curiosity, creativity, and drive, your value should increase. You'll be making less than industry average likely (cheaper, talented labor is an incentive for the company), but you'll also be paid for your education instead of the other way around.
This assumes you can find a company that has a culture that fosters this sort of thing. Remember that when you interview you are interviewing them as well; ask questions about opportunities to pursue this sort of strategy.
Those are valid statistics insofar as they reflect a very low reporting of problems, which is a good thing from the dev perspective. However, the nature of the problem is something that the majority of users aren't going to notice right away, or think to attribute to the game software on their machine. Notably, the over-time slowing down of cd burn speeds, eventually resulting in unusably slow hardware.
Not exactly the sort of thing that the silent 99% of the user-base is going to connect with game software, which is sort of the point of the noise that is being generated.
How many times do you have to have this conversation before it gets old? I'm fluent in many computer systems, and you can make a case for why they all pretty much suck without expending too many brain cells. I'm glad you've found your dogma. Stick with it, and enjoy the confines of your paradise.
I wish every person that ever complained about the "Start" button used to turn off the machine had to teach a 5-year-old with a mac how to eject a cd. "When you're done, just throw it in the trash can!" is not a great lesson to teach a beginner. At least you'll know where to look for all of the missing files off the desktop...
I've never worked at either Apple or Microsoft, although I have visited both campuses and spent time working with developers at both. Microsoft does indeed utilize "usability lab" methods, including video-taping users.
No offense, but I think you have a simplified perspective on the interface design process at Microsoft if you think developers just do what they feel like. I'm not saying you should respect or enjoy what they do, but they do iterate through designs.
I must confess that I never played MULE in my com64 days, but I am very familiar with Bunten's work. My favorite of all time has to be Modem Wars. I lost many many hours to this game.
Commanding upwards of 30(?) independently-programmable robots across mountains and through forests while under the fog-of-war (no enemy sightings unless your units do the sighting) all in real time! Vaguely based on football metaphor, each side also had a ComCen unit, which was effectively your quarterback. To lose this unit was to lose the game. The Comcen could also launch massively destructive missles, or attempt to shoot down said missles.
All of this in real time, all over a 1200-baud modem. Wow!
Slashdot Mirror
Asynchronous reviewing software systems really help. I've found that when things get busy, they get busy for different people at different times, and it can be hard to get the full value of somebody's attention when they're in the pressure cooker.
I really enjoyed using Code Collaborator on a recent project, as the flow was more compatible with everybody's schedule throughout the project. I could do a commit, select a reviewer (or reviewers), and an email would be generated with a link. When the reviewer HAS TIME, they can log in to the system, see what the review queue has for them, and let them get to the meat of the differences, leaving comments/questions in the system as meta-data (NOT the all-too-standard in-the-code /* what is this never initialized?!?! */ comment). When I in turn log in (when I HAVE TIME), I can see this feedback, and if I comment further, the dialog is scoped right at the change. If I do a follow-up commit, Code Collaborator was good at maintaining the dialog for the new differences...
In any case, I found the system to be valuable, and a lot of it seemed to be the asynchronous nature of it. Not having to schedule meetings was key.
That's exactly what happend to Michael "J" Fox.
If you can get a job doing QA work for a software company, that can be an excellent education. In your interview when you discuss your interests/ambitions, let it be known that you are interested in learning as much as you possibly can about the overrall process of software developement.
If you can prove yourself a capable technology team member, you may get tapped to entry level development work (possibly at the same pay initially as QA, and done as ancillary work to your core work). You'll already be familiar with the project, the process, and the players. If you've got the curiosity, creativity, and drive, your value should increase. You'll be making less than industry average likely (cheaper, talented labor is an incentive for the company), but you'll also be paid for your education instead of the other way around.
This assumes you can find a company that has a culture that fosters this sort of thing. Remember that when you interview you are interviewing them as well; ask questions about opportunities to pursue this sort of strategy.
Good luck!
Not exactly the sort of thing that the silent 99% of the user-base is going to connect with game software, which is sort of the point of the noise that is being generated.
Why apologize? You're not sincere, so what's the point? Reflexive antagonism makes my head hurt. Needless to say, my head hurts more often than not.
Thanks for the tips in any case. If any of the kids I know get more "modern" macs, I'll look fwd to avoiding the whole "trash can" business.
I wish every person that ever complained about the "Start" button used to turn off the machine had to teach a 5-year-old with a mac how to eject a cd. "When you're done, just throw it in the trash can!" is not a great lesson to teach a beginner. At least you'll know where to look for all of the missing files off the desktop...
No offense, but I think you have a simplified perspective on the interface design process at Microsoft if you think developers just do what they feel like. I'm not saying you should respect or enjoy what they do, but they do iterate through designs.
Commanding upwards of 30(?) independently-programmable robots across mountains and through forests while under the fog-of-war (no enemy sightings unless your units do the sighting) all in real time! Vaguely based on football metaphor, each side also had a ComCen unit, which was effectively your quarterback. To lose this unit was to lose the game. The Comcen could also launch massively destructive missles, or attempt to shoot down said missles.
All of this in real time, all over a 1200-baud modem. Wow!