Categories
Motivation

How to Learn Anything

It’s New Years, and a lot of you are currently making resolutions and setting goals for the coming year. If one of your goals is to learn something new, or something that you’ve always wanted to learn, this post is for you. If that’s not you, keep reading — this is a cool story.

The hardest thing I’ve ever tried to learn is Calculus. Specifically, it was calculus as taught in a horrific course I was forced to take in University called Calculus 2 for Engineers.

The marking was brutal. Here’s how it worked:

There were three midterms and a final exam. Each midterm was worth 15% of the final grade, the other 45% was the exam. No assignments, no labs, just midterms and an exam. And were those midterms ever vicious! Each one had only seven questions, and they were multiple choice. It was common to have pages of formulae and calculations for any given answer, and if you made even one tiny mistake — a flipped minus sign, a minor addition error, etc — then BAM! There goes 2% of your final grade.

It was awful, and probably the most feared course in all of Engineering at U of O.

One of the most vivid memories I have of University is sitting in class after getting our second midterm back. I failed it, just like I failed the first one.

The guy next to me, a friend of mine, was in the same situation. He turned to me, and he said:

“Dan, we can pass this course. All we have to do is one hour of calculus every day for the rest of the semester. It’ll work. I’m sure of it.”

I probably said I’d “totally do it”, and I might have even stuck with it for the first week or two. But I didn’t follow through, and much to my disappointment (but hardly a surprise), I failed the third midterm, and the exam.

This is the only course I’ve ever failed.

That friend of mine stuck with his plan. He did one hour of calculus every day for the rest of the semester, and passed Calculus 2 for Engineers with a B+. Not bad, considering he failed the first third of the course.

So if you want to learn anything, whether it’s calculus, how to juggle, or how to speak Italian, all you need is discipline. You don’t need to be smart, you don’t need fancy tools or textbooks or courses, you don’t even need a teacher or mentor. All you need is discipline.

Do it for an hour a day.

What are you going to learn?

Categories
Software Development

What Should the Software Industry be Known For?

I was talking with my friend Marc today. He’s a mechanical engineer (and a damn good one) and we were talking about work. He said something that kind of surprised me:

“Sometimes I wish mechanical engineering companies were more like software companies.”

All through school, and even in the workplace, I’ve heard software engineering compared to traditional engineering.

“You don’t build half a bridge, then change your mind about how it’s going to look.”

“It’s a green-field project.”

“Well, the way they estimate construction projects is like this…”

I’ve always thought other engineering disciplines had all these lessons we could learn in software, given that building software wasn’t recognized as engineering until about 1960*. It’s never once occurred to me that what we do in software could help the guys building cars, or skyscrapers, or in Marc’s case, bomb suits.

This begs the question:

What do we want other industries to say about software engineering?

If you could teach one lesson you’ve learned in software to another discipline, what would it be? What would be the top, absolutely most-important anecdote you could recite? Or inscribe on a statue of a programming icon?

Marc said it was how people are managed. The offices, the lax environment, the 20% time.

I think it’s how we integrate teams. I love working closely with designers, and I bet other engineering fields could really benefit from the software designer/developer relationship, and how it has evolved over the past decade.

Your turn.

What should the software industry be known for?

Categories
Uncategorized

Elsewhere: How to Handle Browser Differences on iPhone and iPad

I wrote a post for the company blog this week.

It’s about how we’ve reached a point with mobile Safari where different versions have different functionality. Is this a problem? What can we do about it?

Find out on the Macadamian blog!

Categories
Web Technology

Interviewed by Chris Brogan

In case you didn’t hear about it on Twitter or Google+ or from me jumping up and down and yelling out loud, I was interviewed the other day by Chris Brogan:

We talked about mobile websites, and went over the basics for businesses looking to get into the mobile web space.

I tried my best to not look and sound completely starstruck. I’ve been reading Chris’s blog since 2008, and for those of you that aren’t (a little too) obsessed with blogging, he’s kind of a big deal.

It was a lot of fun, and surprisingly easy to set up. I think I might do a bit more video-stuff in 2012. What do you think?

Have a good weekend!

