Tag Archives: learning

Over communicating

I once had a college class where the instructor was in the process of writing a text book for the class. So we were being taught out of photocopies of the draft textbook. It wasn't a very good class.

It wasn't that he wasn't a good writer. He was. The previous semester I'd had a great class using one of his text books. But it was taught by a different professor. There were some places that the text made a lot of sense to me, and some places where the different approach of the non-author professor made far more sense. With two points of view it's about synthesizing an understanding. If something from the book didn't really stick, something from in class might. And each aha moment made everything you'd read or heard before make a bit more sense.

I was reminded of this this morning reading through some technical documentation that was light on content and heavy on references. It was written that way so as to not repeat itself (oh, this part is explained over her instead). And while that may make sense to the authors, it doesn't make for an easy on ramp for people trying to learn.

It's fine to over communicate. It's good to say the same thing a few different ways over the course of a document, and even be repetitive at times. Because human brains aren't disk drives, we don't fully load everything into working memory, and then we're there. We pick up small bits of understanding in every pass. We slowly build a mental approximation of what's there. And people have different experiences that resonate with them, and that make more sense to them.

There isn't one true way to explain topics. So, when in doubt, over communicate.


Maybe it shouldn't be Computer Science

I had an interesting conversation at lunch yesterday when I met a CS professor at a local college. He's got nearly 15 years industry experience, in addition to a decade being in academia, so exposure on both sides of the fence. During the course of the conversation I asked him what triggered the transition. His response was that he didn't really enjoy programming.

There's nothing wrong with that answer. I'm always jarred by it when I hear it from folks, because programming is what I love. But everyone's different, an there is a lot more to computer science than just programming.

Over the course of the day that statement kept coming back to me, and I realized I'd heard it a lot of times in the past. The vast majority of CS profs I had during my graduate degree were in the same camp. Friends that are in CS academia, tend to lean the same way.

Art and music programs in liberal arts schools are a combination of practitioners and theorists, attempting to build a well rounded art student on both fronts. So why is CS still mostly theory in these environments?

The theory parts of CS wouldn't have been my thing as an undergraduate either. Much like calculus being pretty boring in high school, but becoming down right compelling in my college physics classes when it was a tool to solve a problem, and not just theory that stood on it's own. Without a body of work that's tangible, the theory is much less relevant.

So maybe it's time to call it something other than Computer Science. Software Engineering has the no no of the word Engineering, which doesn't go over well at liberal arts schools. Apparently, Informatics is the monkier in much of Europe, and given the rise of data analysis, that's probably as good an idea as anything else.

You don't need to suck

Three months ago I decided that I was no longer going to suck at design.

This seemed like an impossibly daunting task at first. I started with a project: redesigning the MHVLUG website. Then I went to Amazon looking for a book on web design. Some searching, reading reviews, looking at related/recommended books, and I bought a bunch of books. And I spent the next couple of months reading through them. The best books out of the lot have been The Design of Everyday Things, Don't Make Me Think, and The Non-Designer's Design Book. I read more than that, which is an important point. If you want to learn something new you're going to need to read more than just 1 book.

Basic design, like most other things, has rules and patterns. Just knowing rules and patterns isn't going to make you a great designer, but it will keep you from sucking too much. Having a basic theoretical framework gives you something to work with besides the really scary blank page. These books definitely did that for me.

Books will only get you so far, because you can nod along when reading a book, assuming that you understood, but until you go to apply it, you have no idea if you internalized it. Fortunately I had a project, so after a couple of months of reading, I dove into the project, doing the bulk of the work over Thanksgiving Holiday, with a lot of tweaking since. The results, I think are pretty good.

You don't need to suck at anything. If there is something you wish you were better at, it's within your control to get better at it. It takes hard work, time, and practice, but that's just life.

Start somewhere

When faced with a problem you don’t understand, do any part of it you do understand, then look at it again.

-Robert A. Heinlein, The Moon is a Harsh Mistress

I see a lot of folks that have lofty ideas, and never get anywhere, because they don't want to start until they are sure they can do it right the first time. Here's the thing, you can't do anything right the first time. So just dive in somewhere. Consider the mistakes lessons learned, and the cost of building expertise. Be prepared to feel stupid a lot, because that's the price of learning something new.

You'll never finish a project if you don't start it. You'll never complete a project, if you don't keep working on it. These may seem obvious, but it's impressive how many people don't seem to realize this.

(Thanks to Ed for posting this first.)

Productivity Tip: Learn your tools

At the web design meetup the other day there was a bit of chat about editors afterwards which turned into a normal geek fest of poking fun at each other for our choices. One new truth that came out of this a good editor doesn't make someone more productive, but it does allow them to become more productive.

Vim vs Emacs

As an emacs guy, that can navigate around in vi reasonably, I've was always somewhat surprised that people actually use vi to program. But there are plenty of folks that hold that position, and are as equally surprised that I use emacs. Over the years I tried to look for some common thread. What makes someone choose one or the other, and hold to that choice so firmly. A few years ago I came around to the best predictor. With probably ~ 90% accuracy you can predict which editor a person will use based on what editor their mentor used when they first got serious about computers. People pick up the tools of their ancestors. What looks like free will is basically dictated by heredity.

So, that's how you figure out which one people use. So, which one is better? The answer to that is simple, whichever one you know the best.

Tools Require Skill

There is this naive assumption that using a "better" editor will make you more productive. The answer is, maybe, but don't stop there. If you aren't willing to put in the time to learn how your editor is configured, take time every month to learn a new trick with your editor, give up on either vim or emacs, and go back to gedit. Learning an editor well is going to mean learning how to do very complex activities with complex key strokes. There just aren't enough keys on the keyboard to be able to do what you want to do without combining them together.

Every couple of months I spend a bit of time to learn a few more emacs tricks. It's hard for me to even enumerate what these are, because they are just part of my normal workflow, like water. Buffer changing, remote editing, multi language buffers, integrated source management. I am also aware of other things I could be doing, which include interactive debugger control, which don't warrant the time and skill for me to set them up yet. But I know they are there, and I even know how I would get started in configuring them if I needed to.

Which also brings another point, if your tools themselves aren't extensible, you will be limited in your growth. I have never met a system that I like 100%, though I've met many which did 98% or 99% of what I wanted. This is one of the reasons I'm a really big fan of open source. Couple 98% complete with an easy way to extend it, plus open source so you can really understand what it is doing behind the scenes, and you've got a winning combination.

Become Better

tldr; - If you want to be a better programmer, spend a lot of time getting to know your editor.

If you are not already deeply invested in an editor, I'd heartily recommend emacs, fire it up, then hit "F1 t" or from the menus, Help -> Tutorial. It will walk you through an interactive tutorial of basic key commands, including detecting if your local installation has changed any of the keybindings and alerting you appropriately.

If you are already invested in an editor, commit to yourself that you'll take 1/2 a day a month, for the rest of 2011, and spend that time reading and learning about other capabilities of the editor you are using now. You'll be a better programmer for it by far by the end of the year.