Kategorie: Developing

(All) Boys Club Follow-Up: Links and Stuff

There are a couple of interesting organizations and articles regarding the gender gap I talked about in my last post. I only have listed a few here, if you know more, please don’t hesitate to post in the comments or send me a mail.

There’s the Ada Initiative and Ladies Learning Code, both non-profit organizations aiming to get more women into coding by organizing conferences, workshops, trainings, etc. You can also check to see whether there is a Girl Geek Dinner organized in a city near you.

Then there’s a very cool blog post on the Fog Creek Blog called Girls Go Geek… Again! which (amongst other things) briefly sums up the history of women in programming and includes an article with a female developer at Fog Creek Software.

Another nice article over at Sharp Skirts focuses more on the communication differences and what it means in the workplace and it’s called Girl Developers vs. Women In Tech: More Conversations That Need To Change.

My favorite article though is located over at Microsoft, more specifically Jennifer Marsman’s MSDN blog. It deals with the question why there are so few women giving talks at conferences. This is one of the articles I routinely search for and link when someone asks the „Why so few women?“ question. It’s called Why are more women not speaking at technical conferences? Insights from the WiT discussion at CodeStock and most of all it’s awesome.

Yeah. And there’s this. I thought you shouldn’t miss this.

(All) Boys Club

Let’s try to make this post non-complainy, shall we?

But see, I am annoyed. I am annoyed that at my job I’m usually surrounded by men with hardly any other woman in sight. (This is not completely true. I know and have worked with other female developers, but they – or we – are scarce.)

What I am most annoyed with is that I don’t know what to do. I am perfectly aware of the fact that nobody actively discourages women from going into programming and IT. Yet at the same time I’m tired of hearing excuses like “Women are just not that technical” or “Well, that’s just the way it is”. Even if this is true, I still think that we should care about changing this outrageous status quo and getting more girls and women interested in coding.

See, I don’t believe that it’s a biological thing, but that the biggest reason for the big gender gap in IT is cultural conditioning. And I think I have proof for that.

When we were in Vietnam to train our off-shore developers I noticed that the female-to-male ratio in the development department there was way better than what I have seen in about every company I have worked for in the past ten years. It wasn’t 50/50, but a fair guess (without any numbers to prove it) would be that it was about 30/70 (maybe even slightly more), which is pretty good and the overall impression was that the ratio was enough to make it feel somewhat balanced.

If you look a bit into the history of programming, you’ll also see that back in the 60s it used to be foremost a women’s job, but that pretty obviously has changed.

Now, let me get that straight. I have been lucky and never have I worked in a team where the testosterone level was so high that it made me feel out of place. Most of all I am a software developer and a geek and I enjoy working with other geeky (and non-geeky) developers. But I am also a girl (well, woman, but you know…) and I wouldn’t mind seeing more female developers around. More than that, I would welcome it. Maybe with a song.

The reason I think is mostly to blame are cultural stereotypes and prejudices and the fact that nobody seems to care enough to change it. And while it’s true that any girl can decide for herself whether to go into IT or not, this is not an excuse to just throw your arms down and say “Well, so they are just not that interested. We can’t force you to.”

The truth still is that the whole IT community sometimes feels like an all boys club and while this might sound a bit lame, it’s not that easy to enter this boys club when you’re a girl and not feel weird. I was raised to believe that I could do anything I wanted to, so I did. I was pretty good at math and took biology as a major in high school and was one of the first pupils to spend their afternoons at one of the two computers connected to the internet at my school. I have never and hopefully never will let anyone tell me what I am supposed to like or do or be interested in because I am this or that (e.g. a girl).

But I fear that not everyone is like that, and I also fear that society is still doing a pretty good job in steering boys to science and technology and girls to languages, art and humanities and encouraging girls that it’s perfectly okay to not understand a computer and boys that it’s okay not to be into learning Italian as long as they know how a car works. This, in my belief, is utter bullshit, but I don’t know how to fight it, either.

These prejudices and conceptions of what is acceptable based on a gender run so deep that it’s hard to imagine a world where certain areas of expertise are not predominated by one gender or the other. It happened to me, too, despite of what I said a few lines earlier. I never took any programming classes in school, although I would probably have liked it.

