Can I Talk to that William Fellow? He was so Helpful (2009)
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
It's amazing how myopic you can get after working on a product for awhile. The time spent in contact with ordinary users who are reporting issues helps to bring you back to reality: how do users typically user the product, what common edge cases do you fail to consider, what are common pain points in the UI, etc.
So I would disagree when you say it's "not really your job" and "just plain stupid". Our job (as developers) is to create a product that helps our clients navigate a very tricky business environment -- one which most people have never experienced before working here. The time frame of the initial support training and continued learning is justified.
That's not to say that our system's perfect, mind you. In the 6-plus years since I was hired the company has gone from around 25 employees to almost 100. My initial training before actually taking support calls lasted about 4 days, then I was thrown into the fire. The current new employees spend like 3 weeks in the classroom before ever picking up a phone, which I think is far too long.
That's been my experience when I've sat close enough to hear support calls (although in my case it has always been because of small offices, not because of any deliberate attempt by management to make developers more aware of real customer experiences).
The above is done by simply CC-ing some specific developers into every customer service ticket (which developer depends on what type of problem the ticket is about). Those developers then investigate and, if needed, communicate with the rest of the dev team and coordinate appropriate action.
Since the new policy kicked in 2-3 months ago, we had two main results:
- The development team discovered (and rapidly fixed in almost all cases) several bugs that were unknown up until that point. Some of those bugs had probably been present for some time.
- The UX/frontend devs had significant feedback and redesigned the interface based on it. As a result, we have a more user-friendly website now.
Plus it is therapeutic, you are never going to feel like you will look stupid to a support person again.
* Definitely not sure how accurate this info is. Comes second-hand.
"When you join full-time, you’ll do customer support for WordPress.com for your first three weeks and spend a week in support annually, for evermore, regardless of your position"
it was a west coast company that moved most operations to the east coast. however, the manager was still on the west coast, and wasn't seeing the day to day issues. In one major instance, I remember seeing that the initial 'customer info' screen was taking a LONG time to load. Like...30-40 seconds. In some cases, it was only a few seconds, but for important clients, it was taking a long time. They could vamp and chat for a bit, but it was getting worse.
The agents were hitting a webserver in california, and pulling HTML back, across a private network, and... it was a LONG time for older clients. It was pulling up the entire client history. For important clients - who did a lot of business - it was pulling back megs and megs of data.
When I looked under the hood, the data was being repeated - an entire block of data was being duplicated inside HTML comment tags - someone had put those in for debugging stuff and never got rid of it. So we were pulling back, say, 35 meg when maybe only 18 was needed. I simply deleted the commented info - it had not been touched in 6 months - commented the reason in the svn commit log, requested a new push go out, and the next day things were hugely faster.
I got my ass kicked. I "went behind someone's back" (untrue) and "jeopardized production systems" (untrue). Other people had seen the code and it was pushed out via normal process. It was simply the original developer didn't like that I'd highlighted something he'd forgotten to do. :(
I then angled for actually using gzip compression but was shot down at the time (no, "there's a bug in IE6 with gzip compression and printing" or something like that), even though the gzip would have brought this down to under 1 meg, and every call would have been 'up' in under 4 seconds.
We were further shielded from ever talking to CSRs, because they "might overload us with requests". It was (and still is) a bizarre rationale. :/
It's stupid behavior as far as the company is concerned, but from whoever you made look bad, well, they stopped that from happening again, didn't they?
They exist to solve real world problems for people, using software as a tool. I don't know how anyone can possibly do that even if they don't actively engage their user base and proactively solve workflow issues the end-users may not even know are technically possible.
Very frustrating to watch entire teams spend years on internal corporate business logic apps and never even once spend time with the teams consuming them. The results are always entirely predictable.
It's really, really frustrating when developers don't realize that. The most valuable thing I ever did at any company, saving just under a million dollars a year, was literally just me talking to three people, realizing that none of them were on the same page, and just talking to them to solve the problem.
More valuable than any code I've ever written. We're problem solvers, not just programmers.
The first part is to try to learn from them - how do they normally use the system, what isn't working today, and any errors that are (or aren't) showing up. The hard part in this is in actually wanting to help the person and/or solve the problem, and not getting caught up in your own superior ability to avoid the problem. The first step to good troubleshooting is checking your own ego at the door.
I was working for Tandy, repairing TRS-80 Model I circuit boards when he and his partner, Paul came to Tandy Apparatus with some engineers from Tandy R&D. They had the first masked ROMs for Level II BASIC. They put them on a board and tried it and it didn't work.
I took the board I had just repaired and went to them and told them that they were in a repair area and all of the boards were in need of repair. I offered the board I had repaired and told them that it should be able to run their ROMs.
They moved the ROMs to that board and powered it up. It came up with a MEMORY SIZE? prompt and William said to press enter. I did and it gave a READY prompt. I typed in a one-line program to print numbers and it started scrolling numbers down the screen.
William was so happy that he offered me a job at his company. He said that he had about a dozen employees. For personal reasons I was unwilling to locate outside Texas and turned down his job offer.
http://www.shmula.com/customer-service-andon-cord-jeff-bezos...
EDIT - Wikipedia has more detail. Apparently the main reasons workers pulled the cord were "missing parts, safety issues, tool malfunctions and defects found/created."
Scroll to the bottom :-)
This is comedy gold.
What boggles my mind is, there are lots of people who have good usability taste. But so many software vendors seem to have no-one with taste in a position to do anything about it as their priority. Hence so many crappy UIs…
Funnily enough, I just shared this with a friend two days ago.
Say what you will about Gates, he's a pretty normal guy at heart.
I remember when he was in town for the Windows 95 launch he was just poking around in various local shops, checking things out, no security detail or anything, just one scruffy haired guy going about his day. It's just like, oh, there's Bill Gates looking at bonsai trees.
At the end of 1989, Microsoft was not as famous as it later became. MS/DOS was just one of several competing DOSs in a much smaller market. And DOS was their main product.
I doubt that even amongst most MS customers there'd have been name recognition for Bill Gates, let alone such reverence.
I don't have any particular reason to believe the story as it is told, but I am not sure that is a reason to disbelieve it either.
https://en.m.wikipedia.org/wiki/Timeline_of_DOS_operating_sy...
I recall Amstrad in UK had its own DOS in the early 1990s. They had to declare MS compatibility, which supports your view of MS already being dominant.
I also don't remember much before 1989, but I believe the languages business was earlier and more niche. Ever read Gates' 1976 rant about hobbyists ripping him off?
I remember my PC-1512 (XT clone with 512 Kb RAM, two 5.25" floppies and a mono CGA monitor) and it came with MS-DOS 3.x and DR-DOS boot floppies and also included the GEM window manager. I believe the version of DR-DOS used could also run CP/M 86 executables as well as normal DOS programs.
Yes, I had read his rant, I think it was originally to members of the Homebrew Computer Club, maybe paraphrased, in Steven Levy's book "Hackers: Heroes of the Computer Revolution", some years ago. Pretty interesting book, though I guess Levy may have hyped it up some for sales. Still remember about (Peter?) Deutsch, a lot of stuff about GNU, Lisp and Emacs development (some of the most interesting parts of the book), milliblatts, TECO and many other topics .... :)
And my favorite slogan of all from the book, "Tools to make tools" :)
Sure, Bill Gates was even more famous later on, and Microsoft was even more of a dominating factor in the 90s, but he wasn't chump change in 1989 in the least.
Being in university, I get to see a whole range of people. You realize that people don't really have a robust mental model of how their computer works or how the software they use is structured. Then we 'computer people' wonder why they struggle with our software.
There are so many times I'll watch someone go through a laborious process to find a google doc, despite having seen a link to it on their screen at least 4 or 5 times. Or I'll see them go to the search bar, type in google, then start their search. Or go to the file menu rather than use shortcuts (every. single. time.). Or use tabs to manually center things rather than use the center button.
Even relatively advanced users will completely miss the existence of styles in Docs & Office.
And all of these are just the basics. We really do need to make software easier/more intuitive.
It's such a massive help in finding what can be confusing, what requires industry knowledge, what is easy for a developer vs a user, etc... It's so often that we as developers take some knowledge for granted, and helping the user either get that knowledge, or not need it is monumentally helpful.
Sadly, I've found that once they do that, they are "tainted" and can't really do it again as well with that product, so it's something I try to do as late in the process as possible. But it has been what prompted me to throw out an entire redesign for a screen and start over very late in the process, and to good effect.
I'm seriously afraid our usability will suffer when we run out of people to do this with.
(I work in the marine industry; when a customer has a problem, he's often way out on the high seas, outside of even helicopter range - so, effectively, if whatever issue he's facing cannot be solved with what he's already got on board and some detailed instructions, he's SOL.)
After breaking down the solution (hopefully, we're able to isolate the problem!), I bring all the required hardware, software, scripts and my first draft for the solution document to someone Not Into Automation & Control(tm) - say, the cafeteria or cleaning staff and ask them to work their way through it.
It never ceases to amaze me how many things we just take for granted after working in a field for a few years. ("Oh, but surely it is self-evident that..." "F--k no, it isn't!")
Result: Someone not at all involved in the day-to-day management of our products feel a much stronger attachment to the company and what we do to stay in existence; a customer gets a procedure which is so detailed, they can have anyone do it; I get to sleep well as I know the tasks sent offshore are as detailed and correct as I can possibly make them - and everybody is better off. At least I like to think so.
First thought: what if the software could guess that you're trying to use tabs to center text, and offer a hint to use the "center" button instead? Then I realized that Microsoft Office already went this way once, and we all know the result.
It's a tough thing, making people use your software well, especially if the target audience is not to be expected to actually want to learn anything.
Makes me wonder though, where does the difference between Word and e.g. Photoshop come from? Both are professional tools, but with the latter, you don't get people stuck at the most basic level and utterly clueless. They all know this is a tool and they need to learn to use it.
Photoshop is a tool that you have to specifically seek out, whether that means buying it or "acquiring through other means". It's got a smaller population of professionals and hobbyists who are used to thinking of it as a tool. I think that's where the difference comes in.
Why can't society shoulder some of this burden. We should be teaching people to understand computers and difficult software; the 'make it easier' answer leaves everyone worse off because software is everywhere
- Prepackaged food. Why should lettuce leaves be separated, cleaned and packaged in handy sizes? People should be totally okay with tearing apart heads of romaine if they want to make a salad.
- Zippers. Way back when, people fastened and unfastened buttons or laces to get their clothes on. That seemed like a reasonable burden at the time, so why didn't we just leave it like that, instead of switching to zippers?
- Highway exits and lane merges. Designing a network of roads can be difficult. How many signs alerting you to the next exit are sufficient? What if we asked everyone to pay attention to one clearly posted sign, because anything more is redundant?
I'm grateful for all the simplicity that keeps coming into my world. If grocers, clothes makers and urban planners can embrace simplicity, the software industry can, too.
Tangent, but: prepackaged food irks me. So you pack lettuce leaves in nice small plastic bags, or wrap each cheese slice in a piece of paper and put ten of them in a plastic box - basically creating a humongous amount of plastic waste, all because people can't be bothered to use a cheese cutter or pick the lettuce with their hands, and express this as market preference.
> Highway exits and lane merges. (...)
I like to point at cars as something that somewhat got this right. We're not letting a person to enter the car first time in their life and go driving on public roads immediately. Everyone understands that a car is a tool and needs appropriate training to use. People are willing to spend 30+ hours on driving lessons without blinking, because this is obvious - it is expected by society.
I think we could use a bit of this expectation in software industry too. A lot of software is "unintuitive" only because the user couldn't be bothered to spend 30 seconds thinking about what's on the screen, not to mention using the "help" menu or reading a manual. We can keep dumbing down our software, but there's a trade-off - beyond some point, the only way you can make something easier to use is by removing its essential features. There's no amount of modern UX and Angular code that can make a CAD tool or an accounting package masterable in 30 seconds.
I don't want simple software because my problems are not simple. Computers need to move with me at the speed of my thoughts, and simple software simply cannot do that. Our modern world of software feels like shit-plastic Duplo blocks when I grew up building skyscrapers in Lego
* MP3 players: I used to have a device with buttons that fit into my pocket that was able to locally hold my entire music library. I could control the device through my pocket without needing to look at it or hold it in my hand, it presented a filesystem with folders that I could simply drop music into (or whatever files I wanted, at the time 20/60gb in your pocket was a big deal). Since everythings' transitioned, first into library-based management and then into touch interfaces, actually using an MP3 player (or more specifically, whatever music program is on your phone) sucks so much more now
* Software used to work regardless of what happened to its creator. Desktop software still largely does. Nowadays it's almost like entrepreneurs enjoy writing emotional sunset posts, completely oblivious to all the customers they've fucked over because they suck at business
* Computer internals and abstractions were more exposed. Computing is slowly moving away from keeping users close to abstractions -- using modern software it feels like Product Managers want to erase and destroy users' concepts of things like files and folders. Cloud services would much rather you think of their software as an interface to their silos, and the kind of interoperability that you used to get for free by sticking to a 'protocol' of files and folders, is no longer there. (How hard is it to examine iOS or Android at the individual file level? How hard did it used to be?)
* I used to be able to open most software on my phone without being nagged with a popup for some reason or another. If it isn't a "HEY LOOK AT THIS NEW FEATURE YOU STUPID USER WHO NEVER EXPLORES ANYTHING" it's a "PLEASE VOTE ME FIVE STARS". Software talks too much, and I don't want to have a relationship with its creator. Leave me alone!
* I used to be able to boot up my computer (or, hell, even my Playstation!) without being bombarded with update requests. Software used to be finished, and as a program matured you could expect patches and update frequency to fall off dramatically. Our brave new world of evergreen programming means I am perpetually hassled with updates that I don't want, don't care about, and are frankly unnecessary. Sometimes those updates even remove features, sometimes even features that I am using! (How the fuck is that acceptable nowadays anyway? In what industry is it acceptable to take something away from users that they have paid for? We have compromised our standards too far!)
> Since everythings' transitioned, first into library-based management and then into touch interfaces
I can forgive touch interfaces (smartphones are awesome, and a good headset will have buttons that can be used for track control), but I don't understand the whole library management thing. How on Earth did that happen? Why did iTunes-like interface win, with all that bloat and pointless misfeatures when all one needs is simple way to filter a list of your music files and group them in logical playlists?
Moreover though, in the better days, you controlled your music. It was made of discrete data files. The modern way is all cloud bullshit you have to stream over the Internet every time you want to listen to it.
> Computing is slowly moving away from keeping users close to abstractions
This is huge, IMO. The "low-level" abstractions of files and folders are good, because that's the level software operates on. All those attempts at abstracting files away only lead to your system actually lying to you about how the data is structured, and this can be confusing to people because different software now tells different lies, and they don't add up to a coherent whole.
> This is huge, IMO. The "low-level" abstractions of files and folders are good, because that's the level software operates on. All those attempts at abstracting files away only lead to your system actually lying to you about how the data is structured, and this can be confusing to people because different software now tells different lies, and they don't add up to a coherent whole.
Ah, your word processor can count words. Can we sell a separate product that counts words in documents? Ah, your network interface can be taken up or down. Can we sell a Network Management Product?
Companies still make standalone MP3 players that use dropped-in files and dedicated button controls. In fact, they're cheaper and more available than ever. https://www.amazon.com/Sandisk-8GB-Clip-Player-Black/dp/B00V...
> How hard is it to examine iOS or Android at the individual file level? How hard did it used to be?
It's easier than it used to be, as iCloud on iOS effectively added a shared file system that didn't originally exist.
They succeed in the market because they make complex tasks seem simple. Sorry about the Duplo feeling, and it's a familiar lament of craftspeople everywhere. But we aren't going back to the days of artisans trimming lettuce heads one at a time. Too slow; too costly.
In a model of software consumption where users aspire to better themselves, yes the beginner is stymied but the possibility is still there for completing the task. That's not possible in our current model -- either the program works and you use it the way the designer intended, or you're fucked.
There's an alternative which satisfies both constraints: simplify UIs for the most common use cases while still allowing access to arbitrary amounts of capability for those who want it. There's a reason that every personal computer in my family runs on some flavor of Ubuntu: the default GNOME setup is 50x easier to use than any Windows computer[1] for people like my dad, who's a non-savvy enough user that he still struggles with copy and paste. Yet, it still allows the motivated to Google around and do things like change a single file in a theme's assets folder to make your panel transparent, something I actually did back in college when I cared more about things like themes.
[1] Note that I'm talking purely about the OS itself as an illustrative example of my point: having to be careful and buy a computer without hardware compatibility issues is a separate issue and is an actual pain in the ass that very reasonably prevents many people from following my example and switching their family to Linux. I just did it because installing Linux once every few years was a hell of a lot less work for me than debugging Windows over the phone once a week.
Sure we can have schools teach people how to use PCs, but then people only know how to use certain software. If you've been taught extensively how to use Office and Windows, and that's all a computer is, then LibreOffice, docs, and Linux will be a challenge. Microsoft loves this and Apple has used it extensively in the past.
The danger for competitors is real. Office has caught up in the few features it was lacking; I've seen a resurgence in usage and very rarely see freshman using Google docs anymore (when I entered uni it was the opposite). Google relying on a dated, unintiutive interface that kids don't learn in school anymore is going to kill them if they don't react.
Stuff like, "most software has a menu bar, you can expect to find File, Edit, Window, and Help menus, here's what they usually mean," and so on.
If you teach a narrow set of skills and don't train for flexibility, your robbing the students by pigeonholing their skills into only being applicable to a segment of the market.
I've seen friends who can do mail-merge in Word but cannot navigate the internet on a desktop with the ease and speed I can because they learned mail-merge in school but never bothered to browse internet on a laptop/desktop (instead they use phones all the time).
And gives you a leg up on the competition.
Most software should aim for simplicity though, I am interested in using your software to pay my bills then get back to reddit, I don't want to learn a complex system.
Software complexity should match the complexity of the problem space. The problem today is that the trend is to make oversimplified software. I guess it's fine if it lets you pay your bills, but maybe a little more complex software would let you earn more money to pay those bills with, by expanding the amount or complexity of things you're able to do.
For example, I'm a programmer, but every now and then I open up and clean the office coffee machine, or mop up a spill in the break room. This isn't what I'm being paid for but doing a good job at it makes me happy, and NOT doing it would be being a jerk.
My impression doesn't come from the pop culture portrayals but rather from people who have been/are managers and hearing them on podcasts. But my opinion isn't based on that.
To me (which is a very narrow worldview at the moment), the only measurable things in management are:
- product delivery - product cost - customer satisfaction - dev team satisfaction
And two of those cannot be measured in any meaningful way. Whereas in coding (and I don't like these measures) I have lines written/deleted, work items fixed, product completion, feature parity with the design document (and quite a lot more I'm sure) and most of them are measurable.
This is the basis for my view.
PS: Thanks for sharing your views and telling me that management can also allow you to see impact of the work. Also, I do think that more managers are needed who are knowledgeable (or at least willing to learn/work with other who know) with business, development and have domain knowledge of the product (like an EPR dev should have at least used an ERP) so I also want to improve the situation by going into management if I like it.
I'll have to experience it once I get into a job (starting this July). Thanks for the insight.
Me: "I'm supposed to be running a paramilitary campaign. Why am I repairing someone's carrot?"
Her: "All managers ask themselves this darling".
Cue hilarity all round.
I approached him and spoke to him for a couple of minutes - primarily about some additional British products I thought they should have in that section of the store.
Apparently he missed one such thing by sheer bad luck. From the comments:
"Bill queried the knowledge base, which was normally painfully slow, but this time it was snappy and responsive."
Of course, being informed about it may very well discourage some people from pursuing side projects. But then this comes down to whether you'd rather have developers continue with their side projects oblivious to the potential consequences of doing so.
My friend and fellow intern Tad fielded the return call from the guy who had the issue, and while I didn't speak to the customer myself, I believe Tad's account. It makes sense to me that Bill's answer wasn't quite correct, he did just essentially read the customer the first result from querying the error message on the Knowledge Base.
I mean it's possible, but it's also possible it's just a nice story.
Those details were fictionalized by the author. Everyone who wasn't actively on a call at the time new all about Bill's call, because we were all standing around my cube when it happened. Not long after the call was over our entire team knew all about the call, what the issue was, and how Bill handled it. If I recall it was about an obscure linker error message.