Less code is good. Actually the best code is code that is never written.
Code is going to be read by someone else. Less code makes everything easier to understand.
And the what a feeling you get from cleaning code!
Every line of code that can be removed brings a grin
Every method that can be deleted makes me smile.
Every object that can be eradicated makes me laugh.
Act like there is no tomorrow.
Obliterate code.
Tuesday, October 27, 2009
Monday, October 19, 2009
Mindset
I once worked on a project that had some tests but the architecture was... let's say it could be better. There were many files with over a thousand lines of code many classes had too many responsibilities I did not have enough fingers to count them all.
I think I failed to be as effective as I could in this environment for one reason. A very simple reason.
"Coding in the right mindset you did not" said my master. And the master gave me a bunch of dead trees which people commonly refer to as 'a book'.
Reading Working Effectively with Legacy Code by Micheal Feathers triggered a few thoughts. The book just led me to think differently about legacy code.
And what I found out the hard way is that I should have realized that I was working with legacy code.
Simple isn't it?
Then I would not have minded putting methods public to be able to test them. At least it allows me to test my code without too many changes.
Then I would not cared if the class I was working on had thousands of lines of code - I would just make sure the bit of code I was modifying was tested.
Then I would not have tried to refactor too much code. Small steps are the key.
I plead guilty. I was trying to hard to remove the design flaws. This slowed me down when I had to add features.
Learn from my mistakes. When working on legacy code, change your mindset. Forget about great and extensible design - or at least don't make it your priority. You have a job to do. Do it effectively. It might not be glamorous but in the end, you'll get the features out a bit faster while still improving the test coverage.
I think I failed to be as effective as I could in this environment for one reason. A very simple reason.
"Coding in the right mindset you did not" said my master. And the master gave me a bunch of dead trees which people commonly refer to as 'a book'.
Reading Working Effectively with Legacy Code by Micheal Feathers triggered a few thoughts. The book just led me to think differently about legacy code.
And what I found out the hard way is that I should have realized that I was working with legacy code.
Simple isn't it?
Then I would not have minded putting methods public to be able to test them. At least it allows me to test my code without too many changes.
Then I would not cared if the class I was working on had thousands of lines of code - I would just make sure the bit of code I was modifying was tested.
Then I would not have tried to refactor too much code. Small steps are the key.
I plead guilty. I was trying to hard to remove the design flaws. This slowed me down when I had to add features.
Learn from my mistakes. When working on legacy code, change your mindset. Forget about great and extensible design - or at least don't make it your priority. You have a job to do. Do it effectively. It might not be glamorous but in the end, you'll get the features out a bit faster while still improving the test coverage.
Wednesday, September 30, 2009
Book Review : Peopleware
Project failure is caused by human errors. Very few projects (if any) failed because they used PHP instead of Ruby. Projects fail because people fail.
Peopleware is about these teams. Your team. Why it might be failing it's current project. And mostly what it can do to succeed.
This time I decided to resume the book using a mindmap. I really liked the experience and will definitely give it another go. It allowed me to write down ideas and reorganize them in a coherent picture of what I learned from the book. I believe it will help me remember the main ideas as well.
(Click to view larger image)
You can find the points I found most important in the mindmap. Still, I can't keep silent on one point : quality matters. A lot. Even more than you think. A team that aims to be the best tends to be happy. The turnover rate is lower. On the other hand, asking the team to lower the quality leads to disaster - demoralization, lack of purpose...
Build a cult of quality in your team. Pay attention to details. About everything. Strive to make everything must be perfect. Doing so will push the entire team to aim higher and higher.
Peopleware is about these teams. Your team. Why it might be failing it's current project. And mostly what it can do to succeed.
This time I decided to resume the book using a mindmap. I really liked the experience and will definitely give it another go. It allowed me to write down ideas and reorganize them in a coherent picture of what I learned from the book. I believe it will help me remember the main ideas as well.
(Click to view larger image)"Quality is free, but only to those who are willing to pay heavily for it."
You can find the points I found most important in the mindmap. Still, I can't keep silent on one point : quality matters. A lot. Even more than you think. A team that aims to be the best tends to be happy. The turnover rate is lower. On the other hand, asking the team to lower the quality leads to disaster - demoralization, lack of purpose...
Build a cult of quality in your team. Pay attention to details. About everything. Strive to make everything must be perfect. Doing so will push the entire team to aim higher and higher.
Sunday, September 20, 2009
Personnal Goals
People usually do it for the New Year, but for me the beginning of September was time to think about what I want to accomplish for the next year.
What better way to keep the determination to accomplish my goals than to publish them online and be publicly humiliated if I don't succeed?
So here is what I want to achieve until September 1st, 2010 :
Why did I want to set goals?
I read quite a few books and articles saying that setting goals gives you a way to focus your energy. And a colleague of mine is impressing me by his ability to focus on short term achievements to attain his long term goals. Now is the time to see if these goal-oriented fanatics are right.
Why did I chose these goals?
Blogging - I'm committed to continuing on blogging for the next year. It allows me to try some creative thinking techniques when I'm out of subjects. It also forces me to organize my ideas and learn some subjects in more depth before I blog about them.
Books - I already read about 9-10 a year but I wanted to stretch a bit and go for one per month. That should be pretty doable. Books allow me to find new interesting subjects to talk about and I was always an avid reader. The book I'm currently reading is Peopleware. As I'm reading it I'm experimenting with mindmaps. I'll publish my insights in another post.
Personal projects - pretty much every years I code bits and pieces of small applications. I lay down architectures for more ambitious projects. But (shame on me) I seldom finish a personal project. Time is lacking or more interesting things come around. Whatever the reason, the result is that nothing gets done. Well this time I want to turn things around and focus on closure - I want each project to be finished, in a repo (trying git right now... loving it so far) and tested to my satisfaction. I'm not sure if all the projects will be publicly available, but at least one is going to be.
Final Thoughts
I selected short-term goals to get in the habit meeting my commitments. Setting weekly, monthly and quarterly goals seemed like a good start. Eventually I would like to have a Big, Hairy Audacious Goal, something that will drive me for years to come.
This is only the beginning...
What better way to keep the determination to accomplish my goals than to publish them online and be publicly humiliated if I don't succeed?
So here is what I want to achieve until September 1st, 2010 :
- Write 40 blog posts. I aim for one a week but there are always vacations and weeks where I'm too busy on something else. Forty sounds like a good start for me.
- Read a book a month
- Code four small projects, one every three months.
- Lose 10 pounds.
Why did I want to set goals?
I read quite a few books and articles saying that setting goals gives you a way to focus your energy. And a colleague of mine is impressing me by his ability to focus on short term achievements to attain his long term goals. Now is the time to see if these goal-oriented fanatics are right.
Why did I chose these goals?
Blogging - I'm committed to continuing on blogging for the next year. It allows me to try some creative thinking techniques when I'm out of subjects. It also forces me to organize my ideas and learn some subjects in more depth before I blog about them.
Books - I already read about 9-10 a year but I wanted to stretch a bit and go for one per month. That should be pretty doable. Books allow me to find new interesting subjects to talk about and I was always an avid reader. The book I'm currently reading is Peopleware. As I'm reading it I'm experimenting with mindmaps. I'll publish my insights in another post.
Personal projects - pretty much every years I code bits and pieces of small applications. I lay down architectures for more ambitious projects. But (shame on me) I seldom finish a personal project. Time is lacking or more interesting things come around. Whatever the reason, the result is that nothing gets done. Well this time I want to turn things around and focus on closure - I want each project to be finished, in a repo (trying git right now... loving it so far) and tested to my satisfaction. I'm not sure if all the projects will be publicly available, but at least one is going to be.
Final Thoughts
I selected short-term goals to get in the habit meeting my commitments. Setting weekly, monthly and quarterly goals seemed like a good start. Eventually I would like to have a Big, Hairy Audacious Goal, something that will drive me for years to come.
This is only the beginning...
Monday, September 7, 2009
Essential Bookshelf : Pragmatic Thinking and Learning
Last time I explained how the Pragmatic Programmer book changed the way I thought about software. This time I'll explain how another book challenged me to look at how I learn and process information. What I learned in this book can be applied to pretty much any facet of life.
The second book I advocate a lot these days is Pragmatic Thinking and Learning - Refactor Your Wetware by Andy Hunt. Yes, the same Andy Hunt who co-wrote Pragmatic Programmer.
Here are a few subjects that were covered :
What did I get from the book? So far I got interested in the Meyers-Briggs personality test and in creative thinking techniques. I also added quite a few books in my TODO list from the bibliography. These days I always have a new book waiting to be read...
Pragmatic Thinking and Learning is aimed primarily to programmers and has a few analogies such as "debug your mind" and "refactor your wetware". However the principles in the book can be applied to any skills you want to learn, from blogging to cooking. I strongly recommend it to anyone who likes to use their brain from time to time. Hopefully you'll be interested.
The second book I advocate a lot these days is Pragmatic Thinking and Learning - Refactor Your Wetware by Andy Hunt. Yes, the same Andy Hunt who co-wrote Pragmatic Programmer.
Here are a few subjects that were covered :
- The Dreyfus Model - the journey from novice to expert, how people gain skill in a particular
- How to develop your intuition and why it is important for programmers
- Cognitive Biases and how they might affect your judgment and thoughts
- Generational differences - how different generations view the workplace and what are their values
- The Meyers-Briggs Type Indicator - a personality test, but what mostly interested me is interactions between different personality types
- Mind maps
- Tips and tricks to improve your creativity
What did I get from the book? So far I got interested in the Meyers-Briggs personality test and in creative thinking techniques. I also added quite a few books in my TODO list from the bibliography. These days I always have a new book waiting to be read...
Pragmatic Thinking and Learning is aimed primarily to programmers and has a few analogies such as "debug your mind" and "refactor your wetware". However the principles in the book can be applied to any skills you want to learn, from blogging to cooking. I strongly recommend it to anyone who likes to use their brain from time to time. Hopefully you'll be interested.
Thursday, September 3, 2009
Empower Textmate for Ruby
I've been programming a bit in in ruby from Textmate and although the editor is pretty sharp, I thought there were two missing features.
Power up Textmate with plugins!
I'll try to update this page if I find other useful plugins.
- Start rspec tests
- Start the debugger from Textmate (not often useful but I still do it from time to time... maybe it's my old Java mindset...)
- Rubyamp allows me to start the debbuger from Textmate and does a lot more.
- The rspec bundle allows you to start rspec tests from Textmate
Power up Textmate with plugins!
I'll try to update this page if I find other useful plugins.
Monday, August 24, 2009
Essential Bookshelf - Pragmatic Programmers
I read lots of books. Lately I've been evangelizing the virtues of two of the books that had a deeply impacted me lately. This is the review for one of them.
The first book I want to talk about is Pragmatic Programmer, from Journeyman to Master by Andy Hunt and Dave Thomas. I read this book in 2001, after I worked for a year or so, and it totally changed the way I think about software.
There were lots of great advice under the form of catch phrase (DRY - Don't Repeat Yourself, No Broken Window, the Law of Demeter...). The authors even wrote about usage of metaprogramming and compilers in (almost) everyday software. But that's not what influenced me to become a better programmer.
What inspired me was that the authors have a deep passion for programming and it shows. They talked about investing in yourself as you would in an investment portfolio. "Learn a programming language every year". "Learn your tools". "Care about your craft".
I first heard the expression "rubberducking" in this book as well - if you can't find a human to talk to, talk to the duck.
However programming goes beyond coding. The code is important, but so is knowing your tools, the command shell, deploying an application in a real environment, build files and build automation. Programming is a social activity, you need to show your code to peers to get feedback and improve, you need to talk to your customer to know his requirements. You need to care, improve, learn!
That made me realize that the knowledge I have today is already obsolete - I needed to be aware of where the future might be heading, which technologies might come out on top in a few years. I started to read more books and blogs. I went to local user group meetings. I started a few pet projects in a few languages. And I realized that I would probably be programming even if it wasn't my day job - I was just lucky to get paid for it.
If you haven't read this book yet, it's a must for every programmer who is passionate about his craft.
The first book I want to talk about is Pragmatic Programmer, from Journeyman to Master by Andy Hunt and Dave Thomas. I read this book in 2001, after I worked for a year or so, and it totally changed the way I think about software.
There were lots of great advice under the form of catch phrase (DRY - Don't Repeat Yourself, No Broken Window, the Law of Demeter...). The authors even wrote about usage of metaprogramming and compilers in (almost) everyday software. But that's not what influenced me to become a better programmer.
What inspired me was that the authors have a deep passion for programming and it shows. They talked about investing in yourself as you would in an investment portfolio. "Learn a programming language every year". "Learn your tools". "Care about your craft".
I first heard the expression "rubberducking" in this book as well - if you can't find a human to talk to, talk to the duck.
However programming goes beyond coding. The code is important, but so is knowing your tools, the command shell, deploying an application in a real environment, build files and build automation. Programming is a social activity, you need to show your code to peers to get feedback and improve, you need to talk to your customer to know his requirements. You need to care, improve, learn!
That made me realize that the knowledge I have today is already obsolete - I needed to be aware of where the future might be heading, which technologies might come out on top in a few years. I started to read more books and blogs. I went to local user group meetings. I started a few pet projects in a few languages. And I realized that I would probably be programming even if it wasn't my day job - I was just lucky to get paid for it.
If you haven't read this book yet, it's a must for every programmer who is passionate about his craft.
Subscribe to:
Posts (Atom)
