I’m offline this weekend, so if you submit comments (which are moderated), they’ll show up sometime on Monday or Tuesday. Thanks!
Getting a weird COM Exception with the cryptic ID 0x8055001E?
We’ve been struggling with this problem for over a year now, and we finally have a solution.
We have some critical code that is contacting Exchange server via COM Interop and CDOEX.DLL to read some inboxes and process e-mails. About once a month or so, we get this error:
System.Runtime.InteropServices.COMException (0x8055001E): Unexpected
store error: %1!d! (0x%1!8.8x!)
at ADODB.RecordsetClass.Open(Object Source, Object
ActiveConnection, CursorTypeEnum CursorType, LockTypeEnum LockType,
at MessageService.Exchange.ExchangeClient.Connect(String folderUrl,
String userId, String password, Boolean useHttp)
After this point, restarting our software does not help. The only recourse is to restart the Exchange store completely. Did I mention that our software needs to run 24/7/365 with no downtime (a few minutes here and there are acceptable)?
So about once a month, I get a message on my phone, I log into the server, reboot Exchange, and all is well.
Searching on Google revealed nothing at all. Until recently.
I now believe the problem was we were checking two e-mail accounts back-to-back, in a loop like this (highly simplified):
Apparently, there is some bug in the CDO COM components’ code that will cause errors if you reconnect too fast. Occasionally, the Exchange code must have completed so quickly that it didn’t provide enough time for the COM components to clean up properly before the next solution attempt. Solution?
We implemented that change on a staging server that was also experiencing this problem and haven’t had a single reoccurrence since. The fix will be going into production very soon. No more 2AM alerts!
I’ve been wanting to change the look of this blog to be much more minimalist for a while now, and I think this week will be the week to do it. If you notice weird changes as you’re browsing, please bear with me. 🙂
I’m also going to be reducing the number of ads on the site while trying to make their placement more natural and less intrusive.
UPDATE: Ok, maybe not. I was experimenting with a new theme last night, but it looked a little too sparse. And on my laptop, it was prompting IE7 to install an ActiveX control from Microsoft. I didn’t have time to track it down, so I switched back to this theme, and I think I’ll just concentrate on customizing it further.
I’ve updated my list of podcasts with some that I forgot and some new ones I discovered while finding the links to the first ones. I also slightly reorganized the list (Added a business section)
Jeff Atwood laments the single-item nature of the Windows clipboard, and points out utilities that can expand the capabilities to multiple items. I think that’s a great power tool to have, but I’m not sure having a multiple-item clipboard is really the best thing.
I think one of the strengths of the clipboard is its single-mindedness. You always know that the thing you’ve copied is what you’ll paste (even if it is stored in multiple formats in the clipboard, it’s al conceptually the same). Once you expand the clipboard to contain multiple items, will the average user be able to handle a menu popping up asking which item to paste? No, probably not. That’s why the utility he mentions only pops up that menu when you hit it’s special shortcut. That’s the way it should be. It’s a great thing for advanced users, but I think of little benefit to the average.
For me, the simplicity of the clipboard is a good feature. Even if I had the extended capabilities of a clipboard that held multiple items, I probably would still use the basic functionality most often.
I got a 4 MB blue iPod Nano 2nd Genfor my birthday last June, and while I do have a few music playlists, I almost exclusively listen to podcasts. I can’t believe I went so long without one of these. Putting together the list below led me to some others that I might give a try, but for now here’s my list:
- In Our Time – A weekly BBC production discussing various events, people, or ideas in history (recent or ancient). Always interesting. About 45 minutes long.
- Philosophy Bites – A weekly interview with someone about a specific philosophical topic. About 15 minutes long.
- Talk of the Nation: Science Friday – Weekly show about all sorts of issues relating to science. It’s in a very easy-to-listen-to format. Broken into segments. About 1hr per week.
- Science Talk from Scientific American – I don’t think I like it as much as Science Friday, but it’s still very interesting. It’s usually focused on one or two topics per episode, sometimes recording of lectures by prominent scientists. Weekly, about 30 minutes.
- Grammar Girl – Nice and short, answers to tricky grammar questions. Often plays off current events. Weekly. 5 minutes.
- Get-It-Done Guy – I’m a fan of Getting Things Done, as I kind of discussed in my entry on Outlook. This is a nice, short podcast with simple ideas for efficiency in your life. Weekly. 5 minutes.
- Legal Lad – Answers to interesting legal questions. Weekly. 5 minutes.
- Fundamentals of Piano Practice – really just somebody reading out loud the online book of the same name. I play piano, and I’m learning a ton of fundamental principles from this book that help. The hands-separate method? I’ve played for 8 years and never had it explained to me so clearly. It’s obvious in retrospect, but that’s the kind of good thing you learn in this book. Unfortunately, new readings haven’t been added since October. Varying length and frequency.
- Learn Jazz Piano – I haven’t listened to any of these yet, but I’ve always wanted to play jazz. Infrequent (but still being updated!). 30m.
- WordNerds – Interesting discussion of words and language. I always learn something interesting. Every three weeks. 30-60 minutes.
- MarketPlace – I like to follow the business news, and their format is really good. Entertaining, informative. Daily. 30 minutes.
- MarketPlace Money – Their weekly show that goes into more depth on topics, discusses more “timeless” issues, answers questions. I really like this one. Weekly. 1hr.
- Entrepreneurial Thought Leaders – Forums at Stanford with lecture and questions by famous entrepreneurs. These are frequently interesting, especially if you want to start a business someday. Weekly. 1hr.
- Car Talk – how can you not have this on the list? They’re hilarious. And I do learn something about cars. Mostly, just fun, though. Weekly. 60 minutes.
- LAMLradio: LEGO Talk Podcast – Interviews with LEGO builders, and others in the online LEGO community. I like it, but you probably have to be familiar with the community to follow it. Weekly 15 minutes.
- MunchCast – A weekly show about junk food! I’ve only listened to the first episode, but I’m hooked. It’s more interesting than it sounds. Weekly. 30m.
- .Net Rocks – Very well put-together show about .Net development, upcoming technology, interviews with industry pros. Twice weekly. 1hr+
- This Week in Tech – Casual discussion of the week’s computing news with Leo Laporte. Highly entertaining. Has the cranky John C. Dvorak on often, but the panel rotates. Weekly. 60-90m.
- Windows Weekly – Covers Windows-specific news (mostly) with Paul Thurrott and Leo Laporte. Also interesting stuff. Weekly. 1hr
- Security Now – With Steve Gibson and Leo Laporte. They talk about all sorts of security-related topics. Very interesting, very well done. They have a knack for explaining difficult concepts in a way that’s easy to grasp. One of my favorites. I am not a security guru, but this is fascinating stuff. Weekly. 1hr.
- HanselMinutes – with Scott Hanselman who now works at Microsoft. Discusses various technical topics, usually related to programming. To be honest I don’t like this one as much very often, but I still listen to it occasionally. Don’t know why…a little dry?
- NPR Technology News – stories culled from various NPR programs into a 20-30 minute collage. Weekly.
- The Tech Guy – another Leo Laporte show, in a longer format, with interviews, callers, and more.
- The Restaurant Guys – Discusses “food, wine, and the finer things in life.” If you like food, you’ll probably enjoy this podcast. I was probably interested in about half of their shows but something about them bugged me so I’ve dropped them for now in favor of other things. I may add them back soon. Daily. 1hr.
What attributes can contribute to a highly successful software developer versus the ordinary run-of-the-mill kind? I don’t believe the attributes listed here are the end-all, be-all list, nor do I believe you have to be born with them. Nearly all things in life can be learned, and these attributes are no exception.
Like this article? Check out my new book, Writing High-Performance .NET Code.
Humility is first because it implies all the other attributes, or at least enables them. There are a lot of misunderstandings of what humility is and sometimes it’s easier to explain it by describing what humility isn’t:
- humility isn’t letting people walk all over you
- humility isn’t suppressing your opinions
- humility isn’t thinking you’re a crappy programmer
C.S. Lewis said it best, in the literary guise of a devil trying to subvert humanity:
Let him think of [humility] not as self-forgetfulness but as a certain kind of opinion (namely, a low opinion) of his own talents and character. . . Fix in his mind the idea that humility consists in trying to believe those talents to be less valuable than he believes them to be. . . By this method thousands of humans have been brought to think that humility means pretty women trying to believe they are ugly and clever men trying to believe they are fools.*
Ok, so we realize humility isn’t pretending to be worse than you are and it’s not timidity. So what is it?
Simply put, humility is an understanding that the world doesn’t begin and end with you. It’s accepting that you don’t know everything there is to know about WPF, or Perl, or Linux. It’s an acknowledgment of the fact that, even if you’re an expert in some particular area, there is still much to learn. In fact, there is far more to learn than you could possibly do in a lifetime, and that’s ok.
Once you start assuming you’re the expert and final word on something, you’ve stopped growing, stopped learning, and stopped progressing. Pride can make you obsolete faster than you can say “Java”.
The fact is that even if you’re humble, you’re probably pretty smart. If you work in a small organization with few programmers (or any organization with few good programmers), chances are you’re more intelligent than the majority of them when it comes to computers. (If you are smarter than all of them about everything, then either you failed the humility test or you need to get out of that company fast). Since you happen to know more about computers and how software works than most people, and since everybody’s life increasingly revolves around using computers, this will give you the illusion that you are smarter than others about everything. This is usually a mistake.
Take Sales and Marketing for example. I have about 50 Dilbert strips hung in my office. I would guess half of them make fun of Sales or Marketing in some way. It’s easy, it’s fun, and it’s often richly deserved!
But if they didn’t sell your software, you wouldn’t get paid. You need them as much as they need you. If someone asked you to go sell your software, how would you do it? Do you even like talking to people? As clueless as they are about the realities of software development, they have skills you don’t.
There are some industries where extreme ego will get you places. I do not believe this to be the usual case in software, at least in companies run by people who understand software. Ego is not enough–results matter. If you have a big ego, you’d better be able to back it up. Unfortunately, the problem with egos is that they grow–eventually you won’t be able to keep up with it, and people will see through you.
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. – Dijkstra
Without humility, you will make mistakes. Actually, even with humility you’ll make mistakes, but you’ll realize it sooner. By assuming that you know how to solve a problem immediately, you may take steps to short-circuit the development process. You may think you understand the software so well that you can easily fix a bug with just a few tweaks…and yet, you didn’t realize that this other function over here is now broken. A humble programmer will first say “I don’t know the right way to solve this yet” and take the time to do the analysis.
Finally, humble people are a lot more pleasant to work with. They don’t make their superiority an issue. They don’t always have the “right answer” (meaning everybody else is wrong, of course). You can do pair programming with a humble person, you can do code reviews with a humble person, you can instruct a humble person.
It’s not at all important to get it right the first time. It’s vitally important to get it right the last time. – Andrew Hunt and David Thomas
Perhaps most importantly, a humble programmer can instruct him/herself…
Love of Learning
If you’re new to this whole programming thing, I hate to break it to you: school has just begun. Whatever you thought of your BS/MS in Computer Science you worked so hard at–it was just the beginning. It will get you your first job or two, but that’s it. If you can’t learn as you go, from now until you retire, you’re dead weight. Sure, you’ll be able to find a job working somewhere with your pet language for the rest of your life–COBOL and Fortran are still out there after all, but if you really want to progress you’re going to have to learn.
Learning is not compulsory. Neither is survival. – W. Edwards Deming
This means reading. A lot. If you don’t like reading, I suggest you start–get into Harry Potter, fantasy, science fiction, historical fiction, whatever. Something. Just read. Then get some technical books. Start with my list of essential developer books. They’re not as exciting as Harry Potter, but they’re not bad either.
A lot material is online, but for high quality, authoritative prose on fundamental subjects, a good book beats all.
Reading isn’t enough, though. You have to practice. You have to write your own test projects. You have to force yourself to push your boundaries. You can start by typing in code sample, but then you need to change them in ways unique to you. You should have personal projects and hobbies that expand your skills. Be writing your own tools, or “fun” programs. Write a game. Do what it takes to learn new things!
The type of programs you write have a big bearing on how well you learn new material. It has to be something that interests you, or you won’t keep it up. In my case, I’m developing software related to my LEGO hobby. In the past, I’ve written tools for word puzzles, system utilities, multimedia plug-ins, and more. They all started out of a need I had, or a desire to learn something new and useful to me personally.
Another aspect of this love of learning is related to debugging software. An effective developer is not satisfied with a problem until they understand how it works, why it happens, and the details of how to fix it. The details matter–understanding why a bug occurs is just as important as knowing what to do to fix it.
Learn from mistakes. I have seen programmers who make a mistake, have the correct solution pointed out to them, say, “huh, wonder why it didn’t work for me”, and go on their merry way, none-the-wiser. Once their code is working “the way it should” they’re done. They don’t care why or how–it works and that’s enough. It’s not enough! Understand the mistake,what fixed it, and why.
Good judgement comes from experience, and experience comes from bad judgement. – Fred Brooks
Obviously, some balance has to be struck here. You cannot learn everything–it simply isn’t possible. Our profession is becoming increasingly specialized because there is simply too much out there. I also think that in some respects, you need to love learning just for the sake of learning.
Developing software with today’s technologies is all about the details. Maybe in 100 years, software will progress to the point where it can write itself, be fully component-pluggable, self-documenting, self-testing, and then…there won’t be any programmers. But until that comes along (if ever), get used to paying attention to a lot of details.
To illustrate: pick a feature of any software product, and try to think of all the work that would have to be done to change it in some way. For anything non-trivial, you could probably come up with a list of a hundred discrete tasks: modifying the UI (which includes graphics, text, localization, events, customization, etc.), unit tests, algorithms, interaction with related components, and on and on, each discrete step being broken into sub-steps.
I have always found that plans are useless, but planning is indispensable. – Dwight Eisenhower
Here’s a problem, though: few humans can keep every single task in their head, especially over time. Thankfully, detail-orientedness does not necessarily mean being able to mentally track each and every detail. It means that you develop a mental pattern to deal with them. For example, the steps of changing a piece of software could be:
- Thoroughly understand what the code is doing and why
- Look for any and all dependencies and interactions with this code
- Have a well-thought-out mental picture of how it fits together.
- Examine the consequences of changing the feature.
- Update all related code that needs to (and repeat this cycle for those components)
- Update auxiliary pieces that might depend on this code (build system, installer, tests, documentation, etc.)
- Test and repeat.
An example: I find that as I’m working on a chunk of code, I realize there are several things I need to do after I’m finished with my immediate task. If I don’t do them, the software will break. If I try to remember all of them, one will surely slip by the wayside. I have a few choices here:
- Defer until later, while trying to remember them all
- Do them immediately
- Defer until later, after writing them down
Each of these might be useful in different circumstances. Well…maybe not #1. I think that’s doomed to failure from the start and creates bad habits. If the secondary tasks are short, easy, and well-understood, just do them immediately and get back to your primary task.
However, if you know they’ll require a lot of work, write them down. I prefer a sturdy engineering notebookin nearly all cases, but text files, Outlook tasks, notes, OneNote, bug tracking systems, and other methods can all work together to enable this.
The more experience you have, the easier you’ll be able to track the details you need to worry about. You’ll also analyze them quicker, but you will always need some way of keeping track of what you need to do next. There are simply too many details. Effective organization is a key ability of any good software engineer.
Another aspect of paying attention to details is critical thinking. Critical thinking implies a healthy skepticism about everything you do. It is particularly important as you examine the details of your implementation, designs, or plans. It’s the ability to pull out of those details what is important, what is correct, or on the other hand, what is garbage and should be thrown out. It also guides when you should use well-known methods of development, and when you need to come up with a novel solution to a hard problem.
“Enjoying success requires the ability to adapt. Only by being open to change will you have a true opportunity to get the most from your talent.” – Nolan Ryan
Change happens. Get used to it. This is a hard one for me, to tell the truth. I really, really like having a plan and following it, adapting it to my needs, not those of others.
The fact is, in software development, the project you end up writing will not be the one you started. This can be frustrating if you don’t know how to handle it.
To become adaptive first requires a change in mind set. This mind set says that change is inevitable, it’s ok, and you’re ready for it. How do you become ready for it? This is a whole other topic in itself, and I will probably devote a separate essay for it.
Other than the shift in mind set, start using techniques and technologies that enable easy change. Things like unit testing, code coverage, and refactoring all enable easier modification of code.
In war as in life, it is often necessary when some cherished scheme has failed, to take up the best alternative open, and if so, it is folly not to work for it with all your might. – Winston Churchill
For me, the first step in changing my mind set is to not get frustrated every time things change (“But you specifically said we were NOT going to implement the feature to work this way!”).
I think passion is up there with humility in importance. It’s so fundamental, that without it, the others don’t matter.
Anyone can dabble, but once you’ve made that commitment, your blood has that particular thing in it, and it’s very hard for people to stop you. – Bill Cosby
It’s also the hardest to develop. I’m not sure if it’s innate or not. In my own case, I think my passion developed at a very early age. It’s been there as long as I remember, even if I had periods of not doing much with it.
I’ve interviewed dozens of prospective developers at my current job, and this is the one thing I see consistently lacking. So many of them are in it just for another job. If that’s all you want, just a job to pay the bills, so be it. (Of course, I have to ask, if that’s the case, why are you reading this article?)
One person with passion is better than forty people merely interested. – E. M. Forster
There’s a world of difference between someone who just programs and someone who loves to program. Someone who just programs will probably not be familiar with the latest tools, practices, techniques, or technologies making their way down the pipeline. They won’t think about programming outside of business hours. On the weekends, they do their best to forget about computers. They have no personal projects, no favorite technologies, no blogs they like to read, and no drive to excel. They have a hard time learning new things and can be a large burden on an effective development team.
Ok, that’s maybe a bit of exaggeration, but by listing the counterpoints, it’s easier to see symptoms of someone who does have passion:
- Thinks and breaths technology
- Reads blogs about programming
- Reads books about programming
- Writes a blog about programming
- Has personal projects
- These personal projects are more important than the boring stuff at work
- Keeps up with latest technologies for their interests
- Pushes for implementation of the latest technologies (not blindly, of course)
- Goes deep in technical problems.
- Not content with merely coding to spec.
- Needs an outlet of creativity, whether it be professional (software design) or personal (music, model building, LEGO building, art, etc.)
- Thinks of the world in terms of Star Trek
Just kidding on the last one…
That’s my list. It’s taken a few months to write this, and I hope it’s genuinely useful to someone, especially new, young software engineers just getting started. This is a hard industry, but it should also be fun. Learning these attributes, changing your mind set, and consciously deciding to become the engineer and programmer you want to be are the first steps. And also part of every step thereafter.
Nobody is born with any of these–they are developed, practiced, and honed to perfection over a lifetime. There is no better time to start than now.
* The Screwtape Letters, C.S. Lewis
Ok, I have to give a quick shout out to my hosting company, HostForWeb. I’ve had my web-sites and e-mail hosted by them for about…5 years now? I can’t remember when I started, but a while ago.
Today, I noticed that my e-mail was not going out through my domain via smtp. I quickly determined that the server was up (I could ssh in, and locally telnet to port 25), but I couldn’t reach it from my home. Laptop didn’t work either.
First, I called Comcast. They were less than helpful, claiming not to notice anything wrong with my account. I didn’t push the issue, because I figured I should check my hosting company as well. Also, we’re moving in two weeks and Comcast isn’t coming with us.
Well, I went to HostForWeb’s live chat support, and within 30 seconds Greg answered, and asked what I needed. I explained the situation, telling him I thought it possible that my IP was being blocked. He did some checking and tweaking and asked me to try again. Still didn’t work. I didn’t really think the problem was on their end, but I had to check anyway. In the end, he gave me a new port to access the smtp server, and I was on my way. In less than 5 minutes.
Comcast, try to beat that.
I should also mention, that I have had a few other occasions to contact HostForWeb tech support (I screwed up my DNS; my home IP really was banned at one point for something; etc.). Each time, even via e-mail, the problem was resolved incredibly quickly. I think the longest I ever waited was 30 minutes until resolution.
So if you’re in the market, these people are great. The support is phenomenal.
I’ve fixed one of the biggest holes in functionality in Windows Live Writer. It’s simple, but essential: the ability to count words (and characters and paragraphs) in your posts before publishing.
Windows Live Writer doesn’t really offer a way to extend the menu system itself, but you can create an “Insert…” plugin that just analyzes content instead of creates it, so it works pretty well.
Go get it from Windows Live Gallery. Let me know what you think!