Idea for a new book. Effective Programmer.

[Vladas Razas]

I have a good idea for a new book. If there is such book already, please give me a reference.

I am talking about programmer's psychology. But it would be a book by programmers for programmers. This is not why we sit endless hours in front of our PCs. Not about programmers usually being intraverts and so on. This would be a book "How to become efficient programmer". They have already books like "how to be efficient businesman", "trader". Have you read anything about how to be efficient programmer? I have not. We have a lot of literature how to use technologies. Even "Effective C++/Java etc." but an average programmer reading this book, might not get what he wants. I did this mistake before: I spent too much time designing a very extensible a very reusable software, even while coding I could partially agree that no one, even myself will never use that class again. I spent designing it a week or two. I could have take a shortcut and do it dirty way in couple hours but I was so busy solving future reusability problems which I never encountered in the first place.

In university I had a teacher which strongly suggested that we need to design every algorythm, method before we start coding it. On paper. Maybe his approach was good for mainframe programmers with limited access to terminal. I really doubt he did write anything complex. Every large project has so many details, you can't track and keep them in your head all at once. Some projects have so many questions to be solved to provide complete design that it might make sense to start from coding (extreme programming) and then later on add new features than have everything designed before coding (waterfall).

Let's take another example: unit testing. If we go to unit testing site, they will strongly recommend "write tests first and code later". Ha. If you new they have a chance to get you. If you try to write tests without defining interfaces first... what are you going to test? If you are working using extreme programming approach (very good for risky projects and I consider every project risky) you will have to throw away lot's of code... and lot's of tests... Do not take every word they write literally. They don't lie to you at whole but you have to use their ideas for your benefit and not sacrifice your results for their ideas.

OO programming is here for a very long time. How many of us are really good at it? I'd say very little, not more than every 1/5 programmer that uses OO language. Everybody has a knowledge of language, most try to structure code using classes, many know patterns, less spot/apply patterns correctly. Everybody can use a good OO library, very few can design it.

As with OO same with other techs. There are a lot of people with good techical expertise. They know technologies, new and complex. But still have you noticed some people catch up quickly, others have more problems even with better prior knowledge of technology? I don't think this is because of smarter and not so smart people, at first place. I think this is because they are applying better general programming practices.

Like in real life in programming there are true values and marketing. Marketing might tell you: "your code must obey these rules, and you must use as many patterns as you can". Even though you don't have a problem those patterns solve. But in practice you will be loved for you write a software that works and it is not too much late on schedule. Other programmers will appreciate simplicity and understandability. Those marketing values are not real, software is.

Have you noticed that most brilliant ideas come when you are not trying to push them? For me, I have my best ideas usually 2-4 days after I was trying to solve a problem "close-and-personal" way and came up with something awful? Maybe we should postpone the problem we can't solve right now and go code some other part of the application?

There are a lot of things to write about, a lot of hidden rocks, everyone has to find out himself. This book shouldn't be technical or technology based. Technologies come and go. I'd like a book with tips, how to be a good and efficient programmer in any technology. All those problems go away with experience but still it would be great to cut a few corners and save some months and pershaps years.

Regards

[Jayesh Lalwani]

There are a lot of books on good programming practices out there. The problem is that programmers dont follow good programming practice unless they get a kick in their pants.


"Every large project has so many details, you can't track and keep them in your head all at once. "

That's why you have UML. So, you can document your design. Lots of books on UML out there. Most begginners dont want to take their time learning UML because they are too eager drilling the code.

"Some projects have so many questions to be solved to provide complete design that it might make sense to start from coding (extreme programming) and then later on add new features than have everything designed before coding (waterfall)"

That's where you have prototypes. You start coding without design when you develop a prototype. Then you throw away the prototype and design from scratch. Read up on waterfall method!! It's a judgement call when you need to prototype or when you cant. No amount of reading will teach you that

"Let's take another example: unit testing. If we go to unit testing site, they will strongly recommend "write tests first and code later". Ha. If you new they have a chance to get you. If you try to write tests without defining interfaces first... "

That's why you have to design first. Interface design is part of software design. Read any extreme programming book. They will tell you design first, then design your test cases and then code. As I said, there are a lot of books on good programming practices

"OO programming is here for a very long time. How many of us are really good at it? I'd say very little, not more than every 1/5 programmer that uses OO language. Everybody has a knowledge of language, most try to structure code using classes, many know patterns, less spot/apply patterns correctly. Everybody can use a good OO library, very few can design it. "

First, You are confusing OO programming and OO design. OO design is a skill as much as programming is. No one can teach you how to apply patterns to solve a proble. Two equally good OO designers will design the same project differrently. You cannot start creating good designs by just reading a book. It requires practice and a lot of failures before you start cranking out robust, efficient and reusable designs.

"As with OO same with other techs. There are a lot of people with good techical expertise. They know technologies, new and complex. But still have you noticed some people catch up quickly, others have more problems even with better prior knowledge of technology? I don't think this is because of smarter and not so smart people, at first place. I think this is because they are applying better general programming practices. "

The ability to understand and use new technology needs a much differrent skill set than the ability programming. My manager cant write a line of cde, but she can understand new technology as fast as me. That doesnt mean that she's smarter than me or I'm smarter than her. It just means that she has the aptitude to understand technology, even though she doesnt have any aptitude to design software. Again, the ability to learn new technology doesnt come from a book. You either have it, or you dont.

"Like in real life in programming there are true values and marketing. Marketing might tell you: "your code must obey these rules, and you must use as many patterns as you can". Even though you don't have a problem those patterns solve. But in practice you will be loved for you write a software that works and it is not too much late on schedule. Other programmers will appreciate simplicity and understandability. Those marketing values are not real, software is."
You need to tell marketing to write the software for you then.

"There are a lot of things to write about, a lot of hidden rocks, everyone has to find out himself. This book shouldn't be technical or technology based. Technologies come and go. I'd like a book with tips, how to be a good and efficient programmer in any technology. All those problems go away with experience but still it would be great to cut a few corners and save some months and pershaps years."

My point is that there are a lot of books on programming methodologies out there. You dont need another book. Programmers dont use the correct methodologies either because they are rushed because of deadlines or because they wag their stick and say "I dont need to do XXX, I can just start coding right now" As for your other points regarding the ability to learning new technology or the ability to create OO designs, those things cannot be learnt from a book. If someone could come up with step by step instruction on OO design, we wont need OO designers anymore, we can just write a program that creates OO design.

[Vladas Razas]

Thanks for taking time to comment my post. I've read your comment. I was missing a book which would address right programming approach or culture. I think I will read The Pragmatic Programmer. That's a close.
Thanks!

[Ilja Preuss]

Originally posted by Vladas Razas:
Let's take another example: unit testing. If we go to unit testing site, they will strongly recommend "write tests first and code later". Ha. If you new they have a chance to get you. If you try to write tests without defining interfaces first... what are you going to test?

The functionality, of course. And by writing the test, you *define* the interface you want to have, from the point of view of a client. That is, you design the interface *while* you are writing the test.

If you are working using extreme programming approach you will have to throw away lot's of code... and lot's of tests...

That's quite contrary to my experience. Where's that statement coming from?

Do not take every word they write literally. They don't lie to you at whole but you have to use their ideas for your benefit and not sacrifice your results for their ideas.

In my experience, you only can fully understand their ideas after you have taken them literally for some time and gained experience in doing so. Otherwise you are likely to sacrifice their ideas to your inexperience in evaluating them.