Enter SyncMyCal. It’s easy, it’s cheap (only $25), and you can try for free. I rarely have duplicated events, and I don’t have to think about it ever–it just WORKS.

How it works: SyncMyCal synchronizes an Outlook calendar with a Google calendar. First I created a Google calendar, then I set up SyncMyCal on both work and home computers. I set the home computer to take priority in conflicts, but at work I set the Google calendar to take priority over Outlook–this way there’s a hierarchy of priority that helps to prevent unresolvable conflicts and duplicates.

I bought it days before Google released their Outlook sync tool, but SyncMyCal can do a lot more and I don’t regret the purchase one bit.

The latest version also syncs contacts, but I haven’t used that yet.

Definition

Any discussion of time-wasting is profitless unless you define what wasting time is. My definition is:

Wasting time is doing anything that does not contribute to my goals.

That is a very broad definition, but it is very useful. It presupposes a goal-oriented mind set and I don’t want to get too far down that path here. If you’re really interested in a goal-focused system, I highly encourage you to read The 7 Habits of Highly Effective People, which is a principles-based approach to effectiveness and goal-setting is a huge part of it.

Whatever your personal system, much of the corporate world and building software specifically revolves around goals (aka “milestones”, “targets”).

This definition includes taking breaks and eating lunch, but let’s not be silly–we’re not talking about that and I’m not going to water down the definition nor am I going to spend pages talking pointlessly about exceptions to it. We’re all intelligent people here and can understand the important principles.

Many Small Goals Are Better Than One Large One

Software development processes have been undergoing evolution since the beginning and lately the whole agile process seems to be taking over. Whatever the process, many companies are finding more success in breaking down large projects into tiny goal-driven chunks, sometimes lasting as little as a week.

This same principles can be applied to ourselves at both large and fine-grained levels. It is definitely good and desirable to have the overall vision of our project in mind, but  this doesn’t often help us get the work done. Some of my most productive days are when I break down a huge task into tiny subtasks and set a goal for each one (”I will have this done by 11am today, then I will wrap up this other small one by 4pm.”)

An example: I’m currently writing some code to move a huge amount of data around in our production database. We’re going to be rolling out a major update that requires some fundamental changes to how things operate. This task is so large and daunting that I get a headache just thinking about it and so I could put it off, just spinning my wheels until I decide to face the inevitable. Instead, I’ve broken it into several smaller tasks that are each easily managed and understood.

(In my example, the After column actually contains about 30 items, depending on how far I want to break it down…it could be more.)

Now, instead of being overwhelmed by the complexity of a large task (and thus doing nothing), I can easily handle each of the sub-steps efficiently. I’ve changed a two-week task into many hour-long tasks.

The psychological effect of  too-hard/too-complex/too-much is devastating. You can’t handle something like that–no one can, and so you won’t–you’ll just end up wasting time fretting about it. Break it up for your sanity and happiness, as well as productivity.

Motivation is Crucial

Often, a key to not wasting time is having sufficient motivation. Motivation can come in all sorts of ways–the key is to figure out what motivates you and then set yourself up to succeed by using that motivation as a carrot to pull you forward. It can be a good idea to share your motivations with managers so they understand what drives you.

Motivation can often begin with picking good goals. If your goals are unrealistic, you are almost guaranteed to fail in some way. Despair feeds on itself and will sink your productivity and cause you to engage in anything but work. Not only will you avoid the drudgery of work, but you won’t take steps to improve yourself or change the situation. This cycle must be broken immediately.

If your projects are just not that interesting this can be a challenge. Everybody has tasks they don’t particularly like, but if the majority of your time is spent doing stuff you get no pleasure out of, you are doing a huge disservice to yourself and your future. Eventually, you’ll become wasted and useless to both yourself and your employer. Fix the situation–get a new project, get a new job, find side projects to do that you do enjoy as rewards for getting through the drudgery–anything to avoid becoming the shell of a person you once were.