So here are some simple ideas:

  • Make programming classes mandatory for all pupils in school for at least one year. I bet you’d be surprised at how many girls find out that programming isn’t nearly as hard as they imagined and – more than that – that it’s fun and that you can do pretty awesome things with it.
  • Offer programming classes (in school, at university or as evening classes) for girls and women only. Yes, I know, that sounds like the wrong direction. We want to get rid of the gender gap, not feed it with special courses just for the ladies. But the issue here really is to get rid of the fear of failing for just as long as it takes to make it clear that programming is no rocket science (unless you are actually coding for a rocket, in which case, maybe it is) and that it is not magic either. We need to get over that first hurdle and this is probably easier done in a (temporary) all girls club.
  • Cater to the prejudices. While they are still there, let’s make use of these stereotypes we talked about. Maybe coding is uninteresting for girls because it seems so technical. Make it look more artisty, colorful and fun. Start with building websites. While you could argue that HTML and CSS are not strictly programming languages I do believe they are the perfect gateway drug to actual full-fledged coding.

So there. Three simple ideas. They won’t solve everything, but they might be a good start and maybe other people have even better ideas.

Just personally, I’m sick of being the one girl crashing the boys club. I’m tired of pretending that I’m somehow less female or different from other girls or women because I work as a software developer. I’m not. And if I could get the support of other awesome girl geek developers out there, that would be pretty sensational.

Should You Do Daily Stand-Up Meetings? Yes, You Should!

Last evening I talked with my husband about common problems with team building and communication and I noticed a familiar theme: There is a common and widely spread misconception that just because people are sitting in the same office they are communicating effectively. Unfortunately, this simply is not the case. And it’s not even because they are not talking. Most of the time they just are not talking about the „right“ stuff.

I put „right“ in quotation marks because I do not think that co-workers are usually only talking about useless things. What they are talking about might very well be justified and well chosen.

The original starting point for this discussion was the question whether short daily stand-up meetings are useful. I am very convinced that they are. I think a daily stand-up meeting should be some manager’s ultimate weapon of choice to discover (and hopefully fix) problems early and facilitating teamwork and communication.

What the manager might say is: „Well, we don’t need daily stand-ups. The whole team is sitting together in one office anyway. So if someone has a problem they can just go right ahead and address it.“

Here’s the thing: This only works for the tip of the iceberg problems that somehow make themselves visible to the team. What you need to know about to make the team more effective are the problems that form the underwater part of the iceberg that you haven’t even seen yet.

In my software development team I work together with another developer. We sit in the office. Our desks face each other. We also talk. Sometimes a lot. But we still miss problems or opportunities to work more effectively. Every so often it turns out that I was working on something that he already had fixed or at least researched halfway. Or one of us was trying to solve a problem to which the other one already knew the answer or at least knew where to look for the answer.

The thing is that you usually don’t bother your colleague with what you’re currently doing all the time. You get something to work on, you dive in, you are hopeful that you can find a solution. In short, you don’t really need their help. And you don’t want to bother your team with your problems (which seem solvable) while they themselves are busy with their own tasks.

Here’s another exmaple: We have a weekly phone call scheduled with some developers in Denmark with whom we work together. Sometimes we have an agenda of things we need to talk about. Sometimes we have little things. Sometimes they have updates for us. Last week my team lead, my colleague and me pretty much had nothing. The developers in Denmark also sounded like they didn’t have a lot. Still, somehow, the phone call took nearly 30 minutes, because someone said something, to which someone else replied, which raised new questions which turned into a long description and discussion. Yeah. It felt like we had nothing really to say. But it turned out that we did.

Daily stand-ups will help you find and fix problems before they even have the chance to become full-grown problems. If everyone will just say what they are doing currently and sometimes what they are struggling with, you will find issues where nobody really expected them to start with. You will find out when two people are actually working on the same thing. You will find out when someone is misunderstanding a task. You will find out if there’s someone who actually knows the solution to a problem someone else is struggling with. You will find out when there are obstacles that you weren’t even aware of. You will find out lots of things and will be able to fix problems quickly and find ways for the team to work together even better.

And don’t underestimate the power of curiousity. That stupid thing you’re working at that you can’t even look at anymore might just spark the interest of someone else who will eagerly volunteer to help you. I remember a bug we found regarding different handling of spaces before exclamation and question marks which a developer who was a linguistics enthusiast practically jumped to grab. (This didn’t happen in a daily stand-up, but it shows how different members of a team might enjoy to work on different tasks.)

