Archive

Posts Tagged ‘learning’

Tau Conference #3

January 20th, 2012 4 comments

In a month we will run our third internal conference. This is supposed to be a full-day event, with one-of-a-kind sessions prepared and presented by our team members.

Here is the program:

Tau Conference #3 Program

Mastery vs. GTD

May 23rd, 2011 4 comments

Mastery by George Leonard is one of my most-cherished-books-of-all-times. I’ve seen this book mentioned on a tennis web-site, and not even once, as I’ve been digging the web for some nuggets of information on what in the world do people do to make their game perfect and enjoy it. Ironically, now I can see that these 2 searches are absolutely irrelevant.

I wouldn’t say that this book has unveiled some unknown truths. It gently reminds of the basics for any learning making readers aware that the mass culture quest for scoring, quick wins and quick fixes at any rate proves wrong in the long run and brings along the consequences more grave than one can imagine.

aikido dojo
Calm face and full concentration. Check large size

There’re some important conclusions I have made for myself out of this book, to name a few:

Mastery is Enjoying

The first and most prerequisite for practicing any art or hobby or job is that you got to enjoy it. Love doing it. Not reading about it, not writing about, not showing off before others, not thinking about the competition. George Leonard cites various examples of this sustained desire to just enjoy it, for example: Aikido black belts are never bored to practice simple moves finding newer and newer shades in what they do, going into focused trance, whereas boredom and hasty search for more tips and tricks are characteristic of shallow students looking to feed their vanity on the rich texture of any given sport or art.

Craftsmanship movement in software development tries to apply similar practices via coding dojo and katas. It is not clear whether this direct transition is good enough, but it definitely looks interesting.

Mastery is Unrewarding

Mastery is an unrewarding process. It’s not about getting 100% results.  It’s about following this path. Master is the one who deliberately takes on the fool’s mask, like court jesters. The point is that if you think of yourself as an expert in any given field — you’re full. There’s no more room for novelty. So, you’ve got to pour out of this glass of attained expertise to keep fit as an agile apprentice. The luggage of expertise steals the ability to enjoy your path of mastery.

Have you met agile experts that know everything and have confident answer to every question? Have you met agile experts that deny new things and believe in a defined set of principles? Beginner’s Mind is a great way to keep learning.

I’ve mused quite a lot on the Mastery book. I do have several hobbies -arts or sports- that I feel like I should practice, because I got talent for them — and I’ve actually practiced them for quite a long time — and I should definitely keep up with them. At some point I just got stuck. I couldn’t figure for myself how one can fit several hobbies and sports, and their diligent practice to a busy schedule — after all, there’s a job that I also love doing! How do I fit all these loves into a limited time?

I also noticed that in the process of getting stuck with this dilemma I seemed to stop actually enjoying those masteries. I would spend countless hours on the web, reading everything I could find on getting things done, finding focus, feeling superior to bloggers describing things that I know very well how to do.

GTD

The problem of choice has been chasing me all the time. Finally, it all came out simple. I also noticed that even if you read countless how-to’s, countless blogs, no matter of how many of those how-to’s you read, and how well laid out they are — it inevitably takes time for things to go home. Reading about something and understanding something from within are two different things. That’s why all the “getting things done” blogs and books are nothing more than someone else’s experience reports. Reading someone’s blogs will not solve your problems of gaining focus and concentration. It’s a substitute for what it’s all about — for practicing. I’ve seen people making a big deal out of GTD. All these GTD software, gadgets, hacks to block interruptions, you name it. Making a religion of GTD gives no more time to practice your mastery, that’s the point.

You’ve got to sit down and decide for yourself: what is it that you actually love doing? Once you listen to your inner voice — it all gets in place, like in a puzzle. There’s no need to think any more. If you really enjoy what you do, setting priorities is absolutely irrelevant, because what you enjoy doing now is the best thing you could do right here, right now.