Maybe you don’t necessarily need a new job right now–maybe you just need to fix the situation at your current job, get some enjoyable hobbies at home, spend more time with the family. The needed changes aren’t always drastic–but figure them out so you don’t spend every day wallowing in a mire not doing anything useful.

Eliminate Distractions Now

I don’t think I’ve answered my office phone in about a year. Not that many people call it in the first place, e-mail being highly-preferred around here, but I like to say I stand on principle. You can read a lot about creating the right environment for highly-skilled software developers in the fabulous book Peopleware: Productive Projects and Teams.

I’ve also stuck to the practice of keeping my e-mail inbox cleared. I delete almost everything I receive unless I need to store it for later or act on it.

In my entry about working an 8-hour day, I talked about various time-wasting activities that I’ve observed, such as  wandering the halls, micro-managing, too many words, poor inbox management skills, and more.

The goal of eliminating distractions is not to completely choke off any aspect of fun, diversion, and other social aspects of working in an office–those are good things. The goal is eliminate the things that don’t help us in our jobs and that aren’t really all that enjoyable to us anyway, all things considered.

One way of eliminating your distractions is to go out of your way ahead of time to manage them so they don’t come up later. Some ideas:

• If you need somebody to do a task, anticipate questions, concerns, or problems they may have. Try to address these in an e-mail or in person (or both) quickly so that the person can expect it and won’t come to you later with problems.
• Shut  the office door, turn off the phone, close e-mail. Don’t let people find a way to distract you.
• Shut down your feed-reader, disable pop-up notifications from it. Set aside time during the day to review feeds and news.
• Have a clean desk. Keep only things you’re actively working on visible.
• Set a schedule or a signal to your peers and supervisors of times when you are busy and should not be bothered. Be assertive and enforce it.
• Focus on one project at a time. Everybody has a million things to do.

Plan Weekly, Daily, Hourly

Finally, bringing it around full circle back to goals: plan as much as you can to the extent it makes sense. That’s a weasel sentence, I know, but there’s no way around it. In general, though, I think we could all do with more planning.

Effective planning combines all the above principles into a coherent framework for your work week.

Every week, you have certain meetings, tasks to be completed, issues to be researched, people to be spoken to.

Every day, a certain subset of those must be done.

Every hour, you must pick a task to work on.

My plan is to take 10-20 minutes every day to plan the day’s activities, set min-goals, while at the same time strategizing to eliminate distractions. Every Monday morning I take an additional 10-20 minutes to review and set the major goals for the week, ensure meetings are scheduled, projects are given the correct priority, I know my tasks and responsibilities, and that I have enough dead-time left unscheduled because things always come up (we operate quickly-growing 24/7/365 services–there’s no avoiding issues).

Every time you finish a task, there should be another one waiting, whether you decide to tackle it right away or take a break and do something else. As long as you have a plan, it’s ok.

There are tons of other resources out there–I’ll just link to some in the forums of Steve Pavlina.

Now I should stop wasting time and get back to work…

Geek Softworks

It uses WordPress, but it’s not a blog–it’s for the software I write. So far, only a few products are up, including DiskSlicer (a new version!), Windows Media Top 10 Plugin, and Word Count for Windows Live Writer.

I also setup forums for those projects. The site is still pretty small, but it’s functional and it will grow.

Thanks for looking!

This is the closest I’ve come to signing up:

It’s gotten a few hundred downloads (thanks!), but the single review is actually spam. Unfortunately, I can’t remove it or even report the review from my account since it’s my own software.

Plea for help: Can a helpful reader out there please report this review as spam and request it to be removed? Also, could someone out there who does use Live Writer write a real review of the plug-in?

If you have further ideas to improve it, please let me know.

“Am I disturbing you?”

