The Pragmatic Craftsman         :: Simplicity from complexity :: | About Me |

If you consider yourself a good programmer, great! But is this going to hold true, two years, five years from now? If you are not going to learn new things, I can safely say that you're going to be "out of date."

If you want to stay still, you have to continue moving: being a good programmer means learning new things constantly.

Here are 10 Ways to Learn New Things by Philosophical Geek. Follow at least some of these and I think you'll be covered.

1. Read books.
2. Read Code.
3. Write Code - Lots of it.
4. Talk to other developers.
5. Teach others.
6. Listen to podcasts
7. Read blogs
8. Learn a new language
9. Learn the anti-patterns
10. Be Humble

Reference
10 Ways to Learn New Things in Development | Philosophical Geek

Ben Watson, whose blog I just came across, lists the following Top 5 Attributes...

1. Humility
2. Love of Learning
3. Detail-orientedness
4. Adaptability
5. Passion

I think this is a very good list. I think effective programmers are humble. Why? Because you have to be able to work well with others. Just from my experience, it's hard to work with people with a lot of ego.

You just have to love to learn. Effective programmers constantly improve. How do you improve? By finding new ways of doing the things you're used to... better. You have to be exposed to new ways in order to do that. Being able to adopt and having a passion for the profession are essential.

Reference
Philosophical Geek -> Top 5 Attributes of Highly Effective Programmers, Philosophical Geek blog

Here's what Ben Rady, who calls himself software craftsman, states under his Statement of Values. I value similar things: I can sign my name under this statement. Excellent summary.

As a technical leader, I value:

* Talented People
* Rapid Feedback
* Individual Relationships
* Facilitation over command and control
* Continuous Improvement
* Frequent Delivery

As a programmer, I value:

* Working Software
* Clean Code
* Rich Communication
* Flexibility over efficiency
* Sustainable Pace
* Simplicity
* Failing Fast over hiding errors

As a human being, I value:

* Courage, not cowardice
* Humility, not hubris
* Compassion, not callousness
* Curiosity, not apathy
* Discipline, not carelessness
* Honesty, not deceit
* Patience, not intolerance

Reference
Statement of Values, Ben Rady

Here's a great definition of what a software craftsman is. It's also similar to the way I think. And this is also part of the Introduction in the book Agile Java.

I am a software craftsman. I have spent much of my software development career trying to quickly build solutions to problems. At the same time I have tried to ensure that my solutions demonstrate carefully crafted code. I strive for perfection in code, yet I know that it is unattainable, particularly with the constant pressure from business to get product out the door. I take modest pride in the code I build daily, yet when I look at the code I wrote the day before, I wonder, "What the heck was I thinking?" This is what keeps the craft challenging to me—the constant desire to figure out how to do things a little better the next time, and with a little less pain than this time.

Reference
Safari eBooks - ACM - 0131482394 - Agile Java™: Crafting Code with Test-Driven Development

I found a great, pragmatic, and simple to understand definition of what a craftsman is from Dean Wampler, read below.

Am I a craftsman? No. Not yet. :-) But I work hard in that regard. Besides the first quality -- being widely recognized -- I think I can get good marks in the other characteristics. I strive to deliver quality; I am passionate about coding; and I continuously learn.

A craftsman is widely recognized by peers
Rino recently won an international competition in Italy, one of many times he’s been recognized nationally and internationally.

A craftsman is passionate about the craft
Rino says that if you are passionate about food, you will work on the presentation of even humble dishes. Pasta, as well as lobster, deserves an attractive presentation.

A craftsman delivers value to the customer while meeting business objectives
Rino keeps the kitchen lean and efficient. He keeps costs low by relying on high-quality ingredients, keeping waste to a minimum, and constantly improving the skills of his staff, all without ever compromising quality. In the year Rino has been at Pazzaluna, costs have dropped, while business and profits have increased.

A craftsman knows that quality is the number one priority
Rino knows that cutting quality today means less business tomorrow. He keeps quality high by keeping morale high. Morale is high because his staff is constantly learning new and better recipes. Also, as you watch him interact with his staff, you can see that he treats all of them, from his sous chefs to the dishwashers, with dignity and respect, while always holding them to high standards.

