The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
Off-shoring high-tech jobs is a growing pain for U.S. professionals, especially now, when the job situation is still tough. See what’s happening in India where many of these American jobs are headed?
In the article, Chitale discusses the mistakes companies make when offshoring IT work, his concerns that US companies will move their offshored workto China, and how the US political climate affects the bottom line of companies in India.
An interview with an Indian Exec.
Retiring CIO Paul Ingevaldson offers 10 tips for surviving — and prospering — in the IT jungle. I think this is a pretty good list from a management point of view, but it is also somewhat related and applicable to programmers, especially for aspiring managers.
10. Don’t be afraid to leave IT.
9. Don’t keep IT in the closet.
8. Never think you know it all, because you don’t.
7. Understand the corporate strategy and mobilize IT to support it.
6. Develop a “cheap” image.
5. Don’t overmanage IT personnel.
4. Expect your people to make dates and budgets on projects.
3. Don’t charge out IT. Operate it as an expense center.
2. Learn to delegate.
1. Force IT onto the plate of all senior executives.
See the this list explained fully on Computerworld.com
The Psychology of Computer Programming
by Gerald M. Weinberg
ISBN 0932633420
Date Read 8/2004
My Rating
A classic book. I’m going to have to re-read it, and maybe provide a more thorough review then. 
Facts and Fallacies of Software Engineering
by Robert L. Glass
ISBN 0321117425
Date Read 2004
My Rating
Want a quick overview of what software engineering is? Want a short book that will tell you what works and what doesn’t work in software engineering? Want a book that’s written by one of the best IT writers?
Look no further: you’ve got it all in this concise, 220-pages book that will become a software-engineering classic. Yes, this book will join the ranks of Mythical Man-Month, Peopleware, and others. This is not a how-to book, but rather factual information about the state of software-engineering. You’ll get 50 facts from areas like management, quality, life-cycle, and more; plus you’ll get 10 fallacies about pretty much the same areas.
Robert Glass created a masterpiece. This book will open your eyes. It should be a required reading by every software engineer. We could all benefit from Glass’s extensive research.
One thing I found very interesting. You’ve all heard that a best programmer is 10 times as productive as the worse one. Glass, in his Fact #2, says that “The best programmers are up to 28 times better than the worst programmers.” How about that?
All in all, a must read. I loved those small, 2-3 pages long chapters with resources listed at the end of each one.
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 speakThis 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 writeIn 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 listenYou 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.
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
According to IEEE-USA, number of employed in IT-related occupations dropped in the second quarter of 2004. The drop in employed software engineers, programmers, and computer scientists is blamed on the continuing trend for U.S. companies to send jobs overseas, often called offshore outsourcing. So there you go, outsourcing is hitting us pretty hard, and encourages others to leave the IT industry altogether. I think something has to be done about it. That’s why I’m looking into John Kerry’s solutions on offshoring. But this is a hard issue, and I don’t know whether there is a good solution for it.
The IEEE-USA reported the following high-tech employment trends yesterday:
* The number of employed software engineers in the U.S. dropped from 856,000 in the first quarter of 2004 to 725,000 in the second quarter. Yet the unemployment rate among software engineers dropped from 3.3% to 2.9% from one quarter to the next. In 2003, an average of 758,000 software engineers were employed in the U.S.
* The number of computer scientists and systems analysts dropped from 672,000 in the first quarter to 621,000 in the second, and the unemployment rate for computer scientists dropped from 6.7% to 4%. An average of 722,000 people were employed as computer scientists and systems analysts during 2003.
See the whole article High-tech employment numbers drop in second quarter on Computerworld.com
|
If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.
–Steve McConnell
|
I don’t know what’s so complicated about UML that I never seem to get it. Or I never seem to remember it. I guess I like to learn by doing. I just don’t learn by reading an article or a book. Nonetheless, you need an article to learn the concepts. Read on.
I’ve read quite a few articles about UML but I had always been confused. I even read some of UML Distilled book (chapter about class diagram) by Fowler (considered a classic intro to UML), which to me is a little vague and not specific enough. (I did like the UML User Guide, though, by Grady Booch, the original author of UML.) However, I don’t think that you really need a book to learn the class diagrams — you can learn from a good article. I am going to give you the article that it is currently my number one intro to UML’s class diagrams. It was published by The Rational Edge and was written by Donald Bell, here is the link. He breaks it very nice: simple, clear, and gradual. With good examples too. Read it, re-read it, and whenever you get a chance draw some. You’ll learn and you’ll remember. Not like me. (( But I think I’m getting it now. 
Article Link: UML Basics: The class diagram by Donald Bell
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.
I’ve had the liberty to work with a few of great programmers. They have had a number of traits that good or average programmers lack. Each of them had a few of these, but I don’t think any had all of them.
- Understanding of the customer’s perspective. A programmer that can put themselves in the customer’s shoes can stop a bad decision from becoming a nightmare. Sure, it is probably someone else’s job to design the product, but I’ve found that developers usually have the best understanding of the product on the whole. The great developer can pick out inconsistencies before they effect the end user.
- Willing to dive into unknown technology and come back with something usable in a short amount of time. Yep, the whole team may be familiar with Java, but maybe XSLT is a mystery to all. The guy that can give himself a crash course in the technology and come back and show everyone else how it’s done is going to save a lot of time, and allow the team to use technologies that save even more time.
- Able to teach others effectively. This is related to the above, but goes beyond. It allows you to hire lesser qualified people and bring them up to a much higher level.
- Stays on top of new technology. Some developers know their languages and APIs and don’t plan on learning anything new. Others are constantly adopting new technology, skills, or concepts. I’ve known developers who don’t use a computer at home after they leave the office. I know others who are constantly reading blogs, whitepapers, journals, and downloading new software. Most of the time, what you’re trying to do has been done before by someone else. The more you know of what is out there, the more likely you are not to re-invent the wheel.
- Is usually right. The sum of the knowledge and experience in a person’s life effects every decision a person makes. A good developer has seen enough and gone down the wrong path enough times to recognize the right decision.
- Is a good at leading others. This one had been done to death, but there’s nothing worse than going on vacation and coming back to find nothing done.
Just some things I’ve noticed over the years of being fortunate enough to work with very talented people.
