Archive for June, 2012

Proper IRC etiquette

21 June 2012 Leave a comment

Hi, I’m back — it’s me, cranky mriet!

I show up now and then when calmer mriet can’t take it anymore.

Today’s topic is how to behave on IRC.

  1. Please be patient. I know it’s hard to imagine, but some of us actually are not sitting around waiting for you to ping us on IRC.
  2. Please be polite. If we were all sitting around a table outside, you wouldn’t just start shooting questions at me, out of nowhere, would you?
  3. Remember, this is text, which means minor nuances are easily lost. So please, stay friendly and polite, even if you think someone is being nasty.
  4. Please only ping me once: most people on IRC have their clients set up so that it will flash or alert them once you type in their nick. Repeatedly pinging me comes across as childish.
  5. Grow a thick skin. Because you’ll need it.

Here’s a list of things that I will respond badly too. I’ve just discovered the /ignore command, and I’m going to start using it.

  • Private messaging me when you’re not someone who I talk to regularly — especially if it’s a technical question that can be asked on an open channel.
  • Popping onto an IRC, asking a question, and then disappearing 2 minutes later.
  • Not saying “Good morning/afternoon/evening!” It’s a very little thing to do, and it will mean a lot.
  • Spewing text at me when I haven’t asked for it.

I’m sure there’s more, I’ll just have to re-edit this entry later when I run into them.

Categories: Other

How to read a stack trace and fix problems

18 June 2012 Leave a comment

To be honest, I could probably write a book about this subject. I would include all sorts of stack traces — lots of mini-chapters, so to speak — and then describe how I figured out what the problem was, and fixed it.

Unfortunately, this would be a very boring book, because every time, I do exactly the same thing.

Kids, developers, random internet denizens, listen up and listen good — and use a hammer to get this into your head, if need be:


How to fix a Java problem when you have a stack trace


  1. Find the stack trace.
  2. Follow the Caused by:‘s until you’ve found the root stack trace.
  3. Search the web for the exception (or code line).
  4. If the web gives you an answer back, go apply the answer!
  5. If the web doesn’t give you an answer back, go debug the problem and find out what’s happening at the line of code!
  6. If you run into a new problem, start over!

Sometimes, you don’t want the root cause — but very rarely. Lastly, and I really shouldn’t have to say this, please think about why exactly the stack trace happened. What is the stack trace actually saying?

Obviously, sometimes, you will have no clue what the heck the stack trace is saying. In this case, you are faced with a golden opportunity to learn something! Learning what a stack trace is actually saying will only expand your knowledge and make you a better programmer. It will make you a better programmer because you will become aware of how programs actually work in the real world, and what types of problems are common.

To tell the truth, we’ve touched on 3 intrinsic skills you better have or learn if you want to fix code problems:

  • a. Learning how Java works (stack-based architecture of the JVM) — and thus, which parts of a stack trace are important.
  • b. Understanding what other people say or type and being able to apply that knowledge to your own (technical) situation.
  • c. Knowing how to debug.

I’m actually not sure which of these 3 is the most important or hardest. I’m tempted to say that c is probably the easiest, although many people (can you say Dunning–Kruger?) probably think c is the hardest. I know that I’m still figuring out how the JVM and Java work and that understanding what other people say or write is something that will keep challenging me for the rest of my life.

Categories: Other