I just finished reading "Effective C#: 50 specific ways to improve your C#" by Bill Wagner. Definitely worth a read. Not too long, and each point is only several pages so you can just read a bit and put it away, read a bit and put it away, read a bit, and - you get the picture.
I've started Refactoring by Martin Fowler. Seems like another great book.
I really wish I'd started reading these much earlier in my career. Although I'm finding that a lot of what I'm reading I'd already picked up from other sources, but it's nice to read a comprehensive coverage of each topic.
Monday, July 11, 2005
Thursday, July 07, 2005
more is more
We've recently had seven people join our team. We recently only had 5 full time developers in our team, so that's a big increase (sure, I could have worked it out as a percentage, but you can do that in your spare time).
The change has been great, I always like meeting new developers to get their perspective on how they approach their work.
It also gives us the chance to do stuff we've been too busy to do - like more pair programming.
Welcome to Richard, Michael, David, Kyle, Mark, Goran and Andrew.
The change has been great, I always like meeting new developers to get their perspective on how they approach their work.
It also gives us the chance to do stuff we've been too busy to do - like more pair programming.
Welcome to Richard, Michael, David, Kyle, Mark, Goran and Andrew.
less is more...
I've been reading/watching/thinking about this recently. Everyone's saying less code is better and I agree. The less code, the less chance for bugs, the less the program has to do and the less code paths makes the code more robust.
Now the art of writing less code is easy - understand exactly what is required and implement it the simplest way possible. Also, avoid duplication of code or functionality like the plague and you're on the way.
Get on board and write less!
Now the art of writing less code is easy - understand exactly what is required and implement it the simplest way possible. Also, avoid duplication of code or functionality like the plague and you're on the way.
Get on board and write less!
Friday, July 01, 2005
swimming upstream
Anyone with experience (or knowledge, Mitch ) will know that the more time you spend on upstream tasks will pay large dividends further into the product cycle.
I know there's no easily identifiable point when you know you've done enough analysis and design, but it's better to overspend in this area then suffer the consequences later.
It's amazing how just one extra class or one decision can save hours (or weeks!) of work.
You're never going to get it completely right, as the details are never immediately obvious. But that's no excuse not to try.
Right now, I'm doing a bit of swimming upstream...
I know there's no easily identifiable point when you know you've done enough analysis and design, but it's better to overspend in this area then suffer the consequences later.
It's amazing how just one extra class or one decision can save hours (or weeks!) of work.
You're never going to get it completely right, as the details are never immediately obvious. But that's no excuse not to try.
Right now, I'm doing a bit of swimming upstream...
Subscribe to:
Posts (Atom)