The last movie I saw in the theater was the 3-D version of Beowulf. The theater was fairly empty–maybe 30-40 people total. Two teenage girls sat two seats to my left. A man was in front of me. The two girls talked loudly through before the movie and when it started, they didn’t stop. They continued to talk and laugh loudly until the man in front gave up first:

Man: Excuse me ladies, the time for talking is over.

Girl: I ain’t talking to you! You turn right around and shut up. I ain’t disturbin’ no one.

Main: if you don’t stop talking, I will go get a manager and have you thrown out.

Girl: You shut up. Turn around, turn around… turn around mister.

Girl: <to me> excuse me, sir, am I disturbing you?

I looked at her and said, “Yes, you are.”

She shut up after that.

That wasn’t all in this showing. A man/woman couple behind me had the following exchange:

Woman: shut off your phone!

Man: I ain’t shutting off my phone! I don’t shut off my phone for anyone–I don’t even shut it off in church!

Woman: shut it off!

Man: No way!

(this repeated a few times in a similar vein.)

This man got up and left half way through the movie when his phone went off. He came in 20 minutes later with a friend, and they stood in the doorway and talked VERY loudly to each other and on the phone. The man in front of me got up and asked them to leave, and they did..after a minute or two.

What goes through the heads of these imbeciles?

“Thanks for coming to our bachelorette party!”

My mother, grandmother, and family friend were in London. They got tickets to see Dirty Dancing (which they thought was good, but not as good as the movie of course). Apparently that show is popular as a destination for girls’ bachelorette parties. The entire performance was punctuated by screams and yells every time the lead male came out.

I’m not against a good time, but this is the theater not a private party. Most of the audience is there to see a show. The theater should advertise certain days as more appropriate for this thing–theater aficionados beware.

“It isn’t real Texas theater unless you get drunk off your rocker.”

When my wife was visiting family in San Antonio they got tickets to see the touring Phantom of the Opera. They had nosebleed seats, which made the experience even more unfortunate.

Apparently, the theater serves beer throughout the performance–not just intermission. The guys in front of them got up half a dozen times to refill their beer glass throughout the show, blocking their view for a significant period of time. Add to this, the glare from the beer glasses, the opening of cell phones during the performance, bathing everyone in bluish glow, talking, and basically acting as if they were at a rodeo.

What is wrong with people that this is accepted behavior? Why aren’t these people kicked out more often? we (I’m including myself)willing to tell them their behavior is unacceptable and get management to act  ? And I mean without a refund–maybe even a fine or a ban.

Edit: My wife was so upset at the experience that she wrote the theater a letter of complaint.

Yeah, I’m a snob. So what–it doesn’t make me wrong.

All of these stories come down to rudeness at a basic level. People just don’t care what effect their actions will have on others. Sooner or later, this will creep up into the higher arts–classical music and opera, if it hasn’t already. Nobody will enjoy anything because of the few who just don’t care and ruin the experience for everybody.

I actually don’t think I’ll ever attend the theater to see a film again. We finally bought our first TVand a sound system. It’s modest, but it’s better than having expensive experiences marred by idiots.

Quite easy:

1. Click on Insert Tags
2. In the Tag Provider combo, scroll to the bottom where it says (Customize Providers…) and select that. It brings up another dialog.
3. Click Add…
4. Here’s what I entered for my site:

HTML Template: <a href=”http://www.philosophicalgeek.com/tag/{tag-encoded}” title=”{tag}” rel=”tag”>{tag}</a>

Now you can select Simple Tags as your tag provider.

In one of our pieces of software we have a process that looks like this:

void MyThread()

{

    while (true)

    {

        DoFunctionA();

        DoFunctionB();

        SleepFor10Seconds();

    }

}

While FunctionA and FunctionB are conceptually similar, they interact with completely different systems.

We had a problem with FunctionA the other day–it was taking 120 seconds to do its thing instead of the normal 10 (or less) because a remote server was down. This caused problems for FunctionB because it wasn’t running as often as it should have so things were getting backed up in the system. Oops.

