Thursday, April 19, 2018

Agile in 160 Billion Gallons: When Agile Principles Occur During A Disaster

While the Agile concepts may sometimes be easy, the why's and how's are a little trickier to wrap your head around.   I’ve unfortunately participated in three recent rising flood water events in Houston over the last three years. Employing my agile skills has had a profound impact on the "success of the project".  

Their are some agile principles that are naturally occuring during a disaster. The "product" is protecting your home by saving your possessions.  The backlog is all of your possessions and it is prioritized by how you plan on attacking it. Some examples might be most expensive to least, or from the floor to the counters.

Some agile principals, like self organized teams or iterations are partially present. And some principals are rarely applied at all.

The  demo, retro, and sprint planning, tend to fall away during a crisis, but I assert that those are most important for a successful product, as they are core to the agile principles of transparency, inspection, and adaptation.

Here are the full slide decks.
Houston Tech Fest ( 10/14/2017 )
Agile Leadership Network Conference ( 04/21/2018 )
Houston Tech Fest - Spring (05/05/2018)
Project Manager's Institute - Houston Conference (06/05/2018)

Saturday, March 10, 2018

Creating our Flood Plan

So having flooded three times, and being an Agile-ist, I'm always trying to improve.  This is the summary of my flood plan.

After my first flood, I spent some time (almost all of my time) thinking through the choices I made "in the moment" and how I could improve. So I came up with a flood plan, in case I ever flooded again. 13 months later, I had a chance to implement the plan. The plan worked very well. I spent some more time thinking about it and have developed the following.

Before diving into the plan, I need to set the context. When I'm talking about flooding, I'm talking about a rising water event. This is where there is a lot of rain and after some length of time (maybe several hours) that rain isn't able to drain away any more and starts coming into the house. This plan does NOT apply to storm surges or dam releases where the water rises into the house within minutes.

First lets start with the objective: "Save my stuff"

Saving my stuff is quite broad. Saving all of my stuff is not realistic. This is where I failed during my first flood. I tried to save everything, but only that didn't happen - much was missed. And the things that I did save, were not the most important. Clearly I needed to prioritize. Here are the ways that I can think of to prioritize the things to save in my house.

  • Irreplaceable -> Common
  • Expensive -> Cheap
  • Useful -> Unnecessary
  • Floors -> Counters
  • Front of House -> Back of House
  • Nearest (to me) -> Farthest away
For me, after the first flood, ending up in a barren apartment with nothing to sleep on, nowhere to sit, and a pile of boxes that I was unsure of what was even inside them. I choose Useful -> Unnecessary would be our prioritization. This means I will save the beds, sofas and chairs first and the stuffed animals and Pokemon cards that litter the floor, would be last. 

Step 1: Determine the prioritization

Now that I have my priority set, how do I go about saving my household. Beds, sofas, chairs and tables take up a lot of floor space. How do I get them off the ground and how high do I have to put them?

Step 2: Determine the minimum and maximum height

For us, we have a 1 ft flood plan, it worked quite well during the second flood, where we only had 13", but would have failed massively during Hurricane Harvey where we would have had 51".  If I had actually looked at and understood my elevation, I would have seen that my BFE was 4' and I should have planned for that all along.

(I say would have had, because we elevated our house the day before Harvey hit. We had been in the process of elevating since the 2nd flood, and were scheduled to lift 1 week later, so we were able to accelerate the actual date when Harvey was developing in the Gulf of Mexico.)

Just listing out our beds, chairs, and sofas, I quickly realized that we didn't have enough "up-space". And if we used all of our countertops for those items, where were we going to put the second and third tier of stuff. We needed to create more "up-space".

The sofa is long and more things can be stored on top of it, so lets start there. For us, the sofa can perfectly span the kitchen counter to the island. This takes up minimal countertop space and the bridge that it creates can hold more things.

We also reasoned that we could bring in the outside chairs, which are waterproof, and then create additional "tables" using our doors. We took the doors off their hinges, using the chairs as the supports, and created bunches more up-space for our inside fabric chairs.

The king size bed was tricky. It is too big and heavy (temperpedic mattress) to try to move to a counter top. We just have to lift the whole bed. We have a collection of cinderblocks that now live under the bed. We remove the mattress and boxspring, position the blocks next to the legs of the bed, then lift the frame on to the blocks, then replace the boxspring and mattress. Then the kids twin beds can fit on top of the king.

