Work – Here Be Subtlety

Conference Tweeting or What Is Up With That?

If you follow me on Twitter, you might have noticed: I was at a conference last week. Not only did I announce it several times, but I’m sure that the frequency of my tweets increased at least slightly. (Actually, I think it increased a lot, but who am I to say?)

The problem with tweeting from conferences is that it can easily scare those who don’t really have a connection with whatever I’m talking about. There probably were a couple of questions: What the hell is up with that? Why is she tweeting so much? And what’s she talking about? And why is she suddenly tweeting in English?

Well, there are answers to all that. But let’s begin from the start…

About the same time last year I was at a Lean/Kanban conference in Munich. Those were two days filled with talks, keynotes and pecha kuchas about Lean and Kanban, agile and processes.

I didn’t really think about it when during the first talk I unpacked my laptop and began tweeting about what was happening on stage. Even better, and faster than I expected I got feedback. People replied to my tweets, retweeted and faved them. Pretty quickly there was an official hashtag for the conference so that it was even simpler to follow all the tweets between and during the talks.

„Ah, you are Anne. I think I’ve retweeted you“, someone said when I sat down for a talk. I’m not one of the hot shots of the Agile scene, but using Twitter made it unbelievably easy for me to get to talk to other people. After all, we had been going back and forth on Twitter all day.

It was at this conference that I learned how to use Twitter. Before that I didn’t really feel comfortable replying to people who didn’t follow me. I thought it would seem weird, even a bit pushy, since – after all – they didn’t know me. At the Lean/Kanban Conference I learned that this is bullshit. Twitter, for me, is best when used as a tool for communication and that’s what I’ve been using it for ever since.

A lot of the people I started to follow at this conference, I still follow. Some people who started following me then actually still follow me, although a lot have dropped out when they realized that usually I don’t actually tweet in English and very seldom about software topics. I can’t blame them. But it means that I’m even happier for those that stuck around.

This year, once again, I was at a conference. This time it was the Agile Testing Days in Potsdam. Because I was pretty certain that I knew what was about to happen I wrote a couple of warning tweets, including the hashtag of the conference. And indeed it was just as predicted: The minute the first keynote started I was there with my Laptop tweeting along and following the tweets of my fellow conference tweeters. Of course I wasn’t alone, actually a lot of the speakers of the conference were big on Twitter, too. There was Lisa Crispin, active as always, as well as Mike Scott and Matt Heusser (whose talks I unfortunately missed), Sigurdur Birgisson and Huib Schoots, who walked up to me during one of the words saying „I have to meet you, I’ve been retweeting you all day“.

The experience basically was the same as last year. The timeline was busy with people writing, replying, retweeting and faving. I seem to be at least fairly good at what I call „conference tweeting“, at least that’s what I gather from my average retweet quota. Conference tweeting isn’t actually that easy and has some disadvantages. First of all, it’s hard to adequately squish the content of a 45 to 60 minute talk or keynote into a couple of 140-character-or-less snippets. And secondly, it does require some of your concentration. I’m still busy repeating these last three sentences in my head to write them down as truly as possible while on stage it just goes on. Nobody waits for me to be done with that tweet.

It’s a trade-off: Trade you loads of awesome interaction and communication for a certain percentage of your concentration. But since I believe that this interaction and communication is one of the most important things at a conference I’m happy to trade. I can understand why other people won’t do it, though.

But I will keep on doing it. For all my „normal“ followers, there’s no need to be scared. I don’t go to conferences that often, and it’s likely to stay that way. But maybe now it’s a bit clearer why I do what I did. And if you don’t happen to find what I tweet from conferences interesting I’m sure there’s a neat filter option in your Twitter client that you wanted to try out anyway.

Most of all I was amazed that some of my tweets actually got positive feedback from people who were not at the conference, sometimes not even involved in software development, but still seemed to like what I was writing (or at least some of it). I actually would like to write about „Agile“ for non-software people, but I will have to think about finding the right angle to attack this huge topic. We’ll see.

