Software Development

I heard a coworker talk about how he doesn't understand why some developers never seem to bother to actually try to comprehend an exception thrown in their (or other people's) code. And i never understood that either, but it has certainly bothered me in the past as well. So let's just list once and for all the steps a developer should follow when presented with a thrown exception.

1. Check whether the exception has an inner exception. If not, proceed to step 2. If it does, check recursively until you've got the original exception (the one that doesn't have an inner exception).
2. Read the exception message. Don't just glance at it, actually read it. If you got an 'aha!' moment upon reading it, you already know what to do. If you didn't, proceed to step 3.
3. Take a look at the stacktrace. If the technology you're using prints its stacktraces in reverse chronological order (as in: the most recent method call is the first one listed) then open the first class of your code base that is listed in the stacktrace and go to the method of that class that is listed first in the stacktrace. If the stacktrace is printed in chronological order (as in: the most recent method call is the last one listed) then open the last class of your code base that is listed in the stacktrace and go to the method of that class that is listed last in the stacktrace. If line-numbers are displayed in the stacktrace, go the line-number that is printed next to the first mention of the first class of your codebase (in the case of reverse chronological order) or the last mention of the last class of your code base (in the case of chronological order) that is listed in the stacktrace. This is the part where you need to begin your search. The actual bug might be somewhere else, but at least you've got a starting point for your search. Once again, if you got an 'aha!' moment after this step, you already know what to do. If not, proceed to step 4.
4. Here's where it gets tricky. Some people immediately enlist the assistence of a teammate at this point. Others spend hours searching until finally calling upon a teammate who might spot the problem after 10 seconds. If it's not immediately clear, spend 10 minutes tops looking for a solution before consulting with a teammate. If you haven't found a solution after 10 minutes, you haven't lost that much time and you can ask a teammate for help. If the teammate can help, neither of you lost a lot of time and at least you tried to fix it yourself before interrupting a teammate. If the teammate can't help, you're probably going to have to investigate this further on your own. Perhaps your teammate has enough time to help you, but don't count on it.

For a lot of the people reading this, there's absolutely nothing new in this list so i apologize for wasting your time. However, odds are high that you're going to run into a developer who can use this sooner or later so feel free to send him a link to this page

As i mentioned in my last post, i want to get together with developers regularly and in an informal manner. Enough people expressed interest to get it started, so i've created a Google Group called DrinksWithDevs-Belgium which we can use to plan the 'meetings'.

Everybody is welcome to join, so please feel free to do so. The idea is very simple: you can suggest a get-together at a bar (or restaurant) of your choice. If people respond, agree on a date, go out, talk about software development, have a few drinks and just have fun. Ideally, these get-togethers will happen pretty frequently and in various locations throughout the country. That way, you can just pick which ones you want to go to. If you can't make one, or don't feel like going, just skip one. Or skip a few, doesn't matter. Just show up when you want to.

Finally, i'd like to repeat the 'rules' again so that we're all very clear on this:

• Leave your ego at home.
• You pay for your own drinks
• Open to all kinds of developers (.NET, Java, Ruby, Python, PHP, whatever...)

Hope to see some of you on these meetings in the future

About 2,5 years ago, i tried to start a Belgian ALT.NET group. Some people were interested at first and we had a few meetings. After a while though, things slowed down due to a variety of reasons. I do meet up with some of the people who were involved from time to time, and one of the things we all seem to agree on is that the most important parts of those meetings were the informal discussions about our jobs and projects that took place either before or after the actual 'meetings' or 'events'.

I want to get something like that going in Belgium again. I want to talk to other developers who are serious about their job. I want to know what they're doing and how they're doing it. I want to know what people are studying or experimenting with on their own time. I want to know what works for people and what doesn't. And i want us to share that information and that experience. If you feel the same way, please respond to this post with a comment (and do fill out your email address) or email me directly. I don't care how many or how few people respond. If 5 passionate developers respond, it's already a win-win situation for each one of them.

But... there are a few rules that i would like to propose to avoid the same result that we saw with the Belgian ALT.NET movement:

• If you wanna come to the meetings, leave your ego at home. We are not interested in being a part of your career plan. We just want to share knowledge and experiences.
• Let's not restrict ourselves to a single technology. It'd be great if these meetings were attended by people who were doing .NET, Java, Ruby, Python, whatever. The goal is to learn from each other and to pick each others brains, and one of the best ways to do that is to look outside of your immediate (technological) environment.
• Let's keep things simple. Let's not seek out sponsorship. Let's not seek out opportunities to do presentations. Let's just hang out and talk about software development.
• Let's get together regularly. Twice a month or so. If you can't make a meeting, show up for the next one. Or the one after that. It doesn't matter, as long as we always have a small group of people who show up to talk with and learn from each other.

Who's with me?