My advice would be: When in doubt, try daily stand-ups. And when are we ever not at least slightly in doubt?

Lean Kanban Central Europe 2011 – A Sort of Introduction

P1010777I was lucky enough to be able to attend the first Lean Kanban Central Europe Conference in Munich this week.

Being new both to these kind of conferences (whatever that means) and Kanban (but not Agile) there were a lot of great first experiences and it was definitely a small adventure. If you follow me on Twitter you might have noticed the mass of tweets all with the hashtag #lkce11 that I sent out on Monday and Tuesday. Yes, I approached the whole thing in a way that seems to work well for me, by immediately making myself visible to whoever might be interested. But I’ll be writing more about Twitter and conferences in the next days (hopefully), because I realized it is an interesting topic and definitely worth a blog post.
Ever since I got back I’ve been suffering from a cold. It actually started on Tuesday and got worse in the afternoon, then definitely worse on the train ride home. So I spent most of today on my new sofabed (which was just delivered this morning as well) trying to get better as soon as possible. (I also now own more tea than I will ever be able to consume, because I shouldn’t be allowed to shop for tea when my throat hurts. Makes me all cravy and then stupid things are bought.)
When recapping the event for my team lead this morning (I went to work for a whole of 90 minutes) I realized that I learned so much that it felt like the double amount of sessions than I actually attended. There was a moment when I went through the program trying to find the sessions that I didn’t already mention and finding that nope, that was really it. My memory is still convinced that it just had to be more than that.
I would like to recap the event and the session in more detail but my current cold-affected brain won’t let me do that with the concentration that it deserves.
So, let me just say this:
First of all, thanks again to all the people organizing this event. It was great fun, I saw very interesting sessions with awesome speakers.
Thanks also for the variety of sessions and speakers. As a Kanban newbie I was glad to get an introduction to Kanban as well as sitting in some rather challenging sessions. The mixture of theory, interactive sessions, experience reports and of course the keynotes worked pretty well for me.
I would also like to thank all the great, funny, interesting, smart and a least mildly geeky people who put up with me during and between sessions. I hope I did say something smart or mildly interesting at times, too.
As a short teaser for upcoming blog posts, I would like to mention my personal top two of the sessions I attended, which was an immensely interesting session about complexity thinking by Jurgen Appelo(@jurgenappelo on Twitter) – who, if you don’t know him yet, seems to be mostly awesome in general – and the funny and captivating keynote by Stephen Bungay in which he went back all the way to tell us what management lessons we can learn from 19th century military.
Sounds interesting? Believe me, it was.
So, stay tuned for more stories and recaps from this event. And just in case you wanted to know. Yes. There was also cake.

What Developers Do

Okay, so here’s what I think a lot of people might think developers do: Write code.

If you know a bit more about the job, you might also know that we write some documentation, test a bit and fix them bugs.

But there’s quite a lot more that makes up the day-to-day life of a developer which most people not acquainted with the pitfalls of this lovely job might not know about. So, here’s just a selection of stuff I find myself confronted with regularly.

What Developers Do

Install Stuff

It takes hours. It’s not particularly fun either. But we do it. We install stuff. And then we update it. And then we install some more. And then we restart. And then two hours have gone down the drain because we had to install stuff and couldn’t really work on anything else in a concentrated productive way. But there’s no way around it and when that stupid Service Pack for Visual Studio is released we cannot really refrain from installing it, even though we know that it takes two hours and we need to close Visual Studio, so we cannot really do any coding in the meantime. Yes, it sucks and yes, we sometimes don’t realize what we’ve just started, until it’s too late, but it happens. It’s not an excuse for slacking time, it’s a fact of life.

Stare

Developers stare a lot. We stare at screens. We stare out of the window. We stare at the ceilings. We stare at the door. Don’t assume that we’re not working. Chances are we’re thinking. No, really.

The fact is that if developing software was just as easy as typing commands, you wouldn’t need specialized people to do it. Unfortunately (or for developers: fortunately) it’s not that easy and there are these times of the day where we just stumbled upon a problem that we have to really think about before it’s actually worth typing one more line of code.

