The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
I have around 6 years of development experience. I have worked for several companies now. I can tell you one thing: a lot of developers don’t know how to write object oriented code. They write Java and they assume they write objects. But those are not objects; they’re more like data structures. Objects are not data structures, objects have to have a clear responsibility, a clear purpose. Object should do one thing and do it well.
Anyway, I am going to put my thoughts on object oriented systems here in this category. My thoughts, learning experiences, etc. Hey, I learn as I gain experience. I’m not perfect and I don’t want to be. But there are some principles that I have already learned that work for me. One thing I’m sure: writing objects is hard, very hard. It takes real effort and dedication. It takes years of experience to do it well. But modifying a nicely structured object-oriented system is a joy. It’s fun. I like to program, but it has to be fun. “Hacking” might be fun, but it is fun in only one direction: it’s not fun when you have to modify it and undo your “hack.” 
Beyond Code: Learn to Distinguish Yourself in 9 Simple Steps!
by Rajesh Setty
ISBN 1590791029
Date Read 4/2006
My Rating
This book is similar to My Job Went To India. However, it’s shorter and reads smoother. It focuses mostly how to improve yourself; how to distinguish yourself. The author has been there, and he tells interesting stories. He has excellent quotes in each chapter. Excellent book recommendations on the back.
Even though a lot of the information can be found elsewhere, the author presents it in an interesting way.
My Job Went To India
by Chad Fowler
ISBN 0976694018
Date Read 4/2006
My Rating
When I first looked at the book, I judged it by the title. I thought, what a stupid title. I did not even look into it. But then I saw recommendations from some people and overall good reviews. I jumped in, bought it, and read it.
If you are scared that your job might go to India, this is a required book for you. Otherwise, you will find a lot of good tips and valuable information that will help you become a better developer.
This book is a quick read. It cointains short 1-2 page chapters — 52 of them. Or you can call them “short lessons.” As I read, I kept telling myself: I need to do that, or I need to do that more often. Some info is common sense, but it serves as a good reminder.
Are you using them?
I only found out about them recently — they’ve been available since JDK 1.4. I think they’re vastly underutilized…. But they can be really helpful in debugging situations and don’t incur any performance hit.
You can enable them in your JDK by adding “-enableassertions” to default VM arguments (type “jre” in filters in Eclipse and edit it there).
Then in your code, whenever you have a feeling “this can never be null or false” add the assertion, as inassert thisField != null; and you’re done.
Assertions are a great debugging tool.
What’s the best job in America? If you asked me, I would say “software engineer.” But that’s just me… Hold on, it’s not only me. Money Magazine lists Software Engineer as the top job in America! Wow.
Here’s what they say about it:
Software EngineerWhy it’s great Software engineers are needed in virtually every part of the economy, making this one of the fastest-growing job titles in the U.S. Even so, it’s not for everybody.Designing, developing and testing computer programs requires some pretty advanced math skills and creative problem-solving ability. If you’ve got them, though, you can work and live where you want: Telecommuting is quickly becoming widespread.
The profession skews young — the up-all-night-coding thing gets tired — but consulting and management positions aren’t hard to come by once you’re experienced.
What’s cool Cutting-edge projects, like designing a new video game or tweaking that military laser. Extra cash from freelance gigs. Plus, nothing says cool like great prospects.
What’s not Jobs at the biggest companies tend to be less creative (think Neo, pre-Matrix). Outsourcing is a worry. Eyestrain and back, hand and wrist problems are common.
Top-paying job Release engineers, who are responsible for the final version of any software product, earn six figures.
Education Bachelor’s degree, but moving up the ladder often requires a master’s.
ReferenceBest Jobs In America, Money Magazine
Java 6 is around the corner. One of its most exciting features is scripting, I think. There are two sides to it: client-side scripting, and web scripting (I’d like to see an example), as explained by the author of the article below. Examples of client-side scripting are in the article, Scripting for the Java Platform.
In any case, this JSR gives us many options of using other languages inside Java. That’s cool.
ReferenceScripting for the Java Platform, Thomas Kunneth
Extreme Programming Explained (E-book from ACM)
by Kent Beck
ISBN 0201616416
Date Read 3/2006
My Rating
Extreme Programming is a good, agile process. It is a disruptive force in the software community. Some XP practices are really good and worth adopting, and some are not so good, I think.
This is a well written overview of XP. If you just want to see what XP is all about, then this book is for you. It is a general overview of XP. For that purpose, the author does an excellent job. However, it’s just an overview, and if you’re looking for a lot of details, you might be dissapointed.
There is not enough detail. I want to see examples of the stories, I want to see the whole process actually work in a example from start to finish. I was not able to find that in this book. There is not enough detail for me.
If you want an overview of XP, this book is for you. If you want a lot of details so you can actually implement XP, look elsewhere. Overall, a good book on a software development process, and might help you improve your process.
The Non-Designer’s Design Book
by Robin Williams
ISBN 0321193857
Date Read 3/2006
My Rating
It’s a great little book for people like me: I have no clue about design. I am not going to become a designer after reading this book, that’s for sure. But I liked the book. I gained some “design” knowledge. I know — by name — the different aspects of design now: proximity, alignment, repetition, and contrast. I’ve also validated some of my thoughts on design. A good, handy book. It’s an easy and a quick read.
Parse error: syntax error, unexpected ‘http’ (T_STRING) in /srv/www/kubasek.com/public_html/wp-content/plugins/php-execution-plugin/includes/class.php_execution.php(273) : eval()’d code on line 1
Are you thinking of becoming an architect someday? What are your plans for future? Maybe you are just a hard-core programmer and want to stay that way? There are people in each group. I would like to become an architect, a technical leader, and a manager. What? All three? Actually, I would like to become a manager, but I think a software manager should also be a technical leader and have at least some of the architect’s skills. I’d say, by the end of 2008, I would like to be a manager. Those are my goals for next couple of years. I am still not 100% on it, but more and more, that’s the direction I want to pursue.
Back to architecture. Being a software architect is not easy. It is only for the select few.
But I know, now, what software architect is, and what it entails. I found out from this excellent article, Characteristics of a software architect, by Peter Eeles, a Senior IT Architect at IBM. It’s an excellent read. A must read if you would like to go in that direction.
Software Architect is (I’m putting my comments for each major point; quotes are taken from the article)..
The architect is a technical leaderNo question about it. You have to know your stuff. You have to be an expert in a lot of different areas.
The architect role may be fulfilled by a teamThis is an interesting point. I think that’s how I would like it to be: a team effort.
The architect understands the software development processThis is a must. A software process needs to be continuously improved. You have to understand it first, to make improvements. Thus, you need to know others processes as well.
The architect has a knowledge of the business domainVery important. One interesting point in the article, by knowing the domain you can foresee some of the problems or extension to the system.
The architect has technology knowledgeOf course.
The architect has design skillsA big part of architecting is designing flexible, easy to understand, maintainable systems.
The architect has programming skillsAs an architect, you will oversee other programmers, you have to know.
The architect is a good communicatorAn architect has to be able to communicate with a lot of stakeholders; he has to share his vision clearly. Plus, he has to defend his decisions.
The architect makes decisionsVery good point.
The architect is aware of organizational politicsYou cannot avoid politics, as much as I don’t like it, that’s the truth.
The architect is a negotiatorYou have to talk to programmers, testers, business people. You have to negotiate.
What do you think? A lot of skills and knowledge required.
Excellent article. This is the best summary I’ve read. Written in a clean manner. Nice, pragmatic approach.
Do you still want to be an architect?
ReferenceCharacteristics of a software architect, The Rational Edge Newsletter, March 2005, my recommended resource
