File -> Document Setup
Click Edit Artboards (upper right)
Cab then set exactly in artboard options.
A blog about creating valuable software
January 18, 2015
December 27, 2014
Here are my notes from a great talk by Tina Seelig (hostess of Stanford e-corner) on a model for describing creativity and inspiration.
Need vocabulary to describe words like: creativity, innovation, entrepreneurship. Don’t have good definition for these words. Sharp contrast to other disciplines like maths, physics.
So we need a model and way to describe. Here is the model/definitions/framework for describing these concepts.
Imagination – The ability to envision what doesn’t exist
Creativity – Applying your imagination to solve your problem.
Innovation – Applying your creativity to come up with a unique solution.
Entrepreneurship – Applying your innovation to bring those ideas to life.
Now can break down and see what have to happen at each level.
engaging and envisioning
you need to start with engagement
if you don’t engage, you won’t see opportunities
Most people don’t pay attention
Go through life with blinders on
Miss opportunities – because they don’t engage
Hence they can’t envision
Many people don’t know they have a passion until they engage
requires motivation and experimentation
most people in world are puzzle builders
they know exactly what their life should look like, and they assembles pieces to complete the puzzle
they are the ones who get stopped by barriers
creativity people are quilt makers – they weave stuff together
many of these people stcratch itches they fac
13:39 Monster maker – cheap prototyping experimentation
focus and reframing
this is for deep insights and breakthroughs
reframing is when you start looking at the problem from all different angles
? + ? = 10 infinite answers
they way you ask the question is profound
the question you ask is the frame into which the answers will fall
Example – Plan big birthday for Morgan
if we change one word to
Plan birthday celebration…
The set of solutions completely expands
If you don’t ask the right question, you won’t get the right answers
18:38 How to reframe problem and come up with innovative solutions
persistence and inspiring others
persistence = grit
people who will walk through walls to get things done
also critical for you to inspire others to join you
22:45 Global innovation tournament example
Organizations need people playing all these roles.
December 23, 2014
December 18, 2014
Notes from a great talk by Liz Wisemen at Stanford Entrepreneurial School.
Is there a danger in knowing too much. A danger to our companies, teams, and innovation.
How does what we know, get in the way of what we don’t know, but perhaps need to learn.
Is it possible that really smart leaders don’t create smart organizations.
That really smart leaders can shut down intelligence, and brilliance, and innovation.
Want to explore the power of being a rookie.
And the power of inquiry.
Explore the power of not knowing.
Experience creates a number of troubling blind spots.
You build up scar tissue – reminder of not to do certain things.
Then when someone new comes along and suggests something that brushes your scars you instinctively reject that idea and say no. We already tried that.
You need a deliberate ritual to get back to your roots.
Bob Hurley tells this story of once meeting Wayne Barthoromyy (Rabbit – reigning world champ from Australian) on Huntington beach, and asking him why he wasn’t surfing where the good waves are. Wayne replied that he liked surfing with kids because that’s where he gets his energy.
So he goes out and surfs with the amateurs. He seeks out the newcomers. Recent college grads, and just hangs out.
Can smart leaders create dumb teams?
Why are we so smart and capable around some, but not others?
Diminishers believe that because they are the boss, they must know better.
Since they are management, they conclude they are the smartest ones on the team.
Therefore my job is to tell, instruct, micromanage.
Multipliers do it differently. They ask questions. They also have hard edge.
They are demanding. They have a hard edge.
They have high expectations.
They challenge. They have become really comfortable asking others to become uncomfortable.
They let you suffer a bit. They let you squirm.
Diminishers operate from a place of knowledge. Their knowledge. They tend to be empire builders. Tyrants. Creating anxiety, stress, micromanagers.
Multiples operate from a belief that people around me are smart. I hired them smart. They are talent magnets. They give accountable to others. They operate from a place of inquiry.
Most of the diminishing done in companies is done with the best of intentions.
People who think they are doing a good job.
The idea guy who spouts ideas.
Or the always on leader.
Or the rescuer. The leader who doesn’t like seeing others suffer.
Or the pace setter. Who sets the pace hoping others will follow.
But instead they don’t. They walk. Because they’re not winning.
Because it’s not fun when you can’t keep up with the boss.
How might you be shutting down intelligence and capability?
One of the most powerful shifts you can make is shifting from knowing to inquiry.
You need to be able to ask the right questions that share the burden with the team.
The best leaders not only give pats on the back, they give a push and get their people into the uncomfortable areas.
It’s irresponsible to let your team suffer.
But you need to remember to give the pen back. (50:47)
December 18, 2014
Be the most positive, enthusiastic person you can be.
Look down on no other persons idea, suggestion, or problem.
Solidly support them in whatever it is they endeavour.
Lead by example.
Kick ass with a smile on your face.
See every challenge as an opportunity,
Do this and you will have no problems.
December 13, 2014
Last week, a group of us did an XP Tech Practices workshop here in Stockholm. We covered Test-Driven Development, Refactoring, Unit Testing, Pair Programming, and a host of other Old school XP practices. Here are some notes and a write up about the course.
XP (Extreme Programming) was the first really popular Agile method. Not only did it introduce Agile planning concepts such as user stories, adaptive planning, and iterative development. It helped popularize engineering practices such as unit testing, refactoring, test-driven development, and continuous integration.
It isn’t as widely practiced today as it was in the early 2000’s (Scrum has largely taken over). But it has many wonderful practices and ideas that deserve repeating and are still very much relevant for software teams today.
This workshop aimed at revitalizing some of software these practices, showing participants who they were originally meant to be performed, and then discussing how they can be introduced into their workplace.
We start off the course by asking participants how they feel about their work. Specifically around quality and design. We do this to start a conversation around what quality is, how we know when we have good design, and what obstacles prevent us from reaching them in our software.
We then break the ice by asking participants to code something up (like a calculator). We do this to get the juices flowing, engage the participants, and just get them hacking. This helps us see where they are coming from, their familiarity with the programming language, and how comfortable they are writing code.
We don’t judge or do anything with the code that we produce here. We simply park it, and revisit it later. We then introduce XP.
XP can best be described as the software methodology that turns the knobs up to 11.
If code reviews are good, we will review code all the time (pair programming).
If testing is good, we will test continuously (acceptance tests, unit tests, TDD, demos).
If design is good, we will design continuously, every minute and every day (refactoring).
If simplicity is good, we vow to always leave the system in its simplest state.
If integration is good, we will integration continuously (continuous integration).
And if iterative development is good, we will iterate from day one, continuously getting feedback on our product, plan, and ability to please our customer.
Once we’ve covered the spirit and intent of XP, we demo the practices. We pair program up a sample problem, applying TDD, refactoring, unit testing, and pair programming in an extreme way, just to give the participants a sense of how all the practices work.
We then revisit the exercise they did in the ice breaker, and try it again, this time using the XP practices, specifically writing the tests first.
We then unleash them on their own codebase – specifically a game. They take what we’ve covered, and apply the practices in as an extreme a way as they can, and we build a fun interactive game over the course of several iterations.
Over the span of the course we look for opportunities to introduce XPisms. Things like:
YAGNI – You aint gonna need it. A reminder to keep things simple, and not add excess functionality / code unless absolutely required (a good test is whether you can write a failing test first before adding the new code).
Production Readiness – A system spends a lot more time in production than in development. So why don’t we start treating it that way, and write code as if we were in production from day one.
Doing the simplest thing that could possibly work –
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. – C. A. R. Hoare
Test everything that could possibly break – We can’t test everything. But we know we can’t test nothing. So we start by testing everything we think could break. And evolving our suites from there.
Dials to 11 – XP’s take on hard problems is to take them head on. Taking this approach takes many of the traditionally hard problems on software projects, and breaks them down into much smaller, easier to digest pieces.
Courage – Have the courage to write that failing unit test. Have the courage to say no to the hack on your finger tips. Have the courage to say no to the unrealistic schedule, and help another team out when they really need it.
It may seem that XP is all about engineering. It’s not. It’s just as much about culture. But the culture XP wants the team to operate under doesn’t happen if certain practices aren’t in place. This course is about explaining the practices, showing how they work, and then helping teams adopt them their work place.
A special thanks to Henrik Kniberg for the initial course outline and for his support in making this course happen.
“I was supposed to have a Hackday today, but this is WAY better”
“I found the course to be a lot of fun, and learned a lot about TDD/XP in the process. The exercises, particularly the four-part exercise to build a game for a customer, were a very good balance of difficulty and fun, and allowed me to learn at a good pace without being bored by trival tasks or overwhelmed by difficult ones.
In fact, the game task actually, perhaps accidentally, was almost tricking me into learning stuff. You know you give a kid a toy that’s actually teaching them maths without them knowing because they’re having fun with the flashy lights? It was kinda like that.
★★★★★ Five stars, genuinely one of the best in-house workshops I’ve attended.”
“Got a good amount of new perspective on XP and TDD. Got into the habit of writing unit tests during instead of after development. And it was a lot of fun!”
November 21, 2014
Yesterday I attended a session put on the People and Organizational Change group here at Spotify, and I liked the question we used to start off the workshop.
This task/workshop/activity/tool/doc would have a positive impact on the experience of joining Spotify.
I like the question because instead of just griping and complaining, it forces the attendees to switch from problem mode to solution mode.
Great question. Going to use this sometime in the future.