Archive

• Don't take on too much
• What surprised you?
• Remember what you achieved last year
• SMART goals are good but SMART systems are better
• Make new year systems not resolutions
• Take a break
• The curse of knowledge
• Interesting things vs Priority things
• You can prep even if you don't have the full picture
• Keep a daily work log
• Make sure the overall architecture is documented
• The four levers you can pull
• Focus on the here and now
• Learn a different programming language
• How often do you test your backups and restores?
• How safely can you put some hard to test code into production?
• How quickly can you do an end to end test?
• Don't make unnecessary DSLs
• Second system syndrome
• Beware pre 1.0 dependencies
• Are your upgrades scheduled?
• It's hard to review your own work
• You can't please everyone
• Building is an expensive way to learn
• What are best practises?
• Hamming on "open source"
• Use a shared password manager
• How many priorities do you have?
• Think about what you don't know when estimating
• System 1 and System 2 thinking
• Three phase database migrations
• If you have bad news, deliver it as soon as you can
• Is there a bigger picture you could be looking at?
• If we built houses like we build software
• Project mindset vs Product mindset
• Minimise context switching
• How often do you do a personal retrospective?
• Optimised code can be hard to understand so make sure it's documented
• Oral tradition vs Written tradition
• Always leave some slack
• When you find yourself struggling re-assess your systems
• YAGNI is great until you do actually need it
• Don't edit when you're writing your first draft
• Technical debt interest rates
• Don't argue about code style, pick a tool and use it
• Reading about running will not make you fit
• Are we using LLMs as faster horses?
• Always bring some spares
• 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