Don’t waste your time.
I am always surprised when a developer prefers a solution that requires special maintenance or deep knowledge of a platform to make it work versus a simple solution that will work in all cases. It’s like leaving landmines for those that follow them. There are a ton of examples of this, but the most recent one that caused me to blog about it is the debate over semicolon inclusion/exclusion in Javascript.
For those not familiar, people have “discovered” that there are some cases where it is “ok” to leave out a semicolon at the end of some javascript statements. The debate is whether this is a “good practice” or not. (See this EPIC discussion on the topic for a taste…)
Unless I’ve missed something, the main benefit of this is that you save one keystroke. The perceived benefit to the person who does this is pure vanity — they can show you how “deeply” they know JS. What this signifies to me is that they don’t care about the person who needs to read/use the code later. It also tells me that they would rather waste their energy on memorizing/recalling arcane rules than writing anything of consequence.
The only way that one can ever write anything worthwhile is if they can focus fully on the model/algorithm and focus as little energy as possible on the mechanics of typing the code. To be clear, the majority of the energy you spend on any development task is not “pressing the right keys.” (Note that I am not claiming to be the originator of this idea — and YES, Atwood is saying that you shouldn’t be wasting your brain power on typing…).
As a rule, I find the most direct, “works in the most cases” way to do something, and then I have freed up the brain cells for the more important work. Using semicolons even when the computer *may* insert them is one of those — there is no need to find out later that I mis-remembered the rules. I also include curly braces for all if/else statements (in languages that use them) — as a developer I can eliminate ambiguity in my intent by including just 2 extra characters, this seems like a cheap price to pay.
Another argument always surfaces when one discusses this topic: “If it’s in the language, I can (and should) use it.” I feel it would be a waste of time to attempt to explain why this is a totally wrong-headed view. Every single language that has been created to date (natural and artificial) has flaws. It is not reasonable to say that because a feature exists, that is enough justification for using it. The converse is reasonable: when a feature is shown to cause bugs, it should not be used. (I leave the “shown to cause bugs” as an exercise to the reader).
There is simply no excuse for a developer choosing a less robust construct over a more robust one whenever they have the opportunity. Characters are not in short supply, but brain cells are. Do yourself a favor and don’t waste them memorizing silly rules to impress your friends.
Wisdom of the Ancients
xkcd.comA webcomic of romance,
sarcasm, math, and language.XKCD updates every Monday, Wednesday, and Friday.
Wisdom of the Ancients
RT @jmarnold: Love. http://t.co/0D7FtrBG
Fear and Loathing in Software Engineering.
I’ve been writing software professionally for a couple of years now, it’s a good gig, and something I love doing. I have always had a very strong sense of obligation to do my best. Although I have made mistakes throughout my career, there is no doubt that I will make more in the future.
What I’ve noticed is that beyond deadlines, ever-evolving requirements, perplexingly bad code, and vexing platform behavior, there is one thing above all else that stresses me out: Being blocked from fixing broken code.
I’m not talking about code that is ugly. I mean code that I had a hand in that is just plain wrong.
I like to think that others would describe me as a person of the utmost integrity, that will own up to my mistakes, and work to correct them. I tend to first look at issues and search for a solution, then see how to make sure that particular issue (or class of issues) doesn’t happen again. Every minute that there’s code in production that is broken because of me weighs on my mind. I really feel like the worst thing you can do to a competent developer is to show them something that they could have prevented, or that they could fix, and then tell them that they can’t touch it.
Make the leap of faith that mistakes will happen, and that the best developers will be responsible for some of them. Do your best to streamline your development process so that correcting mistakes is cheap. Remember that relaxed (and happy) developers are productive developers.
Form is Function
About ten years ago, as any self-respecting nerd would do, I was toying with Linux. I remember endless hours of package installations and command-line hocus-pocus, searching forums, swapping video cards… I even got SAMBA working. Once.
I wanted to make the switch off of Windows, but there was that nagging feeling that I might need to get some work done on my PC someday, and I didn’t want to be stuck. I wanted all the unix utilities, and all of the freedom that Linux seemed to offer. I just didn’t want to give up the convenience that Windows gave me.
Then somebody showed me something that changed my life:
Ok, it wasn’t the iBook itself, but what they had installed on it: OpenStep installed via Fink and running on a local X11 install. I found out I could have all of the stuff I wanted from Linux, and the safety net of an operating system that “just worked” (I should note that Windows XP and later usually ‘just work’, and if you don’t install a bunch of junk on them, they’ll get the job done).
So, The Function of the thing was just so impressive. It really could do everything I wanted. But there was something else….
The Form
At a time when this was the most beautiful PC you could get:
PowerBooks looked like this:
Now, you’re about to say that “It’s just a machine, you use it to get work done. Who cares what it looks like?”
And you’d be right.
But you’d also be wrong.
Try this out; You can put wi-fi in a laptop that weighs 15 pounds. It’s “portable,” but will you carry it anywhere? Now, chop that to 8 pounds, and there’s a chance you’d tote it into public. Chop it to 1 pound, and it can change your life. That’s a very real case where Form basically creates utility and adds value.
We try really hard not to seem like the form of things matter to us. It’s too “touchy-feely.” But, deep down, we make decisions about things all the time based on design and form. Frankly, if we embrace that fact, we’d make better overall decisions.
Think about it, do you make decisions about whether you will buy something from a website based on how “reputable” it looks? I do.
So this brings us to the one true point of this post…
Form is function.
Functionally, Windows, Linux and Mac all suited my needs. But in the end, the one that brought all of them together in the most cohesive Form won my heart. Linux definitely has the most raw power. Windows gets the job done with a painful - sometimes crippling - UI. But, the Mac brings the power of *nix and the cohesive, ergonomic UI in a way that the other two couldn’t. As a result, I’ve had a Mac since 2003, and I will probably never switch again. The functionality is important, but the form is actually the selling point.
People that have read my blog will know that I write C# for a living. I love the language, and I think .net is a great platform in many respects. But I also see the cracks. I think that the tools you’re using actually have a direct impact on what you produce. Windows lacks a certain style, and a large chunk of the stuff that gets pumped out from .net development reflects that. Windows is not personal, so a big chunk of the software designed on Windows reflects that. .Net/Windows drives towards a mentality that if the code is “functional”, that’s “good enough,” but it’s the little touches that make people feel good about the software we make.
I try to develop software that people want to use. And that’s at every level, whether it’s a public-facing website, or a database driver.
I want the person that uses my software to feel like a superhero, leaping small buildings in a single bound, not taking the stairs like all the other mere mortals.
That’s not a functional thing, that’s a form thing, and it’s the difference between software that people will cherish, and software that people will try to forget.
Happy Birthday, Zach
This is just a bit of a nostalgic rambling about one of my life-long friends and how we get to where we are. As is probably apparent if you’ve read any of my blog posts. I’ve been fascinated with personal computers for a large part of my life. I’ve had an obsession with them and their power to change my life… Starting with this:
Andrew & Zach, ca. 2000
There were times when we disagreed on things, and I was not always the best friend in the high school years. Looking back, there are any number of paths our lives could have taken. I could have been sick the day that Zach showed up in 4th grade. Zach could have decided that my disdain for Macs was too much to bear. But as it turns out, we’ve been friends for almost 20 years, and outside of my wife, there is no one else on this planet that I trust as much as Zach. I sometimes wonder what other directions our lives might have gone, but I am mostly thankful for the way they’ve turned out so far. Happy Birthday Zach. P.S. Zach did eventually win the little Mac battle, but that’s another blog post.
Hi. I'm Andrew. I write software.