A craftsman never stops learning
You would think that he knows it all, by now. Yet, he has never forgotten a lesson his own mentor taught him, “you can learn something from even the worst cook, because he always knows something you don’t!” How many gurus do you know that think they have nothing left to learn?

Dean Wampler on Craftsmanship

What does all this have to do with software? Pretty much everything. Like cuisine, clean code is part art, part science. Clean code is created by passionate craftsman who are fanatical and fastidious about every detail. Clean code is the product of years of accumulated experience. The decisions a master makes moment-by-moment, whether test-driving the next feature or fighting a fire, reflect the wisdom and breadth of knowledge that produce high-quality results quickly and efficiently. Finally, a master leads by example, bringing the rest of the team up to his or her standards.

So, if you’re young and ambitious, latch onto the mentors around you. If you can’t find any, find another job. (Your organization is doomed anyway; so you might as well move on now.) If you’re older and wiser, seek out the promising junior people, teach them what you know, and learn from them as well! Oh, and if you want to taste real Italian food, make a pilgrimage to St. Paul. Tell Rino I sent you.

Reference
What I've Learned from Master Chef Rino Baglio, Dean Wampler

Practice makes perfect.

I think you can agree with me on that. To become a craftsman, you not only need to acquire new knowledge and new skills, you need to be able to apply that knowledge, be able to polish your skills, and improve the output every time. I don't remember who said it, Mozart I think, that every time he played the same piece, he did it differently. He was always looking to improve it. That's the type of mentality of a true craftsman. And that's what I need to develop to become a true craftsman.

Practice new technologies: put your knowledge to the test
Over the last few years, I must have read 20-30 software books. I learn a lot, no doubt. But rarely do I actually put that knowledge to test. I just read, make notes (sometimes), and move on to another book. Doing it this way, I think my knowledge is not deep enough. I really cannot do anything with it, and I easily forget it.

I need to read a little and be able to put that knowledge to practice: I need to apply it. How do I do that? By writing a project based on that technology. By practicing -- playing -- with the new technology.

For instance, I want to learn Ruby (and Rails). Before I can say that I learned it, I should build a website or another project in Ruby. Only then I can say that I learned Ruby.

Same with any new technology. To really learn it, I should create my own project based on it. Anything new, whether it is a pattern or a technique, before you really learn it, you need to be able to put it into context. Ask yourself, how can I put that technology to use?

Practice to polish your skills
In an ideal work environment, we would get to work on new and different technologies fairly often. That does not happen in the real world too often (or you're lucky). As a result, we stagnate and get used to our working environment. I don't think that's a good situation. As a craftsman, you can never let your skills stagnate -- lose freshness. You have to stay abreast with new technologies, acquire new skills constantly. But how? On your own!

Use your down time at work to freshen up on your skills. Once again, practice comes into play. Think the project you're working on could benefit from migration to a newer, better technology. Do it! On your own. Start a new project, and migrate the old project to the new technology. Doing this keeps your skills fresh. You're gaining new skills.

Playing with new technologies is very important. If you cannot do it at work, you need to find time for it, whether at work or at home.

Practice to polish -- improve -- the product
Every time you build a product, always strive to make it better. Better than your previous one. That's the mentality of Mozart. I think that's a mentality of a craftsman. And that's what you want to become, right? Then you have to have that mentality! In design meetings, suggest a better way; when designing on your own, reflect and see what could be improved from your last project.

By practicing continuously, you'll be able to see how things can improve. You'll be able to build on your skills. You'll be able to keep your skills up to date. This is key to getting better, improving your skills, and becoming a better developer, a craftsman. And remember: you can never stop practicing!

Once again, and that's the bottom line, to move into architecture, to move up, to become a craftsman, you need a lot of practice. You need to continue practicing or you will not be "crafting" but "hacking." Practicing takes time, but that's the only way to make sure that you "got it." BTW, as a craftsman, you should be loving it! :-)

