Archive for November, 2011

You Know Better Than That

Monday, November 28th, 2011

In grade six, everyone thought I was smart.

I’m not smart. Anyone who watched me struggle through university can tell you that. Smart kids get scholarships. Smart kids ace exams. Smart kids get good grades. I’m not smart.

But in grade six, I was still doing alright in school, and people still thought I was smart. Especially my teacher, Mrs. Mainwood.

Every time I would hand in an assignment, or show her my homework, or answer a question, she would compliment me on how well I did. It was nice. When I gave a speech in front of the whole class one time, she asked if I would come back next year and present it again so that future students could see how it’s done. Nice.

Finally one day, something strange happened.

Mrs. Mainwood came to my desk to talk about some written assignment I’d handed in. She pointed at a bulleted list I had written. It looked like this:

  • some sentence about the assignment
  • another sentence
  • and another

The content was fine, and the rest of the assignment was fine, but she was really upset about this bulleted list. Why?

Because it had no capitalization or punctuation.

That was it. And apparently it was very important. She was furious! She went on a rant that I’m sure the rest of the class could easily hear. I still remember the exact words that ended her tirade: “You know better than that.”

I didn’t understand what she meant at the time; I probably just apologized and fixed my mistake. (I’m an apologetically easy-going guy). But I understand now. It was a big deal.

It looked stupid.

It was an eyesore on an otherwise flawless page. And you know what? Mrs. Mainwood was right. I did know better. My list looked careless, but I cared about what I was saying. See the problem?

I’m sick of seeing tweets and Facebook posts written in all lower-case letters. Questions that don’t end with question marks. Paragraphs where every thought is laid out between mangled ellipsis instead of real sentences.

I’m not talking about imperfect grammar. English is a messy language, I get that. Plurals and spelling are often non-obvious, especially for non-native speakers, and even native speakers break the rules sometimes. We’re forgiven.

But everyone — everyone — knows that sentences start with a capital letter, and end with some sort of symbol. No fancy rules, no special cases. It’s one of the first things we learn while becoming literate.

So if you’re one of those people who’s social network feed is devoid of periods, capital letters, and apostrophes, please do better. I know you have it in you. Your lack of basic grammar is distracting from your message, and it’s driving people like me and Mrs. Mainwood crazy.

You don’t have to be smart to get this right.

You know better than that.

Brand New Adobe

Monday, November 21st, 2011

Adobe is changing. The once-great giant of web and web tools has fallen, and is poised to rise again — albeit in a much different form. What does this mean for us web developers?

For starters, let’s go over some recent news. Adobe made three major announcements in the past six weeks that will have sweeping implications on their image. See if you can spot a trend in these headlines:

What do these press releases have in common? If you caught that all three are about open technology, give yourself a pat on the back. Let’s dig into the facts before discussing the ramifications.

Adobe has seen the light, and open source is sparkling.

Closed formats are dying across the web. The days are numbered for plugins like Silverlight and Flash; they’re simply not necessary anymore for the vast majority of sites and applications. HTML5, on the other hand, is thriving. We’re starting to see open fonts pick up, and even longtime-stalwarts MP3 and MPEG-4 are starting to lose their grasp of the online audio/video markets.

Adobe isn’t blind. They know they need to transition away from closed platforms. Picking up PhoneGap shows their commitment to this cause.

Re-aligning their mobile efforts towards HTML5 is another positive step towards open technology. Adobe still makes some of the web’s best tools, and Javascript development could seriously use an outstanding IDE. This seems like a great match-up.

Finally, releasing Flex to the community is a smart move. There is a very vibrant community around Flex, and there are still niches where RIA will matter for a little while longer. If Adobe can’t support Flex on its own, enabling the community to take control of it’s own future simply makes sense.

Adobe’s intentions are clear. Proprietary formats are out, the open web is in.

What does this mean for web developers?

Three things:

First and foremost: Learn your shit. If you’re a web developer, learn everything you can about Javascript, HTML5, CSS3, and the myriad of related frameworks. These will only become more important following the fall of Flash.

Second: If you’re a Flash/Flex dev, start looking at Sencha. At SenchaCon last month, the number-one answer I got back when I asked people what they worked in before switching to Sencha was Adobe Flex. And I believe it. I’m a Flex guy too, but that market’s shrinking quickly. Sencha is going to be a major player on the web for a while to come, and it’s a relatively smooth transition.

Third: Get into mobile. Adobe didn’t pick up PhoneGap just to gain FOSS-cred. Mobile is huge. Huge! This is where you want to be right now, and you can join in using Javascript and Sencha and many other web technologies.

