10 Introduction This is one way in which programming is very different from other forms of communica- tion.When you speak to other people,you assume-usually correctly-that they have some knowledge that lets them fill in missing information.Not so with computers,or at least conventional computers given stand-alone programs.Writing successful computer programs requires a degree of explicitness that is unparalleled in other aspects of human experience.This is one reason why learning to write computer programs can be challeng- ing.On the other hand,being explicit to the point that a computer can carry out instructions may sometimes carry over well to other things you do.like writing papers or reaching agreements with others about who will do what in connection with some project 1.7 Working Incrementally Another challenge of progr coauidy makin ally.By we mea m yo little at a time builds you al.: build you re you go ent is added.by e the ba nent is solid befor the first floo is added.and so on.During p n develo ent.you will often find it useful to ger rate intermediate output to ver rify that each sten works as expe cted.You may later inhibit that output when the program is completed and is no longer needed.Think of this incremental D ess as the digital equivalent of the ancient woodworking adage (attributed to John Florio,1591).Alwaies measure manie,before you cut anie("Measure twice,cut once.") When you're reasonably sure your program works and before you add another component or make other significant changes.save the program with a file name unique to the last working version.The moment you prepare to make changes to the program,save the file with a new name or version number before putting in any changes.Follow the American folk adage,"If it ain't broke,don't fix it."Too often,attempts to further develop a program will,in fact,break it,or otherwise reveal some weakness in it,and you might want to go back to an earlier version.You'll be glad you have one Remember,too,that computer storage is cheap.There is no harm in having a folder full of documents called Ma rogram_01.m,Max_Program_02 .m,Max Program 03.m u actual work s Ma? Pro othing wrong with such a high nun ay the ons I versions ATLAB es it easy to compare the ng connec sa compa ferences betweer wo vers a program,simila ck changes”inMic 0 ligh 1.8 Being Open to Negative Feedback How can you tell if your prog ram works?as you consider this question one attitude should rule over all others:Be tive fee back.if you treat ne gative feedback as a help rather than a hindrance. ou will become a better,and certainly happier,programmer than if you treat ngative fcedback in a ngativeay. The research of psychologists Carol Dweck and Janine Bempechat(1980)is relevant in this regard.Dweck and Bempechat distinguished between people who take negative feedback 10 Introduction This is one way in which programming is very different from other forms of communica￾tion. When you speak to other people, you assume·usually correctly·that they have some knowledge that lets them fill in missing information. Not so with computers, or at least conventional computers given stand-alone programs. Writing successful computer programs requires a degree of explicitness that is unparalleled in other aspects of human experience. This is one reason why learning to write computer programs can be challeng￾ing. On the other hand, being explicit to the point that a computer can carry out instructions may sometimes carry over well to other things you do, like writing papers or reaching agreements with others about who will do what in connection with some project. 1.7 Working Incrementally Another challenge of programming is translating your procedural ideas into language the computer can understand. Here it is useful to work incrementally. By this we mean you should build your program a little at a time, making sure each part works before you go on to another part that depends on what youÊve just written. You should build your program the way a reliable contractor builds a house, by making sure the foundation is solid before the basement is added, by making sure the basement is solid before the first floor is added, and so on. During program development, you will often find it useful to generate intermediate output to verify that each step works as expected. You may later inhibit that output when the program is completed and is no longer needed. Think of this incremental programming process as the digital equivalent of the ancient woodworking adage (attributed to John Florio, 1591), Alwaies measure manie, before you cut anie („Measure twice, cut once.‰). When youÊre reasonably sure your program works, and before you add another component or make other significant changes, save the program with a file name unique to the last working version. The moment you prepare to make changes to the program, save the file with a new name or version number before putting in any changes. Follow the American folk adage, „If it ainÊt broke, donÊt fix it.‰ Too often, attempts to further develop a program will , in fact, break it, or otherwise reveal some weakness in it, and you might want to go back to an earlier version. YouÊll be glad you have one! Remember, too, that computer storage is cheap. There is no harm in having a folder full of documents called Max_Program_01.m , Max_Program_02.m , Max_Program_03.m , and so on. It may be that the version youÊll use for actual work is Max_Program_101.m . There is nothing wrong with such a high number. You can tuck away the earlier versions in a sub-folder until youÊre sure youÊll never need to look back. Having sequential versions of a program in development makes it easy to compare the changes. In this connection, it is useful to note that MATLAB has a comparison tool that highlights all differences between two versions of a program, similar to „track changes‰ in Microsoft Word. 1.8 Being Open to Negative Feedback How can you tell if your program works? As you consider this question, one attitude should rule over all others: Be open to negative feedback . If you treat negative feedback as a help rather than a hindrance, you will become a better, and certainly happier, programmer than if you treat negative feedback in a negative way. The research of psychologists Carol Dweck and Janine Bempechat (1980) is relevant in this regard. Dweck and Bempechat distinguished between people who take negative feedback