So my engineering bookclub is continuing on with Chapter 6 in The Pragmatic Programmer. We have had some stops and starts along the way. For chapters 4 and 5 we ended up combing the weeks because none of us were really feeling discussing chapter 4 (Pragmatic Paranoia). We did have to move Chapter 6 from last week, because it was towards the end of the sprint and a lot of our members wanted to try and push through on some sprint commitments and get more work time on their stories.
That’s probably one of the hardest things about doing a work book-club, how easy it is to push back chapters. We have probably done that 3 or so times, which really does increase the amount of time it takes to finish a book, and seems to bring down momentum.
As always, I used questions from the awesome Dev Empathy Bookclub. If you are interested, they are diving into Rocket Surgery Made Easy right now.
Notes on Chapter 6, While You are Coding
- Programming by coincidence, don’t just rely on code that just works but you don’t understand why it works, program deliberately
- Program deliberately by being aware of what you are doing, THINK, rely only on reliable things and document your assumptions.
- Test your code and your assumptions
- Don’t be a slave to history, existing code should dictate future code.
- Algorithm speed, Big O notation
- Just another kind of estimating, estimating with algorithms
- Ex. Sorting with strings (n), decrypting a message, the size of these input will affect the algorithm.
- The larger the input, the longer the running time or memory
- Linear – O(n) time increased in direct proportion to the value of n, sequential search, simple loops
- Constant – O(1), access element in array, simple statements
- O(lg(n)) Logorithmic, binary search, binary chop
- O(n lg(n)) Worse then linear, but not a ton worse, quicksort, heap sort, divide and conquer
- O(n²) Square law, selections and insertion sorts
- O(n³) Cubic, multiplications of 2 n x n matrices
- O(cᴺ) Exponential, traveling salesman, set partitioning
- Test your estimates, and best isn’t always best, choose the algorithms that works with your data
- Refactoring, refactor code when you see duplication, nonorthogonal design, outdated knowledge, and performance issues.
- Make code easy to test, unit test is a test that tests a module and test against a contract
- Don’t use wizard code that you don’t understand
Questions for Chapter 6
- In the section about optimization (Algorithm Speed), the authors warn against premature optimization, because often a less performant implementation “will take you less time to write and debug” and you don’t want to invest your time unless it’s necessary. We might say that rather than optimizing for CPU cycles, we’re optimizing for programmer cycles. What are the things you think are most important to optimize for in software development?
- Testing is more cultural than technical; we can instill this testing culture in a project regardless of the language being used. How does one go about instilling a strong culture of testing, or any coding practice, in a team that doesn’t have that as part of its routine, and maybe doesn’t even believe in it? Does it matter whether you’re a manager, a tech lead, or a developer?
- The authors aren’t against frameworks, but rather oppose using auto-generated code you didn’t write and don’t understand. What are the dangers of having code you don’t understand? Is there some amount that’s OK? How much is too much?
Top comments (0)