Tag Archives: apple

I’m a PC

Judging, by the blogosphere’s reaction, I’m one of the few people who liked the Gates-Seinfeld ads by Microsoft. They were odd, sure, but it got people thinking, talking, going WTF? – and that can’t be bad.

But I definitely like the I’m a PC ads better. I was at the company meeting when they debuted, and they immediately sparked a rumble in the audience—a positive one.

The cool thing is you can upload your own picture or video with your “I’m a PC” acting debut.

There are some interesting ones: a guy singing in the shower, for instance. Steve Ballmer’s is worth a look.

The greatest thing about these ads, though, is that they essentially take all the wind out of the obnoxious Apple ads that have been on for years.

Top 10 Things To Do My First Week at Microsoft

  1. Wear my Google t-shirt.
  2. Set my homepage to www.google.com
  3. Continually ask, “Have you met BillG? Where’s BillG? When can I see BillG?”
  4. Show off my bright blue iPod Nano
  5. “Upgrade” my workstation to Windows XP
  6. Then just format it and install Ubuntu
  7. Randomly shout “Yahoo!” as I walk through the halls
  8. Add my gmail address to my e-mail sig
  9. Start an open-source project for Google Android
  10. Default browser: Firefox Safari

(I kid, I kid…)

10 Ways to Learn New Things in Development

Expanding upon one of the topics in my post about 5 Attributes of Highly Effective Developers, I’ve been thinking of various ways to kick-start learning opportunities in my career and hobbies.

1. Read books. There are tons of books about programming–probably most of them are useless, but there are many, many gems that can greatly influence your abilities.

I still find that it’s easier and faster to find information about many topics in familiar books than to find similarly valuable information online. Read all your books to get to this point.

Books are also valuable from theory, architecture, design point of view. There just aren’t that many places on the web to get high-quality, authoritative instruction in this.

Like this? Please check out my latest book, Writing High-Performance .NET Code.

2. Read Code. This is something I was late to. I didn’t start reading a lot of significant code until after I had a few years of professional programming experience. I would be a better programmer if I had started earlier. I try to read some source code every week (not related to work, not my own, etc.) from an open source project. Start with programs that you use and are interested in. I started with Paint.Net and it solidified a lot of .Net program design technique for me.

Reading other people’s code shows you different ways of doing things than you might have thought of on your own.

3. Write Code – Lots of it. Fundamentally, the best way to learn something is to do it. You can’t fully internalize something until you’ve written it. This starts with something as simple as copying the code examples from tutorials and books. That’s copying by hand, not cut&paste. There’s a difference. The idea is internalize and think, not blindly copy. Look up new API calls as you go. Tweak things.

Most importantly, develop your own projects–whether they’re simple games, participation in an open source project, or a simple plug-in to a program you use.

Try to use new technologies, new techniques, new designs–do things differently. Do things better in this project than in previous ones.

This is really the core point–if you want to be a better developer than develop.

4. Talk to other developers – about specific problems you have, as well as the latest tech news from [Apple|Microsoft|Google|Other]. This not only helps you feel part of a team or a community, but exposes you to a wide variety of different ideas.

Different types of projects require different designs, coding techniques, processes and thinking.

If you work in a small team (like I do) and you don’t have access to many other people, go find some at a local user group meeting. If nothing else, participate in online forums (you’ll have to look harder for an intelligent discussion).

5. Teach others. Similar to just reading code versus writing it, teaching other people can do wonders for forcing you to learn a topic in depth.

The very idea that you’re going to have to teach a topic to someone else should force you to learn something with a far better understanding than you might otherwise. You can face questions.

If you can’t explain a concept to a 6 year-old, you don’t fully understand it. – Albert Einstein

Teaching situations are myriad: one-on-one with your office-mate, water-cooler meetings, informal weekly gatherings, learning lunches, classrooms, seminars, and more.

How about setting up a once-a-week 30 minute informal discussion among like-minded developers? Each week, someone picks a topic they want to know more about and teaches it to the others, instigating a conversation. If you knew were going to teach the group about synchronization objects, don’t you think you’d want to understand the ins and outs of critical section implementation?

6. Listen to podcasts

