Professor for one year (week 12): Lessons learned

You learn from errors.  It would be great if you could just learn from errors made by someone else.  But sometimes I even make the same error again and again -- at the first sight it looks like a different situation, but in the end it's not.  However, here is a short list of lessons I hope I finally got:

Don't trust the nice guys

This is the academic equivalent of "Give him an inch and he will take a mile."  There are deadlines and guidelines.  Both are there for a purpose.  Sometimes, people ask you for an extension of a deadline.  And if you think the person will be able to meet the new deadline and deliver something of high quality, you agree -- even more, if you think it's a nice person and everything will go smoothly.  But then people start negotiating this and that and you spend a lot of time discussing and explaining that of course you expect guidelines to be carefully attended.

Don't make verbal contracts

Although in Switzerland (and maybe in Germany, too?) contracts don't necessarily have to be signed by the involved parties, it's not a good idea to only have verbal contracts.  I made this error twice.  The last time, I accepted a job without even asking about the payment.  I was lucky enough that the payment is OK.  Before this, I got an offer including a statement about payment.  I agreed, resigned my former job and started the new one.  I hadn't signed a contract for the new job.  Two weeks after my first day I got the contract -- with a much lower payment.  It turned out that even the salary stated in this contract wasn't correct.  I could negotiate a bit, but I regretted having resigned my old job.

Don't procrastinate

This is easy, you should start a task as early as possible and necessary.  Most of the time I estimate the time a job will take.  And I start just the estimated amount of time before the deadline.  Sometimes it is easy and my estimation is correct.  But most of the time it is not.  Some jobs or projects take longer and then I have to work until very late, I get tired, and I'm angry about myself.  Sometimes I get a job done a lot faster than estimated -- but then I'm angry about myself too, because I spend more time planning and thinking about the task and defining the best point to start than for the task itself.  If I would have started immediately, I could have had more time for something else.

You always underestimate the time needed for a software project

"Software project" refers to every kind of programming task, may it be small or large.  Even with a lot of experience, every project is something new and every project comes with surprises.  Clients change specifications on the fly, you start without any specification at all, nobody is available for beta-testing -- it just has to work now! --, you don't have a backup structure or even a backup strategy.  You spend hours with debugging, because you have been interrupted in the middle of programming a structure.  You work with a not-so-mature framework.  Documentation is only available for a different version of the framework than you are using.  The data you work with is bigger than expected and interactive processes have to be transferred to batch processes.

But what to learn from all this -- don't program at all?  The better lesson is probably to learn to estimate better.  Somewhere I read that for programming you estimate the time needed, then double the amount, and then take the next larger time unit -- for a task estimated to be done in one hour, this will result in two days you should allow for.

End then you have to take into account the user of the code you produce.  If it is only you, you can skip comments and keep it simple (like using default variables, anonymous datastructures, short versions of control structures, etc).  For other programmers being the users, you need to add more information and you should do error handling.  The next step would be a program someone will call from the command line.  Even more effort is needed for a web application.  And even more time you need for adding a nice GUI and converting it into an actuall application.  I think there was an article in the Communications of the ACM some months ago basically saying that each step increases the time needed by factor ten.  And of course being a computational linguist, most of the time your "clients" will be linguists or other non-technical users -- so whatever you program it has to have some kind of interface and user guidance.  Meaning that you are creating actual applications, not scripts that just output a number or a string.

Don't reschedule your plans and don't discuss programming with non-technical people

Having said that programming will allways need more time than you had estimated -- the Hofstadter's law -- you should never agree to reschedule your plans because your users think they need the things to be done just now.  The only effect this will have is more stress on you and constant arguing with your users.  People without any experience in programming usually cannot assess the complexity of a task --  How costly is sorting large data?   How long does it take to create a frequency list?  What does it need to allow users to make searchable comments during annotating corpora?  What does it mean to "have everything in a database?" -- You are the expert, you estimate the time needed and you decide if a feature should be implemented at all.  There is no sense in spending a lot of time in implementing a "probably-nice-to-have feature" just to find out that no-one will use it.  If users don't provide a specification and are not willing to create a specification together with the programmer, it's up to the programmer to create something.  With usually tight schedules in projects, there is no time for specifying something on the fly or to make substantial changes after a first version has been tested.