Ed: Second in the series, see Dwight for earlier one. My reviews of Bravo’s Startup Silicon Valley
What I learned from Bravo’s Startup Silicon Valley about Women in the Valley
I could write a detailed diatribe/analysis of the reality series in contrast to my life as a woman engineer in the city I’ve lived in for 30+ years. But, instead, I’ll just tell you what it would tell me if I knew nothing about it. Therefore, not coming from the informed reality that is my life, but what Randi Zuckerberg’s – sister of Mark and executive producer- her reality and/or version of her experience in my hometown, the friends she cast, and the overall effect the producers, including but perhaps not her directly her input, that influenced the image of the woman in engineering-entrepreneurial SF tech to the rest of America. I do a bit of end-notes stating where/what I get this from after each statement. And, you know, you be the judge.
Women in Silicon Valley get their hair done for hours by professionals at fancy hotels, feeding their dog steak from room service (Sarah). Women in Silicon Valley aren’t actually programmers – I never saw a woman sitting at a computer coding (Kim was working at a computer, but mostly talking to her coworker). They always talk on speakerphone (some requirement for reality show people, I assume), and do their nails at salons. Sometimes, they make inappropriate sexual jokes (Hermione), and do gymnastics in living rooms (Kim). They live in apartments that are in the higher end of the rental market (Kim, Hermione). They don’t work, or, you never see them work (Hermione, Sarah).
This combination of not seeing them work and having high rent lifestyles equates to this magical source of income and/or “what are they doing?” tension while you’re watching the show. They are very comfortable speaking in public. They wear the latest fashions. They are unsuccessful in dating. They are very unaggressive in dating, waiting to be asked out for most of the season by various guys. They are young, straight, and mostly blond.
They have poor backgrounds and/or backgrounds and childhoods in other careers that are not tech-related. Most of their time is spent having complicated interpersonal friendships (Hermione, Sarah), or agonizing over career changes (Kim) or business partners who don’t let them do what they want (Hermione).
In investor meetings, they say “And my brother will discuss the tech” (Hermione) (even though he then hires an engineer to “do the tech”). In interviews, they ask pointed questions about how much money people are going to get (Sarah). They say a lot of generalizations about what it’s like to be “in the valley” (Kim, Hermione). They don’t drive cars (Hermione, Sarah). They are driven around in more expensive cars by men. They have very emotional tantrums in public (Hermione, Sarah).
Basically, a kind of primped up bag of feelings, in a lifestyle paid by men. And how is this different than Basketball Wives (A show I adore, btw.)?
Maybe my next post will be: my view of women in the valley. Hmmm.
Ed: Unlike most of my peers in tech, I liked Bravo’s Start-Ups Silicon Valley. When I gave recaps at lunch, everyone seemed interested, so… I’ll be posting a series of blog posts on characters, themes, and general responses. Too busy to do recaps, sorry.
Dwight is the engineer formerly from Google who is the archetype: young, white, male, nice, and smart. His Achilles’ heel and dramatic tension would either be his inability to admit his undying love for his friend Kim OR his intermittent abusive social drinking that leaves him blacked out and wondering what the f**k he did the night before. Besides that… he lives and works in a 2-bedroom in a 60s dilapidated apartment complex in Mountain View, sharing this with some of my other single male friends down there. I know a few Dwights, and they know each other, actually too. Note: I will stop playing the Name Game since it really doesn’t say much more than: it’s a small town & I’m in tech.
His storyline was the most realistic to me, and probably because of this, the least fit for drama. Because successful engineer-entrepreneurs are working all the time. Sitting at their computer, working. It’s boring. Which makes this series somewhat ill-fated. The sad part of the story was the end (spoiler). His startup, a way of finding a car on the internet “Carsabi” is bought by Facebook. Facebook kills innovation again, because honestly, have you seen the car search on Facebook? I haven’t. Will we ever see it? We do know that Facebook got a good entrepreneur-engineer (among their leagues). How much does he get for it? He doesn’t say, but he does buy a nicer car, get a real bed. And, he works now at Facebook. Is that a good outcome, for him (the 9-5) or for us, deprived of new way of searching for cars? Note: in other articles, turns out Craigslist blocked him which prevented his startup’s success.
Acquisition versus taking it on yourself- that’s an interesting conversation to explore with our characters (which we never hear them saying more than a soundbyte, over and over before and after commercials, Bravo-reality-show-style). But real business conversations aren’t in this show, I’m not sure why. Because we wouldn’t be interested? We’re watching a show about Start-ups, we’ve already “gone there.” OK back to Dwight. He works hard, he’s scrappy and lives very low maintenance, and we all know he’s the one we would invest in. Why? Because he works hard and got shit done. His low maintenance lifestyle shows that he makes good decisions. He works well with his partner, he seems pleasant to work with, and nothing ridiculously stupid has come out of his mouth. Toga parties and algorithms? That looks really staged, but perhaps is supposed to spice up the life of the average viewer, or show that it’s not all sitting in front of your computer (when it really is). The best quote, as usual, comes from Kim-of-the-vocal-fry says, “It’s funny because Dwight is always in front of his computer.”
Technical review: two points at which we hear Dwight actually discuss programming: he turns to his business partner, and asks him how long the Android app will take. The guy says, “I don’t know, I just started today.” That was awesome. Another good quote (of 2 tech quotes, I’m serious, there’s less tech in here than in [insert Bravo series I don't watch]) … another good quote is: “What’s the jQuery for __?” Partner: “___.” Dwight: “Thanks.” As I said, realistic, and probably not good TV. Up there with Warhol’s Sleep.
Dwight Crow’s life is unreal on Bravo’s ‘Silicon Valley’ and off LA Times
I’m sitting here at work kinda slammed and sick, but hey, it’s ALD, and that’s kinda cool.
At work, we were talking about Ada Lovelace – interesting because we are in fashion, and her first application was making jacquard. I love that fact.
In thinking about Ada with this coworker, I realized that she is an important lesson in what one can do with childcare, money, and education. She heard about someone making a machine, thought about how she’d apply the technology, and wrote him a long letter with instructions… before it was even built. She had the leisure and time and energy to pursue science and math.
So next time you’re judging an industry on its lack of women, don’t say “because they don’t have interest/ability/”they don’t have minds like that”" think instead of how the world would look, and be, very different if everyone had equal access to good math and science education, childcare if they chose to have children, and time to study and pursue free projects, if they could afford it.
Hm. Opinionated a little?
A couple of times, folks ask me: do you know X? And I say, why, no I don’t. I do know the language that X avoids. X is: Objective-C, Java, etc. the list goes on. Tonight at a study group, a friend who had just learned Objective-C agreed with me (I had told her- “… just learn it, it’s not that hard”) that “It’s not that hard.” See??!! OK maybe an anecdote isn’t enough to prove my point.
So you want an iPhone/Android app. You’re worried that:
- You will invest a lot of code into one operating system
- You will alienate the other users- iPhone or Android (OK, face it, usually Android)
- The native language is hard
None of those are good reasons. Why?
1: Think investing in Android/iOS is faulty? Think of investing a lot of time and effort in a framework that, while fancy and fun today, will go out of favor in (count them) 4 months approximately. Rarely do these last that long, for various architectural reasons. It’s a total b***ch keeping up with two different platforms (iOS/Android) that are constantly evolving- think of this from the framework’s perspective. At least Google & Apple have a lot of developers building out their SDKs. Most hybrid/cross-platform frameworks have a few open source fans, or a crew of 5-20 developers in a start-up/funded environment with various levels of skill.
2. Different businesses and apps have different target markets. Figure out what devices your users have, how they use them, whether they use native drivers (camera, voice, etc.), and build a simple, native or web app for them. And then roll out a comparable one (or even diminished in features) for the smaller represented set. Or, build in the most popular native operating system for your target demographic, and create a web version to encompass the others. Or, what I like to do, wait for people to complain. If enough do, there’s your market, develop for that.
My most conservative, time-saving, and risk-adverse advice is to build out testing. And rarely do new frameworks that straddle both native systems have good testing frameworks. That’s a pretty strong reason in itself.
My hackfest-programming-partner Stacie Hibino and I submitted ChickenDance to the 2012 iOSDevCamp Hackfest. We were in the first batch called up to demo, and had various network issues that resulted in the much competed for prize: “Best App with Demo Fail.” I had been holding out for a “Had Most Fun Making App” award, but had to lower my hopes when our names were called.
It’s the third “win” for us at the iOSDevCamps. We won “Best New Developer” for DicePad (throw a dice from iPhone to iPad), then “Best Social Game” for “SocialPong” (play Pong with X number of people, consoles are your phone in HTML5).
I’m still suffering from the blow of the Demo Gods. Our app takes a voice input “song” and mashes it up randomly with a 7-second dance video. You can also input video “dance” and that will mash it up with 7-second long songs that were recorded earlier. So, oddly the video worked later in the hallway. We got this fun mash-up of the audience doing a wave to my song “YMCA”:
Of course, it’s a sign of loving inclusion to get the award. The worst would be – being ignored – no prize, or having it fail just generally. The fact that the app works, and that we had a lot of fun playing it earlier, is testament to something, right??
Future mods will be: using a database (instead of Amazon S3 exclusively- was a delay in scanning directories) and using Facebook network, as right now it might devolve into a Chat Roulette problems.
The tradition with the dev camp is to mod the giant skeleton head booby prize. for the next poor soul. Stacie has some fun secret ideas. We put an Angry Bird in the eye socket as a hint to what may come. I’m thinking some kind of vicinity detection that emits smoke from its eyes.
One of the camp founders, Christopher Allen, tweeted:
@banane @staciehibino it is not a booby prize, but a celebration of effort! Freedom to fail is important! #iosdevcamp bit.ly/Miezqp
Very true, very true. Still, it’s hard when your super cute app flails. I do usually learn from failures, from this one, the lessons were: don’t change your wifi settings right before the demo, and, test the exact sequence of the demo BEFORE the demo.
The New York Times just announced: Marissa Mayer took the position as Yahoo’s CEO a few minutes ago. She has broken through the glass ceiling at Google only to encounter the “glass cliff”:
via Wikipedia/Univ. of Exeter:
A glass cliff is a term coined by Prof Michelle Ryan and Prof Alex Haslam of University of Exeter, United Kingdom, in 2004.
Their research demonstrates that once women break through the glass ceiling and take on positions of leadership they often have experiences that are different from those of their male counterparts. More specifically, women are more likely to occupy positions that are precarious and thus have a higher risk of failure – either because they are appointed to lead organizational units that are in crisis or because they are not given the resources and support needed for success.
The telltale signs that make this a classic glass cliff situation are:
1. It’s a position of leadership
2. The company is in crisis
3. Average or under-skilled for role
She’s inexperienced at being a CEO, and the company is in huge crisis. The former CEO’s (with lots of experience) have bailed and/or been chucked out (see: Carol Bartz). She’s also quite young. Her background is in engineering, not management. Unlike Campbell’s woman-CEO, who is very experienced, trained for the position, and the company was not in (this level of) crisis when she took over. Or, Jobs swooping into Apple when it was in the shitter. Hm. WWSJD?
Why is Yahoo in crisis?
Here are Yahoo!’s latest headlines:
450,000 Yahoo users hacked
Yahoo calls off patent battle with Facebook
Yahoo CEO resigns after resume scandal
Yahoo! founder leaves, paving way for possible sale
… and so on.
Here’s a metaphor: I see Yahoo as a tall-masted ship in the era of WW2 battleships. They lost the search wars, and have been unable to innovate at the same speed as their competitors. Now, they’ve hired a top artillery midshipman. But the ship still has cannons. See what I’m saying? She’s managed a ton of people, true, and been at a really great organization- Google- but now she’s at Yahoo!, floundering on a model built on ad revenue, a failed inbox, and corrupted data. Compare corporate acquisition strategies: “… Google products originated as services provided by companies that Google has since acquired” (Wikipedia on Google Acquisitions), whereas Yahoo has “acquired and killed” startups (Gizmodo).
Best of luck, Marissa (gulp). If she figures this shit out, I have 2X the respect for her, than I already do, and that’s quite a lot.
(photo credit: Horrible Tianmenshan glass cliff in Zhangjiajie, Hunan)
I really like attending conference talks on how people screwed up. Not just to laugh at their mistakes, but to learn from them. It’s important to fail, and so many people are afraid of admitting it, for various reasons. Thing is, if they failed at something awesome– a new gaming console, a cure for cancer, a self-cleaning apartment robot, learning Tlingit– you end up respecting them. If it’s a stupid mistake, yeah, that’s not that interesting.
1. What did you fail *at*. Was it a worthwhile, ambitious, interesting, valuable goal? Did you expect a certain outcome and get another? Was it unexpected? Was it worth the doing?
2. Interesting people fail a lot. For example: Abraham Lincoln, had quite a rocky life and career. Do I want to sit next to the skyrocket-to-the-top success, or the one who endured struggle and challenge after challenge? It’s not just that I’m a blind lover of the underdog, but find it more interesting when someone can speak intelligently as to how they got where they are.
3. From that last point, why is someone who has failed a lot more interesting? It’s the magic of:
an important/ambitious/boundary-risking task + an attempt (sucess or failure) = interesting lesson
Easy success? Not a lot learned. Safe success? Also rather boring. “We kept selling the gizmos that were already selling well!” Not as good a story, nor as useful, as, “We tried digital cameras but they were too expensive (our users said). Next time, we’re making them from cheaper parts/less features, and lower price.” A lot more interesting.
Work Isn’t Play
This is true, and one of my pet-peeve buzzwords in this industry is “play.” I had a teacher who called coding “play” and while I know what she means, it’s largely not “play” to write test scripts. Writing “f**k you” over and over again recursively on your screen (as I saw a teen do in a Ruby class) is, though, play. And funny. She didn’t innovate, but let her doodle around some more for a few days/months, and who knows.
What we get from playing, though, (reference: Jane McGonigal’s talk on gaming) is that, obviously, we’re goofing around. We’re having fun. We’re experimenting, being creative, testing boundaries, all great ingredients for innovation. Still, we need safe parameters, lack of repurcussions, etc. Interesting that when we were kids playing on the playground, I personally remember falling *a lot*. But I didn’t think “I should never play again on the jungle gym again,” I simply went out there the next day, with bruises fresh and callouses, and climbed up a different way, or held on longer, or something.
Similar to anything, you can fail a bit more safely: fall better, cushion the blow, fail fast. Talking to a client the other day, I was like “you can fail long and painful and expensively, or fail fast.” Not that failure was imminent, but he was worried about whether the idea would be good, proofed in the market, etc. I’m a fan of course, as we all are, of failing fast. It’s a bit of an oxymoron, failing safely, because if you were attempting something safe, it’s not a very interesting failure. How you can “cushion the blow,” though:
- put metrics on everything
- lock down a time frame (fail fast)
- make sure the only variables are the ones you are testing (no new talent, no new features, etc.)
I wrote a blog post about Cedar way back in the day. Now, Xcode ships with OCUnit.
I’ll go through a basic way of adding tests to an existing project, as that’s a very common task, and not very well documented thus far. Props to the following blog posts- I’m consolidating their advice basically in a single one, with screenshots.
Why do tests? Well, it’s a great way to work. If this is new to you and you’re more interested, check out tons of resources referring to Test Driven Development (TDD). Of course, if you read this from a Google search, you already know what that means.
1. Add New Target
1. In Xcode 4 (.3.3, for me), add a Target. Took me forever to find this. It’s the “+” circle at the bottom of the Project pane:
2. Set to Cocoa Touch Unit Testing Bundle
2. Change Target Build Phases & Settings
Click “Build Phases”, expand “Target Dependencies” and add your App.
Click “Build Settings”, and add:
Under “Links”, “bundle Loader”, “build/Debug-iphoneos/[yourapp].app/[yourapp]
Under “Unit Testing”, “test host” put in “$(BUNDLE_LOADER)” (will populate with bundle loader).
3. Change App’s Bundle Settings
Set “Symbols Hidden by Default” to “NO” – frankly, this is usually already set to No.
4. Test to Run!
So let’s run this, even though the sample test sends a failure. Still, it’s good to see that in action right off.
Now, if you’ve installed this into an already made project, you will select the target in the “manage scheme” area, then select Product/Test from the menu.
One distinction- if you’ve started a project with OCUnit “baked in”, then you don’t have to select the scheme/target in the upper left, simply use Product/Test from the menu.
5. Check Out Those Errors
Unlike the lovely test frameworks in rails, and some other languages, OCUnit prints out boring black and white console log errors: so have your console up and running when you Product/Test. Here’s some live test results!
* Testing your Bay Area cred… this title is from the ad that ran 50s… 90s in the SF Bay Area for Berkeley Farms, that had a very catchy tagline: “Farms? In Berkeley? Moooo…” Several radio spots can be heard on their site now, and you can check out some old photos of this neat Berkeley dairy.
I really have never thought I had Imposter Syndrome. I’m not a shrinking violet, I tend to talk pretty authoritatively, I’m confident, like to speak in public, etc. Yet, I joined a mailing list for women-techs and during discussions this term came up. I looked it up, and started locating this behavior in a few of my interactions.
Imposter Syndrome is the feeling of inauthenticity, that you will be “found out,” that you don’t belong, and roughly that everyone has reached some basic level of knowledge or performance, that you haven’t.
Your accomplishments are due to:
- or as a result of deceiving others
I only got that award/Hackfest win because of tokenism, or because our competition wasn’t that great. Or, they thought it did something it patently didn’t (good/fake demo?). Not only do I think these things occasionally, but, others tell me this. I’m not kidding. Right after presenting Ruckus at AngelHack this guy accused our demo of not working, of being faked. To our faces. Most presenters didn’t even have a demo, and very few had one that worked.
For me, the imposter syndrome rears its ugly head during technical interviews. No matter if I’m a subject expert, no matter if I don’t know the backgrounds of the guys (and they are always guys) interviewing me, I will give them more authority than they’re worth, and think they know things I don’t know, and doubt or diminish my own accomplishments.
Afterwards, when reviewing the transcript in my mind, I am amazed at my lack of confidence and surity, and, generally, how I give them more than the benefit of the doubt. My solution to this- work more and more on doing LinkedIn checks before the interview, or, ha, ask what material’s going to be in it so I’m prepared. Also, as women (or people,) we’re taught not to be braggy, but we have to be able to state our accomplishments clearly.
I also tend to over-estimate the knowledge and experience of speakers at conferences. Recently volunteered to be on a panel simply because I wanted to attend and I was wait-listed. It was on contracting in iOS. Turned out I was on the upper-median spectrum of experience on the panel. Why did I assume that they were qualified to speak with authority? Because they were men? I didn’t know the facilitator, and yet assumed he knew his stuff. So in a way the Imposter Syndrome feeds off itself, as more people undervalue themselves, they are also overvaluing those around them.
We all know that an accurate understanding of your own knowledge is what helps you grow and learn. It’s actually quite rewarding when I find out a pocket of knowledge that I don’t have, and I’m eager to get better at it. I am actually, as I write this, embarrassed to admit my latest learning. I recently tackled and won a battle with threaded programming, in Android and iOS, that has me eager to redevelop all of my old titles. I should write about it, but, having had bombed a (cough) technical interview about threading in Rails, I am shy of mentioning that it’s hard, and that I’ve figured it out, and it has really improved my apps. I’ve also done some serious image and sound encoding and now want to add voice and image creation to all of my old games. I got shot down on StackOverflow by some guy about a sound encoding issue, so guess what, I’m shy about writing about that triumph.
Anyway, it’s a journey, but having an honest assessment of your own skills is vital to learning, so in a way it’s inhibiting our abilty to publicly admit: I didn’t know this, and now I do, and I can now share it with others.
I wonder if this is the key element to why the percentage of women on StackOverflow is so low.
Maybe, perhaps because I’m an English major, I tend to notice patterns in my speech. So, I noticed recently that I keep saying the same phrases in discussions regarding mobile app development:
- secret sauce
- no login
- no back button
- phase 2
- did the customer want that
- don’t say user
- is it needlessly complex
These discussions came up in hackfests, in client work, and in advising on technical projects. What the repetition of these phrases means to me, is that I need to reinforce certain concepts. So we all like Lean Startups and Customer Development, but are we essentially practicing those behaviors in our day to day work? The fact that I have to repeat them means that they’re having a hard time sinking in. You can know something, but to do it is another thing entirely.
What this app actually contributes, essentially, that is different in the market. The copyrightable/trademarkable essence. The actual chemical recipe for turning water into wine, for example. It’s the core concept that you’re testing, and everything else is a distraction, and muddies the customer testing. You need to narrow down the experience to highlight this secretsauce.
It’s very hard to start a project and not begin at the login process. But, you know what? Logins are assuming that people are going to come back. It’s not actually a pre-requisite for an app. You can grab session information, conduct a Facebook login later down the line, heck, just leverage Facebook entirely for login, etc. There are other options. Is it part of the secretsauce? Largely, it’s not.
No back button
I really hate them. It assumes that it’s important to store the customer’s “state” at all time, and it assumes that it’s core to the app idea or secretsauce. Back buttons are key to making a bloated big application with lots of overhead programming. This was a revolution in thought to me, to exclude them, and now that I’ve gotten over it, I’m not going back! I’ve met really horrified faces when I say this, but it’s true. Integrating a back button means sometimes 3x fold more work, so only include it if it’s part of the “secretsauce.” Usually, users can go through a flow and come back to home. No back button.
First introduced by none other than the wonderful Shaherose Charania of Women2.0, I admit it took me a while to get on the same page, and now I’m totally embracing it. This concept is awesome. Basically it’s a license to mentor, coach, or delegate the work to someone else. You hire a mobile developer, but you can also, (gasp) hire a developer to MENTOR you in mobile development, and then you can (gasp!) do the stuff yourself. You know, teach a man to fish, etc. It’s key to find someone who has good teaching skills, knows their stuff, and has time and interest (it’s non-competitive) to teach you.
During development, you will think of new things, and they will be great ideas. And you should keep a list of those ideas. And you should not involve them in the current phase. You should say no. Say no to the new idea. Keep focused, deliver the secretsauce.
Did the customer want that?
During development, you will think of new things. They will be awesome things. But you know what? You’re not the target demographic. I think the hardest part of Customer Development is not making an app that is precious and owned and used entirely by you, but spread out in the world and owned and used by others. So you have to constantly validate new ideas by the customer base (when you get them). We’re too close to the project and our opinions and use cases aren’t really worth much, essentially.
Don’t say user
From Sarah Allen, who said in a talk, “why call them users… are they drug addicts?” that cracked me up. Stylistically it’s outdated to call your customer a user. We are not all at terminals with our keyboard inputs. We’re at the playground watching our kid, checking Facebook, or in a club taking photos of old college friends, etc. Getting an idea of your customer and thinking of them that way is a big fat step towards making relevant, good apps. Recently at a hackfest my only feedback on a powerpoint pitch for an art festival presentation was – “call them festival goers” because it’s going to show that we “get it” to the judges. It shows you’re connected to the customer and not a bot. This is an old concept in Customer Relationship Management, but still is so maligned and not used, it’s sad. Basically, getting used to saying “festival goer” is 1/2 way to actually getting to know, and develop cool stuff, for your customer. Imagine going into a Disney pitch and saying, “user” instead of “parent” or “delighted kid” (who will become a parent, of delighted kids, etc.).
Is it needlessly complex?
A great thread on a geeky point probably worth an entirely new blog post, this thread brings up some key points- essentially the original poster wrote an abstracted class against the wishes of his client, and he was terminated.
I don’t consider myself a great programmer- my strengths are not in impressing other geeks, but impressing my clients and making great apps. One mantra that helps me “get it done”: I don’t make a routine, method or subclass unless it’s merited by repeat use. Essentially, don’t go all abstraction unless you need to. I can overprogram shit on my off hours. OK sorry to get all scatological, but certain architectural decisions are smart, some are … needlessly complex. For example, offloading logic onto the server, because you’re going to do two mobile versions, and you are using the iPhone simply as an interface controller: good idea. Building out a datamodel and data feed for a series of buttons that could be static in the first version: needlessly complex ( and, assuming that the options will change without customer input… “phase 2″ and “did the customer want that”).
Do you have mantras? Would love to hear, if you do.