Do you feel like your RSS reader is becoming overloaded? Noise-to-value ratio is too high? Then you are ready for this exercise! Read on.
If you’re like me, you follow this cycle: I find somebody new (via Hacker News, Twitter, dzone, etc) and I add the blog to a RSS reader (Google Reader, in my case).
However, if you’re like me, again, , you find it hard to remove people. So the list grows…
Up to the point where you feel overwhelmed, overloaded…
Not a good feeling.
Want a simple solution that works?
This technique utilizes folders. So if you don’t have any, create one and put all RSS feeds into it.
At the beginning of the year, you append a year to the folder and create a new folder with the same name as before. So if I have a “New” folder, or a “Good Stuff” folder, I rename it to “Good Stuff – 2012.” I create a new “Good Stuff” folder. New blogs go to the “Good Stuff” folder. If I see something interesting in the “Good Stuff – 2012″ folder, I move it to “Good Stuff.” After a few months, you’ve essentially filtered the old folder and extracted the feeds that are of interest to you. You then drop the folder and all it’s feeds.
I just went through the exercise and removed all folders with a “2011″ tag on it. I feel much lighter now. With room to grow. It’s a much better feeling than being overloaded.
Effective Programming: More Than Writing Code
by Jeff Atwood
Date Read 9/2012
I’ve been following The Coding Horror blog for at least a few years. When I heard that the author released a book, via a blog post on the blog, , I felt both excited and unexcited. Excited because I like author. Unexcited because I discovered that it’s mostly reprints from the blog. However, the price of $2.99 for the book pulled me in. And I’m glad it did.
You might have read a few posts from the blog, but most likely not all. When put together as a book, I was inclined to read it from cover to cover. My success rate on reading blog posts, especially longer ones, is low. So most of the material was new to me.
Excellent topics! Let’s take an overview of the sections:
Those are sections and they each contain a few chapters.
Easy to read. And fun! Most of the chapters are short. I love books like that. I can easily read one or two chapters on a train. This was a perfect book for that. The author can write. Sometimes he made me laugh. But I really enjoyed the easy to read, conversational style.
Filled with lots of tips. I’m not a newbie to programming, but I’ve learned a few things: few things about chairs, lighting, application pricing, ui, code reviews, testing, and lots more. Along the way, I kept saying to myself: I couldn’t say it better; I can’t agree more. Nothing really ground braking, but still…
Not all chapters were interesting. A few I decided to skip after reading a few paragraphs. But there were only a few, I think two or three.
A great book to pick up and read casually. You will enjoy it. I can almost guarantee that you will learn something new and find a few facts fascinating. And if you think books are too expensive, then is $2.99 too much? Now I get the chapter on pricing!
Almost all of us know the GoF patterns. Perhaps not all of the patterns. I forget them from time to time, but with more experience, I remember more and more. (I keep forgetting what a Memento is. )
As important as they are, I think there are other, perhaps more important patterns and principles that I follow. Some of them are “in my head” when I code. Some of them are there and I just follow them without naming.
They are fundamental theorems/patterns/principles of programming.
Good idea to review them.
Good idea to write about them.
Good idea to revisit them.
Don’t you think?
Languages and trends pass by. Principles and how we approach our programming tasks stays with us. Forever.
Once we have solid principles in place, we’re able to reuse it from language to language. Deepening and improving that knowlege has the highest return, I feel.
So I’d like to revisit SOLID principles; GRASP patterns. They’re at the heart of programming. Close to my programming heart, at least. More to follow.
focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.
–Steve Jobs in [BusinessWeek, May 25, 1998]
I am a TDD fan. I’ve been one for a long time.
But I’m not a TDD practitioner. I don’t follow the TDD methodology of writing the test first, implementation second.
Uncle Bob convinced me to try. Again.
Time to become a TDD developer! Time to step up my code quality.
I have said it many times, Robert Martin, Uncle Bob, is someone who has had a big influence on my career (you can find other references on this site). I usually buy all his books. His latest one, The Clean Coder, is not only a joy to read, it’s filled with great advice. It’s like reading The Pragmatic Programmers again. Who doesn’t want that?
Let’s get to the point, though. Why would I ever want to follow TDD? Isn’t that counterproductive, and… silly!
Do I want to write higher quality code? Faster? Less buggy? And get more fun out of it?
But I’ve tried before. And reverted to old ways of doing it.
This time, I want to infect myself with it.
How? By trying harder. By making this “my way” of doing things. And by actually writing the tests first.
It’s going to take more effort than that!
Today I got an opportunity to do just that. And I am surprised how I was able to kill a few bugs. Bugs that would have “bugged” me later.
But why write the tests first?
So I develop good coverage. So I design better. So I get instant feedback. Those are 3 very good reasons. Not only that, but by first thinking about the tests, I will cover more corner cases; I will make my code testable.
Do I really need more convincing?
Not really. Benefits are clear. It’s just a matter of “doing” it.
Lastly, to give some direction and insight on how to proceed, here are the three laws of TDD as per Bob.
The Three Laws of TDD
1) You are not allowed to write any production code until you have first written a failing unit test.
2) You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
3) You are not allowed to write more production code that is sufficient to pass the currently failing unit test.
Martin, Robert C. (2011). The Clean Coder
Ready to join the TDD camp?
While looking at the top weekly links on dzone (good way to see what are the important things that happened), I came across a very intriguing entry: The Top 10 Attributes of a Great Programmer by Steve Riley.
These always “get me,” but a lot of times they end up being just a quick browse. This one is different. Though the attributes are similar to what I”ve seen before (see entries in Craftsmanship category), they’re good. And it’s always good to re-read them.
Here are the top 10 form the blog. Read the whole post as the author gives his own explanations. My thoughts are below.
- Being a great problem solver.
- Being driven and lazy at the same time.
- Ability to understand other people’s code
- Having a passion for programming
- Loving learning for the sake of learning
- Being good at math
- Having good communications skills
- Strong debating skills
- Extreme optimism
- Extreme pessimism
Being a good problem solver? Of course! Great programmers are great problem solvers. Agreed!
Being driven and lazy. I keep telling my wife that being lazy is a good think. She doesn’t get it! But I agree that being lazy is a good quality to have in programming.
Ability to understand other people’s code. Somewhat agree. Is it just me, though, but I see a ton of code that I’m having very hard time following! I would say it differently: great programmers write code that others can understand; great programmers write code for humans to read.
If you don’t have a passion for programming… can you excel in any other profession if you don’t have passion!?
Everybody needs to learn and work hard to get better. That’s why great programmers go the less traveled road.
Being good at math? Debatable. I think there is a connection, but wouldn’t pay that much attention to it. But yeah, I was good in math.
All in all, a good post by Steve.
Uncle Bob in Clean Code states, “the Boy Scout Rule tells us we should leave the code cleaner than we found it.” Another words, when we make changes to the code base, we should make sure we are leaving it (checking in to repository) cleaner.
The original rule of the Boy Scouts states: “Leave the campground cleaner than you found it.”
This is very relevant to the way we code!
Following this rule is not easy. In some cases it might not even be possible (most likely not a good sign).
Why isn’t it easy?
When I code, I try to follow similar, but fundamentally different rule: don’t make the code base worse than you found it. Worse, not necessarily better. Following this rule is not easy either. It means I have to get a good understanding of the code before I make a change. It means I don’t try to put in a quick fix or a hack, add special exceptions (wouldn’t it be easy to just add a simple “if” statement).
It all starts with one broken window, as the theory of a broken window tells us.
The Boy Scout rule takes it a step forward. It requires you to not only understand the code, but improve it before you check your code in. Just the other day, I saw something that smelled. It had a lot of duplication. My task was to add something similar. Since code was already written, somewhat complicated, I went with the easy route. I followed the same route: I added more duplication! I didn’t necessarily make the code base worse, as it’s already been like that. But I didn’t make it better either.
I did not follow the Boy Scout rule.
If I did, I would have taken the time to refactor the code, generalize it, and make it reusable. I would have removed the duplication and made it easier to modify later on. Read: I would leave it better than I found it.
I’m already feeling resistance. I’m thinking about situations where it might not be possible to follow the Boy Scout rule.
Resistance is good. It means that I have some growing to do. It means that following this rule is…
Yes, it’s going to be a challenge. But the reward is there. Making improvements to the system you’re working on is a reward on its own. Talking about this in an interview should also get me extra points. But most of all, following the Boy Scout rule will make me work harder. It will make me a better programmer.
–The poeple who are best at programming are the people who realize how small their brains are. They are humble. The people who are worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.
in Code Complete
Do you agree with Steve?
Effective Java (2nd Edition)
by Joshua Bloch
Date Read 1/2011
I read the 1st edition (my recommended book) a few years back. I just re-read the 2nd edition. It’s one of the best Java books around (the other must read would be Java Concurrency in Practice).
The 2nd edition is a little harder to read. Some chapters are too long and are not as cohesive (not like they were in the 1st ed), but still, getting all these tips from a Java champion is very valuable. At the very least, you can use his tips to win your arguments and influence others on your team.
And that’s the reason I’m recommending this book: read it to become a better Java programmer. Isn’t that a good reason?
I’ve been quiet on this blog lately. I’ve been quiet in 2010 as a whole! Only 5 blog posts during the year. That does not make it too active, I must say. As new year’s resolutions go, I plan to change that.
Starting from this week, I set a goal to write a blog post per week. But wait, I have 4 blogs (click Home to see them). So that’s roughly 1 post a month. That should at least double the postings in 2011.
In 2010 I changed jobs. I am now involved with pure Java development, which I love. But it’s also a nice change from using Java sparingly, mostly coding Velocity templates — not too say you cannot get creative, but it’s a “contained” circle. I am now “free” and that should lead to more interesting ideas and topics.
What am I up to lately? Deepening my Java threading knowledge, and Java in general. (I just got an idea for a separate post on this subject. )
What are my plans for 2011? I plan to deepen my Java skills. Java 7 is around the corner (finally!). I’d like to improve my Spring knowledge — if you don’t use it you lose it. Guava — a google collections library. I’d like to learn that as well. I mean, I’d like to find uses for it. I also want to learn bash scripting. Never learned it, but coming across it very often. Time to dig deeper. If time allows, I also want to learn Python. Seems like it should be in my toolbox. I can perhaps combine it with Google App Engine application. Sounds cool.
2011 should be a busy year.
How am I doing it? How do I find the time? Early to bed, early to rise… said Benjamin Franklin. And that’s exactly how. I wake up at 5:15am everyday. And I try to collect at least 2 pomodoros (25 minute sessions, with 5 a minute break; check out ChromoDoro in Chrome) reading, practicing — doing dev-improvement stuff. That’s how. It works for me.