Now, the solution is to split these two functions into two independent threads so they don’t interfere with each other, and I’ve been meaning to do this for a while, so that’s what I proposed.

Response back: “That’s a good idea, but before we do something complicated like that, can we just put FunctionB first?“

Um, no.

The time we want to minimize is the time between running FunctionB, which is Time_Sleep + Time_A. Putting FunctionB first makes it Time_A + Time_Sleep. Last I checked, those were actually equivalent.

(BlueJeansCable.com)

(via digg)

One of the things I decided when I started working was that I was not going to be one of those guys who worked 12 hours a day for a company (if I ever become an entrepreneur, all bets are off since I’m working for myself). So far, I’ve been pretty successful, and I’ve noticed a few things that may help others. Some of these are more observations than practices.

1. Understand reality: Work Load

The first thing to realize is that the amount of work to do will always exceed the time available. This is why effective management is important. If you are being ineffectively managed, it may be difficult to force a change in some of the following areas.

Just because there is always more work to do, this is no reason to kill yourself trying to get it all done. Or even overexert yourself (except in rare instances). Don’t misunderstand: I’m not saying you have an excuse to slack. Giving all of your time and attention to your employer/projects/job is the baseline here. I am saying that just because you have a lot of work is not a valid reason to work 12 hour days.

Unless you enjoy it…in which case you’re reading the wrong article. If you’re a workaholic, sacrificing your health, family, and free time to get ahead, knock yourself out. You can stop reading now.

There are always special circumstances, though. If you operate in an environment that runs 24/7 services and Something Bad happens–well, then you need to fix it if takes you 24 hours. Hopefully, you’ll get corresponding time off in return. If it’s the last week before release of a project and a major bug comes up–get it done.

I’m talking about normal days, normal work.

If you are working 12 hour days and you don’t like it, then change. No excuses. Change the job or change jobs.

2. Don’t waste time

I knew someone who always complained about having so much work to do, working 60-70 hour weeks, always been pressured, etc. I know he did have quite a bit of pressure to do a number of things, but I eventually stopped feeling empathy for him because I constantly saw him talking to so many people (friends, not direct co-workers) during work.

If you’re so busy working long hours, why do you waste so much time? Why is it that the people who complain loudest about being overworked mostly create the situation themselves?

Don’t wander the halls looking for distractions–chances are you’ll find them.

There is a balance to strike here between enjoyable work environment, having friends, being part of a team, and actually getting things done. There is also something to be said for the difficulty of concentrating on challenging topics for a long time at a stretch. Breaks are definitely needed.

There are trade offs to everything. If you spend an hour or two every day reading blogs instead of working on your projects, you’ll pay for it in time later. If this is a trade off you’re willing to make, so be it, but make sure you understand your priorities and the consequences of your decisions.

I know someone else who used 100 words to say something when 4 would do. This made meetings long, tortuous affairs (unless strong ground-rules were created, endorsed, and enforced). Even simple questions were avoided because nobody wanted to sit there and endure a longer-than necessary answer about the history of the universe. Don’t waste people’s times, and don’t stand for people wasting yours.

Be wise, what can I say more?

3. Don’t micro-manage

The topic of micro-management is something that could take up other blog posts and books dedicated to the subject, but I just want to focus on aspects of it related to time.

This is an inverse of wasting time on trivialities. I once had another boss who spent unbelievable amounts of time responding to every trivial e-mail (and he insisted on being CC’d on every topic of course) and he also complained about working extremely long weeks. And he worked all weekend. He checked on the status of things constantly and was usually the first to spot potential problems. (There were other reasons for this, too: he was usually a main point-of-contact for customers and he had more domain knowledge of everything we were doing). He was very, very smart and usually not wrong, but he did spend a lot of time doing things that were arguably someone else’s job. We never felt invested in these aspects of work, though, because he just did them.

If you find yourself with your fingers in every aspect of your organization, you have a problem, and need to take some time out for consideration:

