The Professional Programmer article from Uncle Bob

I would like to share The Professional Programmer article from Uncle Bob. His message is mainly target to Business Application Developers. Here is the link.

http://programmer.97things.oreilly.com/wiki/index.php/The_Professio...

Those of you that want to know who is Uncle Bob. Please check this link.

http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob

1. Agile Principles, Patterns and Practices in C#

2. Clean Code

are my favourite books.

The following are copy from his article. His article was licensed under a Creative Commons Attribution 3. So I copy and paste in here.

What is a professional programmer?

The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.

If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up-to-date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: They promise to pay you, and you promise to do a good job.

Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to find nothing because they don't release their code until they've thoroughly tested it. Of course QA will find some problems, because no one is perfect. But as professionals our attitude must be that we will leave nothing for QA to find.

Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help each other, teach each other, learn from each other, and even cover for each other when necessary. When one team-mate falls down, the others step in, knowing that one day they'll be the ones to need cover.

Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue tracking database are tragedies of carelessness. Indeed, in most projects the very need for an issue tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them.

Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, ever rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you. This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say: "I'll go back and fix this later?" Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism?

Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right.

------------------------

want to read more. Please check out his blog.

http://blog.objectmentor.com/articles/category/uncle-bobs-blatherings

dev2709

Tags: programmer

0 members like this

Comment

You need to be a member of MyanmarITPro - A Social Network for Myanmar IT Professionals to add comments!

Join MyanmarITPro - A Social Network for Myanmar IT Professionals

Comment by Ei Maung on March 8, 2010 at 2:48pm: >> Hire more people will be not work.
Agree that "Adding people to a late project makes it later"...

Comment by dev2709 on March 7, 2010 at 5:57pm: @MyintKyawThu

" In a very tight schedule with already passed deadline" is a different story.
That is management problem, program manager problem. You don't have a choice. Program manager have to cut features of your product. or hire more people. Hire more people will be not work.

The company will be out of business soon if company create a buggy software. That's why company used to give product as "Beta" label for the sake of getting out product to the market.

Software developement is changing in these days under the name of Agile, Test Driven Development. Programmer will have to write unit testing code in the future.

Programmer and QA issue - we use usecase to solve that problem.

Comment by Tun on March 7, 2010 at 11:16am: Of course, another interesting perspective will be a form of security through obscurity to deter reverse engineering.

Comment by Tun on March 7, 2010 at 11:09am: "Quick and Dirty" is important too. i did a lot for my research projects :)
But, when we are working with a big team where staff turnover is inevitable, we have to focus on professionalism and maintainability more seriously. In large software firms there are hundreds and thousands of developers, and most of the time we don't fix our own codes, but others.
just my 2 cents

Comment by Mark on March 7, 2010 at 10:56am: And I saw some people, which exactly like dev2709 mentioned too :D

Comment by Mark on March 7, 2010 at 10:54am: I agree with MKT points, yes, and also Quick and Dirty way to solve problems important too

Comment by Tun on March 7, 2010 at 10:51am: Thanks for sharing. very good article.
it will be nice if someone could translate that into Myanmar.
rgds

Comment by Myint Kyaw Thu on March 7, 2010 at 10:13am: Disagree here with most of the points :) The article implied that professionals are being perfect. It is however impossible to practice in real-world scenarios.

>> They do not release code unless they know it works

In a very tight schedule with already passed deadline, if they do that, they are not professionals. Programmers are not artist, they don't need perfection. You can't sell super cool codes like you can with a masterpiece. Codes are NOT masterpieces. If a programmer make perfect codes, the company will be out of business soon.

>> Professionals do not tolerate big bug lists

Again, he don't know what "bugs" list is. Bug list is not exclusive of coding bugs. Most of the time, it's features requested in programmer sense but in QA's sense, it's what the users expected so it's a bug. Bug list can be thousands and it does not mean it's programmer's fault. Thousands bugs does not mean careless mistakes.

>> Professionals do not make a mess

Professional know when and where to make a mess. N00b just makes a mess. See the difference. If you say a professional can't make a mess, you must assume a perfect project with unlimited deadline. Professional programmers don't produce perfect codes, they make the right codes.