Don’t mistake staring for doing nothing. And for developers, if you work somewhere where staring is commonly misunderstood for doing nothing, get the hell out! Anyone working with software developers needs to understand that part of our job is to think about what we’re doing. And while it’s nice to quickly draw something up on the whiteboard or have a lively discussion with another developer, some problems will only be solved by staring.

Marvel

Marvel is pretty similar to staring as it involves the former, but for another reason. Plus, staring usually involves some kind of vacant expression while marvelling involves a kind of irritated, slightly crazy grin or something similar.

The best kind of marveling I know is when you fix a bug and realize that the code should never have worked in the first place. This isn’t as absurd or uncommon as it sounds. It has happened often enough to me. There are other kinds of marveling: incredibly good code, incredibly stupid code, a bug that just shouldn’t happen,… you name it.

Marveling might not be as critical to our job than staring, but it’s usually more fun.

Be Annoyed/Irritated/Totally Surprised

This might be the other side of marvelling. Where marvelling revels in the joys of an obscure bug, being annoyed or irritated just hates the bug for existing in the first place.

There are other reasons to be annoyed though, and bad code or stupid bugs are just a small part. There’s crashing IDEs for example, or slow data connections. There’s the one configuration setting you always, always forget to change and spending an hour to debug until you realize it’s THAT THING AGAIN.

Being annoyed is the part of the developer’s life where we start to rant. It might even be that the time we need to vent off and be done exceeds the actual time we spend being annoyed, but so be it. We’re just people, too. (Maybe a bit geekier.)

Play Around

You can try and stop us and maybe even be successful, but you’ll take half of the fun out of our job.

On the plus side, developers tend to play around with stuff that might actually prove to be useful to their work, so unless you have serious doubts that they’re just goofing off getting nothing done, just let us play. We’re just trying out a little tool or playing around with some cool new technology anyway.

Fuck Things Up

We do that, too. Sorry.*

—

*One of the worst things I have had the pleasure to experience first hand (though I didn’t do it) was when a fellow developer accidentally overwrote one of our development web servers. And no, of course, there was no backup. On the other hand: there’s nothing like the sight of a developer with panic written all over his face. We recovered after the initial shock, and then at least you have a story to tell.

Developers vs. Testers

I recently got an email from a developer/tester from Norway asking for an opinion about the typical relationship between developers and testers and any advice for testers on how to work together with developers.

Let me start by saying: I think it’s complicated.

The first job I had, there weren’t any testers. Naturally, there weren’t any testing processes. There were no development life cycles. There was a whole lot of nothing where you got some kind of requirement, worked on it, fixed your bugs and hoped and prayed that it would work.

The second job was completely different. We had a test department with three full-time testers and a few students working part-time. There was a development life cycle supported by the tools needed to get a requirement all through from specification to implementation to testing to bug fixing to release. There was not a feature going out, not a bug fixed that didn’t go through testing first. This also meant that testing (together with product management) had the power to stop a release from happening.

Of course, there was more involved business-wise, but from the development’s point of view, the testers job was just as important as the developers. I’m not saying that testing is more important than writing code. It’s as important. You don’t have one without the other. If you do, you’re doing something wrong.

I hope I’m not speaking for myself, but I’d say that there was neither rivalry nor one role looking down on the other. We worked as a team trying to release a product and we had to work together to do so successfully.

So, that’s how it should be.

As a developer I’ve worked with pretty amazing testers. The kind you give your feature to and know they will come back to you with bugs you never could imagine. The kind you trust to test your feature so well that it really will come out with as little bugs as possible (because as we all know, there’s always one more bug). The ones that will save you from utter embarassment because they will remember what you forgot before it gets released to customers.

There are a couple of things I am thankful for in testers:

a) They’re doing something for me that I don’t want to do. Testing is not for every developer. Some are crappy at testing, some are doing a fine job, some are actually pretty good at it, but still don’t feel especially thrilled when having to do some testing.

b) They’re my net of safety. I would like to say that when I’m done with a feature it is ready for release, but I know that it isn’t. There is one basic rule that you should never test your own code and that rule is there for a reason. But it also helps if you have dedicated testers instead of developers, because they don’t have the same impatience that developers do. Give a developer something to test and they want to be done with the testing and move on to the next feature to implement. Give a tester something to test and they want to FIND. THE. BUGS. Of course I’m generalizing here, but I think I’m not too far off.

