Designing Applications for the Power Macintosh

Here’s a summary of the tips we’d like to pass on; we’ll look at each one in more detail below.
1. Tackle expensive computations when they can improve the interface.
2. Eliminate dialogs and command lines in favor of direct manipulation.
3. Drop old assumptions and idioms. Use the processing power to explore new interfaces.
4. Provide a starting point for exploration.
5. Avoid programming cleverness. Instead, assume a good compiler and write readable code.
6. Invest development time in user-centered design.
7. Learn the new rules for performance.
8. Design tiered functionality: take advantage of whatever hardware you’re running on.
9. Test on real users.
via Designing Applications for the Power Macintosh.

On Refactoring

Inspired by this post
I was recently handed the responsibility to maintain/fix the code of my officemate who has already left for greener pastures. Its my first day with the code so I did a 2-3 hour refactoring session with around 4k LOC.
I finished trudging through 1k LOC , and would probably be finished with the rest of the code if my team lead didn’t tell me to fix a critical bug (on the code I was refactoring).
Note One: I haven’t been told that the code was my responsibility but I have a sixth sense for things like this, so I faced the hurdle head on.
Note Two: Writing Unit tests before refactoring, trust me on this, You know that feeling you have before an operation, well that’s how you feel before and , while and after you are testing your code. No matter what you do you have that fear that maybe you didn’t do it right. So just write the test. Just do this for your sake.
I saw a few readily fixed errors around 10 and about 4 errors that took me awhile to understand and eventually fixed.
Around 2 hours after lunch we had a quick meeting because of the critical bug. The bug was a show stopper and at the meeting the code/functions/pages were formally given to me with a reminder:  We need the bugs fixed today.
luckily, some of the the bugs I have already fixed and my refactoring allowed me to easily zero in on the offending code. I was able to fix it in less than 30 minutes.
After two hours, my team lead comes to me and ask warily,
“When are you going to finish fixing the bug?”
“Its Already fixed”
“The bug? you sure?”
“yep”
The face of my team lead of disbelief/suspicion/slight admiration was priceless.
This was all due to refactoring!

Refactoring And Maintaining Other People's Code

I’ve been feeling the pain of other developers right now. Maintaining and actually changing other people’s code.
I have a couple of thorns in my side.
1. I’ve been using C# for almost two months now. Although I can already say that I a already have above average skill in C# I’ve had difficulty with mainly lack of familiarity of a lot of shorcuts and the best ways of doing things.
2. I am maintaining and at the same time creating a lot of the code. I feel like I am piling mistake upon mistake. I don’t blame the previous programmer, I must confess that I am slowly rewriting a lot of the code, not for dogmatic reasons, purely to make the code cleaner.
3. How Do You Do Unit Test with C#. This is my primary fear right now, If I cant design proper test units, I don’t know how I’ll survive testing this!
I’ll add more as I encounter more difficulty!