After wading around thigh deep during the first flood, a friend asked me what I would have done if the water kept rising. At this time, I honestly hadn't thought about it. I didn't have a maximum water height in mind. Which in retrospect, is kinda terrifying.  We now have an inflatable boat (with a power AND hand pump). We have also talked to our high neighbors and have arranged refuge in their house should we need it.

Step 3: Define your constraints, then brainstorm around them

The plan is coming together well, but to lift the furniture every time it rains is a non-starter. We needed a plan that including timings that dealt with the fact that most of the rain events wouldn't actually flood our house. We want to avoid throwing out our backs if the water is not actually going to come into the house.

Plan Requirements: Save the things based on our priority, yet be mindful of the saving effort and probability of actually flooding. 

So our plan is broken down into phases to account for the Plan requirements.

Phase 1: Clean up the counters. 

Timing: Anytime the forecast calls for heavy rain / storms

Phase 1 involves cleaning the house. Clean off all of the counters and tables. Put away all of the stuff. No dishes in the sink,  no homework on the table, no unfinished project laying about, no laundry in the hamper, no clothes / stuffies on the floor.

Put away everything to where it is supposed to be. Clean and put away the dishes, do laundry, clean up all of the toys, put away all of the art supplies.

The purpose of this phase is to prepare the house in case it floods. We found that during our first flood, we were trying to save things, but there was stuff everywhere on the counters and it made it difficult to clean as well as lift. We also discovered that when we did salvage what wasn't damaged by water, that similar things ended up being boxed separately. (For example all of the things that were in the dishwasher, ended up being boxed and stored totally separate from the rest of the dishes).

If it doesn't flood, which is the most likely scenario, we have a clean house -WIN. If it does flood, we have created space to put things and have returned everything to its home so that it can be kept together.

Phase 2: Prepare to lift

Timing: Expected flooding event about to start OR water over the curb

Phase 2 is preparing to lift everything, but not actually doing any "saving" yet. For us, this means that we gather the outside furniture under the awnings around the house and near the doors. They are still outside at this point, but they are moved from their normal homes to a point where we can dry them off and prepare them to come inside.

We also gather the saw horses from the garage and the pile of cinderblocks and bring them inside.
We pay close attention to the forecasts / data (,, bayou level monitors) to determine how far Phase 2 goes.

We might determine that preparation is done at this phase, or we might determine that it is worthwhile to go ahead and get farther in the lifting prep work.

Going farther would mean that we would first move the cinderblocks to the areas that they would be used. We would start stacking the cinderblocks near the furniture in about the same size or related to the feet or footprint of the item. The idea being when we go to lift (phase 3) that we could pick up the item and put it down on the blocks fairly easily.  We are not actually lifting furniture at this point though (though moving cinderblocks is not exactly light work either).

We would stop and check the data again. If it is likely that flooding will not happen, we stop here. Sure there is effort to move the blocks, but we haven't rearranged the house yet. It is easy to undo.
If the data still indicates that flooding is possible, or our worry or PTSD is too high, we continue to build the platforms.

Platforms consist of saw horses and outdoor furniture with doors spanning them. We will take the doors off the hinges and create spans between anything that makes sense. This could mean we span the saw horses, kitchen counter and island, dining room table and buffet, etc.

Not only does this create a lot of up-space, but it could also save the doors if it does flood.

Phase 3: Lift

Timing: Flooding potential unknown / water past sidewalks

I'd be remiss, if I didn't include my favorite sound engineer joke (it might be the *only* sound engineer joke). Why do sound engineers say "Check 1...2...    Check 1....2...."? Because on "3" you lift. :)

Start lifting, but follow your priority. We lift our beds and sofas first, then the chairs, then the rest of the furniture. After that we start pulling out lower drawers, things still on the floor,  then lower shelves.

