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.
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…
Next bloggers: Thomas, Sascha, Mathias, Sonu, Kay.
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.
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
Furthermore, ask and answer questions that surely will come up to show that you are acting responsibly:
- 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)
- 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:
A third approach would to split the time between a talk (given by a speaker that will be a member of the user group) and an organisational part of the evening. People could introduce themselves without support by PowerPoint slides, but that tends to less “sticky” than text and speech.
- 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.
- 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:
There are so many hidden talents out there that could be speakers for you user group, you only have to find them. The most important thing is to get them speaking for the first time – it’s usually less of a problem to convince them to give a second and a third talk.
- 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).
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.