After all, you can have a lot of fun on Twitter. When in the first keynote of the conference, Scott W. Ambler said „in the real world“ one time too often, Gojko Adzic couldn’t help but writing:

another f*ing „in the real world“. does everyone else live in the unicorn land? #agiletd

Gojko Adzic, November 20, 2012 10:05

new task for #agiletd speakers. add unicorn pictures in your slides

Gojko Adzic, November 20, 2012 11:20

And that’s why at least 75 percent (that’s a complete guess, by the way) of the presentation suddenly contained unicorns. This caused enthusiastic cheers from those who knew and some irritation for those who didn’t know what the hell that was about. It wasn’t until the second day when I realized that in this case, what happened on Twitter kinda stayed on Twitter, when I overheard a conversation from three conference participants who tried to figure out what was up with the unicorns. Apparently they didn’t use Twitter.

I love tweeting at conferences. Before you know it you are in, communicating, getting to know awesome people and having fun. It’s also great for those who cannot make it to the conference but get to follow it at least a little via Twitter. If anyone is looking for professional conference tweeters for software or internet conference, I’m totally up to it! Although I’m sure there are lots of people who will be there anyway willing and able to do the job. (Damn.)

(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.

(Software) Management Advice Courtesy of Game of Thrones

I recently read Game of Thrones, partly just because and partly because I wanted to be done with the first book of the series before the HBO series started. (Might I say that I think that I was right to read the books first. While I really liked the pilot I’m not sure how many things are lost on someone who hasn’t read the books. It might still work, but it’s probably not the same.)

In the book I stumbled upon two passages that reminded me of very valuable management lessons which apply nearly as is to your common workplace. Here’s the first one:

„Know the men who follow you,“ she heard him tell Robb once, „and let them know you. Don’t ask your men to die for a stranger.“ At Winterfell he always had an extra seat set at his own table, and every day a different man would be asked to join him. One night it would be Vayon Poole, and the talk would be coppers and bread stores and servants. The next time it would be Mikken, and their father would listen to him go on about armor and swords and how hot a forge should be and the best way to temper steel. Another day it might be Hullen with his endless horse talk, or Septon Chayle from the library, or Jory, or Ser Rodrik, or even Old Nan with her stories.

I think this resembles closely to what I’d say goes for a manager. I mean, you don’t have to be each and every one of your employees‘ best friend, but at least get to know them a bit and make them feel that you’re interested in them. This can be purely work-related, by the way. Find out what they like to do, what tasks they enjoy and which ones they hate, what gets them motivated. In the best case, this is a win-win, because you might be able to assign tasks to the employee who has the most interest in doing a good job. You’re happy, they’re happy. I say, in the best case.

But even if you can’t just magically pull awesome tasks from your sleeves to hand out to your happy employees, getting to know them is important. We’re all just people and unless someone really is the kind of guy who wants to be left alone, we enjoy talking about… well… stuff. What you make of it is up to you and maybe it’s nothing more than showing that you care. In the end, though your employees probably won’t literally die for you, chances are they’re more likely to stick up for you and the rest of the team if they feel connected.

(Mind you, I’ve never been in a manager’s position, so this is just my idealistic developer’s point of view. If you want to read more about managing software developers which I’ve heard is very similar to herding cats, just go over and read Michael Lopp’s blog Rands in Repose or his great book Managing Humans.)

Another quote that immediately made me thing of some valuable software development lesson was this:

That was the trouble with the clans; they had an absurd notion that every man’s voice should be heard in council, so they argued about everything, endlessly. Even their women were allowed to speak. Small wonder that it had been hundreds of years since they last threatened the Vale with anything beyond an occaxional raid. Tyrion meant to change that.

That is a classic example of what I learned to know as Design by Committee Must Die. I didn’t come up with this lovely name, there is an excellent article over at Smashing Magazine which says about all that there is to say. It’s true though, while I think it’s important to have people discuss ideas at work, there are certain decisions that are better left for a single person (or at least a very small group of maybe two or three people) to make. The bottom line is, a) you never get done with anything if you want to discuss it first with everyone and b) half of the time you try to make compromises to make everyone happy which leaves you with a design that is so inconsistent that nobody’s happy.

