Archive
- If you want to learn about something do a talk on it
- Process vs Work
- Your code reflects the organisation's structure at the time it was written
- Make sure you have enough time to really get into your work
- Are you doing science or engineering?
- Spin up test projects to try things out
- Start simple and iterate
- Use the tools you have
- The UI Stack
- Some deadlines can't be changed
- How to beat the Olympic mixed relay champions
- You must understand why something broke when you fix it
- If you pick a new tool, have a plan for replacing the old one
- Start with “Hello World” and CI/CD
- Picking technology and architecture for a new project is hard
- Split different user types into different models
- Some definitions of technical debt
- The rule of three
- Just build what is necessary, always build for change
- The Gell-Mann Amnesia effect and LLMs
- Firefighters vs fire inspectors
- Get the work you're delegating explained back to you
- Shortcuts should be temporary
- What do you mean by technical debt?
- Cancel your unfinished projects
- LLMs should be bicycles for the mind
- Do you review your dependencies?
- Improve your feedback loops
- The first time there is a fire is not the best time to learn how to use a fire extinguisher
- Make sure you finish what you start
- Avoid getting carried away at the start of a project
- You do not rise to the level of your goals. You fall to the level of your systems.
- Prefer fewer layers and libraries
- Your job is unlikely to be directly replaced by an LLM
- The important thing about estimation is not the estimates but breaking the work down
- You're not done until you've thought about error handling
- How much of the overall picture can they see?
- Blog driven development and why you should avoid it
subscribe via email