DEVTRENCH: Web Development from the Front Lines

I feel fortunate to have spent the last two days in Dallas, TX with the greatest minds in the MODx world. MODxpo 2010 was so far above what I expected that I’m at a loss to capture everything that went on. The most awesome and most humbling aspect of the conference was the openness, honesty, and down-to-earthness of all of people that attended, including the core team. As I’ve written before, the MODx community is a big reason why I’ve stuck with it for the past 3 years, but these last two days solidified that for me on a very real level. I’ve simply never been around a big group of guys (and one gal), who are doing the same work as me and who know MODx so well. Continue Reading »

If you’ve coded yourself into a problem that you can’t figure out and you’ve spent hours debugging always remember this simple rule to solve your problems faster:  Reduce and Simplify.

If a solution to a problem isn’t obvious by looking at your code (or output), then start taking chunks away until you don’t see the problem anymore.  For example, I was having a tough time figuring out why some web pages I built were very slow in IE 6 & 7, but loaded fine in Firefox.  I had a thumbnail generator that wasn’t working right, which I thought was part of the issue, but once that was fixed, the problem still existed.  At that point I should have started reducing the code to find the problem, but instead I kept at my original assumption that something was wrong with the thumbnail generator and spent hours in forums searching for answers.  After a night of rest I came back at the problem and started reducing the code.  The first thing I did was take all the javascript out of the page, and wha-la the slowness disappeared.  Now I knew the problem was with javascript (or so I thought). I found which particular js file was the culprit.  Then upon further inspection found the javascript used a css file and that had some bad paths to images in it:

/* bad path in IE specific CSS made IE 6 and 7 slow */

.cboxIE #cboxTopLeft{background:transparent; filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=/js/colorbox_assets/images/internet_explorer/borderTopLeft.png, sizingMethod='scale');}

And that was the problem.  Had I remembered how to troubleshoot properly, I could have written this blog post yesterday.

Have you ever asked yourself why you do the things you do?  Why do you design the way you do? Why do code the way you do?  I’ve been asking this question off and on over my career, but lately this question has really come back to me in a big way.

I’ve been reading Getting Real by 37signals and although this is my second reading of it, it’s really hit home this time.  The entire book is basically about your approach.  How do you get up every morning and step up to the plate?  For a long time, my basic approach has been, how can I code this as fast as possible so that I can get on to my next project and keep at my ever growing list of tasks.  Ultimately, this very unsatisfying because the quality of work is low, and low quality leads to a ton of other problems.

So if you’re stuck in a rut like this how do you get out and take a different approach?  How do you slow down while keeping up with high demands.  That’s my problem: I can’t see past the pile of work to know.  So while I would love to “Get Real” now, I’m not to sure that I can all at once.  I do think it all starts with changing my approach and taking a lot of the advice in the book to heart.  It’s not going to happen over night, but I’ve already started to try some of the things they advocate in my symfony development and for the first time it doesn’t feel like I’m fighting with symfony.  So for a little while on the blog here I’m going to be wrestling with a few of these questions and tell you about some of the small successes I’ve had in becoming more real.