2017 Videos, Links, whatever

My Ramblings…

Guy Kawasaki – The Lessons of Steve Jobs – Lean Startup Week 2016

Guy is a great speaker, full of energy. This is a fun quick video to watch where he does a top 10 from Steve. Not to give it away, but I liked the Steve quote, “Some things need to be believed to be seen”.

Jake Archibald – Instant Loading: Building offline-first Progressive Web Apps – Google I/O 2016

This is a very fun to watch video from a very skilled presenter. Ward Bell suggested this on a podcast I recently listened to. Ward pointed out to listen for the “We can ship that” multiple times in the talk which is funny. It gives a thorough explanation of ServiceWorkers and how to progressively update an app to use them.

Jason Fried – Why 40 Hours is Enough: Lessons from Basecamp – Lean Startup 2016

Excellent talk from a fellow who has been “doing it” for the past 17 years. I have always NOT been a fan of email for project related communications. Now that I hear this talk, I wonder if some of my original problems with that type of communication came from reading his book (Getting Real, which I read back in 2006).

Sam Newman – Feature Branches and Toggles in a Post-GitHub World

This guy literally wrote the book on Building Microservices. In this talk he gives a nice history of version control and git. He shows the challenges with feature branching and suggests an alternative “Branch-by abstraction”. This is a major part of using feature toggles. In relation to flags, he suggests using a flag in as few places as possible and remove the flag when it is no longer needed. Another thought is to treat every check-in as a release candidate. He does a great job talking about the problem of having too many changes in a release, which causes it to take longer, which increases the potential for problems (both deployment and one change breaking something else). He also talks about trunk based development. For the right teams on the right kinds of projects, this seems like the sweet spot to me.

Simon Brown – Modular Monoliths

He tries to make documentation match the software it is intended to describe. He leans a little more towards continuing the monoliths than I prefer, but I do like the idea of simple architecture designs that actually describe the software.

Print Friendly