• Why do you feel the need to be connected to everything going on? Is it because you have to feel in control, or do you not trust others to do a good job?
• Do you not trust your employees? If not, why not? Do they really do a bad job?
• If they do a bad job, why? Are they fundamentally lazy, unqualified, dumb? If so, why are they still working there? Why are you paying them and doing their job anyway?
• Would better training help?
• Maybe expectations aren’t clear. Instead of you picking up the slack, review the expectations you have for them and go over deficiencies. Make them responsible and give them ownership. Don’t undermine their jobs by taking it away. Check on them in the future to make sure things are improved, but don’t involve yourself day-to-day.
• Is it necessary to involve yourself in every discussion or can you just ignore until it reaches a level you need to get into? Resist the urge to comment on things you weren’t asked about.

If nothing else, micro-management always breeds resentment.

4. Set boundaries

I have tried to make it clear to my bosses over the years that when I’m working on a task, I am not to be bothered on a whim. When I’m concentrating, don’t bug me. This is a somewhat loose rule for me, because it really depends on what I’m working on. However, it is more true than not.

The context switching that can happen with interruptions is dangerous for productivity. Eric Gunnerson wrote about “flow state” years ago. Flow state is a zone you get in where your brain is completely engaged–you’re firing on all cylinders, fully committed and involved–pick your metaphor. It’s hard to get into and easy to leave.

I have a nice pair of Bose QuietComfort 2 Noise Cancelling Headphones. These are essential for me now. The whole topic of listening to music while programming is a separate one, with some debate, but I find it usually beneficial. Sometimes I put them on to block sound without listening to music. This also minimizes casual interruptions. I rarely listen to music while trying to create a new solution for something–only when I’m coding something I understand.

Also make sure to enforce a work/life boundary. I have made it clear in my job that I am not be called unless it’s an emergency that needs to be fixed RIGHT NOW. I ignore IMs and e-mails (unless I’m in the mood to answer something, or it’s trivial, or I know it would make somebody happy to know the answer to). If there’s a critical problem, I’ll get a phone call.

I also communicate vacations and just how far out of reach of civilization I will be well ahead of time.

5. Limit Meetings

There is an abundance of resources out there for effective meeting management. I’m more in favor of limiting the occurrences of meetings in the first place. How well you can do this depends a lot on your organization and the projects you’re working on.

Pointless meetings are a waste of everyone’s time. They can be demoralizing, energy-sucking vortexes. Recovering from a bad meeting can take further attention away from actually getting things done.

In my case, we have mercifully few meetings–only when the entire team needs to give input, we need to brainstorm about a tricky problem, or general status updates (yearly or quarterly).

Much of what goes on in meetings can be substituted by effective individual planning, e-mail, issue tracking, or planning better in the first place.

6. Know your tasks

Spinning your wheels is death. Don’t be wasting your time unconsciously (If I’m going to waste time, I’d rather do it consciously with Desktop Tower Defense).

If you’re stuck on a task, get help, change gears, do something else. Make sure you have a process to detect when you and others are stuck so that you don’t waste time.

Always know what you’re supposed to be working on. In addition to have issue-tracking software, make sure priorities are communicated clearly and often. Once you finish something, you should know what the next task is, whether  you do it then or not. Whenever I have a problem of knowing my priorities, I ask my manager. It’s his responsibility to know and set them. I don’t have to worry about it.

There is usually a list of “nice-to-haves” that you can work on once high-priority stuff is done. Don’t let that list get lost, but track it the same way you do regular issues.

7. Effective Information Management

This means all sorts of data: e-mail, documents, data, scheduling, task lists. Simplify, automate, streamline. I won’t go into specific techniques–you can find them elsewhere.

Just a few simple points that I use:

• Don’t read what you don’t need to
• Don’t respond when you don’t need to
• File away or delete ASAP