There was an article today on reddit, Seven Secrets of Successful Programmers. The article contains some good tips, but overall it is too simplistic and not challenging enough, as pointed by Lars Wirzenius, in his follow up to the first article, Rant: Secrets of Successful Programmers.

What are the good points from the first article? Code for human consumption. That's true. You should code for humans first, computers second. Make your code readable, it's very important. Comment often and comment well. I think it's critical to write a self-documenting code, as recommended by Steve McConnell. If you have to comment your code, your code is not good. Change it so you don't need a comment, and then add a comment. Name your variables to aid readability. True, variables should not be cryptic. Keep your functions simple. That's very important. Your function should do one thing and do it well. Same goes with your objects. Your object should have a well defined, cohesive set of responsibilities and do them well.

In his follow up, Lars suggests different seven secrets. They're very good. In fact, I think they're excellent. Much more comprehensive, and challenging. Maybe in the future I'll come up with my own list. :-)

Lars Wirzenius, Rant: Secrets of Successful Programmers

Reference
Duncan Merrion, Seven Secrets of Successful Programmers
Lars Wirzenius, Rant: Secrets of Successful Programmers
Steve McConnell, Code Complete

The critical distinction between a craftsman and an expert is what happens after a sufficient level of expertise has been achieved. The expert will do everything she can to remain wedded to a single context, narrowing the scope of her learning, her practice, and her projects. The craftsman has the courage and humility to set aside her expertise and pick up an unfamiliar technology or learn a new domain. --Dave Hoover in article on StickyMinds.com

This is a great definition of a software craftsman: the best I found so far. The article by Dave Hoover on StickyMinds.com is a very good one, link below. Especially if you want to find out who a craftsman really is.

What can you learn from this? Be humble. Be curious. Be eager to learn new technologies. And be lazy. :-)

Reference
Experts, Craftsman, and Ignorance by Dave Hoover

Related Post
Every Craftsman is Dump and Lazy

Yeah, that's true. :-)

Craftsman is lazy because he does not want to repeat what he wrote before.

Crafstman is dump because he knows that if he's not, he'll stop learning and stop being critical of his work. Both are essential for being successful.

It's good to be dump and lazy after all, huh? So be dump, be lazy -- those are qualities of the best!

Read the post, link below, by Jeff to see more explanation. Great stuff.

Reference
How to be Lazy, Dumb, and Successful by Jeff Atwood (Coding Horror blog)

I was slipping...

I got my B.S. in Computer Science from NJIT after four years. I spent another two years there and got my M.S., in CS as well. In between, I got my first full-time job. I can say that everything was going well. What could be better? Yet, not realizing it, I was slipping. I wasn't learning any new technologies. I wasn't keeping up with new books. I wasn't improving myself. Yet I thought I was doing fine.

So what happened? I came across Steve McConnell and The Pragmatic Programmers (Dave Thomas and Andrew Hunt). I met Steve through his classic book, Code Complete. It opened my eyes. It woke me up from my sleep. The Pragmatic Programmers made sure I'm awake.

Steve and The Pragmatic Programmers directed me to a path of continual improvement. In order to improve, they told me, I have to constantly read. They told me to constantly learn and practice new technologies. They told me to invest in my knowledge portfolio continuously, just like I invest in my stocks.

That's why, I know now, to be a software craftsman, and stay a craftsman, the most critical element for me is to get better every month, every year. Constantly. Reading is a great way to accomplish that.

Reading
Reading is probably the best way of improving yourself. There are a lot of experts in the software industry. But we don't get to meet or hear them (unless we're lucky). A lot of the experts want to share their information with those that want to learn, though. How do they do that? They do it by writing. We, on the other side, can receive that information by reading their works. Read...

Read books.
Read at least 5 to 6 books per year. Steve McConnell recommends reading a book every two months (roughly 35 pages per week). The Pragmatic Programmers recommend reading a book every quarter, and then eventually moving to a book a month (mixing it with non-technical books). I think both of the recommendations are adequate. Steve goes on to say, that if you do that, you'll distinguish yourself from everybody around you.

