03.24.09
Posted in Best Practices, Web Design at 12:55 am by madcap
According to an article from Valleywag, Mark Zuckerberg had some not-too-pleasant-sounding things to say about Facebook users:
“He said something like ‘the most disruptive companies don’t listen to their customers.’” Another tipster who has seen the email says Zuckerberg implied that companies were “stupid” for “listening to their customers.” The anti-customer diktat has many Facebook employees up in arms, we hear.
It’s difficult to tell what Zuckerberg’s real tone was, since the above is hearsay. If his point is that a company never has to care about or listen to its customers, he is dead wrong. On the other hand, if he believes that innovation rarely bubbles up from one’s user base, then he is correct. It is the balance between the two forces that makes or breaks a company.
Read the rest of this entry »
Permalink
04.02.07
Posted in Rants, WTF at 5:21 pm by madcap
Reason #43: Everyone’s selected music starts playing when you load their page, regardless of any preferences you might have set for your account.
Permalink
10.10.06
Posted in Best Practices, Software Development at 3:00 pm by madcap
If you’re a trained software engineer (or purport to be one) responsible for a certain area of code along with team members, and you encounter a problem while testing some related area, have the decency to follow the following steps (in order):
- Gather all pertinent information, at least in your head. You’re a software engineer and should be more familiar with the area than a key op tester would be. So, whether you’re going to debug the problem yourself or ask someone to, you should have a much better idea of what kind of data to collect in order to triage the problem. Don’t just assume your teammate will be happy to reconstruct what you were doing and where logs, etc. might be. We may have to act like detectives sometimes, but it doesn’t mean we like to.
- Try to identify the problem yourself. Even if it’s probably not your fault (and it never is, is it?), what’s stopping you from looking into the problem a little and seeing if you can identify the bug. Hell, if it’s simple enough, fix it yourself. That’s why you’re on a team.
- When describing the problem to others, be detailed. Your teammates are not mind-readers. You know how frustrating it is to get a bug-report from a non-engineer along the lines of “the feature didn’t work,” so don’t do the same to your teammates, or any engineer you’re asking for help from. Personally, I react very poorly to someone showing up in my cube and saying “X isn’t working. What’s broken?”. A corollary to this is if you’re asking another engineer to look at your code (informally or in a formal review), give him or her some background as to what the code does, what you changed about it, and why. Just throwing some code listings in my face and asking me to look at it is probably going to garner a “looks good… whatever” from me, or at least force me to ask you explain yourself (if I’m feeling charitable).
Permalink
