Book Review: The Pragmatic Programmer: From Journeyman to Master

This is a nice book on the now common-place wisdom of programming or software engineering discipline. As a software engineer for 13 years I found it not so useful but nevertheless good in reviewing what are today well understood and common practices in the industry like the DRY principle (Don’t repeat yourself), Fix the broken windows today, refactoring etc. I highlighted some points as I was reading this book and I am reproducing them below (more for myself to be able to review these once in a while):

1. Every day, work to refine the skills you have and to add new tools to your repertoire.
2. The greatest of all weaknesses is the fear of appearing weak. • J. B. Bossuet, Politics from Holy Writ, 1709
3. Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered.
4. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.
5. It's often the accumulation of small things that breaks morale and teams.
6. Striving to better, oft we mar what's well. • King Lear 1.4
7. As Ed Yourdon described in an article in IEEE Software [You95], you can discipline yourself to write software that's good enough—good enough for your users, for future maintainers, for your own peace of mind. You'll find that you are more productive and your users are happier. And you may well find that your programs are actually better for their shorter incubation.
8. We are simply advocating that users be given an opportunity to participate in the process of deciding when what you've produced is good enough.
9. Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution.
10. Don't spoil a perfectly good program by over-embellishment and over-refinement. Move on, and let your code stand in its own right for a while. It may not be perfect. Don't worry: it could never be perfect.
11. An investment in knowledge always pays the best interest. • Benjamin Franklin
12. Learn at least one new language every year.
13. Read a technical book each quarter.
14. Once you're in the habit, read a book a month.
15. After you've mastered the technologies you're currently using, branch out and study some that don't relate to your project.
16. Read nontechnical books, too.
17. Take classes.
18. Participate in local user groups.
19. Start learning a new language this week.
20. Start reading a new book
21. Get out and talk technology with people who aren't involved in your current project, or who don't work for the same company. Network in your company cafeteria, or maybe seek out fellow enthusiasts at a local user's group meeting.
22. I believe that it is better to be looked over than it is to be overlooked.
23. You're communicating only if you're conveying information.
24. Encourage people to talk by asking questions, or have them summarize what you tell them.
25. Always respond to e-mails and voice mails, even if the response is simply "I'll get back to you later." Keeping people informed makes them far more forgiving of the occasional slip, and makes them feel that you haven't forgotten them.
26. Where possible, always use accessor functions to read and write the attributes of objects.
27. Two or more things are orthogonal if changes in one do not affect any of the others.
28. Our preference is to start by separating infrastructure from application. Each major infrastructure component (database, communications interface, middleware layer, and so on) gets its own subteam. Each obvious division of application functionality is similarly divided. Then we look at the people we have (or plan to have) and adjust the groupings accordingly.
29. There is an easy test for orthogonal design. Once you have your components mapped out, ask yourself: If I dramatically change the requirements behind a particular function, how many modules are affected? In an orthogonal system, the answer should be "one."
30. Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system.
31. Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned
32. We think it's a great idea to record your estimates so you can see how close you were.
33. Iterate the Schedule with the Code
34. To ensure that we never lose any of our precious work, we should always use a Source Code Control system—even for things such as our personal address book!
35. you can't be a great programmer until you become highly skilled at Debugging.
36. Keep Knowledge in Plain Text
37. Clearly the list could go on. The shell commands may be obscure or terse, but they are powerful and concise. And, because shell commands can be combined into script files (or command files under Windows systems), you can build sequences of commands to automate things you do often. Tip 21 Use the Power of Command Shells.
38. Ideally, the shell you use should have keybindings that match the ones used by your editor. Bash, for instance, supports both vi and emacs keybindings.
39. Choose an editor, know it thoroughly, and use it for all editing tasks.
40. As one of the new languages you are going to learn this year, learn the language your editor uses. For anything you find yourself doing repeatedly, develop a set of macros (or equivalent) to handle.
41. Try to accomplish any given editing task in as few keystrokes as possible.
42. Progress, far from consisting in change, depends on retentiveness. Those who cannot remember the past are condemned to repeat it. • George Santayana, Life of Reason
43. sounds simple, but in explaining the problem to another person you must explicitly state things that you may take for granted when going through the code
44. Debugging Checklist -
1. Is the problem being reported a direct result of the underlying bug, or merely a symptom?
2. Is the bug really in the compiler?
3. Is it in the OS? Or is it in your code?
4. If you explained this problem in detail to a coworker, what would you say?
5. If the suspect code passes its unit tests, are the tests complete enough?
6. What happens if you run the unit test with this data?
7. Do the conditions that caused this bug exist anywhere else in the system?
45. Learn a Text Manipulation Language like perl.
46. Good fences make good neighbors. • Robert Frost, "Mending Wall"
47. Organize your code into cells (modules) and limit the interaction between them. If one module then gets compromised and has to be replaced, the other modules should be able to carry on.
48. Traversing relationships between objects directly can quickly lead to a combinatorial explosion[1] of dependency relationships.
49. We want to configure and drive the application via metadata as much as possible. Our goal is to think declaratively
50. We need to allow for concurrency[3] and to think about decoupling any time or order dependencies. In doing so, we can gain flexibility and reduce any time-based dependencies in many areas of development: workflow analysis, architecture, design, and deployment.
51. All functions related to the fulfillment of business logic fall into the category of core concerns.
52. You can support multiple views of the same data model. You can use common viewers on many different data models. You can even support multiple controllers to provide nontraditional input mechanisms.
53. Model. The abstract data model representing the target object. The model has no direct knowledge of any views or controllers. View. A way to interpret the model. It subscribes to changes in the model and logical events from the controller. Controller. A way to control the view and provide the model with new data. It publishes events to both the model and the view. Let's look at a nongraphical
54. Each model may have many viewers, and one viewer may work with multiple models.
55. Use Blackboards to Coordinate Workflow
56. Network monitoring tool. The system gathers performance statistics and collects trouble reports. You'd like to implement some agents to use this information to look for trouble in the system.
57. Sometimes we come up with fairly complex O() functions, but because the highest-order term will dominate the value as n increases, the convention is to remove all low-order terms, and not to bother showing any constant multiplying factors. O(n2/2+ 3n) is the same as O(n2/2), which is equivalent to O(n2).
58. Rewriting, reworking, and re-architecting code is collectively known as refactoring.
59. Workflow can be captured with UML activity diagrams, and conceptual-level class diagrams can sometimes be useful for modeling the business at hand.
60. Teams as a whole should not tolerate broken windows—those small imperfections that no one fixes. The team must take responsibility for the quality of the product, supporting developers who understand the no broken windows philosophy.
61. Make sure everyone actively monitors the environment for changes. Maybe appoint a chief water tester. Have this person check constantly for increased scope, decreased time scales, additional features, new environments—anything that wasn't in the original agreement.
62. Divide your people into small teams, each responsible for a particular functional aspect of the final system. Let the teams organize themselves internally, building on individual strengths as they can.
63. The project needs at least two "heads"—one technical, the other administrative. The technical head sets the development philosophy and style, assigns responsibilities to teams, and arbitrates the inevitable "discussions" between people. The technical head also looks constantly at the big picture, trying to find any unnecessary commonality between teams that could reduce the orthogonality of the overall effort. The administrative head, or project manager, schedules the resources that the teams need, monitors and reports on progress, and helps decide priorities in terms of business needs.
64. To ensure that things get automated, appoint one or more team members as tool builders to construct and deploy the tools that automate the project drudgery. Have them produce makefiles, shell scripts, editor templates, utility programs, and the like.
65. Remember that teams are made up of individuals. Give each member the ability to shine in his or her own way. Give them just enough structure to support them and to ensure that the project delivers against its requirements.
66. Civilization advances by extending the number of important operations we can perform without thinking. • Alfred North Whitehead