If you’ve got time where your brain isn’t otherwise occupied, subscribe to podcasts. My current favorite programming-related one is .Net Rocks. They also do a video screen cast called dnrTV.

These will help you keep up on the latest and greatest technologies. You can’t learn everything and podcasts are a good way to get shallow, broad knowledge about a variety of topics, from which you can do your own deep investigations.

If there are other, high-quality developer podcasts, I’d love to hear about them.

7. Read blogs

There are more blogs than people to read them, but some are extremely well-done. I’m not even going to post links to any–there are plenty of other resources out there for that. This is one of the best ways to connect to people who actually develop the software you love and use.

8. Learn a new language

If all you’ve ever done is C(++,#)/Java there are a LOT of other ways to think about computer problems. Learning a new language will change the way you think. It’s not just a different syntax–it’s fundamentally rewiring the brain. Sure, all languages get compiled down to assembler in the end, but that doesn’t mean a high level abstraction isn’t valuable.

Functional, query, and aspect-oriented languages are starting to merge with C-based languages–are you ready?

9. Learn the anti-patterns

Aside from knowing what to do, learn what not to do. Read Dailywtf.com often and take the lessons to heart if you don’t already know.

It’s all well and good to understand proper OO design, coding style, and what you should be writing, but it’s easy to get into bad habits if you’re not careful. Learning to recognize bad ideas is vital when taking charge of a project.

Wikipedia has a thorough breakdown of many common anti-patterns,

10. Be Humble

Learning means:

  • Replacing faulty knowledge with better knowledge
  • Adding knowledge that you do not already have

There’s no way to learn until you admit you have some deficiencies. It all comes back to humility, doesn’t it? If you ever start thinking you know everything you need to, you’re in trouble. True learning is about hungrily seeking after knowledge and internalizing it. It takes lots effort. We all know this in theory, but we have to be constantly reminded.

Linux Reality Check

Over at Slashdot, Fedora Project Leader Max Spevack responds to some frank question about the Fedora project.

He talks about a number of topics:

  1. Unified package managers across distros
  2. Propritetary drivers
  3. Differences in Linux over time
  4. Fedora’s biggest weakness
  5. Threat of Vista
  6. inclusion of NTFS driver in kernel
  7. Wacky package dependencies
  8. a few others…

What his article demontrates to me is that Linux is going through some growing pains and that the community is realizing the difficulties that Apple and Microsoft have already dealt with in their own ways.

For example,

I guess the “problem” with package managers is that they are so integral to the rest of a distro that it’s a major endeavor to switch them. One reason is that a switch of that kind would break the upgrade chain.

Welcome to the real world of computing. Upgrading, advancing, improving are all important issues for real users using their computers. The only reason we still use the x86 architecture is backward compatibility. The only reason Windows has universal marketshare is that it works with basically everything ever written.

Another fundamental issue:

In terms of getting people to use Linux instead of proprietary operating systems — I think that battle is best fought in the world of people who are new to computers. People will tend to be loyal to the first thing that *just works* and doesn’t cause them pain. Making that first experience for people a Linux one as opposed to a proprietary one — that’s the challenge.

How true. It’s been a while since I’ve installed Linux, but my memories of it were not all that pleasant. It worked well enough, I suppose, but it certainly isn’t as polished or streamlined as it should be. MS and Apple are still years ahead of Linux in this regard.

Still No Silver Bullet…

Much is being made lately about vulnerabilities in Mac OS X, and various people are either haughtily dengrating the Mac while others are pooh-poohing the results with bad logic.

All of the ridiculous claims of “My OS is [better | more secure | safer] than your OS” is getting old. All these problems really do is serve to show us that, once again, that there really is no silver bullet in software design.

Credibility

One thing I cannot stand that is so prevalent in the computer industry is criticism by people of ideas, products, and technologies that they don’t understand. You see this a lot in the OS wars–especially of Windows, but Linux and Apple are not immune.

In very few cases do people have a well-reasoned and thought out explanation for their feelings. People who bash other ideas for their “religious” reasons are not intelligent–they are freaks who should not be trusted to make good decisions about technology.

Sure, there are horribly bad products out there, but those are mostly ignored and quickly die off. Religious wars start over successful products. A little study and research into the reasons for various design decisions would go a lot towards increasing the intelligence of most of these people.