Skip to content

Technical

How long will it take to implement feature X?

I came across this article. I'll jump to the end and quote his conclusion:

Estimates – as defined in the English language – isn’t really the problem here. The problem is when estimates are treated as predictions, deadlines, and used to put pressure on developers who are just trying to do their jobs. Estimates – the way they are used in our industry today – hurts people and reduces the psychological safety in our organisations. I believe we would be better off if we could work in a way that allows developers to be transparent and continuously communicate updated estimates as development progresses.

What do you think? How can estimates be realistic? How are estimates done where you work? Agile, e.g. Story Points, planning poker? Or more formal software costing, e.g. COCOMO, Function Points?

Everyone and anyone are welcome to join as long as you are kind, supportive, and respectful of others. Zoom link will be posted at 12pm MDT.

desk

Managing Change / Change Management

This is a big topic! We can discuss change at the corporate/organizational level, or we can zoom in on controlling change in software development. I’ll leave it open for the group to steer the conversation. Controversial opinions welcome.

Anyone have horror stories? Boss drops a 500-page manual on your desk Friday afternoon and says “figure this new tool out by Monday”? You show up one morning and the entire phone system/email client/ERP has been replaced overnight with zero warning?

What about managing requirements? You work for weeks on a feature and it's suddenly dropped? Or a new requirement causes a major rewrite? Or maybe the real issue about managing expectations.

Regarding version-control, we can also dig into trunk-based vs feature-branch workflows vs Git Flow, and when each actually makes sense.

Everyone and anyone are welcome to join as long as you are kind, supportive, and respectful of others. Zoom link will be posted at 12pm MDT.

alt text

Don’t Pre‑optimize: Why Clarity Beats Premature Performance Tweaks

Every developer has stared at a fresh function and wondered, “Can I make this faster right now?” Simon Harris’s Beginner Algorithms (2006) reminds us that pre‑optimizing is often a wild goose chase. In this week’s Weekly Dev Chat we’ll unpack that advice, examine real‑world trade‑offs, and surface strategies for balancing performance with readability. Main arguments:

  • Most hot‑spots are hidden in I/O, network latency, or third‑party services, not in the loops we think matter.

  • Well‑structured code is easier to profile, test, and refactor. Simple abstractions often let compilers and runtimes optimise better than hand‑rolled tricks.

Everyone and anyone are welcome to join as long as you are kind, supportive, and respectful of others. Zoom link will be posted at 12pm MDT.

scientist in laboratory