It’s easy to get buried in information these days–and consequently it’s easy to think it’s at all important. Don’t fall into that trap.

8. External Motivations

A little obvious, this one, but important to ponder. None of this will work if you don’t have strong outside motivations. You have to really enjoy being outside of work–and I don’t think the satisfaction of doing nothing is enough. You’ll get bored of that eventually. Sitting in front of a TV every night “unwinding” for three hours is not a motivational experience (quite the opposite, usually).

Hobbies, projects, sports, exercise, cooking, family, church, books, culture, service are all part of life and should be enjoyed.

I usually schedule my evenings to some degree–whether it’s working out,  moving ahead on personal programming projects, building my latest LEGO model, watching a movie with Leticia, or reading a book–I’ve got a long list of things I enjoy doing. If I don’t follow the schedule exactly, or can’t fit everything in, I don’t sweat it–as long as I’m enjoying myself, that’s what matters.

Work isn’t everything–in fact, it isn’t even the greatest part of anything. Be well-rounded.

* Exceptions

Unfortunately, not every job can be forced into a neat 8-hour work day. My wife, for example, works for a news wire service. She works 8-hour days most of the time, but quite often she ends up staying late to take care of things. Unfortunately, when your job depends so much on other people, it can be a bit hard to plan days, and it’s very possible that work comes up right when you leave, or there is too much work to fit in in a day. However, this is unsustainable in the long run. Either more efficient processes have to be introduced, the work load decreased, or more people hired.

A word or two about politeness as well: it’s difficult in some environments to enforce better behaviors without being considered rude, grouchy, or holier-than-thou. Sometimes firmness has to give way to politeness. The carrot usually works better than the stick anyway in the long term.

The code was calling something like:

CSize sz = m_btAdjustColors.GetDC()->GetTextExtent(sCaption);

It seems correct, but these script languages are throwing it for a loop–the measured size is much smaller than it should be. The GetTextExtent documentation doesn’t shed any explicit light on this subject, but may hint at it.

The solution? DrawText. There is a flag you can pass to tell it to calculate the rectangle needed instead of drawing.

CRect rect(0,0,0,0);

m_btAdjustColors.GetDC()->DrawText(sCaption, &rect, DT_CALCRECT);

It’s important to initialize the rectangle to zeroes because, as the docs say, it only modifies the right and bottom members of the rectangle.

One issue I didn’t really see addressed in the comments on the post is the overall issue of mail safety. People need to consider the seriousness of stealing mail. There’s a reason the fines for it are so severe. A reliable and trusted mail system is the foundation of a good portion of our society and its communications mechanisms.

Having lived overseas, and having had many family members live all over the world, I can personally testify to the need for a secure mail system. There are countries I would not mail a package to–it would just be a waste of money. The security of our system *HAS* to be enforced harshly or people will lose faith in it and it becomes a system of corruption and scamming. This kid got off lucky. If he were older or there were stronger evidence he were stealing more valuable items, or he were being less discriminating in what he stole, I think he could have gotten a far worse punishment.

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.

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.

Technorati Tags: Vista SP1

Frank Kelly wrote up a good summary of some items. They’re simple, easy to understand, easy to follow, even for non-programmers.

In fact, I’m sending this link out to everyone in my group here at work.

Technorati Tags: testing,programming,bug reporting

I’ve simplified the code quite a bit in order to demonstrate the issue. Suppose I have a wrapper around an image (it has many more attributes):

   1: class Picture

   2: {

   3:     Image _image;

   4:     string _path;

   5: 

   6:     public Image Photo

   7:     {

   8:         get

   9:         {

  10:             if (_image==null && !string.IsNullOrEmpty(_path))

  11:             {

  12:                 _image = Bitmap.FromFile(_path);

  13:             }

  14:             return _image;

  15:         }

  16:     }

  17: 

  18: }

I had this and a view that loading about 2,700 of these into a customized ListView control at program startup. On a cold start (where none of the pictures were in the disk’s cache), it would take 27 seconds. Unacceptable.

