=== [[AdamDingle]] ===

=== [[AdamDingle]] ===

As you may know the roots of NetBeans can be traced to 1995, when seven of us, students of [http://www.mff.cuni.cz/toUTF8.en/ Faculty of Mathematics and Physics] at [http://www.cuni.cz Charles University] in [[wikipedia::Prague|Prague]] needed to finish a compulsory student project and decided to create a [[wikipedia::Borland_Delphi|Delphi]] for [[wikipedia::XWindow|XWindow]] system. The idea was there, however we needed a guidance. A teacher that would lead the project. We quickly found out that no Czech teacher is fool enough to try to lead us. Luckily, we knew Adam, a visiting professor not knowing exactly what it takes to lead seven students and their never-ending work. That is why, when Adam agreed, he became the grand father of NetBeans. Without his help we would not have NetBeans, and I could never finish [[TheAPIBook]]. Thanks Adam.

As you may know the roots of NetBeans can be traced to 1995, when seven of us, students of [http://www.mff.cuni.cz/toUTF8.en/ Faculty of Mathematics and Physics] at [[Charles University]] in [[wikipedia::Prague|Prague]] needed to finish a compulsory student project and decided to create a [[wikipedia::Borland_Delphi|Delphi]] for [[wikipedia::XWindow|XWindow]] system. The idea was there, however we needed a guidance. A teacher that would lead the project. We quickly found out that no Czech teacher is fool enough to try to lead us. Luckily, we knew Adam, a visiting professor not knowing exactly what it takes to lead seven students and their never-ending work. That is why, when Adam agreed, he became the grand father of NetBeans. Without his help we would not have NetBeans, and I could never finish [[TheAPIBook]]. Thanks Adam.

When Adam returned back to U.S., he disappeared from our radar for few years. However at the end of last year, he re-appeared on our mailing list and confessed to use [[NetBeans]] IDE. I was really glad to see him and I thought, OK, it would be very nice to get Adam to be a reviewer. He helped start [[NetBeans]] and now he can also review the wisdom we generated over the years. I think it was a great choice to invite Adam. Although he is emotionally attached with the project, he does not know anything about its organization, about its code and about its APIs, as such he can play a perfect role of patient external reviewer. He did that perfectly. I remember getting comments like: "this section is too much NetBeans centric, this one is not generic enough". Based on this advice I rewrote a lot of the text to not mention NetBeans at all, or at least explain that the topic is generic enough. Thanks Adam, for making the content of [[TheAPIBook]] more generally acceptable.

When Adam returned back to U.S., he disappeared from our radar for few years. However at the end of last year, he re-appeared on our mailing list and confessed to use [[NetBeans]] IDE. I was really glad to see him and I thought, OK, it would be very nice to get Adam to be a reviewer. He helped start [[NetBeans]] and now he can also review the wisdom we generated over the years. I think it was a great choice to invite Adam. Although he is emotionally attached with the project, he does not know anything about its organization, about its code and about its APIs, as such he can play a perfect role of patient external reviewer. He did that perfectly. I remember getting comments like: "this section is too much NetBeans centric, this one is not generic enough". Based on this advice I rewrote a lot of the text to not mention NetBeans at all, or at least explain that the topic is generic enough. Thanks Adam, for making the content of [[TheAPIBook]] more generally acceptable.

In the scale of our reviewers, we needed some really skilled Java API designer, moreover one that would not be connected to [[NetBeans]] at all. [[GeertjanWielenga]] recommended Dave, the API design guru behind [http://www.jfugue.org JFugue musical library]. I can hardly imagine someone better playing Dave's role. He acted like real API designer. Skilled, fast, sharp in his reviews and always ready to jump to the gory details of individual code samples. I remember Dave sending comments like ''Common, I do not need you to tell me what is API, I already know it, just show me the real API code!'' Sure, Dave, you designed a lot of APIs, it is easy for you to understand the basics, but we need to get everyone on the same starting line, so please bear with me, you'll get what you want!

In the scale of our reviewers, we needed some really skilled Java API designer, moreover one that would not be connected to [[NetBeans]] at all. [[GeertjanWielenga]] recommended Dave, the API design guru behind [http://www.jfugue.org JFugue musical library]. I can hardly imagine someone better playing Dave's role. He acted like real API designer. Skilled, fast, sharp in his reviews and always ready to jump to the gory details of individual code samples. I remember Dave sending comments like ''Common, I do not need you to tell me what is API, I already know it, just show me the real API code!'' Sure, Dave, you designed a lot of APIs, it is easy for you to understand the basics, but we need to get everyone on the same starting line, so please bear with me, you'll get what you want!

As Dave received more and more chapters, his complains slowly fade away. However, as Dave is typical API designer, they were not replaced by clamours of happiness. For a few weeks I was not really sure whether Dave really liked the book or not. However when we met during JavaOne 2008, he said something like: ''Chapter 18, [[Case Study of Writing the Extensible Visitor Pattern|Extensible Visitor Pattern Case Study]] is really nice summary of all the content of the book, all the advices suddenly emerged and played very nicely together.'' I am glad for these words. I was not really sure if the chapter 18 is not too complex, however since Dave's comment I know it is not. Thanks Dave helping me realize that!

As Dave received more and more chapters, his complains slowly fade away. However, as Dave is typical API designer, they were not replaced by clamours of happiness. For a few weeks I was not really sure whether Dave really liked the book or not. However when we met during [[JavaOne]] 2008, he said something like: ''Chapter 18, [[Case Study of Writing the Extensible Visitor Pattern|Extensible Visitor Pattern Case Study]] is really nice summary of all the content of the book, all the advices suddenly emerged and played very nicely together.'' I am glad for these words. I was not really sure if the chapter 18 is not too complex, however since Dave's comment I know it is not. Thanks Dave helping me realize that!

=== [[MartinRinard]] ===

=== [[MartinRinard]] ===

=== [[User:RichUnger|Rich Unger]] ===

=== [[User:RichUnger|Rich Unger]] ===

[[User:RichUnger|Rich]] is long time [[NetBeans Platform]] user and as such he had to go through all the suffering associated with using [[NetBeans]] APIs. He started to use [[NetBeans]] platform in version 3.2 or so, which was possible, but hard. In fact there was no support from the [[NetBeans]] IDE for developers like [[User:RichUnger|Rich]]. Together we tried to fulfill the need for this by giving frequent presentations describing the necessary tricks when using the [[NetBeans Platform]]. These presentations stop being necessary when we created new wizards that remove the need to understand all these tricks. This adventure helped me realize that ''the wizard is the best API'' as mentioned in Chapter 9, [[Keep Testability In Mind]]. Thanks Rich talking this wisdom out of me.

[[User:RichUnger|Rich]] is long time [[NetBeans Platform]] user and as such he had to go through all the suffering associated with using [[NetBeans]] APIs. He started to use [[NetBeans]] platform in version 3.2 or so, which was possible, but hard. In fact there was no support from the [[NetBeans]] IDE for developers like [[User:RichUnger|Rich]]. Together we tried to fulfill the need for this by giving frequent presentations describing the necessary tricks when using the [[NetBeans Platform]]. These presentations stop being necessary when we created new wizards that remove the need to understand all these tricks. This adventure helped me realize that ''the wizard is the best API'' as mentioned in Chapter 9, [[Keep Testability In Mind]]. Thanks Rich for talking this wisdom out of me.

Rich also was the first external [[NetBeans]] developer who tried to contribute to our APIs via the [[APIReview]] process, as described in Chapter 16, [[Teamwork]]. After reading the chapter, Rich told me that he liked the secret behind the history of the [[APIReview]] process invention. Rich also asked whether I got some punishment for revealing the secret. Well, I did not, as nobody affected read the book yet, but I'll keep you posted. Thanks Rich for practising the [[APIReview]]s with us.

Rich also was the first external [[NetBeans]] developer who tried to contribute to our APIs via the [[APIReview]] process, as described in Chapter 16, [[Teamwork]]. After reading the chapter, Rich told me that he liked the secret behind the history of the [[APIReview]] process invention. Rich also asked whether I got some punishment for revealing the secret. Well, I did not, as nobody affected read the book yet, but I'll keep you posted. Thanks Rich for practising the [[APIReview]]s with us.

Martin is the inventor of term [[Cluelessness]], at least in my eyes. When I saw [http://www.oopsla.org/oopsla2006/index.php?title=Martin_Rinard's_Talk his presentation] at OOPSLA 2006, I was amazed and shocked. His advices were so ugly, but so true, that I could not stop thinking about them. I was thinking about relation between reliability and [[Cluelessness]], about importance of testing and also about the role APIs play in the attempt to increase [[Cluelessness]] while improving quality of our applications. At that time I realized that [[Cluelessness]] is great meta principle that allows us to evaluate whether an advice is good or not. If something allows people to ''achieve more while knowing less'', then the thing is good. Thanks Martin for inventing such meta principle!

Martin is the inventor of term [[Cluelessness]], at least in my eyes. When I saw [http://www.oopsla.org/oopsla2006/index.php?title=Martin_Rinard's_Talk his presentation] at OOPSLA 2006, I was amazed and shocked. His advices were so ugly, but so true, that I could not stop thinking about them. I was thinking about relation between reliability and [[Cluelessness]], about importance of testing and also about the role APIs play in the attempt to increase [[Cluelessness]] while improving quality of our applications. At that time I realized that [[Cluelessness]] is great meta principle that allows us to evaluate whether an advice is good or not. If something allows people to ''achieve more while knowing less'', then the thing is good. Thanks Martin for inventing such meta principle!

An interesting moment occurred when Martin finished reading first half of the book and said: ''Your book talks about [[Cluelessness]], but it cannot be read in clueless mode itself!'' A perfect observation, which I knew somewhere in my brain, but I did not realize it until Martin revealed it. Yes, I love [[Cluelessness]], I want to see [[Cluelessness]] everywhere in software development. However when thinking about it and describing it, I automatically applied the scientific methods I learn at European Universities: Theory first, practical applications later. As a result this book does not teach how to design APIs cluelessly, with as little understanding as possible. Instead it sees properly designed APIs as a tool to help other developers to practice [[Cluelessness]]. However the API designers themselves need to think about what they do quite a lot.

An interesting moment occurred when Martin finished reading first half of the book and said: ''Your book talks about [[Cluelessness]], but it cannot be read in clueless mode itself!'' A perfect observation, which I knew somewhere in my brain, but I did not realize it until Martin revealed it. Yes, I love [[Cluelessness]], I want to see [[Cluelessness]] everywhere in software development. However when thinking about it and describing it, I automatically applied the like to be scientific methods I learned at European Universities: Theory first, practical applications later. As a result this book does not teach how to design APIs cluelessly, with as little understanding as possible. Instead it sees properly designed APIs as a tool to help other developers to practice [[Cluelessness]]. However the API designers themselves need to think about what they do quite a lot.

Martin, as the inventor and great propagator of [[Cluelessness]] naturally expected this book to be written in clueless mode, for people in hurry, without need of deeper understanding. This resulted in false expectations, which could not be satisfied by [[TheAPIBook]]. I'd be glad to advice to design APIs cluelessly, however I still do not know how to do it properly. That is why I at least tried to set the reader expectations right as soon as possible and warn and straight things up. Thanks Martin for pointing this out, hopefully the changes I've made according to your suggestions will prevent wider disappointments due to readers' false expectations.

Martin, as the inventor and great propagator of [[Cluelessness]] naturally expected this book to be written in clueless mode, for people in hurry, without need of deeper understanding. This resulted in false expectations, which could not be satisfied by [[TheAPIBook]]. I'd be glad to advice to design APIs cluelessly, however I still do not know how to do it properly. That is why I at least tried to set the reader expectations right as soon as possible and warn and straight things up. Thanks Martin for pointing this out, hopefully the changes I've made according to your suggestions will prevent wider disappointments due to readers' false expectations.

=== [[AdamDingle]] ===

=== [[AdamDingle]] ===

As you may know the roots of NetBeans can be traced to 1995, when seven of us, students of [http://www.mff.cuni.cz/toUTF8.en/ Faculty of Mathematics and Physics] at [http://www.cuni.cz Charles University] in [[wikipedia::Prague|Prague]] needed to finish a compulsory student project and decided to create a [[wikipedia::Borland_Delphi|Delphi]] for [[wikipedia::XWindow|XWindow]] system. The idea was there, however we needed a guidance. A teacher that would lead the project. We quickly found out that no Czech teacher is fool enough to try to lead such project. Luckily, we knew Adam, a visiting professor not knowing exactly what it takes to lead seven students and their project. That is why, when Adam agreed, he became the grand father of NetBeans. Without his help we would not have NetBeans, and I could never finish [[TheAPIBook]]. Thanks Adam.

As you may know the roots of NetBeans can be traced to 1995, when seven of us, students of [http://www.mff.cuni.cz/toUTF8.en/ Faculty of Mathematics and Physics] at [http://www.cuni.cz Charles University] in [[wikipedia::Prague|Prague]] needed to finish a compulsory student project and decided to create a [[wikipedia::Borland_Delphi|Delphi]] for [[wikipedia::XWindow|XWindow]] system. The idea was there, however we needed a guidance. A teacher that would lead the project. We quickly found out that no Czech teacher is fool enough to try to lead us. Luckily, we knew Adam, a visiting professor not knowing exactly what it takes to lead seven students and their never-ending work. That is why, when Adam agreed, he became the grand father of NetBeans. Without his help we would not have NetBeans, and I could never finish [[TheAPIBook]]. Thanks Adam.

When Adam returned back to U.S., he disappeared from our radar for few years. However at the end of last year, he re-appeared on our mailing list and confessed to use [[NetBeans]] IDE. I was really glad to see him and I thought, OK, it would be very nice to get Adam to be a reviewer. He helped start [[NetBeans]] and now he can also review the wisdom we generated over the years. I think it was a great choice to invite Adam. Although he is emotionally attached with the project, he does not know anything about its organization, about its code and about its APIs, as such he can play a perfect role of patient external reviewer. He did that perfectly. I remember getting comments like: "this section is too much NetBeans centric, this one is not generic enough". Based on this advice I rewrote a lot of the text to not mention NetBeans at all, or at least explain that the topic is generic enough. Thanks Adam, for making the content of [[TheAPIBook]] more generally acceptable.

When Adam returned back to U.S., he disappeared from our radar for few years. However at the end of last year, he re-appeared on our mailing list and confessed to use [[NetBeans]] IDE. I was really glad to see him and I thought, OK, it would be very nice to get Adam to be a reviewer. He helped start [[NetBeans]] and now he can also review the wisdom we generated over the years. I think it was a great choice to invite Adam. Although he is emotionally attached with the project, he does not know anything about its organization, about its code and about its APIs, as such he can play a perfect role of patient external reviewer. He did that perfectly. I remember getting comments like: "this section is too much NetBeans centric, this one is not generic enough". Based on this advice I rewrote a lot of the text to not mention NetBeans at all, or at least explain that the topic is generic enough. Thanks Adam, for making the content of [[TheAPIBook]] more generally acceptable.

=== [[User:RichUnger|Rich Unger]] ===

=== [[User:RichUnger|Rich Unger]] ===

[[User:RichUnger|Rich]] is long time [[NetBeans Platform]] user and as such he had to go through all the suffering associated with using [[NetBeans]] APIs. He started to use [[NetBeans]] platform in version 3.5 or so, which was possible, but hard. In fact there was no support from the [[NetBeans]] IDE for developers like [[User:RichUnger|Rich]]. Together we tried to fulfil the need for this by giving frequent presentations describing the necessary tricks when using the [[NetBeans Platform]]. These presentations stop being necessary when we created new wizards that remove the need to understand all these tricks. This adventure helped me realize that ''the wizard is the best API'' as mentioned in Chapter 9, [[Keep Testability In Mind]]. Thanks Rich talking this wisdom out of me.

[[User:RichUnger|Rich]] is long time [[NetBeans Platform]] user and as such he had to go through all the suffering associated with using [[NetBeans]] APIs. He started to use [[NetBeans]] platform in version 3.2 or so, which was possible, but hard. In fact there was no support from the [[NetBeans]] IDE for developers like [[User:RichUnger|Rich]]. Together we tried to fulfill the need for this by giving frequent presentations describing the necessary tricks when using the [[NetBeans Platform]]. These presentations stop being necessary when we created new wizards that remove the need to understand all these tricks. This adventure helped me realize that ''the wizard is the best API'' as mentioned in Chapter 9, [[Keep Testability In Mind]]. Thanks Rich talking this wisdom out of me.

Rich also was the first external [[NetBeans]] developer who tried to contribute to our APIs via the [[APIReview]] process, as described in Chapter 16, [[Teamwork]]. After reading the chapter, Rich told me that he liked the secret behind the history of the [[APIReview]] process invention. Rich also asked whether I got some punishment for revealing the secret. Well, I did not, as nobody affected read the book yet, but I'll keep you posted. Thanks Rich for practising the [[APIReview]]s with us.

Rich also was the first external [[NetBeans]] developer who tried to contribute to our APIs via the [[APIReview]] process, as described in Chapter 16, [[Teamwork]]. After reading the chapter, Rich told me that he liked the secret behind the history of the [[APIReview]] process invention. Rich also asked whether I got some punishment for revealing the secret. Well, I did not, as nobody affected read the book yet, but I'll keep you posted. Thanks Rich for practising the [[APIReview]]s with us.

However, Jesse did not stop on the level of documenting my APIs, he also started to write his own. In fact he is architect of quite a big portion of [[NetBeans]] IDE. Jesse's adventures during the API design motivated many observations and conclusions present in [[TheAPIBook]]. Whenever we argued about APIs with each other or with other persons, I've taken notes, added a paragraph or two. Sometimes I even directly copied Jesse's email into the raw book's material. For example the ''Do Not Put Setters Where They Do Not Belong'' in Chapter 5, [[Do Not Expose More Than You Want]] is heavily based on one such email conversation.

However, Jesse did not stop on the level of documenting my APIs, he also started to write his own. In fact he is architect of quite a big portion of [[NetBeans]] IDE. Jesse's adventures during the API design motivated many observations and conclusions present in [[TheAPIBook]]. Whenever we argued about APIs with each other or with other persons, I've taken notes, added a paragraph or two. Sometimes I even directly copied Jesse's email into the raw book's material. For example the ''Do Not Put Setters Where They Do Not Belong'' in Chapter 5, [[Do Not Expose More Than You Want]] is heavily based on one such email conversation.

Jesse speaks a special kind of English, at least from my point of view. It is always pleasure to read it. That is why I have always found it a sad that Jesse keeps all his notes in emails and does not publish them for everyone to see them. That is why I am very happy about Jesse's decision to join [[Blogs:JesseGlick|the API Design blogosphere]]. Thanks Jesse for all your past and future notes.

Jesse speaks a special kind of English, at least from my point of view. It is always pleasure to read it. That is why I have always found it a sad that Jesse keeps all his notes in emails and does not publish them for everyone to see. That is why I am very happy about Jesse's decision to join [[Blogs:JesseGlick|the API Design blogosphere]]. Thanks Jesse for all your past and future notes.

However, Jesse did not stop on the level of documenting my APIs, he also started to write his own. In fact he is architect of quite a big portion of [[NetBeans]] IDE. Jesse's adventures during the API design motivated many observations and conclusions present in [[TheAPIBook]]. Whenever we argued about APIs with each other or with other persons, I've taken notes, added a paragraph or two. Sometimes I even directly copied Jesse's email into the raw book's material. For example the ''Do Not Put Setters Where They Do Not Belong'' in Chapter 5, [[Do Not Expose More Than You Want]] is heavily based on one such email conversation.

However, Jesse did not stop on the level of documenting my APIs, he also started to write his own. In fact he is architect of quite a big portion of [[NetBeans]] IDE. Jesse's adventures during the API design motivated many observations and conclusions present in [[TheAPIBook]]. Whenever we argued about APIs with each other or with other persons, I've taken notes, added a paragraph or two. Sometimes I even directly copied Jesse's email into the raw book's material. For example the ''Do Not Put Setters Where They Do Not Belong'' in Chapter 5, [[Do Not Expose More Than You Want]] is heavily based on one such email conversation.

Jesse speaks a special kind of English, at least from my point of view. It is always pleasure to read it. That is why I have always found it a sad that Jesse keeps all his notes in emails and do not publish them for everyone to see them. That is why I am very happy about Jesse's decision to join [[Blogs:JesseGlick|the API Design blogosphere]]. Thanks Jesse for all your past and future notes.

Jesse speaks a special kind of English, at least from my point of view. It is always pleasure to read it. That is why I have always found it a sad that Jesse keeps all his notes in emails and does not publish them for everyone to see them. That is why I am very happy about Jesse's decision to join [[Blogs:JesseGlick|the API Design blogosphere]]. Thanks Jesse for all your past and future notes.

=== [[User:RichUnger|Rich Unger]] ===

=== [[User:RichUnger|Rich Unger]] ===

[[User:RichUnger|Rich]] is long time [[NetBeans Platform]] user and as such he had to go through all the suffering associated with using [[NetBeans]] APIs. He started to use [[NetBeans]] platform in version 3.5 or so, which was possible, but hard. In fact there was no support from the [[NetBeans]] IDE for developers like [[User:RichUnger|Rich]] and we tried to fulfil the need for this by giving frequent presentations describing the necessary tricks when using the [[NetBeans Platform]]. These presentations stop being necessary when we created new wizards that remove the need to understand all these tricks. This adventure helped me realize that ''the wizard is the best API'' as mentioned in Chapter 9, [[Keep Testability In Mind]]. Thanks Rich talking this wisdom out of me.

[[User:RichUnger|Rich]] is long time [[NetBeans Platform]] user and as such he had to go through all the suffering associated with using [[NetBeans]] APIs. He started to use [[NetBeans]] platform in version 3.5 or so, which was possible, but hard. In fact there was no support from the [[NetBeans]] IDE for developers like [[User:RichUnger|Rich]]. Together we tried to fulfil the need for this by giving frequent presentations describing the necessary tricks when using the [[NetBeans Platform]]. These presentations stop being necessary when we created new wizards that remove the need to understand all these tricks. This adventure helped me realize that ''the wizard is the best API'' as mentioned in Chapter 9, [[Keep Testability In Mind]]. Thanks Rich talking this wisdom out of me.

Rich also was the first external [[NetBeans]] developer who tried to contribute to our APIs via the [[APIReview]] process, as described in Chapter 16, [[Teamwork]]. After reading the chapter, Rich told me that he liked the secret behind the history of the [[APIReview]] process. Rich also asked whether I got some punishment for revealing the secret. Well, I did not, as nobody affected read the book yet, but I'll keep you posted. Thanks Rich for practising the [[APIReview]]s with us.

Rich also was the first external [[NetBeans]] developer who tried to contribute to our APIs via the [[APIReview]] process, as described in Chapter 16, [[Teamwork]]. After reading the chapter, Rich told me that he liked the secret behind the history of the [[APIReview]] process invention. Rich also asked whether I got some punishment for revealing the secret. Well, I did not, as nobody affected read the book yet, but I'll keep you posted. Thanks Rich for practising the [[APIReview]]s with us.

=== [[TomWheeler]] ===

=== [[TomWheeler]] ===

=== [[MartinRinard]] ===

=== [[MartinRinard]] ===

Martin is the inventor of term [[Cluelessness]], at least in my eyes. When I saw [[http://www.oopsla.org/oopsla2006/index.php?title=Martin_Rinard's_Talk his presentation] at OOPSLA 2006, I was amazed and shocked. His advices were so ugly, but so true, that I could not stop thinking about them. I was thinking about relation between reliability and [[Cluelessness]], about importance of testing and also about the role APIs play in the attempt to increase [[Cluelessness]] while improving quality of our applications. At that time I realized that [[Cluelessness]] is great meta principle that allows us to evaluate whether an advice is good or not. If something allows people to ''achieve more while knowing less'', then the thing is good. Thanks Martin for inventing such meta principle!

Martin is the inventor of term [[Cluelessness]], at least in my eyes. When I saw [http://www.oopsla.org/oopsla2006/index.php?title=Martin_Rinard's_Talk his presentation] at OOPSLA 2006, I was amazed and shocked. His advices were so ugly, but so true, that I could not stop thinking about them. I was thinking about relation between reliability and [[Cluelessness]], about importance of testing and also about the role APIs play in the attempt to increase [[Cluelessness]] while improving quality of our applications. At that time I realized that [[Cluelessness]] is great meta principle that allows us to evaluate whether an advice is good or not. If something allows people to ''achieve more while knowing less'', then the thing is good. Thanks Martin for inventing such meta principle!

An interesting moment occurred when Martin finished reading first half of the book and said: ''Your book talks about [[Cluelessness]], but it cannot be read in clueless mode itself!'' A perfect observation, which I knew somewhere in my brain, but I did not realize it until Martin revealed it. Yes, I love [[Cluelessness]], I want to see [[Cluelessness]] everywhere in software development. However when thinking about it and describing it, I automatically applied the scientific methods I learn at European Universities: Theory first, practical applications later. As a result this book does not teach how to design APIs cluelessly, with as little understanding as possible. Instead it sees properly designed APIs as a tool to help other developers to practice [[Cluelessness]]. However the API designers themselves need to think about what they do quite a lot.

An interesting moment occurred when Martin finished reading first half of the book and said: ''Your book talks about [[Cluelessness]], but it cannot be read in clueless mode itself!'' A perfect observation, which I knew somewhere in my brain, but I did not realize it until Martin revealed it. Yes, I love [[Cluelessness]], I want to see [[Cluelessness]] everywhere in software development. However when thinking about it and describing it, I automatically applied the scientific methods I learn at European Universities: Theory first, practical applications later. As a result this book does not teach how to design APIs cluelessly, with as little understanding as possible. Instead it sees properly designed APIs as a tool to help other developers to practice [[Cluelessness]]. However the API designers themselves need to think about what they do quite a lot.