This isn’t a call for tyranny, but it is a call for healthy judgement of decisions that don’t need to be made with the whole team. If someone has valid arguments to object the final decision they will (hopefully) voice them and if they are valid, they should be heard. But make that decision first and then see who deems his time and energy worthwhile to defend their take on the idea.

I find it fascinating who these ideas which are presented in a book in contexts of war and castles and kings and whatnot are so applicable to today’s management values. But then again, maybe it’s not that strange and there are just some values that hardly ever change.

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:

by David Wilborn / www.urbanjunglecomic.com

Blame versus Bullshit

In one of our sprints I had worked with another developer to fix a bug that we found in one of the modules already implemented and integrated into the Main codeline. The bug must have been there from the start and it accidentally deleted an attachment from the database if it was considered too big to be handled by the UI. It was fairly easy to miss, although not exactly a minor bug. You just had to stumble over it at some point and we did.

During the sprint demo we mentioned this bug while going through the list of important bugs we fixed and it quickly turned into an argument with another developer from a different sprint team about whether this really was happening (it was, data was deleted from the database, we CHECKED), whether it had any side effects (it did, only those were the same side effects that had already been there from the start) and when this bug was introduced (guess what, nobody cared, it was a bug, it was fixed, end of story). The quote that stood out though was the overly awesome „Then it was not my code.“

So here’s the thing. Nobody cared. So far nobody had blamed anyone. Nobody had checked source control to see who was to blame, because so far nobody had thought about checking. Once we had found the reason why data was deleted we started working on a solution to not let that happen. Then we closed the case.

Naturally after the sprint demo the first thing to do was to actually check who introduced the bug. I don’t need to tell you, who it was, do I? On the plus side, from that day „Not my code“ became one of the most quoted lines in our office.

Here’s the thing. In our development department there was a lot of healthy blame going round. By healthy blame I mean the kind of blame where you find something wrong or strange in the code and you go to the person who wrote it and ask about it. It’s the blame where when a feature goes wrong you go and have a talk about why it happened. It’s the kind of blame where when you find awkward code you sit down with the developer who wrote it and go through the code.

To sum it up: You might name names, you find the responsible person, you point out the error. But you do it because you want to improve the team, the code and the process. This is not about telling someone that they are stupid or pointing fingers and feeling superior. The fact was, everybody was doing it all the time.

Yes, even this kind of healthy blame might feel bad sometime. It’s not your favorite moment of the day when someone stands at your desk telling you that you probably did something wrong. It’s also not your favorite moment when you have to go to someone and point out a bug that you found.

Here’s the thing: It’s not personal. It made people aware of when they didn’t understand a concept. You would sit together and figure out what the issue was and how it could be solved. It made you re-evaluate how you went about implementing something and probably made you vow not to do it again.

Basically, healthy blame can be relabeled as „learn from your mistakes“. The only thing is that in order to learn from your mistakes someone actually has to come up to you and tell you. Otherwise it simply won’t happen. So embrace the blame. And as the blamer be prepared to be proven wrong. It happens all the time as well. That piece of weird code might actually have a reason – it just needs better comments.

What this has to do with „not my code“ is very simple. In an environment where blame is not considered evil, you don’t care about who did what and when. If it’s something serious or discussion-worthy you will seek out the person responsible. If it’s nothing serious, and easily-missed bug, some inconsistency or some code lines that aren’t exactly pretty, you just fix it, be done with it and move on the next thing. And that’s what we did.

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

Un-Scare your Participants With a Few Simple Tricks

I came back from a half-day training in England last night. The whole development team is holding training sessions for a group of developers from Vietnam and the UK for about three weeks and it’s a lot of going back and forth.

I only knew four people out of a group of about 20 participants. This can be quite intimidating. Yet, I imagine these kind of situations may be just as intimidating and awkward for the participants as it is for the trainer. They don’t know me any better than I do know them. They don’t know what to expect from the training, how I will react, whether they can be comfortable asking questions, how to best address me and so on.

