Archives
-
GhostDoc in "Windows Developer Power Tools"
Today I received my copy of “Windows Developer Power Tools” by James Avery and Jim Holmes, to which I contributed a chapter about my Visual Studio add-in GhostDoc, comparable in scope to what I wrote for “Visual Studio Hacks”. For the chapter in “Tools” (which grew to 7 pages compared to 5 in “Hacks”), I took the opportunity to be more clear about what GhostDoc can do, and what it cannot achieve, and what to look out for e.g. when re-using inherited documentation.A small error was introduced in editing of my original text (which by the way turned out surprisingly tame considering the fact that English is not my native language): Unlike suggested by the text on page 314 “when you want to document a method or class”, GhostDoc does not generate documentation for classes. On a sidenote: While this is a feature that has been requested a couple of times, it hasn’t been implemented yet. And honestly, I’m not quite sure of the value of such a feature, let alone what exactly it is supposed to do (most of the examples I have received so far show a certain ELIZA effect concerning the belief in GhostDoc’s abilities, but I’m still open to suggestions).
To bring the topic back to the book: at more than 1300 pages, it contains a lot of stuff, covering more than 170 free and open source tools for developers. The concept of the book is to describe each tool on roughly 3 to 10 pages, helping you to decide whether or not to give it a shot, and if so, how and where to start. If “Windows Developer Power Tools” saves you from either missing a really good tool, or installing some crud software in the process of finding one, the book has reached its goal and saved you a lot of time (and maybe even trouble). As one reviewer puts it “You could spend your time tracking down these applications, but why?”. From what I can tell by a first quick glance at the table of contents and skimming the pages, definitely an interesting book.
-
Five Things about Me
The game of blog-tag has finally reached me: i got tagged by Albert. While this is obviously a pyramid scheme which at some point will collapse, I must admit that I have enjoyed reading the “five things” entries of other bloggers so far. So here we go, five things you probably don’t know about me:
- As a child back in the 70s, the children’s TV series “Wickie der Wikinger” (Vicky the Viking) and “Sendung mit der Maus” have played a big role in getting me interested in science and technology.
- At primary school, I was the first in my class to borrow a book from the public lending library in our school building. I went to the library on the day we received the ID cards, right after school, even though I knew that I would miss the school bus (that was before I was allowed to ride the bike to school); fortunately the walk home was only 20 minutes. The first book I borrowed was a children’s book about the exploration of space.
- I have a long list of failed hobby projects in the time between 1983 and 1986. Overambitous designs, fragile architectures collapsing after minor changes, lack of documentation causing incomprehensible code, loss of interest after a few weeks – all the things you can expect from a typical teenager. Looking back I learned some of the most valuable lessons in that time.
- I once wrote a Sidekick clone called SideWorx for the 8bit computer CPC 464 (by Amstrad, sold by Schneider in Germany). Even though the program worked very well with other programs, its reliance on a rarely-used third-party memory expansion kit prevented any success. Computer magazines I sent the program to ignored it, presumably because the editors weren’t able to try it out. This was before the Internet and access to a BBS was out of reach for me at that time, so without any chance to spread the word, SideWorx had in total the impressive number of four users (my father, two of his colleagues, and myself).
- As a student at university, I got hired more or less immediately after using a self-written tool in a programming class. Students had to develop a program in Turbo Pascal, teaming up in pairs. I ended up with some other guy I didn’t know and we started coding. After some time we ran into a situation where we needed to modify the source code in a very repetitive way. I left the IDE, grabbed a disk out of my backpack and started up a text editor with a macro recorder. The other guy asked where I got the editor from and I told him that I wrote it myself. What I didn’t know was that he – at age 19 – had his own software company and a fat BMW standing in front of the university building…
-
Ten Years at Comma Soft
Today, exactly ten years ago, I started working at Comma Soft here in Bonn, Germany, coming straight out of university. Just amazing how fast time has gone by. Ten years at the same company is even more amazing considering the fact that I originally had planned to stay maybe one or two years, just enough to gain some professional experience, and then move on.
But towards the end of 1997 I joined what would later become the infonea product team. Working in a team of nice and intelligent people (neither nice bozos nor intelligent back-stabbers are helpful in the long run), using a wide array of different technologies over the years, made me stay. And I'm pretty sure that I may stay just a bit longer, because there must be really good reasons to leave a workplace where I have these two very nice TFT monitors (24” @ 1920x1200 + 20” @ 1650x1080) on my desk ;-)
(Photo published with kind permission of Comma Soft AG)Update: The story "How I got Hired Straight out of University" is now online.
-
Part 6: How I got Hired Straight out of University
How I got Hired Straight out of University
Monday, January 6th, 1997: This was the first day of the new year back at the Institute of Physics at Bonn University, and at the same time I knew it was about to be one of my last days. The past 14 months I had worked on my diploma thesis, which involved developing a C++ library for accessing data acquisition and motor controller modules for various bus systems. I had already turned in the thesis paper and given a talk about the project back in December, but had to wait for the results. In the meantime I was wrapping up loose ends in the code base, getting ready to move out the office, and surfing the web for a job as a software developer.
While I did have a (somewhat vague) job offer at a company I had worked for as a student, the actual job interview (more or less pro forma I was assured) had been delayed over and over again as an important meeting deciding on how many people should be added to the company hadn’t taken place. It was now scheduled for end of January ("this time for sure").
After some time in my office I thought a hot chocolate would be nice. I went to the vending machine in the hallway, where I ran into one of the two professors who had read and evaluated my thesis paper. The professor told me he liked my work and asked me about my plans after university. When I answered that I was looking for a job as a software developer, he said he knew some people at a local company and could make a contact. Of course I accepted his offer, but having been promised many things in my life before (with only a fraction actually coming true) I remained a bit sceptical. It was quite a surprise when only 15 minutes later I received an email from a person at Comma Soft, asking me to call him on the phone. I called and we talked a bit about my work. After about 10 or 15 minutes he asked me if I’d like to come over for a job interview – the next day!
Tuesday, January 7th: The job interview. I was nervous, my heart pounding. After all, it was my very first job interview, ever. The interview wasn’t done by the person I had talked to on the phone, but two developers. The interview started with some questions about my diploma thesis which went pretty well. After that came questions about how I would approach future projects, how I would design class hierarchies, what I thought about multiple inheritance, and so on - nothing too technical. Then one of the interviewer changed the topic:
- Interviewer: "Ok, let's see... Well, we could ask you about X…"
- Me: "..." (hmm, I hope he won’t go too deep)
- Interviewer: "…or we could ask you about Y"
- Me: "…" (ouch, I’d have to look that up)
- Interviewer: "But these are things that we assume you either know…"
- Me: "…" (hmm…)
- Interviewer: "…and if you don’t, you could look them up."
- Me: "…" (phew)
- Interviewer: "So here’s a question that may be a bit unfair, I’m not sure, just to get a picture of you, not necessarily a problem if you can’t answer that…"
- Me: "…" (uh uh, this doesn’t sound good…)
- Interviewer: "Do you have a rough idea what a C++ compiler does with virtual methods behind the scenes, i.e. how they are translated?"
Tons of rocks dropped from my heart. What a coincidence.
When I started my diploma thesis, I had to debunk the myth that C++ was automatically much slower than C, otherwise I wouldn’t have been allowed to use something so "advanced" as C++. Among other things, I had to do perform some benchmarks on the various possible types of C++ function calls (standalone functions, class member methods, and of course virtual methods), compared to C functions calls (standard call, via a function pointer, via a pointer to a function pointer). I included the benchmark for the call via a pointer to a function pointer reasoning that if I had to reproduce in C what I could do with a virtual function call in C++, pointers to function pointers would be something I'd use. Not surprisingly, the times measured were comparable.
When I started mentioning that fact, the interviewer cut my answer short and said "yeah, there’s this vtable thing, and then these function pointers and stuff, … I guess we stop here, thank you". The two devs left the room, a couple of minutes later the door opened and somebody else came in, turning out to be the person I had talked to on the phone. When he started a monologue about what a great company Comma Soft is, I knew they wanted me. But we didn’t close a deal yet, instead we agreed that I would send them my final results as soon as I got them from university and that I would hear from them.
Wednesday, January, 8th: In the morning I received my final results (sooner than expected), and faxed them over to Comma Soft. A couple of hours later I received a call from Comma Soft and was asked how much money I wanted. I told the person what the other company was offering, he said that it sounded reasonable and asked me if I would like to come over the following Monday to sign a contract.
Monday, January, 13th: With the contract ready to be signed, one final question remained: When would be my first day at Comma Soft? I told them I would like to start as quick as possible. At that time I didn’t have money for a journey and my idea of fun was spending my spare time learning Windows programming (prior to that, I had developed in private mostly DOS, and the diploma thesis was for *ix systems). They said "well, we don’t have a computer ready for you by tomorrow, but what about Wednesday?". I agreed and signed the contract.
Wednesday, January, 15th 1997: My first day of work at Comma Soft. Funny, originally I had planned to choose my first company very carefully - and here I was sitting at a desk just nine days after my first contact with an unknown company! On the other hand, the people I met and my overall impression of the company seemed nice enough to convince me. I reckoned that I could start looking for another company if things wouldn't work out, making some money and gaining some experience in the mean time.
Well, things worked out better than expected. An important step was that in fall 1997 I joined what would later become the infonea team that I’m still a part of. But that's another story...
P.S. I received an email from the other company at the end of January. Now they were ready for a job interview - but I wasn't anymore.
-
Need a New Year's Resolution? What about User Groups?
You are a developer by passion. You are interested in new technologies, even in your spare time. You are driven to keep your skills up-to-date. You are reading blogs, maybe you are writing a blog yourself.
But something is missing.
The developers around you are different, and you can’t even blame them. Maybe they are busy building a house, their children are keeping them on their toes, a non-computer hobby eats away their spare time – or they are simply working crazy hours and need a well-deserved rest when they get home.
You would like to get in touch with other developers. The Internet offers a huge number of possibilities to get connected to people all over the world, but let’s be honest, nothing beats meeting “real” people.
Have you thought about joining a .NET user group?
At a .NET user group, you’ll find a wide variety of people, coming from different backgrounds, with vastly different skills and experience levels, all united by the common interest in .NET technologies. Most user groups are having regular (e.g. monthly) meetings, where talks are given by members or external speakers – this is were you meet real people, not online personae.
A good place to find out whether a user group exists in your area is the website of the International .NET Association (INETA) at www.ineta.org. Choose your region and start looking for a nearby user group. If you find a group in your area, things are really easy: go to their website, get in contact and visit one of their meetings.
If you are wondering whether you are a “user group person”: Don’t be shy or too critical of your own skills – a user group meeting is not a place where you have to prove yourself in any way. If you prefer sitting quietly in the back, you can do just that. Nobody will force you to become a speaker the minute you enter the room.
Here are a few tips for your first meeting. These are pretty obvious, but being a user group leader myself I have my fair share of experience with first time visitors:
- Don’t be late (yes, duh). Note that coming late can be a major annoyance, e.g. if the meeting takes place in a company meeting room, where somebody may have to pick you up at the entrance.
- Come a bit earlier so you can talk to the user group leader or the person you had contact with, or other members. Don't be way too early as that will most likely disturb the preparations (setting up equipment etc). The best thing is to ask your contact for when other members usually start to show up.
- Prepare a short introduction you can use when talking to other people – who are you, what are you doing, what are your interests. You don’t want to drive home thinking “dang, I should have mentioned I’m very interested in technology X” given the chance that somebody else could have started a conversation “hey, I’m using X, too… what tools are you working with?”.
- Avoid being under time pressure. Depending on the user group and their meeting location, group members may go to a bar or a restaurant after the “official part” of the meeting. Plan for enough time to join them, it’s the best thing you can do to get in contact with other people.
But what if the next user group is too far away?
Have you thought about founding a .NET user group?
So you didn’t find a user group near where you live. Of course you could wait until a group is founded by somebody else. That’s what I did for almost a year before I eventually founded a group myself in Bonn, Germany called Bonn-to-Code.Net (yup, pun intended, all credits go to my buddy Jens Schaller) – that was exactly one year ago on January 1st, 2006.
A couple of tips for building a user group:
- Find a meeting location. Sure, you can found a group first and take care of the location later on (maybe hoping that somebody else has a room to offer), but obviously you are in a much better position with a proper location. I had luck that I could convince my employer (Comma Soft AG) to provide the meeting rooms complete with beamers and a sound system. To convince your employer, write up a list of
- risks, e.g.
- Developers from other companies could benefit from specific internal know-how that took a long time to develop
- Skilled employees are more visible outside the company and thus could be lured away
- and opportunities, e.g.
- Generating an influx of know-how and new ideas
- Providing a venue to show that this company is a cool place to work at, and getting it known among developers (especially developers that share a certain level of “energy” in contrast to people with a 9–5 mindset)
- risks, e.g.
- How to determine which topics of everyday work company employees can talk about at meetings (if you find it easily on Google, it's not a trade secret)
- How to make sure nobody can wander freely inside the company building (e.g. accompanying people to the restrooms)
- How to make sure no computer of an external person is hooked up to the network
- Build a website. Lots of what can be done wrong here…
- For a start, keep it simple. Don’t dream up what could be done with forums, wikis and blogs; you’d need a critical mass that’s hard to reach on the Internet, let alone in the context of a local user group.
- It’s all about content. It doesn’t matter if you start with a website consisting of a single page whipped up in FrontPage if it’s updated on a regular basis – even if it’s just a blog-style report describing the process of founding a user group. Long-term solutions can be searched for after the first meeting(s).
- Remember that user groups are about people. Too many user group websites make it hard to see that. Who are you? What are your interests?
- Don’t try to “sell” too hard. Yes, there are benefits for the members of a user group (e.g. rebates on software licenses and/or books, see the INETA website for more on that), but that shouldn’t be the focus. You are not looking for customers you have to convince, you are looking for a bunch of devs coming together and having some fun.
- Advertise the group.
Use everything at your disposal: your blog (if you have one), community websites like codezone.com/de, etc. Create flyers, posters – whatever comes to your mind. - Take a look at what INETA offers
On the website you’ll find information on how to start a .NET user group, how to apply for (free) membership, etc. Don’t expect miracles from INETA, but founding a user group and not contacting INETA is plain dumb. - Plan the first meeting. There are multiple approaches to a first meeting, two I have witnessed myself (in Bonn and at the neighbour group in Cologne, DNUG Köln) are:
- Let people introduce themselves and get to know each other
In Bonn, the first meeting consisted mainly of short introductions on two or three PowerPoint slides. Obviously, this approach doesn’t scale well beyond let’s say 15 people, but looking back this really gave the group a jump start in terms getting to know each other. The evening did not offer any technical content, but dealt with planning future meetings, deciding on topics, etc. - Start with a “big bang”
In Cologne, the first meeting had a well-known conference speaker giving a talk. There was no time for really speaking about organizational issues, and after the event, the speaker was the focus of attention. Nevertheless, the Cologne group is now running successfully. Starting “big” attracted people who otherwise wouldn’t have shown up (by their own honest account), many of them still being members.
- Let people introduce themselves and get to know each other
- Make sure you have a rough idea for the second meeting. Maybe you are lucky to you have a bunch of “natural born speakers” in your group, eager to give talks. If that is not the case (or if you don’t find enough material for a full evening), have a plan B up your sleeve, i.e. a talk that you could give. Note that your primary goal must be to get other people involved as quickly as possible, which brings us to the next point.
- Lower the entry barrier for contributions. Preparing a talk takes time and effort, which may put people off. There are things you can do to encourage contributions:
- Offer a PowerPoint template
Make it easy to author PowerPoint slides that “fit in”, i.e. have a certain “official user group feel” for those that are not comfortable developing their own design or using a stock template shouting “look at me, I’m a PowerPoint n00b”. - Introduce the concept of a “QuickTip”
Don’t require each talk to be of same length and depth. Sometimes just a hint on a single hotkey, a small tool or a cool website can be enough for the visitors of the meeting to drive back home with a positive feeling. At Bonn-to-Code.Net, a “QuickTip” consists of just a few slides: what’s the problem, what’s the solution, and a short demo (sometimes maybe even just a screenshot).
- Offer a PowerPoint template
New year’s resolutions are about changing something in your life. If you get involved in a user group, you life will change – be it just a little bit (just coming to meet other developers), a little bit more (taking the plunge and contributing a talk here and there), or a whole lot more (founding and running a user group). Whatever you do, be assured you’ll have lots of fun.
