About the Book
This book is about the things that go into being a programmer that aren't specifically the programming. Coder Complete, if you will. It starts fairly close to home, with chapters on working with other coders, on supporting your own programming needs, and on other "software engineering" practices that programmers should understand and make use of. We'll go through talking about psychology and metacognition — about understanding how you the programmer function and how to improve that functioning — to finally discuss what programming is, philosophically speaking, and why we do it.
10% of all sales of this book are donated to Charity:Water.
Share this book
Table of Contents
- Introduction
- What’s this book about?
- Why are you writing it?
- These are the ramblings of one person
- Who should read it?
- Something you said was rubbish
- About the Author
- Acknowledgements
- Tools that support software development
- Version control / Source code management
- Continuous Integration and Deployment
- Build Management
- Bug and work tracking
- Integrated Development Environment
- Static Analysis
- Code Generation
- Coding Practices
- Test-Driven Development
- Domain-Driven Design
- Behaviour-Driven Development
- xDD
- Design by Contract
- Development by Specification
- Pair programming
- Code Reviews
- Programming paradigms and their applicability
- Testing
- A Philosophy of Testing
- Black and White boxes
- Test case design
- Automate all the things
- Getting someone else in
- Other benefits of testing
- Architecture
- Non-functional requirements are essential
- Defer when appropriate; commit when necessary
- Justify your decisions
- When to fix and when to replace
- Know when to nitpick, and when to leave it
- Support, don’t control
- Documentation
- Documentation is more useful than you might think
- The up-to-dateness problem
- Automatically Generated Documentation
- Analysis Paralysis
- How to Document
- Summary
- Requirements Engineering
- Study People
- You shouldn’t necessarily build what the client asks for
- Avoid asking what you want to hear
- Understand the problem domain
- Uncover tacit requirements
- You shouldn’t build what your client wants
- Human factors in software systems
- Prioritising Requirements
- Is it really “engineering”?
- Learning
- Do As Much As You Can
- Don’t Stick to Your Own Discipline
- Put it into Practice
- Collaborate and Share what you Learn
- Opportunities to Learn
- Rediscovering lost knowledge
- The teaching of software creation
- Reflective Learning
- Critical Analysis
- Criticism is often uncritical
- How to form an argument
- Forms of fallacy
- Further Reading on Arguments
- Debates and Programmers
- Software as Essays
- Business
- Evaluate risks dispassionately
- Find out what you need to know, and how you can know it
- What you discover may not be to your liking
- How to interview a programmer
- Be transparent and honest with your business partners
- Choose Appropriate Technology
- Manipulation and Inspiration
- You don’t need to be a founder to be a programmer
- Teamwork
- Focus vs Interruption
- Working environment
- Prioritising Work
- Tell experts what needs to be done
- Working with junior programmers
- Working with managers
- Patterns of Software Project Management
- Negotiation
- Empathy
- Shared language and shiny buzzwords
- Ethics
- Examples of ethical codes
- Application of the ethical code
- Ethical Ambiguities
- Respecting Privacy
- Epilogue
- Philosophy
- Software as a pursuit
- An economic philosophy of software
- A management philosophy of software
- A social philosophy of software
- A pedagogic philosophy of software
- What does it mean to be “good” at making software?
- Conclusion
About the Author
