The power to say no

Being a freelancer entices us with a great power : refusing part or all of a job. In the myriad reasons why you would choose to be an independant worker, that is the most obvious one. You get to choose your assigments, your work hours, etc…

Thing is, being a freelancer is also about people. Saying no might trigger some antagonistic reponses. Just as having a good reputation gets you clients without prospecting for them, having a bad reputation gets your clients thinking twice about hiring you again. And remember, to a customer, the complexity or the dullness of the deed they pay for doesn’t really matter. Most of them don’t get that their “small additional request” is actually a lot of work, let alone an uninteresting lot of work.
We all get our preferences. For instance, I just love banging my head on a theoretical, or nigh impossible, problem, whether it is a 10 lines piece of code, or a 2 millions+ lines one. Optimization, or debugging, are all part of this thrill. But designing an interface, with all the buttons and the linked actions is both incredibly difficult and kinda dull for me. Intellectually, I understand the need, and I know I should do something about it. I just can’t get my head around it.

So, whenever the GUI design is part of the development, I am thrilled. It’s only a mild problem, the main issue generally lies elsewhere. However, when the whole contract is just slapping a GUI over some existing tools, I have second thoughts.

And here is the crux : I can say no, if I don’t feel like doing it. I can go to the movies instead of going to work in the morning. I can take a nap after lunch time, if I want to. The main question is “why would I act otherwise?”.

Several reasons might tip the balance. For instance, it might be for someone I like, someone I want to work with, or as a courtesy to a common friend. This is called the Sympathy Factor. Or it could be because otherwise I wouldn’t be able to pay the rent this month. This is the Money Factor.

Most of my fellow in-house developers react strongly to the second factor : they are paid to do a job, they generally don’t choose the projects they work on. Don’t get me wrong, I don’t mock the behavior… Some people work that way. Most people, should I say. And that’s a perfectly sane motive, to begin with.

I, on the other hand, react more strongly to the first one. We freelancers are known for sometimes working 20/7 out of interest or sympathy. We are therefore very strained, physically and emotionally, in these periods. So when a customer for which we have no sympathy whatsoever asks for something we don’t really want to do…

In the past, I had a client who got me working on an interesting project. So I entered the “hyper” mode (term coined by Julie), and for a week or so, I slept 2 or 3 hours a night. Then the guy comes back to me and asks for a change that implies a 70% rewrite of the code. The project is still interesting, so I stack up a second week of work at the same rate. Then, once more, the “one more thing…” number, and it also means some heavy work that was not part of the original deal. When the third time comes, what would you do?

I just said I was not interested in the project anymore. I had lost 3 full weeks of work and quite some weight, but the Sympathy Factor had run pretty low.

For those out there who employ developers : it’s true that we love what we do. It’s true that we can be driven by our projects to the point where the outside world doesn’t exist anymore. And like every specialist in this world, we like a challenge. But that doesn’t mean we are robots either. And sometimes, being proud is more important than being hungry. Don’t let the Sympathy Factor go too low.


The bug reporting mechanism

As all developers know, even the best of us leaves bugs here and there. I guess it comes with the package.
One of my teachers said that it was all a matter of probabilities : coding complex routines and structures gets exponentially difficult as the size grows, and therefore produces statistically more bugs. QED.

Most of us, when we start, think we produce bug-free software. The program is too small, the users are too few too even notice, and even if there are bugs, they are peripheral at best. So we just ship out the product and drift happily back to another project.

And the bug report hits us. It can be:

  • A bad review, online (cowards!)
  • A friend saying “you must have noticed this, that’s why I didn’t report it during the beta testing phase. Why did you even ship it?” (that’s what beta testing is about, dammit! I don’t see the same problems you guys see!)
  • An email stating the program crashes/loses data/does something really dreadful, without any detail (I know a bug sucks. I want to fix it too. Please help me!)
  • An email by a fellow developer, or a power-user, who actually details everything, including the crash log, along with some suggestions on the way to fix it (most of the times, this is very useful, but can be ill-perceived, depending on how condescending the tone feels)

Apart from the last one, the real problem lies in the “shyness” (let’s say) of the people reporting bugs : either they don’t want to be confrontational, or they think the bug is not a real issue, or they just assume someone else will report it. In my book, it’s a cultural thing. People would like to help, but they assume the worst.

We developers are not monsters, we don’t prey on poor users unable to defend themselves. Most of us aren’t even real geeks, incapable of interacting socially with our fellow human brothers. We just talk a different language. And we are used to interacting with a very very stupid entity : the computer.

As such, we need a way to allow non-technical people to grant us the benefit of their help that is as simple as possible for them, and as complete as possible for us. If there are technical guys reading, please bear in mind that explaining that is something that can also be interesting for you.

What do we need to make a good bug report?

  • A nice submission mechanism (email, web interface, crash reporter, …). The best ones are those that leave a trace
  • The setup of the machine. No need to go in deep details, just what’s relevant : OS version, computer model, and potential third-party upgrades
  • The actions that triggered the bug. If it’s repeatable (meaning “it doesn’t occur just once, I saw it several times in similar circumstances”), it feels really good to have a simple way to crash “on demand”
  • If possible, the crash log

When we have all these items, we are in debugging heaven. On small scale projects, emails are just fine. Even if you get 10 bug reports a week, you probably have a lot of duplicates. And here lies one of the major objections to bug reporting : “the developer must know already”. Well… probably not. And even if I do, it makes me feel this particular bug is more important than another. But it is a very good help to actually have a list of reported bugs somewhere accessible. That way people can look there to see if a report matters or not.