I have taken their recommendation to heart. I have started reading a technical book every two months. Recently, I've upped it to a book every month. I've been on this continuous reading path for over a year now. And you know what? I've never been more confident. I want to stay humble here, but I can see that I'm doing more than the guys around me. I'm distinguishing myself more and more every month. I知 feeling good. :-)

But there are so many books to read! Yes, that's true. But I follow this approach: I read the best books. I read books with a 5-star rating on Amazon.com (or close to it). "I only read the great ones," said Jerry Weinberg, when asked by Joshua Kerievski how he keeps up with all the books that come out. Follow this approach and you'll be fine.

Read magazine articles and journals.
Reading books is great, but you also have to keep up with the industry. You should know what new technology are coming up. You should be aware of your surroundings. The best way to do that is by reading magazines and journals.

I read a lot of magazines. I start off a week by checking out eWeek and InfoWorld (both free). Every other week I receive an issue of SD Times (free). These 3 magazines are the Newsweek for IT, they tell me what's happening. Every month I get JDJ, Communications of the ACM, Queue, IEEE Computer, Software Development (very good; free), Better Software (very good), and an issue of CrossTalk (free). Every other month I receive the IEEE Software (my favorite). These magazines tell me about new technologies. They tell me about new development techniques. They teach me new ways of doing development. And they also lead me to good books. All of this for almost nothing (I only pay for IEEE Software).

Read blogs and newsletters.
I read books every month, magazines every week, and I read software blogs every day. There are so many good, expert bloggers out there that I think it would be a waste not to check out what they have to say. You have to pick what you like as there are a lot of good developers writing/bloggin. Reading Joel on Software (especially the archive) is one of the best, though. (I have over 100 feeds at my Bloglines account.)

When I graduated from college, I thought I knew it all. I thought that on-the-job learning and experience will be enough. It might have been enough for my current job, but what would happen if I lost that job? Would I be prepared? No! I have to take things into my own hands. I have to learn for myself and by myself. Reading continuously is a great way to learn and has been my savior for my renewed confidence.

Steve made me realize that it doesn't take that much to be one of the best in your group, to be on par with the best in the software industry, to feel like you belong in the software industry. My advice? Read constantly and you'll get there.

I've recently changed the way I work as well. I said it to myself, I have two things to do at work: one, to do what's asked of me in the best possible way, and two, to improve myself as a developer, and I do that by reading books and technical blogs. I have virtually eliminated reading news, sports, and other time consuming resources. I'm on a mission here: I want to be one of the best in the industry. I want to be a software craftsman.

Yukihiro Matsumoto, the creator of Ruby, the object-oriented scripting language (I don't know it but I hear it is a good language -- Pragmatic Programmers recommend learning it), shares his top 10 tips for programmers. I like the list. The list is inline with what I believe good programmers should do and believe in. The list describes what a crafstman should do. Read this interview on Aritma, Matz on Craftsmanship, where he is asked about the tips that are found below. I extracted the Top 10 list and showing it to you below.

Software Crafstmanship defined. Defined by nobody else but by a true craftsman himself, Uncle Bob. This entry was so good and so relevant to this blog that I had to include it in full. Read it and re-read it often. I will.

Uncle Bob's Software Craftsmanship Corner
We will not ship shit.
by Robert C. Martin
July 15, 2003

In a recent JDJ article, Interviewing Enterprise Java Developers, the author, Yukov Fain, explained what J2EE developer needs to know. I really liked the article (you should read it), and author's suggestions. Here is an excerpt from that article:

What does a good J2EE developer have to know in addition to understanding the difference between abstract classes and interfaces?

Usually employers are looking for people with at least 10 of the following skills:

• Java servlets,
• JSP,
• Struts or a similar framework,
• EJB,
• JMS,
• any commercial message-oriented middleware,
• JDBC,
• JNDI,
• HTML,
• XML,
• Ant,
• SQL,
• one of the major application servers,
• a couple of relational database management systems,
• any UML modeling tool,
• several design patterns (at least a Singleton!),
• and familiarity with Unix.

Next year JavaServer Faces and Hibernate will most likely be included in this laundry list.

What do you think? I think the list is reasonable. I know most of the technologies. No I don't know all of them. I don't know EJB, JMS, and I'm not really familiar with the applications servers. However, that's on my to-learn list. I'm playing with JBoss, WebLogic, and WebSphere (hey, why not learn all of them :-)) Plus, EJB 3.0, which is coming up soon, is something I want to learn.

Are you completely clueless what those acronyms mean? Then it's time to wake up. You better start reading and learning! :-)

In the road to becoming a craftsman, I need to define a software craftsman. In this section, Becoming a Craftsman, I'm going to try to explore who a software craftsman really is, and offer my advice in steps required to go in that direction. Don't worry, you're not alone. I'm either going through the action steps, went through them, or they're on my list. That's a real deal. I'm going to start off with communication skills.

Software craftsman is a good communicator

There is no question about about it: If you cannot explain what you're doing to others you will not be a true craftsman, no matter how skillful you are. You have to become a good communicator! Being a good communicator is not only knowing how to speak (yes, that's part of it), it is also knowing how to write well, and how to listen well. I'll explain one by one.

