Skip to content

Persevering through technical issues

I just wrapped up a painful 4-hour lesson is self-discipline. While working through James Holmes’ Struts The Complete Reference, I found that my ActionErrors collection did not seem to be getting passed back to the JSP view was supposed to render them. I spent hours debugging in Eclipse, attaching the Struts source code to the project so I could see just what was going on. (Isn’t it funny how after you have been frustrated by a problem for a while you begin to wonder if it’s the framework/language/operating system? Blame-shifting is a funny thing.)

After I could not figure out the problem for a couple of hours, I decided to download the sample code from the website for the book. Sure enough, once I had James’ code in an Eclipse project, it ran fine. I even opened all related source files and did a line-by-line comparison of the code to ensure that I hadn’t mis-coded anything.

It ended up that I had wrongly placed an exclusion filter on my source folder to not place any *.properties files into the build folder. Since my initial properites file had the form labels, it would run, but there were no error messages for it to display, even though I had added them – to the copy of the file in the source folder. Egad! As soon as I rectified that, all was right. It took forever to figure out what I had done wrong, but I doubt I will repeat that mistake anytime soon.

That sort of time-devouring learning experience is part of the price for mastering a technology. Until you have gotten your hands dirty and really screwed up and had to recover from it, you can only know so much. The books seldom cover all the mistakes outside the code that you can make.

The Pragmatic Programmer series talks about technical debt, a concept that the technical issues you don’t resolve never really go away. Rather, they accrete into an ugly mess that you will eventually have to face. Establishing that discipline starts small. When you hit a snag, work through it. Struggle with it. Don’t fag out (that is not a homosexual reference, for those who just executed that sharp intake of breath); work the problem.

Mailing lists for various technologies get peppered every day with folks who don’t want to work through issues. They would rather flail their arms and post messages with subject lines like “URGENT HELP NEDED – PLS RESPOND!!!” or “SOMEONe HELP PLEASE!” that offer little to no insight on the problems they face than wrestle with what is most likely their own careless error. As one who makes those errors regularly, I can say that the majority of the time, it’s not the language, it’s not the server, it’s not the tool – it’s probably you.

Don’t give up; push through to a solution. Sure, you may need help. Try it on your own first, with a good reference or even TFM. You’ll grow from it.

I think this post primarily serves to help me not feel like my evening was a total loss. 8^)