But it remains that there are a lot of developers who seem to NOT be thankful for testers. Or – equally worse – those who look down on testers as second-rate teammate just doing the monkey work that nobody else wants to do. Having seen a development cycle were testing as well as testers were taken serious as hell, this screams utter bullshit to me.

Sure, release testing is a tedious, tedious thing that everyone hates. EVERYONE. And writing up a test script and ticking it off isn’t something that sounds especially awesome.

But here’s something that a tester from my last job told me: It’s like actively and creatively destroying something that wasn’t meant to be destroyed. It’s taking apart something that should hold together. And as a developer and a quarter-time tester (thanks to Scrum) I must say that I know the tickling feeling when you found a bug that was carefully hidden, but you still managed to drag it out into the open and smash it.

The same tester also said that sometimes it is hard working with developers. As a tester you can’t help but telling someone they made a mistake. And developer’s seem to be a sensitive species who like to take criticism of their feature rather personally. Instead of „I found a bug here“, they might hear „You did something wrong, stupid“. Which is not what the tester said, but still.

Developers might see a tester as an obstacle to having their fine and working code released. I’ve actually had consultants try to circumvent testing because it took too much time and the customer wanted that feature NOW. Well, the customer unsurprisingly always wants their feature NOW, but they also want it to work. Naturally, features who don’t go into at least a somewhat proper testing phase will always be buggy and in the end will cost you more time than if you had given that tester the extra day they said it would take them to test it properly.

Now as to the actual question on how to approach developers as a tester, I first want to give the advice one of our QA managers said I should give: He called it The Mom/Dad Approach and it boils down to somehow making the developers understand that you really mean them no harm, you just want them to be better and you want the feature to be as bug-free as possible. (Hint: Don’t be patronizing though. Developers will pick up on that and hate you for it.)

Also, make sure that you understand the technical side. You might not have the same technical background and you might not understand the details of the implementation, but try to understand that there is something technical going on and the small bug you just logged might mean a load of work for the developer.

Maybe offer to sit down together and look at what you found together (this might also help you weed out the „works on my machine“ replies). Communicate. Ask.

After all, you are working towards the same goal. Nice, working software. It’s a mystery why some managers and developers think that this can be achieved without testers, because it can’t. Testers are testers because they think differently. Because they are willing to dig deeper into the software than everyone else. And because they take a job that will piss off others by nature.

There was an awesome web comic I found once about typical developer replies to bug reports, but I can’t find it again. Instead, have fun with this one, it’s equally close to reality:

2009-07-30-bing
by David Wilborn / www.urbanjunglecomic.com

The Trouble With Estimates

I recently had the pleasure of being asked to estimate a set of features. I was new to the customer’s system, hadn’t been involved in any of the steps leading up to the final requirements and was still working on fixing the bugs from another project.

I sat down with the specifications and roughly estimated how long it would take to implement the required features. The estimation that came out of this was roughly two days more than was originally planned for the complete set. I also asked for a complete part of the feature set to be removed from the list and made into its own project.

So, basically in the end, I estimated more time for less work than was originally planned. Not a good thing per se, but unavoidable. As the consultant or customer you might be trying to get the developer to estimate optimistically: „Do you really need that much time?“ „Are you sure it takes that long?“ „These are just basic forms, can it really be so much work?“

The answer to that is: Maybe not, but probably yes. In my experience in every project that’s at least slightly complex, there are pitfalls. There will be trouble. As a developer I try to be as optimistic as I can get about how long something will take. But I also need to take care that I don’t end up with an estimate that will collapse as soon as I encounter even a regular-sized problem. It’s finding the balance between customer service and self preservation that is the hard part here.

Basically, I won’t give you optimistic estimates. I can’t. I won’t. The best reason not to be optimistic is that in my personal experience it hardly ever works and in the end you either have to postpone the release or you end up with a low quality product.

There are also good reasons not to be pessimistic. One is that this is a bad state of mind. I don’t want to be pessimistic. Really. I’d rather not run into problems and work smoothly on a project. Plus, it never goes over too well with whoever is waiting for the project to get done and I’d rather work with someone who’s not suspecting me of being a lazy developer.