Book Review: MY INVENTIONS: The Autobiography of Nikola Tesla

This book by Nikola Tesla is a quick read and does not go very detailed into his inventions like some biographies on Tesla do. It still has some lessons that Tesla conveys throughout the book on what he thought was different than normal in him and a one very unique thing that he says towards the end of the book is – when someone does bad to him then almost always he finds that person starts to pay for his deeds and he thought as if there is a mental influence one can have on others lives which he experienced but could not prove it to others but was very convinced that it was his mind that was causing his tormentor sufferings. Following are some things I remember:

1. At one point Tesla says: When natural inclination develops into a passionate desire, one advances towards his goal in seven-league boots.
2. He had been through near death experiences several times in his life.
3. He had very sharp hearing capacity – but because of this he was not able to bear even sounds which may appear normal for most people.
4. He was very inspired by reading works of Mark Twain once when he was very sick and bed-ridden. When he came to America and happened to befriend Mr Clemens himself who Tesla describes to be a man of very jovial nature and tells the author that his books were the reason he could recover from his sickness as they gave him the strength to live then at hearing this Mark Twain (Mr Clemens) started to cry like a child and said it was the greatest reward for him.
5. Of note, Tesla does not say anything about Edison (or not that I remember now so even if he did it was only done in the passing).

A good quick read and an inspiring one at that. Highly recommended.