Those that Do

Reading blogs filled with opinions on the latest software/language/library tuckers me out. Now, if instead they were contributing to such a project and were hashing out their ideas and/or struggles in public, I’d be on the edge of my seat. Alas, there aren’t enough of those on the net. And really, it’s the nature of a blog to be mundane and mostly insignificant. Notable exceptions noted. So instead, I waste my reading time by keeping up with (active) software projects and hoping to witness progress. People write too well too often about software stuffs; I want to see results. Of course, I’m writing this in my blog, where none of my code lives. Oh well. For that there’s always greaterscope.net.

Continuing on, I’m a big fan of the efforts of Rob Landley. I may not be able to see the code he’s working on but I can read about it, which is good enough for now. It’s comforting just knowing he’s actually doing things. My favorite method (and seemingly his) of contributing to the betterment of computing is by consciously trying to improve software. This isn’t for everybody and many probably see it as less spectacular than coming up with brand-new things but I remain committed. I don’t want to be a revolutionary. The chance that a person will make a truly original contribution seems pretty slim anyway. But it’s not impossible, so even I occasionally entertain those dreams. Improving upon existing concepts just seems a more readily rewarding — and perhaps a more noble — goal.

Re-Inventing

Starting from scratch on a particular application is great for generating quality software, but only when you know you can create something better. And really, the only way to know you can do a better job is to have experience with alternatives and a keen understanding of where they succeed and/or fail.

Also, if you’re going to take the time to re-invent a piece of software, do it well, especially if you’re planning on Open Sourcing it. You can hack it together in the beginning but refinement is king. Write the code for an audience. Write it to be usable and easily understood. Making software intuitive is an art, but attempt it anyway. Also, take a visibly different approach than the competition or you’ll end up looking just like them.

Why Obfuscate

I’ve heard some people boast about writing obfuscated code and I wondered why they’d even spend their time doing such a thing. To me it seems nothing more than an egotistical endeavor of deliberately making something confusing to others. Since I intend for my code to be understood by others I wouldn’t want to invoke the opposite.

And in comparison, doesn’t it require more skill to construct a program that works well, has a beautiful structure, and comprehensible code? I think so. But in some cases you might not want others to be able to comprehend or modify your code, such as if you’re selling a killer JavaScript application.

Obfuscation can also help create smaller code: there won’t be much left after you do away with the scaffolding that normally makes code organized and extensible.

Web Programming Likes and Dislikes

Since they’ve never been enumerated before, here are things I do and don’t like about web applications programming.

Dislikes - Least to Greatest

• That no real debugging environment exists, so code has to be written to temporarily print out variables and data structures in an effort to track down bugs
• Many projects don’t contain enough abstraction, making standard tasks time-consuming
• Writing CSS
• When code is interspersed with HTML
• Writing JavaScript

Likes - Least to Greatest

• It often requires knowledge and experience with many different technologies: scripting languages, data structures, databases, XHTML, CSS, JavaScript
• Can provide experience in dealing with deadlines, changing requirements, feature creep, and clients that assume features not mentioned in the original spec
• It serves as an excellent starting point for coders wishing to develop their skills. Working on a variety of web-based applications is a great way to become better at problem solving, critical thinking, working with others.
• Though it’s often regarded as less-difficult than developing non-web-based applications, there are many complex problems begging to be solved by clever means. Most of those I see are related to good code design.

Some Reflection

For more than a year I’ve been wanting to improve my skills in non-web-applications programming. However, since there’s still much to be done in the field I don’t envision ever leaving it entirely. The experience I’ve gained since I started writing HTML in 9th grade has landed me several jobs and enabled me to earn money while going to college. It’s the field of computing with the least barriers to entry, shallowest learning curves, and the most job opportunities. Experienced coders that also have an eye for design should have no difficulty finding work, since most smaller shops prefer to hire a single person willing to fulfill both needs.

Have a comment to make? Feedback is always open.

Write a line, Compile, Test

In reading Software Craftsmanship by Pete McBreen, I reached a section that focused on taking the time to develop a robust, quality product. Being able to consciously deliberate on design decisions and implementation details makes for good software. Having an employer that puts more emphasis on writing great code, rather than writing “good” code in x hours would be a great employer indeed. Too many times the emphasis is on speed, which is not only stressful but also leads to frantic mistakes.

Developers need to be free to put forth a concentrated effort in order to feel a sense of pride in the quality of their work. After all, it takes time to get things “just right”, and feeling good about one’s work means less burnout and usually drives one to strive for improvement.

The text also contained the phrase “‘debugging [one's] way to stability”. This I related to my own frequent internal conflicts:

Should I really be compiling after almost every line of code I write or should I try to write as much as I can and then compile and debug later

My answer was usually the former, and as I read more about software development I’m further grounded in my stance. It boils down to this: make it robust now, rather than trying to do so later. And, since I’m biased towards the “release early, release often” mantra, when testing immediately follows code-writing it means my software will reach many more releasable states than it would otherwise.