Links to articles I read in 2020 with a few notes to remind me of the topic.
Growing our team with retrospectives
Who are you trying to impress with your deadlines?
- "Allow your intuition to guide you to a conclusion, no matter how imperfect — this is the ‘strong opinion’ part. Then –and this is the ‘weakly held’ part– prove yourself wrong. Engage in creative doubt. Look for information that doesn’t fit, or indicators that pointing in an entirely different direction. Eventually your intuition will kick in and a new hypothesis will emerge out of the rubble, ready to be ruthlessly torn apart once again. You will be surprised by how quickly the sequence of faulty forecasts will deliver you to a useful result."
- Reasons it works well: "1. Leverage your team's collective wisdom. 2. Overcome your biases. 3. Have an on-demand decision."
Why do we fall into the rewrite trap?
- "It's harder to read code than to write it." Don't rewrite because you don't understand it.
- Prefer refactoring over rewriting.
- Once you understand confusing code, refactor to make it easier for someone else to understand.
- Refactor before making other changes. "Make the change easy (warning: this may be hard), then make the easy change." -Kent Beck
- Only rewrite when better functionality is needed.
Eradicating Non-Determinism in Tests
- Non-deterministic tests are useless and ruin the test suite. Can cause you to ignore test failures.
- Keep tests isolated: rebuild state on each or cleanup when done.
- Asynchronous calls can utilize callbacks or polling.
- Remote services can use Test Double or Contract Tests.
- Time based calls should be wrapped with a clock stub. Same for resource limiting - wrap the calls with a stub.
Optimizing for iteration speed
- "Two-week or three-week sprints are mini waterfall and sacrifices a lot of flexibility for the purpose of providing external stakeholders a bit more predictability."
- "Splitting up tasks into small, incremental pieces and shipping each of them separately is the fastest way to deliver value."
- Teams and individuals should be cross-functional, able to complete a full-stack task themselves.
- Trust each other to timely and thoughtfully review code.
- Be flexible in how you review code - understand the priority and audience.
- Guide rather than tell to allow for growth.
- An essay should make correct statements. It should tell something important that some people don't already know or haven't yet put into words.
- Don't publish until you feel confident in the writing. Proof-read to get to that point.
- Write about something important to you that you think about often.
- Short, Self Contained, Correct (compilable), Example
- Prepare example code that follows this format for others to see and help out.
- if tests fail, changed code is reverted.
- encourages very small changes.
- "When you work bottom-up, you usually end up with a different program. Instead of a single, monolithic program, you will get a larger language with more abstract operators, and a smaller program written in it."
- double entry bookkeeping is similar to test driven development
- excuses that an accountant wouldn't use shouldn't be used for writing tests
Numeric Separators in TypeScript
- Typescript 2.7 introduces underscores in numeric literals i.e. 4_000_000
Declare what you need, not what you get
- Typescript lets you pick specific properties from a type to store into another type. This lets you state exactly which properties you actually need.
Programming Isn't Manual Labor, But It Still Sucks
- meandering rant and analagies galore about programming life.
Why Scaling Agile Doesn't Work (video)
- focus on value, not cost
- estimated cost is worthless compared to finding out if people will actually use the software
- quickly deliver the things that provide the most value (other requirements can be delayed)
- small feedback loops to validate assumptions
- you can get value from software before you finish building it
Incorporate the Modern World Into the Software’s World
- all code is technical debt
- utilize existing tools and frameworks
- much time can be wasted by fussing over project configuration when it doesn't really matter
My life as a Code Economist (Four Questions)
- "Every time you fix a bug, you risk introducing another one."
- Determine these four things about each bug: Severity, Frequency, Cost, Risk
- Understand market windows and expectations
How Do You Make Good Decisions Efficiently in a Flat Organization?
- "Once everyone can live with a given solution, you’ve reached rough consensus, even if there are outstanding objections."
- A solution should not be rejected unless it has fundamental flaws.
The 13 Most Impactful Things Teams Can Do To Stay Productive While Working From Home
- "Focusing on inputs leads to constant interruptions, busywork, and burnout, more often than stellar results. Instead, shift the focus to outputs — the results that actually create value for the company"
- Communicate through the appropriate medium
- Setup a work space to separate work life. Maintain a daily routine.
The Fallacy of Move Fast and Break Things
- "To effectively move fast, you need processes in place to support the velocity." Fixing the broken things also needs to be fast.
- "Employees need to feel empowered to speak up if things are moving too fast.... They need to feel they won’t be blamed when something breaks."
- Put effort upfront (priming the pump) into making your work easier. Invest in yourself.
Your statement is 100% correct but misses the entire point
- Making a true statement as a counter-argument does not necessarily invalidate the original statement.
- "Being right is easy. Being relevant is extremely difficult."
- the basic commands to run a docker image
Const Assertions in Literal Expressions in TypeScript
- storing literals in objects as const
Function Overloads in Typescript
- function overloads give more typing options than union types and generics
- code reuse or strict frameworks can introduce more coupling
- "For example, losing ten pounds is a goal (that most people can’t maintain), whereas learning to eat right is a system that substitutes knowledge for willpower."
The Omit Helper Type in TypeScript
- "The
Omit<T, K>type lets us create an object type that omits specific properties from another object type"
- "Tests are bad if you don't find them useful. The entire point of having tests is to increase your productivity, workflow and confidence in your codebase."
- Good tests have a descriptive name and steps for: setup, invocation, assertion.
Testing With Intent: Descriptive Test Naming
- "A descriptive test name should include the expected input, or setup state. It should include the subject we are testing, or the action we are taking. And, it should include the expected result."
- "Ultimately, test naming is about making your own job easier in the future."
- Test classes can have nested classes. This can help organize tests and group together shared setup steps.
Read-Only Array and Tuple Types in TypeScript
- TypeScript can have immutable arrays and tuples. e.g.
ReadonlyArray<string>orreadonly string[]
Outcome Over Output: Also Impact and Effort
- By analyzing "How are we doing?" we can decide what to do next. In this analysis, prefer measuring outcome (how much value customers receive).
Lessons from 6 software rewrite stories
- Generally avoid rewrites and make incremental improvements instead.
- It might make sense to create a new product in addition to the existing one. Don't immediately drop support for the original product.
- The existing product has value. It doesn't have to be thrown away to innovate.
- The magpie developer is always looking for the next new, shiny thing. Don't let this get in the way of getting things done. Use what works for our use case.
The unknown Type in Typescript
- The
unknowntype is similar toanybut with more restrictions when accessed.
Why Warren Buffet Believes Feedback Is A Gift and You Should Too
- Be open to any feedback people want to give you. It means they care about helping you improve.
Developing a Growth Mindset (video)
- Learning shouldn't be about success vs. failure. Failure should be thought of as "not yet."
- We focus too much on getting A's and getting things right the first time. We should instead reward the process and the effort. This leads to growth.
- Expiring skills (specific to a given time) get more attention, but permanent skills (relevant in any time) lead to long term success.
Please read the paper before you comment
- Many people critique articles they have never read or take quotations out of context.
Concatenating Arrays in JavaScript
- Several different approaches to concatenate multiple arrays into a single one.
Nullish Coalescing: The ?? Operator in TypeScript
- An operator to provide a fallback value for a nullable value.
Test-Driven Development (TDD) and Why People Get it Wrong
- TDD is for more than just creating a new feature. It can also be used for updating features and fixing bugs.
TDD, Where Did It All Go Wrong (video)
- Write tests for requirements/api/behavior, not for implementations / low level code
- Red, green, refactor - Write sinful code - It's about getting to green very quickly
- Find work that energizes. It will likely be high effort, but have high impact too.
- Don't let ego or highly visible work distract from more impactful work.
- "Things that simply won’t happen if you don’t do them are your biggest opportunity to work on something that matters, and it’s a category that will get both narrower and deeper the further you get into your career."
- "The only viable long-term bet on your career is to do work that matters, work that develops you and to steer towards companies that value genuine expertise."
How to Make Your Code Reviewer Fall in Love with You
- Spend time preparing code reviews as the author. Value the reviewer's time. 13 techniques to do so.
- "Allow [the reviewer] to spend time on the interesting parts of your code. If you require them to untangle your code or police simple mistakes, you both suffer."
Software development is like geriatrics
- "Caring for software takes more knowledge than a single person can acquire."
- "Interdisciplinary teams have smooth relationships with each other. They each have increasing knowledge in some areas, and enough knowledge of everything to know when to consult each other person. They work together to fix the software, rather than each inadequacy."