Knowing how to speak
This is very important because a lot of times a person is judged by it. Just think about it. Who do you perceive as smart? Who has left a good impression on you? Whom are you more likely to listen? Usually, somebody that knows how to speak well. Usually, somebody that has got your attention. Besides, if you want to gain confidence or move up the ranks you need to be able to speak clearly. What can you do about it? Practice, practice, practice. I've recently joined a local Toastmasters club solely for that purpose. It's a speech club that gives you a chance to talk at every meeting. I can't tell you how it has helped me, since I joined it recently, but judging by the people in the club, I think it's going to help me tremendously. Plus, I found out about it because it was recommended by an article on Computerworld.com -- How to Prevent Offshoring From Taking Your Job. Check out Toastmasters.org, find a local chapter, and go to a meeting and see how it is.

Knowing how to write
In software development there is a lot of writing. You write software requirements. You write design document. You write code. You write tests. There is a lot of writing. What comes with it? An opportunity to shine. An opportunity to be better than others. An opportunity to be perceived as quality oriented. Just by writing well you will be perceived as a better developer. What can you do about it? Set it high on your priority. Say it to yourself: I'm a good writer. And then practice, practice, practice. Read some books on writing well. There are two that I read and that I think are must reads: The Elements of Style by Strunk and White, and On Writing Well by William Zinsser. You should definitely read at least those two. Here is a list of others by a professional writer and his recommendations.

Knowing how to listen
You might be saying to yourself, whaaaaaat? Yes, knowing how to listen is also a very important communication skill. However, it's a skill that many of us, including me, take for granted. I am not doing a whole lot in that direction, except acknowledging that it is important to do so and reading up on some strategies in Carnegie's book (see below). What can you do about it? Get a book on communication skills and you'll sure find it there. Plus, take notice: don't interrupt when somebody talks; stay interested when somebody talks; ask questions. Basically, when somebody talks, stay active, don't daydream.

Being a good communicator will not come right away. This is a long-term process because it is a change that has to come from inside of you. Make a dedication and evaluate your progress every 1/2 year (or more often -- the more the better). You'll see a difference. This is a skill that will help you in other areas of you life. It is a universal, whatever-you-do skill. It has a potential to be a difference maker. Take it seriously.

On a related note, a classic book that everybody should read (I'm finishing it slowly), is Dale Carnegie's How To Win Friends and Influence People. I am highly recommending it, as are hundreds of users on Amazon (it has almost a 5 star rating).

So, say it to yourself and try to achieve it: I am a software craftsman and I know how to communicate well.

I found an interesting reply to a pretty good post, Kick-ass Software Developer looking for work, submitted by an anonymous reader. Take a look, as I think they're quite interesting. In the quest to becoming a craftsman, I think this is a pretty good guideline. It's certainly one I will keep an eye on, and judge the progress I'm making. This is the best list I've seen so far.