I find there are very simple ways to show the participants of a training that:

a) You’re just human, too.

b) They don’t have to be afraid to ask questions or ask you to clarify something.

c) You are interested in who they are as well.

The tricks I find to work are the following:

Explain that questions are important for the training and for you
This may seem obvious, but I’d still want to mention it. Tell your participants that you want and you need them to ask questions. Tell them that this is important for you as well to make sure that what you teach them is actually clear and makes sense.

Learn their names
When I say learn their names, I mean, try to make an effort. I was holding a training for a group of people from Vietnam and UK and at one point when everyone was busy playing around with the system on their computers I walked around and tried to get the names of the Vietnamese guys right. It’s not that easy with foreign names and you’ll probably not get it perfectly, but showing an interest in learning who your participants are and what their names are and how they are pronounced is important. After all your name is important to you and it is part of who you are. Practicing someone’s name in front of the whole group also shows your participants that you are not perfect, but willing to learn new stuff.

Bring sweets
If I learned one thing in my years of working it’s that people like cake, cookies, and whatever other sweet things there are. Basically, nobody is ever too old oor too serious to not like chocolate. For the training I bought some German sweets at the airport to bring to the training and told the story of how I lived right down the street from the Haribo factory in Bonn and could smell licorice in the air sometimes. Whether it’s chocolate, cake, donuts, cookies or something else. Your participants probably will like it. Plus, bringing a bit of sweetness to your training might add a bit to the fun side of a training.

The Long-Lasting Effects of Scrum are Not Yet Known

Recently I moved from a Scrum team to a non-Scrum team. I was kind of aware that after nearly a year of doing Scrum (a total of eleven sprints) this would make a difference to me, but only now can I say for sure how that affected me and my perception of work in the first days after switching from Scrum to non-Scrum.

Frankly, it’s kind of terrifying. This is even stranger since for the most part of my work experience so far I have worked in non-Scrum environments. It seems like the Scrum-experience is indeed a bit intense and has an effect on you that you might not expect.

The way I work now can be loosely described as „there is no defined process“. In other words, there’s work to be done and the goal is to get that work done on time. That’s it.

During the first week I was confused by the lack of daily Scrums. We had daily Scrums at 11:30 am and I noticed that around that time I got slightly nervous and had to remind myself that there was no daily scrum. No more. I could just keep on working. Similarly the lack of daily feedback irritated me. How would anyone know how far I’d come since yesterday? How would I learn what everybody else was doing? (The answer, of course, is simple. They could ask me. I could ask them. Done.)

Apart from that, the lack of tasks is even more irritating and it still gets me from time to time. How long am I supposed to work on this? When is it done? When I should I start worrying about how long it takes? How long is it supposed to take anyway? Help!

Fortunately, I think these are just minor withdrawal syndroms that I will get over soon. But still, I find it interesting how the way Scrum works and the way you work with Scrum can affect you, especially if suddenly you find yourself NOT doing Scrum anymore. The bottom line is, Scrum provides a safe (or seemingly safe) environment for the team to work in. Things are clear. There are rules. There are numbers. There are timeframes. There are commitments. There are dates. There are times.

With all these things gone, you feel lost. (You really do.) The challenge now will be to create a safe environment to work comfortably in without all these fixed things surrounding you.

I will be working on that.

Every Developer’s Nightmare

The coffee machine on our floor broke yesterday. This might sound like a little thing, but for most developers (as well as project managers and testers) this comes very close to a catastrophe.

But since we are a creative and communicative bunch, this is what you might see when the unthinkable has happened:

The original message says „Broken – Technician has been informed“. I don’t have to translate what desperate coffee-addicted people have added below that, do I?

The kitchen whiteboard also was used as an outlet to channel the despair:

Don’t worry about what’s scribbled on there, but the many many unhappy „smilies“ should tell you enough about how we feel about our coffee here.