The document contains a collection of short passages on various topics for programmers. A few key passages are summarized below:
1. "Do Lots of Deliberate Practice" emphasizes the importance of repetition and practicing to improve skills through deliberate practice, not just completing tasks.
2. "Learn to Estimate" distinguishes estimates, which are approximate, from targets and commitments, which are more precise expectations of delivery.
3. "Know Your Next Commit" highlights the importance of having a clear understanding of what code will be committed and when, rather than just focusing on task details.
This document discusses the Lean UX process for building apps that users love. It emphasizes starting with user research to understand problems, rapidly prototyping solutions, and getting frequent feedback to iterate designs. The process involves creating personas, testing assumptions with users, prioritizing problems, making paper/digital prototypes, getting early feedback, and continuously improving through multiple iterations. The goal is to build something that solves the right problems in a way users enjoy.
The document discusses various topics related to analysis and design processes including front-end analysis, analysis paralysis, evaluation models, performance analysis quadrants, agile development principles, flashcard software options, and open source development practices. It provides resources and information on needs assessment, instructional design, project management, and software development.
Deep Distillation from Natural Language TextNaveen Ashish
This document discusses deep distillation from text, which involves extracting more complex information than just entities and sentiment. It describes extracting expressions, entities, aspects, and contextual sentiment. The approach uses natural language processing, machine learning classifiers trained on engineered features, and leveraging existing knowledge sources and ontologies. Case studies show deep distillation applied to health informatics, retail surveys, and risk assessment from biomedical literature. The method aims to provide more actionable insights from unstructured text data.
The document discusses several principles and best practices for pragmatic programming. It discusses avoiding duplication by eliminating imposed, inadvertent, impatient, and interdeveloper duplication. It also discusses the principles of orthogonality and reversibility. Orthogonality refers to decoupling unrelated things to increase productivity and reduce risk. Reversibility means designing software in a way that allows for changes in requirements, users, and hardware over time.
This document contains titles and authors of various articles on topics related to social media, business, marketing, mobile internet, and databases. Some of the articles include "Social Media Around the World" by Steven Van, "10 Business Models that Rocked 2010" by Board of Innovation, "Top 10 Mobile Internet Trends (Feb 2011)" by Kleiner Perkins, and "NoSQL Databases: Why, What and When" by Lorenzo Alberton. The document seems to be compiling a list of resources across different subject areas within the technology and business fields.
Let's turn the table. Suppose your goal is to deliberately create buggy programs in C and C++ with serious security vulnerabilities that can be "easily" exploited. Then you need to know about things like stack smashing, shellcode, arc injection, return-oriented programming. You also need to know about annoying protection mechanisms such as address space layout randomization, stack canaries, data execution prevention, and more. These slides will teach you the basics of how to deliberately write insecure programs in C and C++.
A PDF version of the slides can be downloaded from my homepage: http://olvemaudal.com/talks
Here is a video recording of me presenting these slides at NDC 2014: http://vimeo.com/channels/ndc2014/97505677
Enjoy!
Sometimes you see code that is perfectly OK according to the definition of the language, but which is flawed because it breaks too many established idioms and conventions. On the other hand, a solid piece of code is something that looks like it is written by an experienced person who cares about professionalism in programming.
A presentation at Norwegian Developer Conference 2010
This document discusses the Lean UX process for building apps that users love. It emphasizes starting with user research to understand problems, rapidly prototyping solutions, and getting frequent feedback to iterate designs. The process involves creating personas, testing assumptions with users, prioritizing problems, making paper/digital prototypes, getting early feedback, and continuously improving through multiple iterations. The goal is to build something that solves the right problems in a way users enjoy.
The document discusses various topics related to analysis and design processes including front-end analysis, analysis paralysis, evaluation models, performance analysis quadrants, agile development principles, flashcard software options, and open source development practices. It provides resources and information on needs assessment, instructional design, project management, and software development.
Deep Distillation from Natural Language TextNaveen Ashish
This document discusses deep distillation from text, which involves extracting more complex information than just entities and sentiment. It describes extracting expressions, entities, aspects, and contextual sentiment. The approach uses natural language processing, machine learning classifiers trained on engineered features, and leveraging existing knowledge sources and ontologies. Case studies show deep distillation applied to health informatics, retail surveys, and risk assessment from biomedical literature. The method aims to provide more actionable insights from unstructured text data.
The document discusses several principles and best practices for pragmatic programming. It discusses avoiding duplication by eliminating imposed, inadvertent, impatient, and interdeveloper duplication. It also discusses the principles of orthogonality and reversibility. Orthogonality refers to decoupling unrelated things to increase productivity and reduce risk. Reversibility means designing software in a way that allows for changes in requirements, users, and hardware over time.
This document contains titles and authors of various articles on topics related to social media, business, marketing, mobile internet, and databases. Some of the articles include "Social Media Around the World" by Steven Van, "10 Business Models that Rocked 2010" by Board of Innovation, "Top 10 Mobile Internet Trends (Feb 2011)" by Kleiner Perkins, and "NoSQL Databases: Why, What and When" by Lorenzo Alberton. The document seems to be compiling a list of resources across different subject areas within the technology and business fields.
Let's turn the table. Suppose your goal is to deliberately create buggy programs in C and C++ with serious security vulnerabilities that can be "easily" exploited. Then you need to know about things like stack smashing, shellcode, arc injection, return-oriented programming. You also need to know about annoying protection mechanisms such as address space layout randomization, stack canaries, data execution prevention, and more. These slides will teach you the basics of how to deliberately write insecure programs in C and C++.
A PDF version of the slides can be downloaded from my homepage: http://olvemaudal.com/talks
Here is a video recording of me presenting these slides at NDC 2014: http://vimeo.com/channels/ndc2014/97505677
Enjoy!
Sometimes you see code that is perfectly OK according to the definition of the language, but which is flawed because it breaks too many established idioms and conventions. On the other hand, a solid piece of code is something that looks like it is written by an experienced person who cares about professionalism in programming.
A presentation at Norwegian Developer Conference 2010
This document provides an overview of pair programming and discusses its benefits. It defines pair programming as two developers working together at one computer, with one typing code as the "driver" and the other reviewing the work and providing feedback as the "navigator". Research has found that pair programming can result in 15% fewer bugs and slightly better design quality compared to solo work. Benefits include improved learning, quality, focus, motivation and morale. The document also covers challenges, tips, and different pairing patterns like driver-navigator and ping-pong pairing.
UCD / IxD Introduction - User centric design, interaction designsdavis6b
This document provides an introduction to user-centric design (UCD) and interaction design (IxD) principles for building software. It discusses how UCD tools like personas, goals, and interaction loops can help design coherent experiences and increase agility, sanity and quality. While earlier software was system-centric, the focus is now on designing intuitive experiences through iterative collaboration using UCD and pairing it with Agile development methods.
This document discusses various techniques for rapid application testing (RAT) such as unit testing, integration testing, smoke testing, system testing, regression testing, performance testing, and test-driven development. It emphasizes automating test plans and test execution to allow tests to be run multiple times for little additional cost. The goal of testing is to balance cost and risk by reusing automated tests that are fast and good predictors of issues while throwing more tests at critical areas.
How Functional Programming Made Me A Better DeveloperCameron Presley
The document discusses how learning functional programming improved the author's skills as a developer. It describes their journey learning F# by porting projects like a screenshot tool and card games. This helped them think more about pure functions, immutable data, and leveraging LINQ. It influenced how they write more testable code through interfaces and by avoiding null values. The author now considers types of components like boundaries, business rules, and workflows when building software. Overall, learning functional programming was challenging but improved their ability to design maintainable and testable systems.
The document discusses anti-patterns and worst practices in software development. Some examples covered include static cling pattern, flags over objects, premature optimization, copy-paste-compile, and reinventing the wheel. It also shares lessons learned from experiences, such as being mindful of date times across time zones, avoiding building SQL from untrusted inputs, and not being too cute with test data. Overall, the document aims to help developers learn from the mistakes of others and adopt better practices.
The document discusses essential skills that programmers need versus accidental skills. Essential skills are hard to acquire but long-lasting, including things like managing complexity, writing readable code, and limiting bugs. These skills separate good programmers from bad. Accidental skills like knowledge of a specific programming language are easier to obtain but have shorter usefulness. The document advocates spending time on design, planning, unit testing, discussing solutions with others, and considering alternative solutions rather than just focusing on writing code. Developing essential skills through these practices can help programmers continuously learn and improve over the course of their careers.
Michael Losee grew up in Layton, Utah with 6 sisters. He enjoys video games, reading fantasy novels, and building custom computers. He has a Bachelor's degree in Computer Science from Weber State University. Professionally, he has 5 years of experience as a Lead Systems Analyst for the Defense Logistics Agency and 2 years as a Security Consultant. He is currently working to help paralyzed people learn to walk again and pursues coding as a hobby and potential career.
Three coding experts discuss the importance of readability in code. They emphasize:
1. Code should be written for human readers, with descriptive variable and function names, proper indentation and formatting, and comments explaining purpose not just restating code.
2. Readable code is more likely to be correct and easier to maintain than code written only for computers. Formatting, style, and structure help convey meaning to human readers.
3. Assertions, comments, and documentation help future readers understand code by stating assumptions and intended purpose, not just surface behavior. Readable code supports understanding problem requirements in addition to technical solution.
Agile Methodologies And Extreme Programming - Svetlin NakovSvetlin Nakov
1. Agile development and Extreme Programming (XP) are methodologies that focus on iterative development, collaboration, and adaptability.
2. XP consists of 12 key practices including simple design, test-driven development, pair programming, and small releases. It aims to improve quality, reduce risks, and adapt to changing requirements.
3. While XP works well for some projects and teams, its practices may not be suitable or flexible enough for all situations. Developers should understand the principles behind XP and tailor practices as needed for their specific projects.
Yenikod Yazılım Kursu - Kodlama Öğrenebilir Miyim? Kodlama Bana Göre Mi?Mustafa Ekim
This document provides information about a software development career and learning to code. It discusses the growing demand for software developers and how the number of developers has doubled every 5 years. It notes that half of developers have less than 5 years of experience. The document recommends focusing on skills, talent, character, motivation, strategy, attitude, and luck to succeed as a developer. It emphasizes the importance of lifelong learning as technologies and best practices constantly change. It also outlines different coding career paths and domains like AI, security, and blockchain.
The document discusses concerns and best practices for agile developers. It outlines 70 tips from the book "The Pragmatic Programmer" covering topics like continuous improvement, testing, refactoring, and automating processes. It also discusses techniques like test-driven development, design evolution, continuous integration, and ensuring code quality without compromising on quality. The overall message is about caring for one's craft as a developer through practices like refactoring early and often and using common sense.
Agile Methodologies And Extreme ProgrammingUtkarsh Khare
The document discusses Agile development and Extreme Programming (XP). It provides an overview of 12 key practices of XP, including planning games, small releases, test-driven development, pair programming, collective ownership, continuous integration and 40-hour work weeks. It also discusses how XP aims to solve software engineering problems through intensive teamwork, handling changes and staff turnover, and involving customers.
In 2011, the website edge.org asked the question, 'What scientific concept would improve everybody's cognitive toolkit?'. There were answers from renowned intellectuals. I have listed some of the concepts which are relevant to software development.
Jeff shares four important lessons he has learned about software development: [1] The best code is no code at all - avoid writing code when possible through alternatives like calling other departments or using existing open source/commercial solutions. [2] Code is for humans first, and computers second - code expresses the problem to humans, so write code that is clear for other humans to understand. [3] You are not as smart as you think you are - the software field is constantly changing, so continuously learn and question your assumptions. [4] Software development is 80% social and 20% technical - most of the challenges lie in understanding user needs through communication, while technical problems can often be solved through search engines.
The document provides advice for senior developers to share with junior developers. It emphasizes that the job is about critical thinking and problem solving rather than just writing code. Software development requires teamwork and effective communication. Developers will inevitably make mistakes, so it's important to have processes and tools to catch and address errors. Estimating timelines accurately requires understanding the difference between predictions, targets, and commitments. Developers should continue learning new skills and technologies throughout their career rather than focusing on a single platform. The real world is more complex than may be assumed, so developers need a willingness to tackle difficult problems and the confidence to eventually solve them.
Let‘s have a discussion about quality.
- How do you measure it?
- How can you compare it?
- How can you achieve it?
- What‘s necessary and what makes sense to achieve it repeatably with different teams?
I will give answers (my answers) to these questions. But I hope to actually have a discussion about it. Perhaps round-table like? Who would be up for that?
Getting Real is a book by 37signals that advocates for building software in an agile, iterative way that focuses on the essential features customers need. It recommends starting with the interface, doing the minimum necessary to solve problems, and making changes inexpensive. The book emphasizes frequent iterations, eliminating unnecessary features and complexity, and optimizing for programmer happiness to efficiently deliver valuable software.
Software development and Sambar - what's the connection ?Dasarathi GV
The document compares the process of software development to developing a new type of sambar dish. It outlines 6 steps in this process:
1. Analyzing customer needs and preferences
2. Deciding on the overall architecture and style
3. Designing details like ingredients and amounts
4. Implementing the design by cooking the dish
5. Testing the dish with customers
6. Deploying the final product and getting feedback
The document explains that steps 1-2 involve domain knowledge, while steps 3-6 involve technical implementation skills. It argues that many Indian software jobs focus mainly on coding (step 4) without deeper involvement in requirements analysis or design.
This document provides an overview of pair programming and discusses its benefits. It defines pair programming as two developers working together at one computer, with one typing code as the "driver" and the other reviewing the work and providing feedback as the "navigator". Research has found that pair programming can result in 15% fewer bugs and slightly better design quality compared to solo work. Benefits include improved learning, quality, focus, motivation and morale. The document also covers challenges, tips, and different pairing patterns like driver-navigator and ping-pong pairing.
UCD / IxD Introduction - User centric design, interaction designsdavis6b
This document provides an introduction to user-centric design (UCD) and interaction design (IxD) principles for building software. It discusses how UCD tools like personas, goals, and interaction loops can help design coherent experiences and increase agility, sanity and quality. While earlier software was system-centric, the focus is now on designing intuitive experiences through iterative collaboration using UCD and pairing it with Agile development methods.
This document discusses various techniques for rapid application testing (RAT) such as unit testing, integration testing, smoke testing, system testing, regression testing, performance testing, and test-driven development. It emphasizes automating test plans and test execution to allow tests to be run multiple times for little additional cost. The goal of testing is to balance cost and risk by reusing automated tests that are fast and good predictors of issues while throwing more tests at critical areas.
How Functional Programming Made Me A Better DeveloperCameron Presley
The document discusses how learning functional programming improved the author's skills as a developer. It describes their journey learning F# by porting projects like a screenshot tool and card games. This helped them think more about pure functions, immutable data, and leveraging LINQ. It influenced how they write more testable code through interfaces and by avoiding null values. The author now considers types of components like boundaries, business rules, and workflows when building software. Overall, learning functional programming was challenging but improved their ability to design maintainable and testable systems.
The document discusses anti-patterns and worst practices in software development. Some examples covered include static cling pattern, flags over objects, premature optimization, copy-paste-compile, and reinventing the wheel. It also shares lessons learned from experiences, such as being mindful of date times across time zones, avoiding building SQL from untrusted inputs, and not being too cute with test data. Overall, the document aims to help developers learn from the mistakes of others and adopt better practices.
The document discusses essential skills that programmers need versus accidental skills. Essential skills are hard to acquire but long-lasting, including things like managing complexity, writing readable code, and limiting bugs. These skills separate good programmers from bad. Accidental skills like knowledge of a specific programming language are easier to obtain but have shorter usefulness. The document advocates spending time on design, planning, unit testing, discussing solutions with others, and considering alternative solutions rather than just focusing on writing code. Developing essential skills through these practices can help programmers continuously learn and improve over the course of their careers.
Michael Losee grew up in Layton, Utah with 6 sisters. He enjoys video games, reading fantasy novels, and building custom computers. He has a Bachelor's degree in Computer Science from Weber State University. Professionally, he has 5 years of experience as a Lead Systems Analyst for the Defense Logistics Agency and 2 years as a Security Consultant. He is currently working to help paralyzed people learn to walk again and pursues coding as a hobby and potential career.
Three coding experts discuss the importance of readability in code. They emphasize:
1. Code should be written for human readers, with descriptive variable and function names, proper indentation and formatting, and comments explaining purpose not just restating code.
2. Readable code is more likely to be correct and easier to maintain than code written only for computers. Formatting, style, and structure help convey meaning to human readers.
3. Assertions, comments, and documentation help future readers understand code by stating assumptions and intended purpose, not just surface behavior. Readable code supports understanding problem requirements in addition to technical solution.
Agile Methodologies And Extreme Programming - Svetlin NakovSvetlin Nakov
1. Agile development and Extreme Programming (XP) are methodologies that focus on iterative development, collaboration, and adaptability.
2. XP consists of 12 key practices including simple design, test-driven development, pair programming, and small releases. It aims to improve quality, reduce risks, and adapt to changing requirements.
3. While XP works well for some projects and teams, its practices may not be suitable or flexible enough for all situations. Developers should understand the principles behind XP and tailor practices as needed for their specific projects.
Yenikod Yazılım Kursu - Kodlama Öğrenebilir Miyim? Kodlama Bana Göre Mi?Mustafa Ekim
This document provides information about a software development career and learning to code. It discusses the growing demand for software developers and how the number of developers has doubled every 5 years. It notes that half of developers have less than 5 years of experience. The document recommends focusing on skills, talent, character, motivation, strategy, attitude, and luck to succeed as a developer. It emphasizes the importance of lifelong learning as technologies and best practices constantly change. It also outlines different coding career paths and domains like AI, security, and blockchain.
The document discusses concerns and best practices for agile developers. It outlines 70 tips from the book "The Pragmatic Programmer" covering topics like continuous improvement, testing, refactoring, and automating processes. It also discusses techniques like test-driven development, design evolution, continuous integration, and ensuring code quality without compromising on quality. The overall message is about caring for one's craft as a developer through practices like refactoring early and often and using common sense.
Agile Methodologies And Extreme ProgrammingUtkarsh Khare
The document discusses Agile development and Extreme Programming (XP). It provides an overview of 12 key practices of XP, including planning games, small releases, test-driven development, pair programming, collective ownership, continuous integration and 40-hour work weeks. It also discusses how XP aims to solve software engineering problems through intensive teamwork, handling changes and staff turnover, and involving customers.
In 2011, the website edge.org asked the question, 'What scientific concept would improve everybody's cognitive toolkit?'. There were answers from renowned intellectuals. I have listed some of the concepts which are relevant to software development.
Jeff shares four important lessons he has learned about software development: [1] The best code is no code at all - avoid writing code when possible through alternatives like calling other departments or using existing open source/commercial solutions. [2] Code is for humans first, and computers second - code expresses the problem to humans, so write code that is clear for other humans to understand. [3] You are not as smart as you think you are - the software field is constantly changing, so continuously learn and question your assumptions. [4] Software development is 80% social and 20% technical - most of the challenges lie in understanding user needs through communication, while technical problems can often be solved through search engines.
The document provides advice for senior developers to share with junior developers. It emphasizes that the job is about critical thinking and problem solving rather than just writing code. Software development requires teamwork and effective communication. Developers will inevitably make mistakes, so it's important to have processes and tools to catch and address errors. Estimating timelines accurately requires understanding the difference between predictions, targets, and commitments. Developers should continue learning new skills and technologies throughout their career rather than focusing on a single platform. The real world is more complex than may be assumed, so developers need a willingness to tackle difficult problems and the confidence to eventually solve them.
Let‘s have a discussion about quality.
- How do you measure it?
- How can you compare it?
- How can you achieve it?
- What‘s necessary and what makes sense to achieve it repeatably with different teams?
I will give answers (my answers) to these questions. But I hope to actually have a discussion about it. Perhaps round-table like? Who would be up for that?
Getting Real is a book by 37signals that advocates for building software in an agile, iterative way that focuses on the essential features customers need. It recommends starting with the interface, doing the minimum necessary to solve problems, and making changes inexpensive. The book emphasizes frequent iterations, eliminating unnecessary features and complexity, and optimizing for programmer happiness to efficiently deliver valuable software.
Software development and Sambar - what's the connection ?Dasarathi GV
The document compares the process of software development to developing a new type of sambar dish. It outlines 6 steps in this process:
1. Analyzing customer needs and preferences
2. Deciding on the overall architecture and style
3. Designing details like ingredients and amounts
4. Implementing the design by cooking the dish
5. Testing the dish with customers
6. Deploying the final product and getting feedback
The document explains that steps 1-2 involve domain knowledge, while steps 3-6 involve technical implementation skills. It argues that many Indian software jobs focus mainly on coding (step 4) without deeper involvement in requirements analysis or design.
Similar to 97 thingseveryprogrammershouldknow (20)
Discover the benefits of outsourcing SEO to Indiadavidjhones387
"Discover the benefits of outsourcing SEO to India! From cost-effective services and expert professionals to round-the-clock work advantages, learn how your business can achieve digital success with Indian SEO solutions.
Ready to Unlock the Power of Blockchain!Toptal Tech
Imagine a world where data flows freely, yet remains secure. A world where trust is built into the fabric of every transaction. This is the promise of blockchain, a revolutionary technology poised to reshape our digital landscape.
Toptal Tech is at the forefront of this innovation, connecting you with the brightest minds in blockchain development. Together, we can unlock the potential of this transformative technology, building a future of transparency, security, and endless possibilities.
Gen Z and the marketplaces - let's translate their needsLaura Szabó
The product workshop focused on exploring the requirements of Generation Z in relation to marketplace dynamics. We delved into their specific needs, examined the specifics in their shopping preferences, and analyzed their preferred methods for accessing information and making purchases within a marketplace. Through the study of real-life cases , we tried to gain valuable insights into enhancing the marketplace experience for Generation Z.
The workshop was held on the DMA Conference in Vienna June 2024.
Meet up Milano 14 _ Axpo Italia_ Migration from Mule3 (On-prem) to.pdfFlorence Consulting
Quattordicesimo Meetup di Milano, tenutosi a Milano il 23 Maggio 2024 dalle ore 17:00 alle ore 18:30 in presenza e da remoto.
Abbiamo parlato di come Axpo Italia S.p.A. ha ridotto il technical debt migrando le proprie APIs da Mule 3.9 a Mule 4.4 passando anche da on-premises a CloudHub 1.0.
1. 97 Things Every
Programmer
Should Know
http://programmer.97things.oreilly.com
@97TEPSK
Kevlin Henney
kevlin@curbralan.com
@KevlinHenney
2.
3. Adrian Wible
Alan Griffiths
Alex Miller
Allan Kelly
Anders Norås
Ann Katrin Gagnat
Aslam Khan
Burk Hufnagel
Cal Evans
Carroll Robinson
Cay Horstmann
Chuck Allison
Clint Shank
Dan Bergh Johnsson
Dan North
Daniel Lindner
Diomidis Spinellis
Edward Garson
Einar Landre
Filip van Laenen
Gerard Meszaros
Giles Colborne
Giovanni Asproni
Greg Colvin
Gregor Hohpe
Gudny Hauknes
Heinz Kabutz
Jan Christiaan "JC" van Winkel
Janet Gregory
Jason P Sage
Johannes Brodwall
Jon Jagger
Jørn Ølmheim
Kari Røssland
Karianne Berg
Keith Braithwaite
Kevlin Henney
Kirk Pepperdine
Klaus Marquardt
Linda Rising
Marcus Baker
Matt Doar
Mattias Karlsson
Michael Feathers
Michael Hunger
Mike Lewis
Nate Jackson
Neal Ford
Niclas Nilsson
Olve Maudal
Paul W Homer
Pete Goodliffe
Peter Sommerlad
Rajith Attapattu
Randy Stafford
Richard Monson-Haefel
Robert C Martin (Uncle Bob)
Rod Begbie
Russel Winder
Ryan Brush
Sam Saariste
Sarah Mount
Scott Meyers
Seb Rose
Steve Berczuk
Steve Freeman
Steve Smith
Thomas Guest
Udi Dahan
Verity Stob
Walter Bright
Yechiel Kimchi
Yuriy Zubarev
4.
5. Act with Prudence
Apply Functional Programming Principles
Ask "What Would the User Do?" (You Are Not the User)
Automate Your Coding Standard
Beauty Is in Simplicity
Before You Refactor
Beware the Share
The Boy Scout Rule
Check Your Code First Before Looking to Blame Others
Choose Your Tools with Care
Code in the Language of the Domain
Code Is Design
Code Layout Matters
Code Reviews
Coding with Reason
A Comment on Comments
Comment Only What the Code Cannot Say
Continuous Learning
Convenience Is Not an –ility
Deploy Early and Often
Distinguish Business Exceptions from Technical
Do Lots of Deliberate Practice
Domain-Specific Languages
Don't Be Afraid to Break Things
Don't Be Cute with Your Test Data
Don't Ignore That Error!
Don't Just Learn the Language, Understand its Culture
Don't Nail Your Program into the Upright Position
Don't Rely on "Magic Happens Here"
Don't Repeat Yourself
Don't Touch That Code!
Encapsulate Behavior, Not Just State
Floating-Point Numbers Aren't Real
Fulfill Your Ambitions with Open Source
The Golden Rule of API Design
The Guru Myth
Hard Work Does Not Pay Off
How to Use a Bug Tracker
Improve Code by Removing It
Install Me
Inter-Process Communication Affects Application Response Time
Keep the Build Clean
Know How to Use Command-line Tools
Know Well More than Two Programming Languages
Know Your IDE
Know Your Limits
Know Your Next Commit
Large Interconnected Data Belongs to a Database
Learn Foreign Languages
Learn to Estimate
Learn to Say "Hello, World"
Let Your Project Speak for Itself
The Linker Is Not a Magical Program
The Longevity of Interim Solutions
Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly
Make the Invisible More Visible
Message Passing Leads to Better Scalability in Parallel Systems
A Message to the Future
Missing Opportunities for Polymorphism
News of the Weird: Testers Are Your Friends
One Binary
Only the Code Tells the Truth
Own (and Refactor) the Build
Pair Program and Feel the Flow
Prefer Domain-Specific Types to Primitive Types
Prevent Errors
The Professional Programmer
Put Everything Under Version Control
Put the Mouse Down and Step Away from the Keyboard
Read Code
Read the Humanities
Reinvent the Wheel Often
Resist the Temptation of the Singleton Pattern
The Road to Performance Is Littered with Dirty Code Bombs
Simplicity Comes from Reduction
The Single Responsibility Principle
Start from Yes
Step Back and Automate, Automate, Automate
Take Advantage of Code Analysis Tools
Test for Required Behavior, Not Incidental Behavior
Test Precisely and Concretely
Test While You Sleep (and over Weekends)
Testing Is the Engineering Rigor of Software Development
Thinking in States
Two Heads Are Often Better than One
Two Wrongs Can Make a Right (and Are Difficult to Fix)
Ubuntu Coding for Your Friends
The Unix Tools Are Your Friends
Use the Right Algorithm and Data Structure
Verbose Logging Will Disturb Your Sleep
WET Dilutes Performance Bottlenecks
When Programmers and Testers Collaborate
Write Code as If You Had to Support It for the Rest of Your Life
Write Small Functions Using Examples
Write Tests for People
You Gotta Care About the Code
Your Customers Do Not Mean What They Say
6. Act with Prudence
Apply Functional Programming Principles
Ask "What Would the User Do?" (You Are Not the User)
Automate Your Coding Standard
Beauty Is in Simplicity
Before You Refactor
Beware the Share
The Boy Scout Rule
Check Your Code First Before Looking to Blame Others
Choose Your Tools with Care
Code in the Language of the Domain
Code Is Design
Code Layout Matters
Code Reviews
Coding with Reason
A Comment on Comments
Comment Only What the Code Cannot Say
Continuous Learning
Convenience Is Not an –ility
Deploy Early and Often
Distinguish Business Exceptions from Technical
Do Lots of Deliberate Practice
Domain-Specific Languages
Don't Be Afraid to Break Things
Don't Be Cute with Your Test Data
Don't Ignore That Error!
Don't Just Learn the Language, Understand its Culture
Don't Nail Your Program into the Upright Position
Don't Rely on "Magic Happens Here"
Don't Repeat Yourself
Don't Touch That Code!
Encapsulate Behavior, Not Just State
Floating-Point Numbers Aren't Real
Fulfill Your Ambitions with Open Source
The Golden Rule of API Design
The Guru Myth
Hard Work Does Not Pay Off
How to Use a Bug Tracker
Improve Code by Removing It
Install Me
Inter-Process Communication Affects Application Response Time
Keep the Build Clean
Know How to Use Command-line Tools
Know Well More than Two Programming Languages
Know Your IDE
Know Your Limits
Know Your Next Commit
Large Interconnected Data Belongs to a Database
Learn Foreign Languages
Learn to Estimate
Learn to Say "Hello, World"
Let Your Project Speak for Itself
The Linker Is Not a Magical Program
The Longevity of Interim Solutions
Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly
Make the Invisible More Visible
Message Passing Leads to Better Scalability in Parallel Systems
A Message to the Future
Missing Opportunities for Polymorphism
News of the Weird: Testers Are Your Friends
One Binary
Only the Code Tells the Truth
Own (and Refactor) the Build
Pair Program and Feel the Flow
Prefer Domain-Specific Types to Primitive Types
Prevent Errors
The Professional Programmer
Put Everything Under Version Control
Put the Mouse Down and Step Away from the Keyboard
Read Code
Read the Humanities
Reinvent the Wheel Often
Resist the Temptation of the Singleton Pattern
The Road to Performance Is Littered with Dirty Code Bombs
Simplicity Comes from Reduction
The Single Responsibility Principle
Start from Yes
Step Back and Automate, Automate, Automate
Take Advantage of Code Analysis Tools
Test for Required Behavior, Not Incidental Behavior
Test Precisely and Concretely
Test While You Sleep (and over Weekends)
Testing Is the Engineering Rigor of Software Development
Thinking in States
Two Heads Are Often Better than One
Two Wrongs Can Make a Right (and Are Difficult to Fix)
Ubuntu Coding for Your Friends
The Unix Tools Are Your Friends
Use the Right Algorithm and Data Structure
Verbose Logging Will Disturb Your Sleep
WET Dilutes Performance Bottlenecks
When Programmers and Testers Collaborate
Write Code as If You Had to Support It for the Rest of Your Life
Write Small Functions Using Examples
Write Tests for People
You Gotta Care About the Code
Your Customers Do Not Mean What They Say
7. Do Lots of Deliberate Practice
Jon Jagger
You do deliberate practice to improve your ability to perform a
task. It’s about skill and technique. Deliberate practice means
repetition. It means performing the task with the aim of
increasing your mastery of one or more aspects of the task. It
means repeating the repetition. Slowly, over and over again,
until you achieve your desired level of mastery. You do
deliberate practice to master the task, not to complete the task.
8. Learn to Estimate
Giovanni Asproni
An estimate is an approximate calculation or judgement of the
value, number, quantity, or extent of something. This definition
implies that [...] hopes and wishes must be ignored when
calculating it. The definition also implies that, being
approximate, an estimate cannot be precise, e.g., a
development task cannot be estimated to last 234.14 days.
A target is a statement of a desirable business objective, e.g.,
“The system must support at least 400 concurrent users.”
A commitment is a promise to deliver specified functionality at
a certain level of quality by a certain date or event.
9. Know Your Next Commit
Dan Bergh Johnsson
I tapped three programmers on their shoulders and asked what they were doing.
“I am refactoring these methods,” the first answered. “I am adding some
parameters to this web action,” the second answered. The third answered, “I am
working on this user story.”
It might seem that the first two were engrossed in the details of their work,
while only the third could see the bigger picture, and that he had the better
focus. However, when I asked when and what they would commit, the picture
changed dramatically. The first two were pretty clear about what files would be
involved, and would be finished within an hour or so. The third programmer
answered, “Oh, I guess I will be ready within a few days. I will probably add a
few classes and might change those services in some way.”
10. Comment Only What the
Code Cannot Say
Kevlin Henney
1. If a program is incorrect, it matters little what the documentation
says.
2. If documentation does not agree with the code, it is not worth much.
3. Consequently, code must largely document itself. If it cannot,
rewrite the code rather than increase the supplementary
documentation. Good code needs fewer comments than bad code does.
4. Comments should provide additional information that is not readily
obtainable from the code itself. They should never parrot the code.
5. Mnemonic variable names and labels, and a layout that emphasizes
logical structure, help make a program self‐documenting.
Kernighan and Plauger
The Elements of Programming Style
11. Code in the Language of
the Domain
Dan North
Phillip Calçado
http://fragmental.tw/2009/04/29/tag-clouds-see-how-noisy-your-code-is/
12. Encapsulate Behavior,
Not Just State
Einar Landre
An object encapsulates both state and behavior, where
the behavior is defined by the actual state. [...]
This inherent property of an object makes the design
process conceptually simple. It boils down to two
simple tasks: allocation and delegation of
responsibility to the different objects including the
interobject interaction protocols.
13. Don't Repeat Yourself
Steve Smith
Duplication Is Waste
Repetition in Process Calls
for Automation
Repetition in Logic Calls
for Abstraction
14. Beware the Share
Udi Dahan
The fact that two wildly different parts of the system
performed some logic in the same way meant less than I
thought. Up until I had pulled out those libraries of shared
code, these parts were not dependent on each other. Each could
evolve independently. Each could change its logic to suit the
needs of the system’s changing business environment. Those
four lines of similar code were accidental—a temporal
anomaly, a coincidence. That is, until I came along.
15. The Road to Performance Is
Littered with Dirty Code Bombs
Kirk Pepperdine
MORE OFTEN THAN NOT, PERFORMANCE
TUNING A SYSTEM REQUIRES YOU TO ALTER
CODE. WHEN WE NEED TO ALTER CODE,
EVERY CHUNK THAT IS OVERLY COMPLEX OR
HIGHLY COUPLED IS A DIRTY CODE BOMB
LYING IN WAIT TO DERAIL THE EFFORT. THE
FIRST CASUALTY OF DIRTY CODE WILL BE
YOUR SCHEDULE.
16. Act with Prudence
Seb Rose
Martin Fowler
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
17. The Boy Scout Rule
Robert C Martin (Uncle Bob)
Try and leave this world a little
better than you found it.
Robert Stephenson Smyth Baden-Powell
18. Apply Functional
Programming Principles
Edward Garson
An expression is said to be referentially transparent if it can be
replaced with its value without changing the program (in other words,
yielding a program that has the same effects and output on the same
input). [...]
The importance of referential transparency is that it allows a
programmer (or compiler) to reason about program behavior. This can
help in proving correctness, simplifying an algorithm, assisting in
modifying code without breaking it, or optimizing code by means of
memoization, common subexpression elimination or parallelization.
http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)
19. Thinking in States
Niclas Nilsson
People in the real world have a weird
relationship with state.
In most real-world situations, people’s
relaxed attitude toward state is not an
issue. Unfortunately, however, many
programmers are quite vague about state
too — and that is a problem.
20. Two Wrongs Can Make a Right
(and Are Difficult to Fix)
Allan Kelly
21. Code Reviews
Mattias Karlsson
Making code reviews fun is perhaps the most
important contributor to success. Reviews are
about the people reviewing. If the review meeting
is painful or dull, it will be hard to motivate
anyone. Make it an informal code review whose
principal purpose is to share knowledge among
team members. Leave sarcastic comments outside,
and bring a cake or brown-bag lunch instead.
22. Testing Is the Engineering Rigor
of Software Development
Neal Ford
Testing “hard” things is tough because you
have to build them to test them, which
discourages speculative building just to see
what will happen. But the building process
in software is ridiculously cheap.
23. Write Tests for People
Gerard Meszaros
So who should you be writing the tests for? For the
person trying to understand your code.
Good tests act as documentation for the code they are
testing. They describe how the code works. For each
usage scenario, the test(s):
o Describe the context, starting point, or
preconditions that must be satisfied
o Illustrate how the software is invoked
o Describe the expected results or postconditions to
be verified
Different usage scenarios will have slightly different
versions of each of these.
25. Ask "What Would the User Do?"
(You Are Not the User)
Giles Colborne
We all tend to assume that other people think like us. But
they don't. Psychologists call this the false consensus bias.
This bias explains why programmers have such a hard
time putting themselves in the users' position. Users don't
think like programmers.
The best way to find out how a user thinks is to watch one.
27. The newest computer can merely compound, at speed,
the oldest problem in the relations between human
beings, and in the end the communicator will be
confronted with the old problem, of what to say and
how to say it.
Edward R Murrow