The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
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.
ReadingReading 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.
Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers
by Steve McConnell
ISBN 0321193679
Date Read 5/2005
My Rating
Steve McConnell is one of my favorite writers. He writes in an interesting and easy to follow way. There is only a few (that I know of) in the software industry that do it as good as him. This book is a general overview of the whole software industry. It’s general, but contains some good advice. The chapter on Construx’s professional ladder is very good (you can find it on the web, though). Overall, a good book. Not a required reading, but you’ll enjoy it.
To learn design patterns is not easy. It’s one thing to just read about them and think you know them. It’s another thing to actually know how to use them, and to remember them as time passes by. I must admit, there is only a couple of the GoF patterns I remember. I read about them and after a while I forget them. However, that might be changing, as I have a different approach: I read several books on patterns at the same time.
A while back, I read Robert Martin’s Agile Software Development, Principles, Patterns, and Practices (a great book). I also read portions of the first edition of Design Patterns Explained (ok), portions of the classic Design Patterns, and the whole Holub on Patterns (I did not like it at all). I own all of the books I mentioned (except Holub on Patterns). And I recently bought Refactoring to Patterns by Kerievski. This latest book is what prompted me to change how I study design patterns. (I also own Martin Fowler’s Refactoring, which is a classic book that every developer should have by his side.)
I started reading Refactoring to Patterns. So far, about a third into the book, the book is very good. But I feel that the design patterns are starting to click. Why? As you might guess, the book tries to combine Fowler’s Refactoring and the GoF’s Design Patterns. So, whenever I read about a particular refactoring, I jump into Martin’s book. Not only that helps me understand the text better, I also get more info about the refactoring. (Plus, you get some good advice from Fowler, which I admire as a developer.) Same with patterns, whenever he mentions a GoF pattern (almost every refactoring), I go to the Design Patterns book.
However, the GoF book is not easy, and the book by itself is not enough sometimes. That’s when I turn to Robert Martin’s book, which contains simple Java code for a lot of patterns he mentions. And because he doesn’t mention all of them, I hit the web. This site, Design Patterns, contains code about all GoF patterns — very good resource.
And if that was not enough, I try to write practice code in Eclipse. I created a learn patterns project, and I create a new package for each pattern. This is very useful when, down the road, you forget about the pattern and want a quick reminder (I learn by example). Design patterns are hard to learn because we don’t get to use them right away. By practicing them, you see them in real world. You see them from a different angle. This is very valuable.
Have I found the ultimate solution for learning patterns. I don’t think so. But it makes a big difference to me. Yesterday, I learned about a Composite pattern, today I learned about the Boulder pattern. And I think the knowledge is deeper this time. I think this is a very good way. Little more involved and time consuming, but at the end, it’s what stays with you. Try it and learn.
There’s been a lot of talk about AJAX (Asynchronous JavaScript and XML). Mainly because of what Google is doing with it. But AJAX, in my opinion, will be a key part of web development in the future. If you’re involved in web development, you will have to learn it (this year or next). I actually wasn’t sure what the fuss is all about. Until I read this excellent, easy-to-read article, Asynchronous JavaScript and XML (AJAX) with Java 2 Enterprise Edition.
How does AJAX work? You make an asynchronous (non-waiting) call from JavaScript to the server without submitting a page, the request is processed, and the result is returned to a JavaScript function as XML. Nice, heh? And simple.
AJAX is a breakthrough in web development. Hopefully, it will become a standard soon. (Go to maps.google.com to see it in action.)
Software Craftsmanship: The New Imperative
by Pete McBreen
ISBN 0201733862
Date Read 4/2005
My Rating
I’m disappointed. I expected more from this book. Being that I want to become a software craftsman, I thought this book is going to give me a fairly clear direction on how to get there. There are some bits and pieces of it, but not very convincing.
What I did not like about this book, is that the author is a craftsman himself, but he wrote in 3rd person. If this was based on his experiences, if this book was more personal, it would have been more convincing. It would have been a lot more interesting. Even though I believe in software craftsmanship, I don’t necessarily agree with bashing software engineering in favor of craftsmanship. I belive both fit together well.
Don’t get me wrong, you’ll find some useful information in this book (that’s why I gave it 3.5 stars), but overall it is just a light treatment of Software Craftsmanship.
I’ve been reading some really good articles lately. Below, you’ll find the best ones.
Readings of the Month
J2EE Project Dangers by Humphrey Sheil
If you are involved in J2EE development (seems like everybody is, lately), this article is a must read. It’s well written and very practical. And the article makes me think about today’s IT marketplace. Even though a lot of people call themselves J2EE developers, very few understand the whole architecture. Very few see the whole picture. What comes with it, a great possibility to mess up. It’s almost safe to say that if you’re using J2EE, you are doing something wrong (unless you have a true J2EE guru). I have to admit, I know several different J2EE technologies, but I’m still not seeing the whole picture (different beans, expertise in app servers, and more). J2EE is a beast. But in a year or two, I’ll have it conquered.
J2EE in PracticeContinuing the J2EE theme. This article, actually a chapter from this book, asks some important questions (answered in different chapters in the book) about J2EE development. If you consider yourself a J2EE guru, you should be able to answer most of them. Challenge yourself. If you feel that you need more training, read the rest of the chapters from the book. I will try to. (I would definitely like to see the book published, though, as I I’m having hard time finding a good, practical J2EE book.)
Better Software Magazine — April 2005 issue
This is a great issue of Better Software magazine. I marked three of the articles — It Takes Two to Tango, Injecting Testability Into Your Designs, and The Pleasure of Finding Things Out — as excellent and two other as very good. If you go to BetterSoftware.com and request a subscription, they give you three issues for free (that’s what I did). The articles are short and very practical. If the quality of the articles will be that high every issue, I might have to pay to extend my subscription.
I liked this article, How to Position Yourself as the Top Candidate by Jeff Hocking. It probably gives you the information you heard somewhere else, but you choose to ignore it anyway. As the number of hiring companies increases, you’ll have more choices. Therefore, make sure you choose a company that fits your needs. Do your research. Not only will it help you get the job, but you will be happier because you found something that you wanted. Researching the company, finding out the company internal structure, finding out about company’s culture is a very important step. The article will give you a little bit more detailed information of what you should do.
Ever since I read Goals by Brian Tracy, I’ve been writing my 10-15 goals every night as the last thing before I go to sleep. I am going to share the goals that pertain to becoming a software craftsman so you get a sense of where I am going.
First, I’d like to know J2EE by heart by the end of 2005. That means different J2EE technologies, as well as J2EE application servers (we use WebSphere now at work). I’m keeping my eye on EJB 3.0 and J2EE 5.0 as I think they will be important. (J2EE 5.0 will contain JavaServer Faces and EJB 3.0, among other things, of course.) How? Mostly by practicing. And also by reading.
Second, I’d like to have all of the important design patterns grasped by the end of 2005. How am I going to achieve that? Mostly by reading books. I’ve read Agile Software Development, Principles, Patterns, and Practices (which I recommend), J2EE Core Patterns (also a great book). I’m reading (or referencing) the famous GoF book — Design Patterns. I recently purchased Refactoring to Patterns. What else? I’m reading different articles. Also, when I’m coding, I’m thinking about different patterns. I think I’m on track here.
Third, I’d like to be a well-rounded software engineer by the end of 2005. I’m thinking about becoming certified by IEEE — Certified Software Development Professional (CSDP). I’m planning to read books on requirements, design, testing, and architecture. I might pick a book on RUP.
Fourth, I’d like to become a good software architect by the end of 2006. I plan on reading couple architecture books. I might attend a conference or two. I’m not yet too sure what I need to do, and this goal might take me well beyond 2006, but I know I’d like to become an effective software architect.
What else? I’d like to become more visible in the software field in the next couple of years. That means writing magazine articles, maybe teaching a class. Or simply put, getting more involved in the field.
Am I too aggressive? Maybe, but that does not mean I cannot re-adjust the dates. As I keep writing the goals, they also might change, but that’s where I stand now. One thing is for sure, I’m totally commited to becoming better every year. I am committed to achieve my goals. I work towards them every day.
According to a report by Information Week, it is. It looks like the unemployment rate for IT professionals is 3.7%. which is close to the lowest rate reached at the end of 2001. Are things looking better for us? I think so. And altough things still look a little murky, it looks like the situation brightened quite a bit from a year or two ago. Read the whole report here. Don’t go jumping in joy, yet. The rate is so low mainly because IT professionals started leaving the field. Nonetheles, companies are starting to hire.
|
Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer.
–Steve C McConnell
|