My approach is to be realistic and factor in the risks of running into problems. This includes identifying the spots where problems are most likely to occur and allow for some time to fix these problems. Of course I might be wrong there and it turns out that where I suspected problems everything works fine. Instead trouble pops out somewhere else. Or not at all. Or everywhere at once. Who knows?

One of the best quotes I read about estimates was somewhere on 37signals‘ blog Signal vs. Noise. I don’t remember exactly, but the gist is this: Estimates are guesses. Nothing more and nothing less. They are not promises. They are not random numbers. They are something in between. And they might be wrong.

The best thing I can do is try to stay realistic in my estimates and trust that you trust me enough. I can only guess anyway.

—

I can’t find the original quote that I had in mind when referring to Signal vs. Noise, but here are two interesting posts that deal with the topic:

Unicorns and Projections

It’s not a promise, it’s a guess

Thinking Differently Through Unit Tests

We don’t practice strict TDD where I work, but we make sure that we have a decent code coverage and good unit tests.

Rather than doing TDD by the book all the time I sometimes find myself with a small project wondering how to start and then coming up with the first set of tests that I know will definitely need to pass and then continute from there.

Usually, this „test first, then code“ principle only holds for so long before it breaks down and I find myself switching between writing code and unit tests in no particular order. Nevertheless, it is a good way to start and I usually cover a good deal of code before I’m straying from the pure TDD path to something less structured.

What I noticed when writing tests first is that I focus on completely different things than when I write code the before writing tests. Mostly, when writing tests first I first come up with everything that might go wrong rather than what goes right. Usually, tests for exceptions come first, then all the other conditions where things might not work as expected and last the happy path for when everything goes right.

When writing code first, it’s the other way round: First figure out how to do it, then cover the exceptions. This is probably different for other developers, but in my case it’s a very interesting observation I was able to make about myself and the way I think.

Another good place to practice TDD in small doses is bugfixing. Just write the test first, make sure it fails and then write the code to make it green. When working with untested code, it is a good way to start bringing code coverage up without having to dig through tons of code. It might not be perfect, but it’s a start

Simple Tools to Make Your Life Easier

When working on a feature we often have to check the application’s log files. The easiest way was viewing them with Notepad, but that means that whenever something new was logged you have to close and open the file to see the actual log entry. Then one colleague recommended mTail, a tool that hooks itself to a log file and will automatically appends everything that is added to the file to its UI. It’s a very simple tool, but it does exactly what I need to debug an application and be able to check what is logged without constantly closing and re-opening the log file.

I’ve written about Launchy before, the tool that lets you open about everything with a bit of typing. I use Launchy all the time to access applications, folders and documents and it makes my life a lof easier. A colleague recommended Everything and while it’s very similar to Launchy it does not quite do the same. Everything is the fastest search tool I know. I use it mostly to find out in which Visual Studio solution a class is located, a very basic task, but one which I have to do so often that Everything turned out to be a real time saver here. Another sweet thing I noticed is that it allows using Beyond Compare by right-clicking on files. So instead of just finding files and then going to their specific folders, I can start comparing right from within Everything once I got all my computer content filtered down a nifty list of exactly the files I’m looking for.

There are two other tools that you probably already know, since they are widely popular, but I’m going to mention them anyway:

Evernote is a simple, but powerful organization tool, that lets you clip anything from anywhere. It syncs to pratically every device there is, so I’ve got it on all my PCs, my iPod and my Android. So, whenever I see something worth saving for later I hit my Evernote shortcut and I have access to it from everywhere. It’s also a great tool to take notes, e.g. when you’re in a meeting. The only problem I have with Evernote is that my note collection is getting a bit out of hand. I guess that’s the drawback from being able to take notes of interesting stuff with just one keystroke.

Dropbox on the other hand is a simple file sharing tool that allows you to sync files to all your computers including your iPod and iPhone. I’m still waiting for the Android application. You simply install it and can drop files into your Dropbox folder. This folder will automatically push your files to the cloud and back to all your machines that are linked to the same Dropbox account. Dropbox also allows you to share folders or make files public. It’s amazingly easy and lets me transfer files quickly whenever I think I want to have access to them from… well… anywhere else.

And by the way, if you install Dropbox using the link in this blog entry, I will get an extra 250 MB worth of storing space. Which I really could use. So if you actually plan on using it, please use the referral and make me a bit happier.