What to do?

My first thought was to load the pictures asynchronously. I wrapped Bitmap.FromFile() into a function and called it asynchronously. When it was done, it fired an event that percolated up to the top.

Well, I spent about 30 minutes implementing that and ran it–horrible. The list showed up immediately, but it was unusable. The problem? Dumping 2,700 items into the ThreadPool queue is a problem. It doesn’t create 2,700 threads, but it causes enough problems to not be a viable option.

Asynchronicity is still the answer, though. But it’s at a different level. Instead of loading the individual images asynchronously, I skipped loading the images when creating the list control and instead launched a thread to load all the images and update them when done. The list loads in under a second, and the pictures show up little by little after that.

Measure, measure, measure. And pay attention.

Technorati Tags: code,asynchronous program model,c#

In my day job I work on a real-time messaging system that can have very, very little downtime. As the service grows and sees more traffic, the amount of downtime shrinks. We start to worry now if upgrades take longer than 5 minutes. (It’s almost to the point where we’ll need redundant systems in order to do maintenance).

To upgrade this software, I have to have an awful lot of confidence in the code changes made. Sometimes that confidence varies.

What to do to gain confidence:

1. Consistent process

Having a set of rules to follow is a fundamental requirement of good software engineering. I’m not going to discuss what the process should be, but you should have one that works well.

Why is this important?

Programmers like order. We like well-defined problems where we can see the end from the beginning. We don’t like haziness, indeterminism, or too many choices.

A process nails down the unknowns–it tells you very specifically what the next thing to do is. A good process leaves no room for doubt.

A good development, testing, and deployment process is the first step to building confidence in what you’re doing.

For my messaging system example, here’s a short summary of what our upgrade process is. We didn’t just come up with it–it evolved as our business grew and the requirements grew with it.

1. All unit and integration tests pass (we have about 2200 automated tests for this that can run in about 4 minutes)
2. We’ve run it on staging server for a few weeks with no issues.
3. All new features have been tested on the staging server
4. Formal change document has been submitted and approved.
5. Formal test results documented.
6. Previous version backed up.
7. Perform upgrade
8. Monitor system (including custom automated monitoring tools)

At any point, I know where we are in the process and what needs to be done next. Sure, there may be details within these steps that require thought and creativity, but the process guides it all and makes us more confident that we’re not performing ad-hoc operations.

2. Unit Testing

There are other types of testing, but it all starts at the unit level, with simple tests that exercise your code line by line, function by function, feature by feature. I recently wrote a few thoughts about unit testing. Unit testing is where you can see the overall wellness of your code–you want that green bar!

Without unit testing, how do you know the code you’re writing is doing what it should? do you just run it and push it through its paces? This is highly inefficient for most types of code. You’ll run out of steam before you start getting close to edge cases.

The fact is that automated unit tests are a baseline for confidence in your code. You need to be able demonstrate time and again that your code performs well.

This all presupposes that you are writing good unit tests. If you’re not sure, start studying. I don’t buy the arguments about lulling developers into a false sense of security–sure, that can happen, but having good developers who understand this is a prerequisite.

If you’re not unit testing–what is your basis for confidence in your code?

3. Code Coverage

Code coverage goes hand-in-hand with unit testing as a good way to automatically discover what areas of your program are in need of more testing. I’ve found that one of the biggest barriers to unit testing a large C++ application we have is that we have no way of easily measuring test coverage. If we had time, we could definitely to the analysis ourselves, or we could spend a lot of money to get a C++ instrumentation profiler, but these are slow and very tedious to use in my experience.

In .Net, use the tools to your advantage.

The psychological benefits of seeing 75-, 90-, 95-, even 100-percent coverage are immense. You know that every line of the program has at least been touched.

