Developing in the Cloud

So I don’t have much time for hobby projects… And when I do have time, it is from various computers, with various setup.

That’s why I’m testing the following combination of online services, and so far it looks promising for my needs…

Slack is Unplanned Improvement Work

Full utilization cause delays - http://agileconsulting.blogspot.no/2011/07/explaining-why-limiting-wip-is-so.html

Full utilization is not effective, not efficient, and causes delays

Being busy all the time is bad for you, your team, and your organization.  It is far better to allow for slack, which is not a bad thing, but creates opportunities for improvement without needing to schedule them.

“Recipe” for what to work on next, incorporating slack:

  1. Can you help progress an existing kanban? (planned, started work)
    Work on that.
  2. Can’t do that?
    Find bottleneck and work to release it.
  3. Can’t do that either?
    Do work which

    • won’t create any work downstream,
    • will improve future throughput, and
    • can be paused as soon as existing kanban related work is available.

A bit more reading related to slack.

#techsafety

At LKNA13 in Chicago this year I listened to @JoshuaKerievsky talk about #techsafety.

He made me think about quite a few aspects of safety and injuries for a programmer. Here’s a few quotes and elements:

  • safety on team (ref own dev competence)
  • «working with CVS is hurting my soul.»
  • safe from uncertain work situation
  • safe to deploy – bugs, crash
  • safe from pressure – politics, policies
  • Emotional Injuries: Schedule Stress, Lost Respect, Fear of Failure, Torn Trust, etc

What’s interesting is his claim that having #techsafety as a primary value would be profitable and produce outstanding results. I think I buy into that, even if he hasn’t had time to prove it yet with his own company, @IndustrialLogic.

A few twitter notes from the session.

Edit: Joshua wrote a blogpost on #techsafety himself:  http://www.industriallogic.com/blog/techsafety/