Slashdot Mirror
The Most Powerful Man in Technology Journalism
prostoalex writes "The Wired magazine takes a look at Walt Mossberg, technology columnist for Wall Street Journal Personal Technology section. The magazine quotes some of the technology advances and fixes, for which we should be thankful to Walt Mossberg: 'RealNetworks overhauled its RealJukebox player. Intuit revamped TurboTax. Mossberg even forced Microsoft to scrap Smart Tags, which would have hijacked millions of Web sites by inserting unwanted links to advertisers' sites. Few reviewers have held so much power to shape an industry's successes and failures.'"
Mossberg also has one of the most powerful positions in all of tech journalism... The Wall Street Journal is read by an audience of stock investors.
In short, if you're a tech company and you don't do what he says, Wall Street's going to notice what he called you out over. That'd be harmful to your stock price...
Call me when he's managed to get the RIAA to stop being jerks... then I'll be impressed.
And although he doesn't often put in a good word for Linus and the gang, he does frequently preach the virtues of 'alternative software', and isn't afraid to take on issues like ridiculous DRM .
So, in a nutshell, that is what makes him a good reporter!
Yeah, we all know well Slashdot can predict technology. iPod anyone?
because all the PHBs are folks that don't know what their product actually _is_ or how _real_ people
/. article) as we
would use it and they need someone to slap them a bit so they can see the problems. If a lot of tech
companies actually spent any time _using_, testing, and refining a product before releasing it, things
could be a lot better. The bottom line is that many technology products need to be like the proverbial
toaster/phone; it does exactly what you think it should do and you don't necessarily need a manual to operate it.
At any rate, I agree with his philosophy, i.e. that much of technology products today are too hard to
use when they don't have to be. Part of the problem is really analysing what the function
purpose/workflow is; If you don't actually _use_ a product you designed or test it on someone not
familiar with its purpose, you might not see all those places that break your train of thought or the flow.
When I went to college(1979), a CS degree was more programmer/analyst and less code
monkey/god. As a result, while I'm not the greatest programmer, I write easy-to-use, reliable,
maintainable, functional programs that do what they're supposed to, the way the operator
wants them to work. I spend a lot of time _in_ the process so I can feel the way the workflow is going.
In a production environment, things that break the flow or require you to go someplace else to get
required information encourage operator error. It's also less efficient.
We shouldn't worry so much about how optimised the code is(see
should be worrying about whether people will continue to use a product again and again(and recommend
it to others) because it's easy to use and it works as advertised.
Computers are way fast enough as it is for 95% of the work that gets done on them, so spend more time refining!
I don't want to get into a platform flame-fest, so i'll be brief;
I still prefer to use my Mac simply because it's just easier. Dialog boxes, file browsers, etc. that are
too complicated and especially inconsistent like in many "designed for Windows" products
are my pet peeve(this applies to Open Office too.) The order of the file formats in "open" dialog boxes
seem like they're never the same from app to app; "all formats" is sometimes at the top, sometimes at
the bottom. Just pick one way and keep doing it that way!
Here are some of the things I've learned over the years:
For Designers:
- Pretty doesn't necessarily mean useful.
- Consistency, consistency, consistency.
- Can your Mom use it without calling you?
- Simplicity over complexity.
For Programmers:
- Whoever wrote, "If it was hard to write, it should be hard to read" should be caned.
Please write good comments and documentation. I've had to ponder over too many
modules with two-letter variable names.
- Assume that You will be supporting the code you just wrote for the next Ten Years off and on.
Will you remember why you wrote that module that way ten years later?
"...that's as white as it gets; all the bits are on..."