This is an exciting time to be in web development. Let’s keep on top of the constantly-changing platforms and tools. Let’s keep building wonderful things. Let’s make this an age to be proud of when they talk about the day Adobe changed their ways.

Who’s with me?

What Does 6 Months of Developer-Effort Look Like?

Friday, November 11th, 2011

Well, a little something like this:

Word cloud of terms used in timesheet reports.

Beautiful, isn’t it?

This is a cloud of the most commonly used words in my timesheet entries for a project I worked on over a six-month period. (When you work at a services company, you have to log all your time using archaic worklog software that only works properly in IE7 and below.) Size represents frequency, so the bigger the word, the more I used it to describe what I do.

It’s quite telling.

I’m happy to point out that patch is my most-commonly used word, followed by reviewed. We’re religious about code review at Macadamian, and it’s awesome to me that this is spelled out so clearly in my notes.

Something I’m not as proud of is that tests is a tiny little speck (above the V in reviewed). It’s beaten out by crutch words like etc and sure. Worst of all, we had unit tests set up on this particular project (front-end and service-level). Why did it have such little impact in my notes? This is something that I think I should be spending more time on.

It’s rare to get such a clear glimpse of what my priorities are. I spent nearly 1000 hours of my life on this project, and in one simple image I can see where all that time went. It’s both humbling and encouraging to get this sort of perspective.

What do you think your cloud would look like?

The Key Skill that Makes for a Great Software Architect

Monday, November 7th, 2011

Software architects are a strange breed.

They obsess over code quality. They can’t explain anything without a whiteboard. They adore design patterns that most of us have never even heard of.

When the project is in trouble, they swoop in and save the day.

And they constantly reject my patches.

But I’m thankful for that — all of it. I’ve been fortunate enough to work with some really, really great architects in my (admittedly short) career, and through it all I’ve managed to distill the one skill possessed by every great architect I’ve ever met:

The ability to identify potential pitfalls.

Expecting something more dramatic? Well, tough luck. I know it’s not sexy, but if you want to be a great software architect someday, you need this skill.

Here’s why:

Pitfalls are easy to spot when building a room.

The wife and I are currently finishing our basement. I’m learning a lot during this process, like how to make sure a wall is straight, and the joys of using a ramset.

And of course while I’m swinging that same old hammer into about the fiftieth 3″ nail, my mind starts to correlate what I’m learning about building a room to what I know about building software.

The biggest realization so far?

In simple construction, spotting potential problems is very easy.

If you line up a 2×4, you’re going to notice if it’s not the right size. Measure again, cut again. Problem solved.

If you have to extend some piping, it’s easy to grok the current pipe system and figure out where to make a cut. Plumbing refactored, job well done.

If you’re about to fire a nail through a plank of wood to affix it to the floor, it’s easy to visualize that you’ll have trouble cutting out a doorway there later. Nobody wants to hack through molten metal, so put those nails around where the door is going to be. Crisis averted.

In fact, it’s so trivial to see problems in advance that we’ve yet to make any major mistakes. This is amazing to me! Can you imagine saying anything like that about a software project? (Even a small one?)

Of course you can’t. And you already know why:

Pitfalls are nearly impossible to spot when building software.

How many times have you had to refactor some code you wrote last month, because it wasn’t up-to-snuff? Or had to completely re-write a feature that you implemented earlier in the project?

Seeing potential pitfalls in software is hard.

You would never build a cutting-edge webapp, then turn around and brag about how you got everything right on the first try. Your fellow developers would think you’re crazy, and your QA wouldn’t be able to stop laughing.

Every software developer makes mistakes all the time. Functions that aren’t quite single-purpose, dependencies that aren’t strictly necessary, routines that are a little too verbose. And we always end up paying for it later. Who will save us from this madness?

Architects, that’s who.

Great software architects mitigate rework and lost time by identifying pitfalls in advance.

They can look at a framework and tell you if it’s too abstract or not abstract enough. They can examine an existing codebase, and have a pretty good idea of where to start refactoring. They can tell when a new patch is going to break a valuable design pattern, or introduce inconsistencies into the codebase, or need to be re-written before the end of the next sprint.

This skill, this ability to look at some seemingly-harmless change and intrinsically know what problems it will cause later — it’s amazing. I don’t understand how they do it, and I don’t know if I’ll ever acquire that talent.

But I know it’s something I admire. And if you ever want to become a great software architect, this is the one thing you need to get right.

Now if you’ll excuse me, I have to go fix up my latest patch…