Personnally, I use RT ( from Best Practical ), for one reason : it is fully cross-aware between emails and web interface. When you modify something in the web view, it sends out emails, and when you send emails, it updates the web interface accordingly. It has all the gimmicks you want to use, such as severity and such, but it’s still pretty simple on-screen. It’s better not to frighten non-technical users with a flurry of options and popups.

Why did I ramble about bug reports exactly? Well, yesterday, I received a response to a bug I reported… in March 2005. Having a good bug reporting mechanism helps you keeping track of the time spent on bugs, and (if you are stubborn enough) it can nag you every so often to keep you from forgetting the “old ones”.


First class of the year

Here we go for another year full of students! The two topics for the 2006-2007 sessions are Object Programming Techniques in Java, and Embedded programming, in Java as well.

My first batch of students are in their last year (the french system is fairly complicated for foreigners, but basically, we are supposed to go through the high-school end exam – called the Bac – at 18, and we count from the aforesaid Bac on), Bac+5 level. They are specialized in embedded systems, with a good electronics background. The aim of this session is to make them understand that on top of hardware, there usually is software, and that embedded means… well constraits.

They were shocked, awed, and a little afraid, to learn that this class is taught in english. My english is fairly good, I hope, but french people tend to get shy very quickly with foreign languages. From school, we learn grammar, not how to talk… So if you english-speaking people out there ever visit France, don’t be surprised at the reluctance. It’s not they don’t want to talk, it’s just that they feel out of their depth with english. Talk with the hands, if need arises :D

So, 2h of Java later, they seemed okay. No one had fallen asleep, and I can’t say I had seen a lot of people doing crosswords. Either I am getting lousier at spotting slackers, or I actually get less every year!

Embedded Java is not the funniest thing to do in the best of times, so I can understand that these classes that range from highly abstract to awfullly pragmatic can be a little disappointing. It will get better once we get to the hands-on sessions, I promise!


Apple Expo ’06

Being a freelance developer is all about people. Pleople you work with, people you would like to work with, people who are using your products, etc…

Social networking becomes very important in my line of work. Clients contact me from mouth-to-ear, because they know someone who worked with me, or people who have used one of my small programs. I don’t remember ever having to actually prospect for customers, because a) I don’t have the credibility (I’m young, but I worked on a lot of projects. Nope, I can’t talk about them, most of them are still under NDA. Please, believe me!) and b) it’s very hard to tell someone he actually needs you, especially if you don’t have any idea why he would need your help.

So it is without any surprise that I accepted to help out for the big french “mass of Apple” – a.k.a. Apple Expo, on the “Business & Innovation” booth. Helping people I know is both immensely satisfying as a human being (I’m nice, right?), and as a professional developer (who’s the guy sitting there? really? cool, let’s chat!).

As usual, I’m part of a very small team, doing a very unspecialized job : we handle the Problems. From network access all the way to stool-theft (no kidding!), the four of us got to handle the well-being of our fellow professionals, making contacts and being as unobtrusive and efficient as possible. This year was comparatively easier than the previous shows, partly because being a mac developer (as opposed to being an iPod-something) isn’t as image-rewarding as it used to be – so we have to stick together -, partly because the general public was not as interested as before, prefering to drift towards the loud speakers.

So we spent a week together as professionals having a good time in a not so pro environment. The business was attented to when the general public was still waiting for the week-end, and for the last couple of days, all that was left to do was preventing people from entering the bar (Sorry, it’s a private lounge. No there’s no open-bar lounge on the show floor. Yes, I will prevent you from entering if the need arises), trying to keep people away from the exhibitor’s computers (Sorry this is not a cybercafe. No it’s not an empty post, the guy will be there shortly, to work. Yes, I’m a mean guy, because you can’t play online chess on this computer) and drinking coffee (to cope with the tiring activity).

I took the liberty of shooting a few pictures, starting with The Before Crew,

then The During Crew

PG & HGNoarMS & Ju'Yann

All in all, it was a success on all fronts. Thanks to everyone who attended!


[UPDATE] Yann has posted his own impressions


Highlight 1.0

Sometimes, someone asks me if an application for doing such and such actually exists. If it doesn’t, then they taunt me into making it.

This is the case with Highlight. Arnaud contacted me, asking if I had any on-screen drawin application, a simple one, just to make demos. I had already thought about it, since my teaching activities sometimes involve showing live stuff to the students, but I never actually took the time to make one myself.

After a quick chicken dare (and I quote: “The Nicolas I know would make it in less than an hour, so why doesn’t it exist already?”), I took some time to look into it and it was actually pretty quick to code. An hour later, I had the first beta ready for Arnaud, and a day or so later (after receiving some feedback), I had a working and (hopefully) bug-free software to release. So here is Highlight, the magic pen!

Highlight icon

Quote from Versiontracker:

Highlight is a tool designed with teachers and demos in mind : it helps you attracting the attention of your audience on what happens on the screen. It is designed to be as unobtrusive and simple as possible, while letting you express your communicating skills efficiently.

End quote

In essence, it’s an invisible sheet sitting on top of your screen that lets you draw… well whatever you might want to draw. It had a pretty decent feedback from users.

I just love this screenshot, so I’ll put it here:

Applesfera shot
This is taken from Applesfera

[UPDATE] Someone asked me to put highlight on a magazine CD. Whoohoo!