Of course, most code coverage tools analyze line coverage, not path coverage. Combine  complexity analysis with code coverage to determine which functionality should probably have better testing. There are plenty of free and commercial tools that will give you cyclomatic complexity, among other metrics.

Use other analysis tools like FxCop to make sure your other ducks are in a row. It can find easy-to-overlook problems like not validating arguments of public methods, which can then lead to more unit tests and more coverage to achieve.

4. Automation

Take yourself out of the equation as much as possible. The point of a process is to be repeatable–it’s like automating yourself. Not only should unit testing be automated (thankfully, most testing frameworks handle this easily), but so should coverage and quality analyses.

What about deployment? Automate it. Documentation generation? CD master creation? Web upload? E-mail notification? Automate them all. Production builds should be invoked with a single command.

Working on boring, repeatable code? Automate it with code-gen.

The bottom line is: Don’t waste your brain cells on stuff that is highly repeatable, especially when it is prone to mistakes.

5. Code Review

Last week, a rather serious bug was discovered in some of our software (not released yet, thankfully, but close). The bug was mine, and I knew exactly what the problem was, but instead of designing a solution by myself, I brought a co-worker into the discussion just to bounce ideas off of. He had great suggestions, and made me think of things I might not necessarily have thought of on my own. We both went over the code and came to a solution that was simple and acceptable to both of us. The confidence level was much higher with this than it would have been otherwise.

This story is repeated daily by programmers throughout the world. Code review is a practice based on the simple notion that there is no one person smart enough to get it correct the first time.

Even if you’re working alone, which I often do, it pays huge dividends to regularly review your code with an eye for finding trouble. If you see any weakness at all, don’t ignore it–fix it. If you’re reviewing your own code, it’s a good idea to wait a bit after the time you wrote it. This gives your brain a chance to forget a little bit about it. Then, if you find you can’t understand it anymore, it’s either too complicated, or (if it fundamentally really is complicated) you need better comments.

Reviewing with other people has more benefit, however. Not everybody thinks the same way about problems. People have different experience, different expertise and focus, and you can’t take advantage of that if you don’t let them teach you. Even if the other people have less expertise than you, it is still beneficial (assuming they have some basic competency that they can bring to the discussion).

Once you let other people tear into your code (nicely, I hope), your confidence can be higher because you can add the confidence other people have in it (once your problems are corrected, of course!)

6. Repeatable Experiences

In the end, one of the best ways to increase your confidence in yourself, your code, and your practices is to have the evidence of repeated experiences behind you. You’re always learning, and that learning contributes to improvements in processes, testing, and your personal coding practices. Once you learn what works, especially during tricky upgrades, you can go into the next trial with increased confidence that you’re doing something right.

Have any other ideas on increasing confidence? Leave them in the comments!

Technorati Tags: process,confidence,unit testing

“Dear Mr. Watson,

Thank you for contacting us on 12/27/07 regarding the quality of LEGO(R) toys and products.

“We were sorry to learn of the difficulty you experienced with your LEGO set. We understand how upsetting and disappointing it can be when a product does not live up to its reputation. Please accept our apologies for the packaging error you encountered. Producing the highest quality LEGO products possible and establishing consumer trust in the LEGO brand name, are the most important goals of our Company. Certainly, whenever a packaging error does occur, we want to correct the situation as quickly as possible to restore your faith in our brand name and what it represents. Therefore, I have enclosed the item(s) you requested to complete your set.

“Please accept our apologies for the inconvenience you have experienced. If we can be of further assistance, please do not hesitate to contact Customer Service…”

And that’s why I love LEGO.

Technorati Tags: LEGO,customer service

 Goodreads.com also looked nice, and it almost won. bookwormr.com, the one I originally found was just too immature at this point. I’m also wondering what features are going to set it apart from the pack, especially when there are so many well-established sites that do the same thing.

Meanwhile, if you want to read some books that will definitely NOT make you smarter, check out 5 Books that can actually make you stupider.

Visit my Shelfari page.