I have strong spacial packing skills (I'm always in charge of the dishwasher and the ornament box :)). I make sure that I'm maximizing our up-space.

NOTE: Anything wood will float! Free standing book shelfs are not safe place to put things, unless the bottom is weighted (also another good use for cinderblocks)

At this point, if it doesn't flood, we feel good that we practiced our plan. I find that working the plan helps me tremendously with the PTSD. I might grumble (alot) about un-lifting the furniture, but I (and my wife) appreciate having had actions counteract the worry.

The kids might or might not be able to help lift during this phase. If they are not able to lift furniture, have them take pictures..... lots and lots of pictures. I told my kids I want at least 50 pictures per room. Take 3 pictures from every corner into the room, then 3 more from every doorway. Take pictures of every shelf. Open up every drawer and take pictures. Take pictures of the art on the walls.
Please note, you might have to coach them that they should be clear pictures, and not hold down the button as they literally run around the room creating 50 house tinted blurs.

Phase 4: Water in the house

We found that phase 4 is an odd emotional time, as water is actually in the house. At this point we continue to lift the things that we have missed. Maybe we tackle the second or third shelves based on what the predictions are.

We had left one leaf of the dining room table for the kids to hang out in where they are safe and dry. There they are on devices to their hearts content.

This is also the point we, the adults, start taking pictures and notifying social media of our status. Inside the house, we would notice and record the areas that the water is entering as potential places to address in the future. This is also the time that we would call the insurance company, figure out our new temporary housing options, and connect with the contractor.

I told the kids that I was going to teach them a bad word. FUUUUUUUUU...... they said they already knew it. I said, well now is the right time to use it.... and you have to hold onto the U and really draw it out. And don't say it in school.

We discovered that during phase 4, we needed to lock our doors. During the 2nd flood, the water pressure forced an unlocked door open. For what it is worth, doors and walls act as a really amazing filter. The water, for the most part, is a lot cleaner if it has to work its way in, versus coming through an opening.

We also discovered that phase 4 might involve slashing the carpets. During the second flood, all of our furniture was secured in an up-space, but some of those spaces were on carpets. As the water rose, air got trapped under the carpet. Then when we would walk through the room, that air bubble would travel to our cinderblocks and platforms. So we took boxcutters and slashed holes in the carpets so we wouldn't cause our furniture to fall.

Finally depending on the data, we would start planning our abort procedure. We have not actually got that point yet during any of the floods, so I can only assume that we would blow up the boat and contact our neighbors.

Phase 0: When we are not flooding

So for all of the normal times that we are not flooding, here is some of the things that we have done to prepare for the next flood event.

  • Take inventory pictures of the house every 6 months and store them in the cloud
  • Bought a 5 person inflatable boat for the 4 of us and the dog
  • Bought a portable pump to be used to help empty out water from the house. We use it to help move pooling water around in our backyard as well
  • Bought a dehumidifier so that we would have one in case it flooded
  • Scanned all of our photos and photo albums and stored them in the cloud
  • Converted all of our VHS tapes to DVD and digital copies. Also stored in the cloud
  • Everything stored below 2 feet is in a plastic bin
  • Everything stored below 2 feet is not important to us or decently water resiliant
  • We have some waterproof kayaking bags should we need to keep things dry during an evacuation
  • Hired a plumber and made sure all of our area drains were clean and in full working order
  • Don't keep any extension cords or power strips on the floor any more
  • We have sealed up the places that we noticed the water coming through
  • We have 2 sets of waders so it is easier (drier) to walk around during the flood

Collected ideas from others: 

Here is a list of ideas that other people have talked about
  • Make sure that (at least some)  toliet paper is stored up high
  • Get life vests for the whole family (and pets). Rescue boats often don't have them and/or if you have to make your way to a neighbors house.
  • Move cars to higher ground, Uber home
  • Valet park at the airport (making your car their responsibility), rent a car with full insurance coverage
  • Empty buckets for make shift toliets

Monday, June 26, 2017

Fluent Conference 2017 - Personal Recap

Fluent Conference 2017 -- Personal Recap

The following is my summary and experience of my time at O’reilly’s Fluent Conference on 6/21 – 6/23 in San Jose, CA. This is not intended to be coverage of any of the sessions I went to, only an account of the relevant, interesting, and/or curious bits that I got from each interaction

Ignite Talks:

I enjoyed attending the ignite talks, especially since I was a runner up for presenting. The presenters were well rehearsed and did a great job in the rapid format that is ignite. I was able to take some notes on what I can do next RFP rounds to potentially get farther. 

One of the talks, which was particularly interesting was about communication and expectation settings

Good questions to ask: 

  • “What happens after I say yes?” 
  • “What happens if something goes wrong” 
  • Most of life is setting expectations and these questions help manage that

  • Lockdown: A security primer

    I always enjoy attending security sessions, It is always good to refresh your personal paranoia. Most of this isn't new, but there are some new attack vectors that I hadn't heard of before. For example the SSLStrip was new to me, as well as some of the easy client side attacks that are available now. 

    Apps are more complex, yet our security knowledge has remained relatively constant
    “Security is like insurance: You only know how good it is after there is an incident”
    Attacks are escalating in severity and the barriers to staging an attack are lower than ever]

    • Man in the Middle Attacks 
      • Defenses: everything needs to be https, specifically TLS not SSL 
      • For man in the middle with SSLStrip, defense is Strict Transport Security (including subdomains) 
    • Client Side Attacks 
      • This includes styles 
      • Opt in to software / libraries that do most of the user validation for you
      • Be very careful about your browser plugins 
    • Embedded malware 
      • Limit attachment types (and do more validation than just extensions) 
      • Optimize and re-process all images (especially dumping non-visual info)
      •  Do not permit arbitrary HTML input 
      • Whitelist content 
    • Cross Site Request Forgery 
      • Defense: CSRF Token with non-predictablity and per request configuration 
    • Click Jacking 
      • Defense: X-Frame-Options

    Async in Js

    This was a fantastic review of the pros and cons about the different methods of async in JS. I did not know about Async/Await or Generators. 

    • Callbacks 
      • Cons: 
        • Pyramid of doom 
        • difficult to decode
        • inversion of control 
        • (Note: Chrome has an async button in dev tools for debugging )
    • Promises 
      • Cons: 
        • No cancellation 
        • Lots of nesting 
        • Inside of thennable is still complicated, 
        • Too many libraries 
    • Async / Await 
      • Built into JS 
      • Looks synchronous but non blocking 
      • Still not cancelable 
    • Generators 
      • Uses yield and next keywords 
      • Easy to read – looks synchronous 
      • Pause and cancellable


     The keynote format had 5-8 mini sessions inside the keynote. The theme of the conference was "Build a Better Web" and obviously most of the keynotes focused on that. 

    • Are we really taking advantage of the technology? 
      • “Whether we are CSS or JS we are united by our users” 
      • On a screen, we are processing in the visual cortext, which means it drives out all other brain activity 
      • Apple ear buds are more than headphones, it is the start of implantable computers 
      • Could we interact without a screen? 
        • Could an always listening device (like Responsive Voice.js) give us a summary of the conversations of our day? 
        • Or help give insight into our mood? 
        • Could it make us better humans? 
    • Building a culture of collaboration in devops 
      • Things I need to look into more:
        • Atlassian Dev Ops Playbook 
        • Team Help Monitor 
        • is a focus on tools and the community, it allows for remixing projects for API and community 
    • The unsexy pillars of the web:
      •  Security, Accessibility, And Performance 
      • “You can’t fix what you can’t measure” 
      • We live in a web bubble of privilege of speed, access, and availability. 
      • “Data changes irreversibly into information can can not be extracted from the information”. It would be like asking “what were the dimensions of this melted ice cube” or “how much milk was used to make this cake” 
    • Accessibility is about software quality

    Functional JS Data Structures

    Excellent description of how functional JS works, especially with immutable arrays. The presenter was super passionate about functional JS and was a joy to listen to.  Most of the talk was defining fuctional data structures vocabulary

    • Perstistant data structures 
    • Path Copying & Structual Sharing 
    • Trie => retrieval tree 
    • Bitmapped Vector Trie (32 bit branches are ideal) 
    • Hash Array Mapped Trie 
    • Libraries
      • Immutable.js (sort of OOP) 
      • (more purely functional and based on clojure)

    14 ways to bounce a ball (through code)

    I had higher hopes for this session. Having taught Flash based animations for nearly a decade, and having left that scene a couple of years ago, I was hoping to get some intel on the tools that people are using to animate. Overall it was nothing more than a list of code based tools to animate. The presenter started out with a client created animation in Adobe Edge Animate, which of course has terrible, not maintainable output. So the presenter went on a quest to discover a better way to animate with maintainability.  Ultimately despite the research, could not create the richness of a visual animation tool, and used the Edge Animate output with all of its inline unmaintainable ugliness. 

    But for reference here is the list that he talked about. 

    • Browser 
      • Vanilla JS 
      • Css Animations 
      • SMIL – deprecated 
      • Web animations API 
      • HTML5 video tag 
      • Animated Gifs 
    • Tools 
      • Greensock 
      • Velocity 
      • Jo.js 
      • Anime.js 
    • Other 
      • Jquery Animations 
      • P5.js 
      • D3.js 
      • Matter.js 
    • Animations Paradigms 
      • Math (equations)
      • Physics 
      • Flipbook 
      • Keyframes


    Being a CSS novice, this was a great session to learn some of the less used features of CSS. I especially liked the alternative (better) option than important. 

    • CSS supports counting, and could be used for counting errors 
    • UI selectors that are not common 
      • placeholder-shown 
      • user-error 
      • indeterminate (checkbox w/ slash) 
      • read-only 
      • read-write 
      • Smell: use of important 
        • Instead of important, use multiple class decorations 
        • .disabled.disabled is stronger than .disabled 
        • #theirWidget#theirWidget doubles the weight of the selection 
    • CSS supports blendmodes
    • CSS supports shapes 
      • Clip-path (shape or SVG) 
      • Shape-outside is the HTML container shape for word wrapping 
    • CSS supports masking 
    • CSS “Material Design Icons” 
      •  Font-family: “Material Icons” 
      • Transforms words as icons 
    • CSS as a modernizer with @supports

    Schema First Development with GraphQL

    I have heard around the office about our GraphQL, I didn't know much about it, so this was an excellent primer. 

    • GraphQL provides an intermediary interface contract between the front and backends 
    • Better then REST because it reduces round trips and simplifies maintenance and provides only the data the client needs 
    • It is a specification not an implementation 
      • Schema with strong types 
      • Query schema 
      • Results 
    • Requirements 
      • Hierarchical 
      • Product centric 
      • Strong types 
      • Client specified queries 
      • Introspective 
    • “Prioritize the developer experience”

    Keynote Day 2

    • Diversity and Inclusion Post mortem 
      • 10 years and $500M invested and virtually no improvement 
      • What went wrong 
        • We have not defined good outcomes 
        • We have not created any methods of accountability 
        • Not measuring inclusion, retention, promotion, or equity 
        • Not monitoring all intersections 
        • Too much reliance on Unconcious Bias Training 
        • Not responding well to reports of harassment 
        • No safe methods to speak up 
    • You can’t get comfortable on the web 
      •  Best photo on slide of whole conference =>
      • You don’t need to know everything, but make sure you know your foundations well
      • why-learing-to-code-is-so-hard:
    •  On Community and Dev 
      • For humans communication is everything 
      • Technology isn’t neutral 
      • Commuinities break from lack of ability to deal with conflict 
      • Commuity is the thing shared with the person you like least 
      • Community is a group organized for mutual survival of their ideas 
    • Frustrations 
      • We are repeating the same ideas that were had at the dawn of the computer age, we have better implementations and new names, but the ideas are the same 
      • “Don’t frustrate your users” 
      • “Never underestimate mobile” 
      • Embrace good ideas 
      • Don’t take tech as a goal – tech is tool 
    • Progressive Web Apps 
      • This is the new buzzword, means app like experience in a mobile browser 
      • Note: Lighthouse is a chrome canary option in dev-tools

    Accessibiltiy testing:

    There was a heavy Accessibility (a11y) theme. It is nice to know that there are many automated testing tools for it. 

    • You can automate 30-50% of a11y issues
    •  Npm install axe-core for unit testing a11y in interaction / focus API, text alternatives, and ARIA states

    Source Maps demystified

    This was a deep dive into source maps. It was interesting discovering how they work. 

    • “JS is the assembly language of the web” 
    • To keep maps secure, you can change the domain (last line) of a source map to vpn or localhost

    Wednesday, April 13, 2016

    Agile simulations - lego game

    I teach an introductory class at University of Houston. This semester I did half technical and half soft skills (like Agile). 

    Given that I have a 3 hour class, I had the ability to try out the Agile simulation using legos ( )

    I had introduced agile to my class, but didn't go into any depth about Scrum or any of the other flavors. We basically had a conversation about if you were going to spend a lot of money on something that you were unsure about the final result (like a full sleeve tattoo), what steps would you go through to ensure that it matched your expectations. 

    All of this saying, they were not familiar with actually implementing agile or scrum. 

    I brought in a huge tub of my kids legos and set them in the middle of the class. I also brought 8 smaller storage containers that would allow the students to take scoops of legos back to their desks / work area. 

    I introduced the project explaining that we were going to be building a lego city, my lego city, and that I recommend that they break into small groups of 3-5 people (class of 25, although about 50% decided to not show up), and rearrange the furniture as they saw fit to prepare to build the city. 

    While they moved a couple of desks to sit on the floor, they generally used this time to come scoop up containers full of legos to take back to their spots. Meanwhile I covered the "land" with paper.  I informed them that this paper was were the city was to be built and that for certain things, like roads, it was okay to draw them on the paper rather than make them out of legos. 

    Then I introduced the things that I wanted in my city. I had, in my head, organized them by potential teams, but I never mentioned that to the class.  I also intentionally didn't mention the acceptance criteria unless asked. 
    • Living: 
      • 4 x 1 story homes 
        • Must have a window 
      • 2 x 2 story homes 
        • Twice the size of a 1 story home 
      • Apartment 
        • 3 stories, outside stairs 
    • Recreation 
      • Park 
        • Trees 
        • Playground 
      • Stadium 
        • Open roof 
      • Zoo 
        • One animal and enclosure 
    • Business 
      • TV station 
        • Satellite dish or Broadcast tower 
      • Retail shops 
        • 4 doors, each shop a different color 
      • Hospital 
        • Has a red plus on it 
    • Education 
      • Elementary school 
        • Has a fence 
      • University 
        • Looking down on the top of the univeristy it should look like UH 
    • Worship 
      • Religious symbol on it 
    • Infrastructure 
      • Power station 
        • Wind turbine (ie propeller) 
      • Waste water treatment 
        • Visible Pipes 
      • City Hall 
        • Dome on top 
      • Transportation 
        • Mass transit 
          • 8” and 6+ wheels 
        • Dedicated bike lanes 
          • Barrier from cars 
        • Roads 
          • Drawn + 1 car 
        • Airport 
          • 1 plane + terminal

    I wrote each item on sticky notes, and used Team estimation game to size the stories. (Think bubble sort). We were about 60% of the way through (when we got to the university), that they started to ask about what I was expecting for the university.

    Since we had been sizing the stories as we went, we decided that we needed to start over. This time through we talked about the acceptance criteria before they determined left, right or same for the sizing.

    Once all of the stories were grouped and positioned, I assigned Fibonacci numbers to them for the points. We had 1,2,3,5,8,13,21 and 50.

    I then organized the stories into a priority order. (I wished I had taken a picture of the final priority order before doing sprint planning). Meanwhile I had told the class to figure out if they were going to represent themselves as the separate teams, or as the company as a whole and to determine what they think is a good number of points to take on for the first sprint, which was 8 minutes.

    We had 4 minutes for sprint planning, where the class, having decided that they were one company (instead of 5 teams) choose the items from the backlog that they were going to deliver for the first sprint. (They completely ignored the priority order and choose what they wanted to work on, including the lowest priorty highest point story). Also somewhat independently, some of the students had already started building, while others where choosing the stories from the backlog.

    We started our first 8 minute sprint with a 106 point commitment. When the bell rang, there was nothing on the "land", so they got zero points. They were pretty disappointed, because they didn't realize that their structures needed to be on the table by the end of the sprint.

    We did a 4 minute retrospective, where again 5-8 students participated and another 4 minute planning, the others continued building. The planning was essentially moving over all of the unfinished stories, but they did add another 3 point story. Sprint 2 started with a 108 point commitment, but many of the structures were "done" and on the land within the first couple of minutes.

    The different groups, not surprisingly didn't talk to each other, and using the single story house as a scale reference, the "3 story apartment" was about 1/3 the size of a 1 story house. The hospital was about 1/2 the size of the house. The stadium, (the lowest priority and highest points), was done and used up a significant amount of lego bricks (that they would want for the next round).

    Sprint 2 ended with 96 points of the 108 awarded. The Sprint 2 retro was largely ignored as everyone just kept building. One person participated in sprint planning. They didn't move any of the unfinished stories over, but they did add 2 more stories. Ultimately they ended up committing to 6 points but completing 46.

    Here is a photo of the finished city.
    Front L to R: Water treatment, power station, place of worship, university, stadium, hospital, airport
    Back L to R: zoo, elementary school, playground, 1 story house, tv station, 1 story house, 2 story house, apartment

    From the debriefing after the last sprint, here is what the students said were issues, especially after talking about some of the things in red from above:
    • knowing the scale of the buildings
    • not knowing what the other groups were working on
    • Initially there was no talking, but it really improved towards the end when the groups started working together
    • Pain point: What does the client expect to see
    • Pain point: Client Priority
    • Pain point: Dimensions / scale
    • Pain point: 8 min sprints were stressful
    • Pain point: looking for resources / running out of resources
    We talked about how they were overall more interested in building (playing with the legos) and less interested in understanding the clients needs. We talked about how they were also skipping the planning, which helps communicate expectations to the client, as well as the retro which would help them improve the internal processes.

    We then talked about variations and improvements. Interestingly enough most of them expressed that even though there were improvements that could have happened in the delivery of the exercise, they valued the mistakes that they made as it were, and ultimately decided that I should not add any more explanation or details the next time around.

    Overall, it was an incredibly useful exercise and discussion around teamwork and communication with the client.

    Wednesday, January 14, 2015

    Treadmill desk as a software developer - injury

    So a couple of days after my last post, I did have a treadmill related injury.... sort of. It wasn't cringe-worthy youtube kind of injury. It wasn't even an injury that was ON the treadmill.

    I was turning left to go into my closet and something BAD happened within my calf. It was crippling and I could barely put weight on that leg for two days. I used a lot of RICE (Rest, Ice, Compression, Elevation) and was able to start bearing weight again.

    My theory is that being on the treadmill, is that given it is a very straight and even surface for such long durations (10+ miles) and low impact, that I have been over developing my "walk straight muscles". So when I went to turn a corner, my now weaker "turn muscles", were literally squeezed out of place by my others.... It is my theory anyways.

    Some loose proof that I have that supports this, is that while I was recovering, I was acutely aware of variations in the ground, unevenness, and different textures.

    So now that I'm recovered and nearly able to to 10 miles again, I'm spending more time on the treadmill walking sideways. I'm also stretching mulitple times a day, using foam rollers and hard massage balls, and making sure that I spend more time off the treadmill and outside on the un-even sidewalks.

    Wednesday, December 17, 2014

    Treadmill desk as a software developer - 3 month

    So we've been going on three months now. I'm able to walk about 30K (~14 miles) steps at least twice a week without feeling too bad. I've killed my tennis shoes that I bought during the summer, so I guess one side effect is that I'll be going through shoes much faster now.

    Things I've noticed:

    • There was an online conference, that I was watching while I was working. This was great, but given that I was already switching between 2 engaging contexts, I didn't notice that I was walking, and I over did it again (37K steps, 2 days in a row before I noticed what was happening - I guess that means I'm getting better endurance). 
    • On the day that my fitbit battery died, I wasn't motivated to walk until it was charged. Apparently I definitely want my steps to "count" 
    • Grading my class assignments is MUCH more enjoyable while walking. Previously I could barely get through 1 without needing a break, now I can do them all in one "sitting"
    • There is a nice pile of dust, crumbs, etc that ends up on the mat at the back of the treadmill. 
    • I hardly ever sit down anymore at work. Although I do still stop and stretch occasionally. As I try to hit 30+K once or twice a week. 
    • I keep a set of hand weights on my desk for meetings, where I don't have to participate or take notes. 
    Overall I've lost 12 lbs (fluctuating wildly as we go through Thanksgiving and the holidays :))

    Still nothing but good things to say about the treadmill desk.

    Monday, December 8, 2014

    What I learned about coding from 5th graders

    So today I was mentoring / volunteering for Kolter's Hour of Code ( and I got to observe 3 different 5th grade classes come through to try to program a visual game like Angry Birds or Lightbot.

    Just for context, both of these games involved sequencing directional puzzle pieces to perform a task. For Angry birds, you would move the bird towards the pig, and for Lightbot, you'd move the robot along a grid lighting blue squares.

    Not surprising nobody read the directions or prompts before diving right in. The part that I found interesting, was that very few would try to solve the problem in small steps.

    Nearly every pair (they were pair programming.... woot!) whether they read the prompt or not, tried to solve the entire puzzle before hitting play. It of course wouldn't work. Then they'd throw nearly the whole thing away and create another complete solution, which also wouldn't work.

    One of the things that I coached them on was to test often.... put down one or two commands and see where you are on the sequence. Basically to get faster feedback.

    So I'm curious as to where in life do we learn that we have to solve the whole puzzle at once?