If you still find yourself digging in how to’s and blogs, there’s nothing wrong about it. Probably your research reflex isn’t yet saturated, and you feel more at ease in a research, in a familiar comfort zone of consuming information on a soft couch.

Visualization and New Year Miracles

December 30th, 2010 4 comments

Last week at the mini-conference, one of our guys had no time to do a nice visual wrap-up for his presentation and sufficed with showing portraits of authors while just reading the extracts from their works. The topic was lean basics, and he was talking about Deming and Taylor. While everyone seemed to get bored with listening, as there was no nice visual stuff like we’re all used to now, I suddenly caught myself visualizing the talk of the boss and this worker. The story was about the boss who was convincing  the worker to bring 47 tons of iron instead of 12 or something like that.

This got me to thinking that sometimes visualization is doing lip service to us. We’re sitting comfortably, watching TV or watching presentations with nice stylishly UX’ed data, and we are losing the ability to make visualisations with our own brain! The picture is brought to us, so we make no use of the imagination “muscles” and our imagination weakens.

I’m not saying that everyone who watches animated drawings from RSA Animate is doomed. But there always should be a balance between perceiving someone else’s visualizations and creating your own. The power of creative imagination is above everything. No speaker or agile champion, or TV presenter will draw a vision of your business, your product or some function of the software you’re crafting. There’s always a time to look at someone’s visualizations, and time to create your own. Each and every “how-to” about creativity includes this magic word called “vision”. Have you ever thought why any business starts with a vision? It’s exactly for this reason.

There’s a paradox:  on the one hand, visual media is everywhere. Lots of visual channels deliver the dish to any, even the laziest perception. The problems is that the legion of those watching produces too few creators.

We’ve got 1 more day left in the year 2010. It’s time for New Year miracles. So let’s devote this day to our creativity, to cleaning the debris of anything we don’t want or need any more, and let’s visualize a

images-2

Categories: Uncategorized Tags: , ,

Company Practice: Mini-conference

December 23rd, 2010 6 comments

Our company is quite small (25 people). Most companies of this size focus on rapid growth and don’t pay much attention to learning. We are different. Fortunately, learning is very important in our company. We boost it in all possible ways:

  • We highly encourage people to try and learn new things.
  • Every employee can dedicate up to 12% of their time to unstructured learning (5 hrs per week).
  • We organize internal trainings twice per months.
  • We organize so-called Friday Shows every other Friday where we watch and discuss some interesting videos about UX, development, business, etc.
unknown

About a month ago we decided to structure our trainings in a better way. The resulting idea was internal mini-conference. Mini-conference is a full-day event dedicated to sessions and discussions. All sessions are prepared internally. The idea is to have a very focused learning event instead of several trainings over 2 months.

Our first conference will take place this Friday. Here is the program

10:00 Registration, “wake-up” coffee
10:15 Data Visualization Alex Tsayun /45 min
11:00 coffee break /15 min.
11:15 Node.js intro Vadim Gaidukevich /30 min
11:45 MongoDB (NoSQL) intro Oleg Seriaga /30min
12:15 coffee break
12:30 Exploring Good Experience Seth Godin (guest video) /20min
13:00 History of Kanban Anton Marchenko /30 min
13:30 lunch
14:30 Performance Metrics Alex Fomin /1h
15:30 coffee break
16:00 Marketing and Sales @ TargetProcess Andrey Mihailenko /1h
17:00 free discussions.

I am really curious about the outcome. Wil people like it? Will we keep this practice? Not sure. But we are trying new things :)

Categories: lean Tags: , ,

Learning & Software Development. Multi-skilled Developer

December 16th, 2010 8 comments

You are having your first project. In the beginning, you know almost nothing about programming languages, business domain, development process, efficient practices and other good things. In the beginning, you know almost nothing about political games, external factors, progress reporting, human stupidity, fear of mistake, boredom and other bad things. You can’t do your job effectively. Suddenly, in 10 years, you are becoming a great software developer. Or you are buried by mediocrity and never ride the wave. Why? What should you do to advance or just survive?