Categories
Motivation

How Do You Fight Starvation?

Do you know how a computer decides what to do when you’re listening to music while browsing Facebook with a half-written blog post tucked way down your alt-tab order?

It uses a scheduling algorithm, of course. Some little process inside your operating system looks at all the applications you’re running, and decides when to spend some time processing each one.

There are all kinds of different algorithms, optimized for qualities like overhead (how much time the scheduler spends making decisions) and response time (how long an application waits before getting its “turn” on the CPU). Whatever device you’re using right now probably has a very fancy algorithm that has been perfected for over a decade.

Let’s compare this to how we as people manage our time.

It’s very similar, right? We generally have multiple tasks on the go, and we often need to prioritize them and decide where to spend our time.

I clocked some overhead thinking about this the other day, and I realized that if my brain is even using a scheduling algorithm at all, it’s due for a firmware update. I have a serious problem with starvation.

In the digital world, a process is starved when it is given a low priority and there are too many other, high-priority processes stealing all the CPU-cycles. So many important things are happening that this poor, less-critical process is constantly ignored.

Most scheduling algorithms account for this by gradually boosting the priority of tasks that have been waiting for a long time. Eventually our forgotten process gets its chance to shine.

My brain struggles with the boosting.

I’m going to cut myself some slack and rationalize that I’ve been especially busy lately. I was in Europe, then speaking at a conference in Texas, then refinishing a basement, and somewhere in there work got kind of crazy. During that time, I let a lot of things slip through.

“I’ll get to that soon. I just have to wrap up [some feu-du-jour].”

The trouble is, there have been a lot of fires, and the tasks that are still really important and I really want to do them but they’re just not quite urgent enough to ever grab enough of my attention at once have been stagnant for far too long.

They’re famished.

So here’s what I’m going to do: Once a week (for the next little while) I’m going to spend an hour or two feeding some poor, starving task(s) in my to-do list. I can work on anything I want as long as it’s:

  • Not due anytime soon (if at all).
  • Something productive that I legitimately want to do.

Now instead of trying to prioritize some hapless, someday-task, I’m prioritizing the FIGHT STARVATION task. This level of abstraction will (hopefully) stop me from writing off those non-urgent-but-way-awesome tasks as things I can do when I’m less busy — a sun that never seems to rise.

I’m very curious to know how you deal with this. Do you find yourself with starving tasks every now and then? Do you have some clever (or super-obvious) way of feeding them?

Categories
Uncategorized

You Know Better Than That

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.

Categories
Web Technology

Brand New Adobe

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?

Categories
Software Development

What Does 6 Months of Developer-Effort Look Like?

Well, a little something like this:

Word cloud of terms used in timesheet reports.
Image generated using Wordle. Click to enlarge.

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?

Categories
Software Development

The Key Skill that Makes for a Great Software Architect

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…

Categories
Web Technology

My SenchaCon Hackathon Entry

The last day of SenchaCon was a hackathon, where everyone that stuck around (probably over 100 people) grouped together and hacked away to see who could make the coolest one-day project. There were a LOT of great apps, and several came away with cash and prizes (all of it very well earned!).

Not featured in the winners list is the app I made, because I missed the submission deadline by about twenty minutes. All this because I lost far too much time debugging issues with HTML5’s native drag-and-drop API. (I was planning on writing a rant about it, but Quirksmode beat me to the punch.)

In any event, I’ve uploaded the incredibly raw creation, and you can now play my simple HTML5 Video Puzzle Game. I only tested in Chrome, but it seems to run alright in the latest Aurora build of Firefox. Basically the app loads up an HTML5 video, slices it into 16 canvases, and scrambles the pieces. Your job is to re-arrange them by dragging them back into place (using HTML5’s native drag-and-drop, of course).

It’s really, really unpolished. I spent all of about 8 seconds on the styling, and there are a lot of features that are complete but inaccessible (like slicing the video into more pieces). I might try to fix it up later.

Anyway, the whole day was a lot of fun, just like the rest of the conference. It would be awesome to go again next year. We’ll see!

Until then, happy hacking, all my fellow attendees!