Skip to content

Posts from the ‘Uncategorized’ Category

Why ultimate players should move heavy things

This is a quick post to collect some thoughts on how strength training applies to ultimate frisbee.

A good place to start is a take by runners world on strength training for runners.

They lay out some good arguments for the basics of strength training and how it relates to an activity that is primarily lower body locomotion centric. Here are my thoughts on the specific movements we choose to start with in our ultimate frisbee strength training class:

Front Squat:

Front squats to a great job of building lower body strength and flexibility with a quad bias. We use our quads to decelerate (think the hollywood squares drill or anytime you are making a cut) so having a strong base including quad strength is important. Additionally front squats require good ankle flexibility and strength. Because the ankle is put into dorsiflextion ( the achilles and calf are stretched and strengthened reducing the risk of achilles tendonitis or injury.

Shoulder Press:

A lot of frisbee players injure their shoulders laying out, or even just extending to catch a frisbee in a contested space. Improving shoulder strength and flexibility enables us to survive contact with the ground or other players with reduced risk of dislocation or fracture. Strict pressing or overhead pressing is more beneficial than bench pressing because it requires overhead flexibility and strength. If we struggle to press weight overhead often it is due to shoulder inflexibility first and lack of strength second. Gain the flexibility, build the strength, keep the arms in the sockets.

Kettlebell Deadlifts:

Kettlebell deadlifts are the first in a series of progressions intended to strengthen the posterior chain. We can be more explosive as sprinting athletes if we have a strong posterior chain. Learning to brace and engage your core, transferring power placed into the floor from your posterior chain all the way to your hands/arms through your core train and strengthen your body in the application of force to move a heavy object. 

Thoughts on strength, to power, to speed to endurance:

The goal is to progress through a sequences of movements that enable us to accomplish three things over time:

  1. Build muscle activation/strength within our existing flexibility, improve flexibility (range of motion available to us), and increase strength in the new range of motion we’ve gained. 
  2. Transfer that strength into explosive power, moving from slower movements (press, squat, deadlift) into faster movements, moving similar weights over similar distances but faster. Squat to a jumping squat, wall ball or box jump. Deadlift to a kettlebell swing, power clean, or jumping trap bar deadlifts. Strict press to a push press, push jerk. Explosive power, that is applying a force quickly, is what really enables us to move faster on the field. Explosive power requires and is built on top of a strength base through a long range of motion.
  3. Finally building the muscular endurance and cardiovascular endurance while retaining the strength, flexibility and power we’re now able to operate with allows us to move faster over longer periods of time, like over 3 days…

You aren’t your users

I really enjoyed this most recent Under the Radar by Marco Arment and David Smith. It made me think of a lesson I learned earlier in my career as a developer/designer. When you are building an application that meets a need you have, it’s easy to use yourself as a proxy for the product user when designing/developing.

In the best case this approach helps you to develop an application that can delight users by meeting not just their vocal needs but also their unarticulated needs. Because you know yourself and your needs more intimately than anyone else, you can build really cool solutions to problems that your users wouldn’t be able to put into words. Your intuition will guide you to spend more time polishing areas that others wouldn’t and often times that pays off with a better product experience. This is possible for teams that are solving problems they themselves don’t understand, but it requires much more UX/UI spend, lots of prototyping and lots of user testing. Sounds expensive.

So while this approach can be a great time/expense saver for smaller teams or independent developers, it can unfortunately also lead you to a substandard product/market fit. It sounds obvious to say but it’s easy to forget that you aren’t the only type of user your product will have. I can hear echos of this in Marco’s description of his aversion to prompting users by sending push notifications to point out new podcast arrivals for new users. Marco finds those things annoying and maybe a bit needy. Do I find it annoying when a new app prompts me to come back and check out some feature I haven’t used? Yes, but that’s also because I’m a tech nerd and when apps try to tell me how to use them I get annoyed either because “shut up I already know that” or “You think I can’t figure this out on my own”. The much much more common user reaction to a helpful notification is going to be “oh, hey that’s handy I didn’t know that” or worse case “I’ve already given up on that app so this doesn’t matter”.

It’s very easy for us to transpose too many of our own needs and traits onto our pretend users if we aren’t able to be introspective about why we care about the things we care about in the products we are creating. A small amount of time creating personas for some of your anticipated users and where and how you fit into them can go a long way to improving your product.

You can’t redefine someone else’s problem

Walt wrote an interesting line in a recent think piece on the Verge. He makes a lot of interesting points as usual, but one little quote got me thinking about an easy and frequent mistake we can all make. In the process of looking for solutions and making commentary we often times subtly redefine the problem someone else is having.

But there are other paths. For instance, that HP Spectre I mentioned earlier is actually a tad thinner, but manages to add a couple of additional ports on the back edge of the machine, and to use full-fledged processors, even if they required a cleverly designed fan.

In the emphasis I added above you can see Walt doing this with the design of the MacBook (non-pro) that Apple has been shipping for the last few years. I used the first design of that machine and agree with all of Walt’s criticisms.

What I don’t agree with is the idea that you can hold up another computer that makes different design trade offs as a direct comparison to the trade offs on this particular computer. The design brief for the MacBook probably read something like “needs to be able to email, browse the web, use office class applications, road warriors dream, long enough battery to last cross Atlantic flight”. Walt would rather have a computer that makes different trade offs. To call this a symptom of “overdesigning” a product isn’t really accurate. It’s a symptom of designing a product for a different set of trade offs than the ones you prioritize. Walt is right, this happens all the time, and I see it as a positive thing.

The uncharitable usage of the word Design implies frivolity. But I think what is happening more often is that companies are being very focused, and in the process eliminating a lot of use cases from their product. This isn’t a bad thing, it allows products to be brought to market faster and with less budget, however it does eliminate possibilities, and in my experience reading the tech press, there is nothing that riles a tech journalist up more than a product that could do something if only the product designer had made the product the way the tech journalist thought it should be made.

Technical Journalists do their best work when they put themselves into the role of a user of a product and seek to understand how the company creating the product has done the work of designing the product trade offs to fit that use case.

Product designers do their best work when they are able to capture a clear picture in their head of how a new thing can be created by questioning the assumptions under which we all operate, and integrate some novel thinking into a product in a way that feels like a natural consequence of problem solving.

Mac – the pros

Just had a thought that wanted to get time stamped so I can “I told you so” later.

When Apple updated the MacBook Air to the new haswell processors many were surprised that they didn’t also update the MacBook Pro line as well. Improved battery life with comparable performance is always great for laptops and the MacBook Pros are no exception so it was a strange omission.

My speculation as to why is because Apple plans on launching a major update in the fall that includes the following:
– new Mac Pro
– new MacBook Pro with retina display
– new 4k displays that are retina capable

The reason they didn’t update the pro laptops is not because they are waiting for haswell but because they are waiting for thunderbolt 2, which they need to support the new displays.

Very simple Kanban workflow in Trello

We’ve been using the following technique since shortly after Trello launched to accommodate our Kanban style agile development workflow.

Quick review: Kanban borrows from lean manufacturing principles and is a Pull based system rather than a Push based system. Team members “pull” a card into their todo list when they have a vacant space rather than having a manager or another team member “push” an item onto their todo list.

To facilitate this in Trello we did something very simple. On our board, when you pull a card onto your list, you assign yourself to the card to indicate you are working on it, when you are done, you remove yourself from the card and move it to the bottom of your current list. If you are blocked on a task but it isn’t complete, you label it with a red label which on our board means “Blocked”.

If you have an open slot on your list you look to the previous list for any cards at  the bottom of the list that are not currently assigned. Unless they are blocked (red tag) they are available to be pulled.

The only list that breaks with this form is the “Up Next” or backlog list. That list is pulled from the top rather than the bottom, mostly so that we can easily visualize our top priorities that haven’t started implementation yet and can easily reorder the backlog when necessary. Same principals apply though, if the backlog has a person assigned to it, it’s not ready for development, and it it’s Red it’s blocked and can’t be moved forward. Developers skip over those cards when pulling from the up next list.

Simple and effective.

The challenge of defining what people want

I think John Gruber has issued a somewhat oversimplified argument when he says:

…people want more different native apps than ever before.  via daring fireball

I think any designer needs to be careful to not conflate the mechanism used to achieve a desired result with the result itself. Gruber’s assertion here is that users want native applications. I believe that what he is really saying is that users want responsive applications, that work while disconnected from centralized services, and that show up on their home screen. Those are not web apps as they are available to us today, but as in anything in the software world that is a flexible assumption.

My point here is a relatively minor one, but one that can be a common roadblock for creative problem solvers. If we don’t question the assumptions of the underlying mechanisms we will unnecessarily limit the potential solutions available to us. Sometimes the most obvious and straight-forward solution to a problem is found by questioning the underlying assumptions. Technology problems are sometimes solved by changing the personnel around them, or personnel problems can be solved by augmenting the situation with technology. Emotional problems can be solved with exercise, and your exercise limits can be overcome by understanding that your current limitations are psychologically imposed.

If we assume that the solution to responsive disconnected applications can be nothing other than compiled Objective C delivered through a curated app store we cut ourselves off from a wealth of potential solutions to the problem. Only in redefining and clarifying our users unarticulated needs are we able to break through creative barriers and deliver truly ground-breaking technological innovation. Granted I love native applications and “want more different native apps than ever before”. I think John’s statement is true for today, but that it’s an assumption that should constantly be challenged and revisited. We can’t simply condense the current failure of web apps to deliver on users needs to be a condemnation of the entire pursuit.

Solve problems the way they want to be solved

via flickr user origamijoel

Most folks have a preferred problem solving method. Some know this, and stick to those well worn forumulas. Some don’t, or forget, or let the fear of missing out trick them into going after opportunities they shouldn’t. One of the keys to successful problem solving is to understand your natural approach and when that approach does or doesn’t fit the problem you are considering addressing.

Let’s look at Apple Maps as an example. With almost unlimited resources and skilled/motivated workers why couldn’t Apple seem to make Maps just work? I believe the primary reason is that their culture doesn’t value the type of work it takes to create a killer solution to that problem. Apple is very good at giving designers time and space to come up with brilliantly innovative solutions to problems. Elegant solutions are coveted. Wherever possible a solution is simplified rather than made more complex.

Unfortunately Mapping is not a simple problem, nor is it one that can be reduced. (see the traveling salesman problem) Instead of one single elegant solution to a large problem, mapping requires many small imperfect solutions. Google is willing to embark on a massive, inelegant solution to a complicated problem. (Remember their company was founded on the premise of “downloading the internet” so you could easily search it)

Finding point A on a map and getting directions from point A to point B doesn’t need to be perfect or elegant, it just needs to work. Apple as an organization has never been satisfied with making something just work (ironic given some of their historical marketing efforts). Unfortunately the solution to make maps “just work” is to add a parenthetical “even if it’s inelegant like driving around taking pictures of every street in the world” to the solution.

The reason that Apple isn’t able to create a successful mapping product is because their culture won’t let them do the kind of work necessary to create a successful product.

Hills Hills and more Hills

Seth Godin chooses the same metaphor as I did in a recent post.

Attacking only steep cliffs where no progress is made isn’t particularly effective either. No, the best path is an endless series of difficult (but achievable) hills.

via Seth Godin

It’s all about the hills…

Naked Devices or Burn the Lifeboats

I’ve never bought a case for any of my personal electronic devices. One time a few years ago our IT manager required screen protectors for all of the phone we had recently purchased. I immediately took mine off (oh yes, quite the rebel here). The protectors were supposed to stop the screens from getting scratched up in our pockets, but the immediate result was a dark, scratched looking screen, the exact problem the plastic slip was trying to avoid in the first place.

I’ve had a few good sports injuries over the last few years, and sometimes the road to recovery can look similar. We avoid doing things that hurt because we are afraid it’ll set back our recovery, when sometimes we need to embrace the hurt and push through the limits to force our body to adapt to normal movement patterns instead of our injured ones. My trying to protect against injury leaves us more injured than we should be.

In a business setting, when trying to build resilience in a business model we sometimes build too much diversity in our plans. “If market A doesn’t work out, we can try B or C or D”. Havig a plan B is a good thing, unless you end up sacrificing your top priority in order to keep your backup plans alive.

This is a really common problem. Sometimes when trying to protect ourselves we actually sabotage ourselves. Seth Godin says entrepenuers sometimes succeed because “There are no life boats”.

Sometimes we need to burn the lifeboats, risk a little reinjury to prevent the long term decline, and risk scratching the shiny glass back of that brand new cell phone.

image via singlefin

Progress is rarely linear

Recently I’ve reached a plateau. Over the last month I’ve reached a certain level of competence as a snowboarder. Nothing amazing mind you, but I’ve reached a point where the blue runs tremble in fear at my approach. I would be hard pressed to say this isn’t a good thing, after all I am certainly enjoying my hat staying above my shoes for most of the day, but over the last few trips up to the mountain I haven’t really gotten any better.

Here’s the question. Should I start pushing myself to do harder things, or should I spend some time simply being content with the skills I’ve acquired so far?

I’ve heard it said that if you’re not getting better you’re getting worse. A lot of times it’s applied in the business world but there is truth to the saying in our personal lives as well. If we aren’t getting faster we’re getting slower, if we aren’t getting stronger we’re getting weaker.

The truth I think is less black and white and more gray. Plateaus are our greatest accomplishments and also our biggest barriers. Since we are infinitely adaptable (well ok, there are probably limits) we will plateau thousands of times throughout our life.

They key seems to be being able to live with a kind of cognative dissonance that both enjoys and appreciates the contentment of a plateau, while at the same time nurturing a sense of discontent with the status quo. To experience both feelings simultaneously.