For all the dramatic changes between the railway age and the silicon age, America still has the right formula for producing entrepreneurs.
Category Archives: development
Storylines and pair programming
A few months ago, I was approached to give a talk at Storylines. I agreed, and we finally managed to get our schedules lined up so that I could give my talk last night. I’ve been working on it for a few weeks leading up to it, trying to figure out what I can share that would be useful and meaningful to someone else.
As I was working on it, I was thinking about how I first got into computers in the first place. When I was a kid, my dad was an enthusiast, and he got a Timex-Sinclair 1000. He and I learned BASIC on it together, transcribing BASIC programs printed in computer enthusiast magazines into it, and then fixing the inevitable bugs (some typos, some transcription errors, some errors in the code as printed in the magazine). Later on, he got a Radio Shack Model 100, and we upgraded from transcribing BASIC programs from magazines to transcribing BASIC programs from books.
Thinking back on learning BASIC with my dad, I realized that we were doing pair programming long before it became a thing. We were way ahead of the curve!
Sept 20, 1954: first FORTRAN program runs
This is hard to wrap my head around: 59 years ago, the first FORTRAN program ran.
things I learned today: the origins of the tree swing cartoon
I don’t know about you, but I’ve seen the tree swing cartoon a million times. It’s a great cartoon that illustrates the difference between what the user wants and how it’s interpreted by various groups in engineering. I’d never seen it attributed to anyone, and as I learned today, its origins have now been lost. There’s lots of variations of it, too. That article is an interesting one about the history and variations that the author has been able to track down.
college versus software engineering
There’s lots of things that you do as part of your job as a software engineer that you don’t learn in school.
When you’re first starting out as a software engineer, you probably don’t really know what it’s like to work on a team. You might have had group projects in school, but their scope was limited to whatever you could accomplish in that semester, you’re working on it from the very beginning through to its completion, and everyone in your group had roughly the same amount of experience that you do. This is very different than delivering real software.
In the industry, you usually start out working on a project that’s already in progress, and if it’s software that’s been available for more than a couple of years, it’s got a history that you know nothing about. You have to learn where the project is today, you have to learn how to contribute to your project, and your deliverables or your deadlines1 are going to change at some point. You’re virtually guaranteed that you’re not there for the beginning of the project, you’re coming in to complete the work that someone else has defined.
There’s often not an actual end of a software project. You finish this version, you start working on the next version, and you have to go back and patch bugs from this version while you’re working on the next version. At some point, you’re going to stop working on this project (either moving to a different project in your company, or moving to a different company altogether), and the project is going to continue on. This means that you’re going to have to figure out how to help whoever is taking over your work understand where you are and what needs to be done next.
Your project team is probably bigger than the ones that you had in college, and there are more roles on it. Your college project team probably had everyone contributing code. Now you’ve got to figure out how test fits into your world, and program management, and documentation, and user experience, and then there’s this marketing person that suddenly appears and you don’t know what this means. In addition to all of these specialized roles that you haven’t had to deal with before, you’re also working with a much higher degree of variance of experience. In college, everyone probably had roughly the same level of experience. When you’re delivering software, you’ve got everyone from fresh college grads all the way up to the person who’s been working on this software since it was first shipped N years ago.
Deadlines are fixed in your college project. You know exactly when the semester is going to end. You might decide to change the scope of your project when you realize that you had planned more than you could actually fit into the semester, or when the person who said that they’d do this important piece of code never actually came through, but the deadline is immutable. When you’re working on on a software project, you’ll learn very very quickly that your deadline can get changed without any notice.
Also, your project might change mid-course. When you’re working on a project in a college course, you don’t have to worry about your competition changing, or about the market suddenly deciding that this new technology is an absolute must-have. That list of features that you thought were going into the next release can change at any time, and it probably will. Not only are you going to have to accept this change, but you’re going to have to accept that a feature that you were working on yesterday that was very important might not be important tomorrow. In fact, you might stop working on it entirely so that you can work on something else that’s now more important. That’s okay, it’s the nature of the business.
None of this is meant to say that group projects in college courses are useless. You learn a lot by having to work with other people to get your project done, and that does translate well to your first software engineering job. What you learn in your group project in college is limited, and doesn’t give you the full story of what you’ll experience when you start working for a company on a software project.
- Note that this isn’t an XOR. It’s actually most likely an AND, but I’m going for OR because OR doesn’t preclude AND. ↩
cool girls code
Cool girls code. It’s one of the awesome t-shirts that VMware is handing out at college recruitment fairs right now. It can be hard to get credibility as a female software engineer, and that pink shirt is a reminder to all my fellow women in tech that we’re not alone, and that it’s pretty damn cool to be a female software engineer.
Given that I’m out and actively trying to recruit more women to join my immensely geeky company, you can imagine my disappointment when I saw that Violet Blue has, yet again, made an idiotic statement about women in technology. Actually, she made an idiotic statement about a specific woman in technology. She attended Macworld 2012, and led off her column with an extended commentary on what she called “the saddest booth babe in the world”. She even included a picture, which she has since removed, of the woman sitting in a chair looking tired.
The problem, of course, is that the woman in question actually isn’t a booth babe. The woman is an employee of a small iOS company, not a model paid to draw in foot traffic by showing skin.
It’s hard enough being a woman in tech without some uneducated blowhard, who happens to try to style herself as all about female empowerment, come along and bash a woman in tech by assuming that she’s a booth babe. I would expect that someone who likes to pretend that she’s a tech blogger would actually know that not all women at a trade show are booth babes. I’d even like go out on a limb and imagine that this so-called tech blogger could even imagine that a good-looking woman can also work in tech. It’s especially galling when that very selfsame uneducated blowhard is the one who was bitching last WWDC when some guy asked what she does, instead of assuming that Violet is a developer. (This is, of course, ignoring the fact that Violet is not actually a developer. Tech blogger, perhaps, but not a developer.) At the time, she decided to play the dumb-chick card and pretend that she knows utterly nothing about computers, and then upbraided the guy in her column for falling for her little gambit.
So let me get this straight: it’s bad for a guy to believe you when you say that you don’t know anything about tech, but it’s totally okay for you to call a woman a “booth babe” and complain about her hunched shoulders and “breasts that were packaged air-tight in a tight, branded t-shirt” and not even bother to talk to her? At least the WWDC guy was trying to make conversation, and believed you when you said that you were a model in town. Violet Blue couldn’t even be bothered to either (a) go talk to the woman, (b) go look up the development company and see whether she works there, or even (c) not start off a column with such a ridiculous anecdote that had pretty much nothing to do with the rest of her column or the event itself.
I’ve worked Macworld before as a vendor. It’s freakin’ exhausting. You’re tired. Your feet are sore, because you’re standing on a thin layer of carpet over concrete. You’re quite possibly hung over, a result of having a bit too much fun at the Macworld Blast party the night before. Your voice is cracking because you’ve been talking too much, answering questions about your application. That’s the perspective when you’re working in one of the big booths, where you’ve got several of your colleagues around to help out. But this woman was at one of the teensy developer kiosks, which means that she was probably either alone or maybe had another person there. That’s also the perspective from someone who just has to drive to San Francisco from Mountain View, so there’s no concerns about jet lag or uncomfortable hotel beds or being in an unfamiliar city and not knowing anyone.
The original picture, which Violet Blue has (of course) yanked, is one that I recognize and identify with. I’m quite sure that I’ve been seen in that exact same pose at some point in my life at Macworld. I hope that no-one out there has such an unflattering picture of me, although I wouldn’t be surprised if it were out there. I’m lucky in that, as far as I know, no-one has chosen to post such an unflattering picture and description of me to a major tech blog. It’s bad enough to be exhausted at Macworld, I can’t imagine what it’s like to be exhausted and publicly ridiculed there.
As if the original article weren’t bad enough, not to mention the edits done to the article so that it doesn’t look quite so appalling, is Violet’s response. You see, she got called on her idiocy pretty early. People who weren’t even at the show took a look at the picture that she posted and figured out that the woman isn’t a booth babe. Violet, instead of putting her big girl panties on and owning up to her idiocy, instead doubled down:
It’s really reaching to brand me a misogynist because I put the woman in a social category based on the environment she was in. I was not the only one to do so. It was not obvious that the woman in the booth was not a booth babe
It was pretty obvious that she wasn’t a booth babe. Let me count the ways:
- She wasn’t dressed as a booth babe. She was in pants, a long-sleeved t-shirt, and a short-sleeved t-shirt over that. Now that I think about it, this is an exact description of what I wore today. The woman in the booth wasn’t displaying cleavage, she wasn’t wearing platform heels, she didn’t have a skirt cut up to her hip. There was no skin showing. Her t-shirt might have been a bit tight, although honestly every t-shirt looks tight when you’re tired and thus not sitting up straight. But it certainly wasn’t booth-babe tight. It was just normal.
- She wasn’t at a booth that would have gotten a booth babe. Yes, there were some booth babes at Macworld, but it’s not every booth that gets a babe. The natural habitat for a booth babe is one of the big flashy booths that are crawling with company representatives, and it’s the booth babe’s job to get people to come to the booth and talk to one of those representatives. This woman was at one of the little developer kiosks. They barely have space for two people to be at the booth at the same time. They certainly don’t have the space for a booth babe, and I bet they don’t have the budget for it either.
- Booth babes are never left in the booth alone. Booth babes are there to get conference attendees into the booth, but then it’s someone else’s job to actually talk to them.
- Speaking with her would have made it clear that she wasn’t a booth babe. Usually, a booth babe can perhaps answer some very high-level questions about the product(s) at hand, like how much it costs and when it will be released. That’s it: they generally can’t answer deeper questions, and since they’re trying to get lots of people to come to the booth, they’re mostly interested in handing you off to someone else so that they can continue to do the job that they’re there for.
But wait, there’s more! Then Violet outdoes herself with this:
If you want to know how I really feel about booth babes (though I’m sure you won’t because the drive-by is always better) – get some context for booth babes in my column by reading this:
The CES Booth Babe Problem
http://www.zdnet.com/blog/violetblue/the-ces-2012-booth-babe-problem/963
And you will see that Ms. Szurmai-Palotai is exactly the kind of “booth babe” I am referring to – women devs, women hackers. Not the kind some of you seem to instantly think I mean.
This is completely and utterly ridiculous. There’s only one definition of booth babe, and Violet’s own CES article is talking about exactly that kind of booth babe: a scantily-clad woman who doesn’t know anything about the technology at hand, but is only there to drive traffic. No-one has ever seriously tried to refer to “women devs, women hackers” as booth babes. The term is a pejorative, and we all know it. Don’t try to pretend that it’s neutral or even positive.
Amusingly, Violet tries to blame the backlash on an “attack” from Daring Fireball, and paints anyone who has criticised her as being a fanboy. Not so: she had already been called on her idiocy quite some time before Daring Fireball linked to it. And Daring Fireball’s commentary cannot, in any way, be construed as an attack:
But as Shawn King points out in the comments under the photo, the woman in question doesn’t look anything at all like a “booth babe” — she simply looks like a developer who happens to be a woman manning her booth. And according to subsequent comments by Tim Breen, that’s exactly what she is
Violet says in her comment that she should have been given a chance to do something:
A simple correction would have sufficed, and then you could have seen what I did with it.
The simple correction came swiftly. And we saw what you did with it, Violet: you did absolutely nothing. You let your nasty little column stay exactly like that for a day. It was only after apparently you’d gotten enough comments calling you on your idiocy that you finally edited the column to note that the woman is a developer, and you replaced the original photo of the “sad booth babe” with one of a lineup of iPhone cases.
Strangely enough, Violet’s column about booth babes at CES does get one thing exactly right:
Present an inappropriate female stereotype and – no surprise – you’ll create an environment of inappropriate and stereotypical behavior.
It’s not the booth babes, it’s the reductive booth babe mentality that’s the real problem here.
Yes, it is the reductive booth babe mentality that’s the real problem here. Now, Violet, take some responsibility for being part of the problem instead of part of the solution.
lessons from a long career
At every geek company that I’ve worked for, most people send out a good-bye email to their team when they’re moving on. Today, one of my colleagues from my previous team posted a going-away mail from someone else who’d been on that team since the dawn of time. He included lessons from a long career at Microsoft. I have to admit that this is my favorite lesson:
6. At some point, you will have to resolve a bug by saying, “If the user does something that dumb, they get what they deserve.”
There are nine other pieces of wisdom on that list, so you should go check it out. #7 on that list is one of the absolute rules of the universe, second only to gravity.
guest appearance on the Angry Mac Bastards podcast
Somehow, John Welch suckered me into doing a guest appearance on the Angry Mac Bastards podcast with him, Darby Lines, and Peter Cohen. I jumped on the bandwagon this week, mostly to have the opportunity to talk about the recent controversy surrounding Violet Blue’s blog post about WWDC. I’ve already written about it here, so you already know where I stand on the topic.
At one point, Peter asked me about Blue’s assertion that Apple has a monoculture and whether there was something that Apple should do about it. I said no at the time, but later John mentioned the work that he does to try to get more female speakers at Macworld Expo. I’m one of those people: John tracked me down (hmmm, I’m noticing a trend here) and suggested that I put together a talk. I did, and ended up speaking a couple of times at Macworld, which then led into a couple of talks at Exchange Connections too.
I didn’t attend WWDC this year, but I have several times in the past. I can’t recall seeing a woman on stage giving a talk. Maybe I just didn’t attend the right sessions, or maybe it was different this year. Unless there was suddenly a huge influx, that’s one thing that I think that Apple could do: get some more women on stage. I’ve met plenty of Apple women who are qualified to give technical presentations. Get ’em up there. It’s an awesome experience, and that kind of example and mentorship would be a great intangible benefit of WWDC.
The full topic list for my appearance is here, and you can download the podcast here.
feedback and constructive criticism
In response to my blog post about taking feedback, Bryan started off with the following:
Reading your post about how some developers can’t take “constructive criticism” or as you wrote, “feedback,”
I view “feedback” as a superset of “constructive criticism”. Not all feedback is constructive (nor, of course, is it criticism). Regardless of whether the feedback is positive or negative, or whether it’s critical or supportive, you’ve got to learn how to listen to it and decide what to do about it.
Listening to feedback and figuring out what to do about it is my job as a researcher. I do this all day, every day. Some of it is formal and follows a research methodology; much of it is informal, simply listening to the zeitgeist, understanding it, and applying it when it comes time to do more formal research. If you don’t have the luxury of having me around, there are some researcher skills that can help you in listening to and acting appropriately on feedback1.
Negative feedback hurts. This is true whether or not it’s constructive. We want to do well. When we’ve worked on something, when we’ve poured our blood, sweat, and tears into our application, we want that work to be recognized. If the feedback is constructive, it’s somewhat easier to take to heart. If the feedback is just of the form YOUR APP SUCKS, it’s easy to blow it off.
For constructive criticism, you probably have less work to do to try to understand that feedback. The person giving you the constructive criticism has taken the time to consider what they’re experiencing and how to share that message with you. You probably still have an emotional response to the constructive criticism, and that’s yours to deal with. After you’ve dealt with that emotional response, deciding what to do about it is easier because the other person has already done a lot of the work for you.
When feedback is negative, you’re hit with a double whammy. You’ve got your own emotional response to deal with, and you don’t have a clear path forward. To be more accurate: you have one obvious path forward, which is to blow off the feedback. After all, if someone is just telling you YOUR APP SUCKS and you’re pretty convinced that your app doesn’t suck (and how could it? you’re poured your entire being into that app!), blowing it off isn’t hard.
Blowing off feedback because you don’t like it is the wrong path. Constructive criticism takes time and effort on the part of the person giving it to you. You can’t reasonably expect that everyone who uses your app is going to spend that much time on it. You get much more feedback than you do constructive criticism. Constructive criticism doesn’t tell you the whole story, it only tells you the story from the people who are so invested that they’ll tell you what they perceive is their story. There’s much more out there. You want the whole story, so you’ve got to find out why you’re getting the YOUR APP SUCKS feedback. You’re going to have to do a lot of work to understand what that feedback means and what you should do about it.
This isn’t to say that you act on all feedback that you get. There are plenty of great reasons that you won’t. When you don’t act on feedback, you need to be able to both clearly articulate the problem that’s been shared with you and why you’ve chosen not to do anything about it. Own this, and love this. Knowing what you won’t do is powerful, and is ultimately part of you making an awesome app.
Taking the time to consider feedback will help you make better stuff. You have to let go of your ego, and you have to dust off your detective skills. Feedback is a gift. Take the time to unwrap it.
- Also, being a researcher makes you a great guest at a dinner party. Being able to ask good questions and distill what you’ve heard means that you’re awesome at keeping the conversation going. This ability is why many people assume that I’m an extrovert, even though my Myers-Briggs score is always off-the-charts introverted. ↩
on taking, and giving, feedback
Remember “The Daily”? It launched in February. It’s a subscription newspaper for your iPad, commissioned by Rupert Murdoch’s News Corp. The main UI is a carousel, allowing you to flip through the pages of the paper to get to the section that you want. The UI got panned by many people. Take this quote from The Telegraph’s review (which starts off by calling the app “a complete failure of imagination”):
After being asked your location, you’re through to the carousel. Imagine tearing out each page of a magazine and having a friend wave them in front of you one at a time.
I think it goes without saying that the rest of this review isn’t any nicer. But it got worse when Loren Britchter, the dev behind the official Twitter Mac and iOS clients1, released a YouTube video that he described as “Evening project – The Daily, less slow: 60 fps, full AA, physically correct reflections, (different stacking style).” His tweet got retweeted all over the place, and most subsequent reviews of The Daily mentioned his video when discussing the UI.
Just before WWDC started2, I read a blog post from Marcus Zarra, one of the guys behind the popular Cocoa Is My Girlfriend blog, who has now outed himself as someone on the development team of The Daily.
Go read that post. This has obviously been bugging him for months. His post is a case study in the wrong way to take feedback. Combine that with the earlier complaining from another indie Mac/iOS developer about how “useless” is a loaded word. At the time, I just pointed out that loaded words matter. But now, I’m beginning to wonder if the whole indie dev community doesn’t need a lesson in how to put their big girl panties on.
Marcus says that he was surprised by the feedback he got from his fellow Cocoa developers. He asserts that, back in some golden age pre-iOS, there was a community and it was all full of sunshine and delight. But now, iOS has come, and somehow there’s a “disturbing trend in the community”. He describes his fellow indie devs as “hostile” and “piss[ing] on” other applications, especially if those other apps have been discussed in the tech press.
I can’t agree that the Cocoa development community is one that’s always been perfectly open and loving. I’ve spent enough WWDCs where many other developers and designers wouldn’t talk to me at all once they read my badge and saw that I worked for a very large company. (Or are you going to try to tell me that it’s okay to shit on your fellow software engineers when they work for The Man instead of by themselves in a local coffee shop?) I’ve watched my apps get torn apart by other developers, asserting that anyone who worked on those apps must be a complete moron who couldn’t code their way out of a paper bag. So no, Marcus, it’s not new. It’s just new for you to be on the receiving end of it.
Taking feedback sucks sometimes. You’ve got to put your big girl panties on and deal with it. Don’t rail against the feedback, and don’t let it get you down either. Take what you can from the feedback. Learn from the experience, fix what you can, and don’t repeat the same mistakes next time around. While you’re at it, learn the lesson of how to give feedback when you’re in a position to do so later.
So how do you take feedback? You listen to it all. Let go of your emotional reaction to the negative feedback, and then deeply consider all of the feedback. This doesn’t necessarily mean that you do what you’re directed to do by some of those who are offering the feedback. It means that you think about what they’ve said (and what they haven’t said), and you then make a decision about what you do about it.
One thing that Marcus points out is that “doing something first sucks”. He’s right. Doing something new means that you have to listen to the initial feedback, and then you have to keep on listening for the ongoing feedback. For an application, the initial feedback tells you a lot about first impression and usability. Ongoing feedback tells you about usage and learnability. If the initial feedback hurts but the ongoing feedback is good, you’ve got one problem to solve. If the initial feedback is so bad that you never get ongoing feedback, you’ve got a different problem to solve. Without listening to the feedback, you’ll never know which it is, and you’ll never learn anything.
Marcus writes up a few points that he calls “some thoughts from the trenches”. I sincerely hope that he remembers these in the future, because his points apply to every development project that’s longer than Hello World:
- Deadlines suck. A deadline was chosen for some reason, and changing that deadline is going to be painful — if it’s even possible.
- It’s not as easy as it looks. The duck glides across the water, but underneath, those little legs are kicking away. On the outside, you might think that it’s got to be easy, but any developer can point out a case where they thought they’d be done in a day but that piece of code somehow took three weeks.
- The last little bit will kill you. This is a corollary to the above: you get the easy stuff done quickly, but then the edge cases are big and messy.
- There’s more to putting an application out there than developing. If you see a number and think “why did they [spend that much | hire that many developers]?”, remember that the number probably doesn’t represent just the development effort.
- Doing a V1 hurts. You’re going to get dinged for not following closely enough to what came before. What’s more, you’re going to learn so much from doing that V1 that your V2 is better, which will further make your V1 not look quite so sexy.
He doesn’t articulate another point, but this point is pervasive throughout his article:
- The team worked hard to make that app happen. They had constraints that you don’t know from the outside. Before you come out and piss on someone else’s work, give them the benefit of the doubt.
But still, developers: feedback is a gift. Sometimes you have to work hard to unwrap that gift. Every piece of feedback has something in there for you. Don’t take it personally, but make sure that you listen and you learn.