I think one of the most important factors is perpetual, passionate learning. Learning is the most important thing that drives software development forward. Learning is the most important thing that drives you, as an individual, forward. It drives your team, as a group of people, forward.

brain_1
source: Ashiro’s LabZone

I believe, learning is a key attribute of a good software development process. Process that empowers learning will work, process that impedes learning will fail.

Basically there are three levels of learning. First, you learn as a person. Then you learn as a group of people. Finally, you learn as a whole organization. This post focuses on personal learning.

I have my own vision about software development. Most likely it comes from my personal background and products I’ve worked on (all of them web-based).

Software developers solve problems. To solve a problem in a cool way, you need to be a multi-skilled professional with quite solid knowledge from as many related disciplines as possible. Only this will give you a complete vision of the best possible solution.

Deep Specialization vs. Broad Knowledge

We are stepping on a slippery ground of deep specialization vs. broad knowledge. My belief is that at the current stage broad knowledge is better. Why? I can provide some analogies that prove nothing, but still are interesting.

Mass-production

Software development is a young discipline. It has its own properties that are not fully understood by most people. You can’t apply mass-production to software development so far, since you can’t formalize it enough. You can’t write a product specification, create design and generate complete application from UML diagrams (yes, I am aware about Model-Driven Development, but it is not even close to mass-production).

Look, there are so many related topics, from psychology to programming languages, from ToC to pair programming. There is no best way to write software so far. If you can’t apply mass-production to software development, you can’t do it efficiently with people who have a very narrow specialization. You can’t put it on a conveyer.

Science

Let’s take science and look back 300 years ago. We will see that many discoveries were made by generalists. Let’s check Wikipedia.

  • Isaac Newton: physicist, mathematician, astronomer, natural philosopher, alchemist, and theologian.
  • Galileo Galilei: physicist, mathematician, astronomer and philosopher
  • Christiaan Huygens: mathematician, astronomer, physicist, horologist, and writer of early science fiction
  • René Descartes: philosopher, mathematician, physicist, and writer

It was common 200-300 years ago. In modern science you can’t discover anything without deep specialization. There are people  with broad knowledge, but it is quite  rare these days. More often you will find people like:

  • Barton Zwiebach: string theorist
  • Max Tegmark: cosmologist.
  • David Joseph Bohm: quantum physicist

There are rare exceptions for sure, like this one:

  • Stephen Wolfram (born 1959): physicist, software developer, mathematician, author and businessman.

What is the point? Software development is obviously neither a science nor a  ‘tangible’ industry, so all such analogies don’t prove anything. But I think software development now is somewhere in 17th century compared to science and in 19th century  compared to usual industry.

With this in mind, a team of generalists with some specializations can create a better software than a team of highly specialized people. It is not obvious and we need to evaluate this assertion. I can throw some arguments:

  1. Communication. Communication flows in a team of generalists. They understand each other easily and speak similar language. Communication in a highly specialized team is hard. If UI developer knows almost nothing about server side and server side developer doesn’t know Javascript, HTML and CSS at all, they will have hard time finding the best solution.
  2. Architecture. Developer may know nothing about testability. As a result he creates a hard-to-test solution. High specialization can lead to local optimizations, but weak overall architecture. If no one understands how does it work as a whole — it’s a bad sign.
  3. Fragility. A highly specialized team will hardly pass a “bus test”. If one of the key persons is hit by a bus, development will stop.

A Multi-skilled Software Developer

I believe in multi-skilled software developers. The right question to ask is “how much skills should I have and how deep?” It really depends, but here are the skills/domains/attributes every great web developer should have. The list is sorted by priority and I put hours that should be spent on formal education:

  • Curiosity and passion
  • Self-reflection / problem solving
  • User Experience (1000 hrs)
  • Programming (OOP/OOD, tools, practices, etc.) (8,000 hrs)
  • Testing (200 hrs)
  • “Sense of beauty” (Graphic design, visualization, etc.) (200 hrs)

