Skip to content

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.

Nexus 7 and iPad Mini

For the first time since its introduction I find myself in the unusual position of being unable to recommend an iPad. Specifically the iPad mini. I’ve been casually testing the new Nexus 7 for a few weeks and find that transitioning back to the iPad Mini, while necessary for the productivity apps, and larger screen size, is nowhere near the pleasure it once was.

The Nexus 7, while occasionally sluggish at scrolling, really is running a better piece of silicon than the iPad Mini. It’s not really surprising since the Nexus 7 just launched and the A5 is several years old at this point. After using the Nexus 7 a refreshed iPad mini in the late summer or fall seems inevitable at this point.

My verdict:

Don’t buy an iPad mini today.

Don’t buy a Nexus 7 until after Apple’s next press event, unless you are already an android fan, in which case the Nexus 7 is a very nice device.

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.

The Durability Paradox

I was reading this article on durable product design at Core77 when I came across a phrase that struck me as being somewhat incongruous.

But what he found was that most of these so-called durable goods were not up to snuff…

… In April of 2010 the first iPad came out, and Hofert bought one. The iPad had of course been a top-secret project at Apple, and upon its release there weren’t a lot of cases available for it. Hofert got himself a scrap of leather hide and decided to make one of his own.

via Core77

The article itself is quite interesting, and Hofert has built himself a fanastic group of products around this idea of durability in an age of ravenous consumption. However I found the example to be an odd one. I also purchased the original iPad and saw this problem unfold myself. Initially only the base cover from Apple was available but over the next few months many alternatives came about. Leather, canvas, wool, all kinds of interesting and not-so interesting designs. Being a bit of a fashionista myself when it comes to a daily carry I can appreciate designs in the finest and most durable of materials and was attracted to these myself. I never pulled the trigger on buying one though, and I think this article helped me understand the reason why. A leather case for a first generation iPad is a durable solution to a non-durable problem.

A durable problem is a problem that lasts. A durable product is a product that lasts. A durable product for a durable problem is a product that lasts solving a problem that lasts.

A leather wallet is a durable product. A waxed canvas bag with buckles instead of zippers is a durable product. A double stitched pair of duck cotton work pants is a durable product.

Storing your ID and cash is a durable problem. Carrying items with you as you walk, bus, bike, or drive is a durable problem. Wearing pants is a durable problem.

Carrying a $500 technical accessory that will be replaced in 15 months is not a durable problem. In fact I would argue that in the course of designing a durable solution that problem, you are actually creating more problems than you solve. If your leather backpack lasts 30 years, that’s great, you’ll get 30 years of great service. If an iPad case that fits the original iPad lasts you 30 years you end up with a fantastic case for 2 years, and a strangely shaped piece of leather for the remaining 28 years.

Creating durable solutions to durable problems is an investment in the future and a fantastic use of time and resources.

Creating durable accessories for non-durable problem is a fashion statement, and a potential waste of time and resources.

Not that there is anything wrong with fashion statements. Nor do I think that an iPad case was really Hofert’s goal, just his first experience in leather working. I simply find it a funny example to choose when trying to highlight the benefits of building durable products, to choose that example.

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…