I insist that these skills are very important for any really great web developer, but they may vary depending on software development type. I expect questions like “Why the hell you put User Experience before Programming?” The reason is that UX is an important part of problem solving. It is more important than implementation itself. UX gives developer the right perspective and makes a strong impact on software solutions. Without UX you can beautifully implement a crappy solution, and 90% of all existing software is exactly like that. IT’s crappy, unusable and bloated with unnecessary features.

Great developer should have a “sense of beauty”. It’s hard to formalize, but in general he should be able to say “this button is ugly” and “this menu is beautiful”. “Sense of beauty” is a very important property, it affects everything: visual design, documentation, architecture, source code. Everything. You can (and should) train it.

In the next post I will share my vision on Learning as a Team.

Book Review #1: Sketching User Experience by Bill Buxton. Part II

July 16th, 2010 1 comment

Read first part of the review.

Evaluating Design

There are two important aspects of design process: generative and reductive. We generate a set of alternatives, then we restrict this set based on various criteria. It is impossible to evaluate a solution without its alternatives.

The best way to a good idea is to have lots of ideas — Linus Pauling

I can’t critique just one thing — Richard Sewell

That is one more reason why sketching is so powerful. It helps to generate and evaluate various alternatives. I’ve read in one article that Apple creates a dozen alternative designs for any product. Good enough…

One of the most positive form of criticism is a better idea

Acquiring positive attitude to criticism is a hard change. People don’t like to be criticized in general. You can’t get the correct reaction to criticism out of the box, but should apply every possible effort to make it a part of team’s culture.

People on a design team must be as happy to be wrong as right. If their ideas hold up under strong (but fair) criticism, then great, they can proceed with confidence. If their ideas are rejected with good rationale, then they have learned something. A healthy team is made up of people who have the attitude that it is better to learn something new than to be right

Built to Last

Without appropriate design, yesterday’s success is tomorrow’s failure, since today’s great applications are tomorrow’s legacy systems

Some design decisions live for about 20 years if product is successful. For example, Photoshop has been on the market for 20 years, and some parts of its initial architecture still exist. Can you now imagine how important architectural decisions are? On to entities framework in TargetProcess that was designed 4 years ago. How long will it live? Definitely we did not consider a 20 year time frame back then…

We should assume that technology that is going to have a significant impact over the next 10 years is already 10 years old!

My takeaway lesson is that we should pay more attention to new technologies and think ahead at the same time. This may sound impossible, but it is worth trying.

Learning

Learning is a very important thing. No, I will re-phrase it. Learning is the most important thing in your company. Surprisingly, Bill has given an interesting perspective on learner’s experience levels:

I haven’t seen this concept of levels before, and I like it very much. If we take agile, I am in transition between levels 9 and 10 (I think). In UX, I am between levels 5 and 6. This model is a good guide and may help understand and plan personal or even corporate learning process. Is it possible to apply it to the whole company? Maybe.

Story-telling and Play

A good story is worth thousands of pictures

That one is true. For example, Steve Jobs told 3 stories from his life at Stanford Commencement Speech in 2005. And this speech was remarkable indeed. I remember all the 3 stories, despite the fact that I heard them only once.

Without play imagination dies

and one more:

Stories, and more importantly, story-telling and play, are critical part of design

Ever been on a boring brainstorming session? Fun is an essential part of any creative activity. It should be encouraged, not suppressed.

Design

Finally, some outstanding quotes on design:

Design is a funny word. Some people think design means how it looks. But, of course, if you dig deeper, it’s really how it works. To design something really well, you have to ‘get it.’ You have to really grok [understand] what it’s all about — Steve Jobs

The last thing that you should do when beginning to design an interactive system is write code

The role of design is to find the best design. The role of usability engineering is to help make that design the best.

Categories: design, ui Tags: , , ,