The Index of Learning Styles is an on-line instrument used to assess preferences on four dimensions (active/reflective, sensing/intuitive, visual/verbal, and sequential/global) of a learning style model formulated by Richard M. Felder and Linda K. Silverman
Friday, July 29, 2005
Index of learning styles
Tying in with my previous posts on learning styles, I just came across this page which has an index of learning styles. From the website:
Thursday, July 28, 2005
Wednesday, July 27, 2005
Ad hoc groups
Sachin posted an interesting comment about learning in companies.
One of the things I've noticed when talking to people is that most [Indian] companies do not take any steps to nurture adhoc groups. These are groups where like minded people can get together and talk or do side projects. Companies can create an environment where people can form such groups by themselves and then just sit back.
If you look at many of the US software companies (Google, MS etc) there is something there which causes people to do side projects and spread knowledge all the time. If one guy finds something cool, pretty soon there are a bunch of people discussing it.
Compare that with my experiences here. If anyone talks about some interesting topic, not connected with work, the reaction is something like "oh ok," rather than "cool, lets find out more about that." Or if someone decides to do something interesting, not connected with work, the first reaction is "whats the use" rather than "cool! lets do that this saturday".
Why is that? Is it that there are not many doer type people in Indian companies? Or is it because the company culture doesn't enable them to actually do anything? It is probably some combination of both I would think.
It's not like this in all companies of course (eg: Yahoo Bangalore), but its true in a depressingly large number of them.
What can be done about this?
This post is a part of the selected archive.
One of the things I've noticed when talking to people is that most [Indian] companies do not take any steps to nurture adhoc groups. These are groups where like minded people can get together and talk or do side projects. Companies can create an environment where people can form such groups by themselves and then just sit back.
If you look at many of the US software companies (Google, MS etc) there is something there which causes people to do side projects and spread knowledge all the time. If one guy finds something cool, pretty soon there are a bunch of people discussing it.
Compare that with my experiences here. If anyone talks about some interesting topic, not connected with work, the reaction is something like "oh ok," rather than "cool, lets find out more about that." Or if someone decides to do something interesting, not connected with work, the first reaction is "whats the use" rather than "cool! lets do that this saturday".
Why is that? Is it that there are not many doer type people in Indian companies? Or is it because the company culture doesn't enable them to actually do anything? It is probably some combination of both I would think.
It's not like this in all companies of course (eg: Yahoo Bangalore), but its true in a depressingly large number of them.
What can be done about this?
This post is a part of the selected archive.
Tuesday, July 26, 2005
The different modes of learning
I've been thinking about this topic a lot over the last couple of months. It is a topic that I'm figuring out with my team. I'm just going to throw it out and see what the feedback is like.
I’m going back to my college days for this the first part of this essay. What I want to discuss is the different modes of learning. This will probably come as no surprise to most of you: Different people learn through different means.
Some learn by listening. Remember people who just sat in class and absorbed the entire lecture ? They learnt by listening. Then there are those who learn by writing. They take notes. Some people learn by reading. They just sleep in all the clases, then go home, read the text book and ace the exam. Some learn by talking. They need to discuess the topic with someone else to clarify their thinking. Finally, we all know that student who could write great programs on the computer, but could barely follow what was going on in class. They learnt by doing.
These five categories represent the different modes of learning. [These are actually a combination of modes. For more on the theory, check out these links - 1, 2, 3]. They are not mutually exclusive. Some people can learn in multiple ways, but most people have one dominant mode of learning and other minor modes of learning.
Think back to your college batch, and you would find a few classmates who fit each of the above categories. The college environment is designed to present multiple methods of learning. You can either listen to the lecturer, try out excercises, attend lab sessions, talk to your classmates about a topic, or read the textbook.
Now, someone is going to point out that (in most of India at least) lecturers are often recent college graduates who couldn’t get any other job, that the textbooks are written to maximise your exam score rather than teach anything, most students take down notes verbatim without any understanding and the labs are underfunded relics. This is a topic for another day. For now, lets just assume that they support all methods of learning.
Let’s get back to the present now.
Scenario I: Your company has a training programme under which they have called someone to give a seminar on Design Patterns. You’re a Project Manager. Madhav, a member of your team, will be doing some design work soon, so you send him over to attend the seminar. The only problem is that Madhav learns by reading, not listening. Not surprisingly the seminar is extremely boring for him and he sleeps through it.
Scenario II: You are working on a new project and have just recieved a thick list of requirements. You pass the requirements to Priyanka, the lead programmer, and ask her to take a look. The problem is, Priyanka learns by talking, not by reading. The next day, the coversation goes like this:
You: So did you have a look at the requirements I passed you?
Priyanka: I had a look, but they look complicated. Can we have a meeting to discuss them?
You: I’m busy right now. I’ll be back in two days to check on your progress.
2 days later…
You: So how are the requirements? I need to give an estimate for the completion date this evening.
Priyanka: I’m not sure I understand it. Can we discuss it?
You: You still don’t understand it? I gave you two extra days. What more do you want? Meetings are just a waste of time. Can’t you just read it and give me an estimate? I need to give an estimate today.
Ouch.
Meanwhile, Scott Adams is drawing you in the next Dilbert strip.
Most managers don’t really understand the modes of learning of their team members. If Priyanka learns by talking, the manager should know it and let her talk about the requirements. Forcing her to read the requirements will go nowhere. Similarly if Ramesh likes to read, his manager should pass his some reading material before he attends the seminar. The primary responsibility of a manager is to enable his or her team members to do their work as best they can, and knowing their learning modes can help with this.
Companies also like to talk about how employee oriented they are, and about their professional development policies, but in most cases this just means that they shove their employees through a couple of seminars a year, just because they have to.
Real professional development is a lot more than just sending everyone to a few seminars. Companies need to take a hint from colleges where most of the real learning takes place. They need a good library where the readers can hang out. They need cool co-workers so that the talkers can talk with each other and learn. They need ad-hoc groups of people who learn by doing to get together and do side projects. They need to create internal blogs so that the writers can write stuff, and of course, the good old seminars for the listeners to attend.
Any comments? How is it at the companies you work (or worked) at?
This post is a part of the selected archive.
I’m going back to my college days for this the first part of this essay. What I want to discuss is the different modes of learning. This will probably come as no surprise to most of you: Different people learn through different means.
Some learn by listening. Remember people who just sat in class and absorbed the entire lecture ? They learnt by listening. Then there are those who learn by writing. They take notes. Some people learn by reading. They just sleep in all the clases, then go home, read the text book and ace the exam. Some learn by talking. They need to discuess the topic with someone else to clarify their thinking. Finally, we all know that student who could write great programs on the computer, but could barely follow what was going on in class. They learnt by doing.
These five categories represent the different modes of learning. [These are actually a combination of modes. For more on the theory, check out these links - 1, 2, 3]. They are not mutually exclusive. Some people can learn in multiple ways, but most people have one dominant mode of learning and other minor modes of learning.
Think back to your college batch, and you would find a few classmates who fit each of the above categories. The college environment is designed to present multiple methods of learning. You can either listen to the lecturer, try out excercises, attend lab sessions, talk to your classmates about a topic, or read the textbook.
Now, someone is going to point out that (in most of India at least) lecturers are often recent college graduates who couldn’t get any other job, that the textbooks are written to maximise your exam score rather than teach anything, most students take down notes verbatim without any understanding and the labs are underfunded relics. This is a topic for another day. For now, lets just assume that they support all methods of learning.
Let’s get back to the present now.
Scenario I: Your company has a training programme under which they have called someone to give a seminar on Design Patterns. You’re a Project Manager. Madhav, a member of your team, will be doing some design work soon, so you send him over to attend the seminar. The only problem is that Madhav learns by reading, not listening. Not surprisingly the seminar is extremely boring for him and he sleeps through it.
Scenario II: You are working on a new project and have just recieved a thick list of requirements. You pass the requirements to Priyanka, the lead programmer, and ask her to take a look. The problem is, Priyanka learns by talking, not by reading. The next day, the coversation goes like this:
You: So did you have a look at the requirements I passed you?
Priyanka: I had a look, but they look complicated. Can we have a meeting to discuss them?
You: I’m busy right now. I’ll be back in two days to check on your progress.
2 days later…
You: So how are the requirements? I need to give an estimate for the completion date this evening.
Priyanka: I’m not sure I understand it. Can we discuss it?
You: You still don’t understand it? I gave you two extra days. What more do you want? Meetings are just a waste of time. Can’t you just read it and give me an estimate? I need to give an estimate today.
Ouch.
Meanwhile, Scott Adams is drawing you in the next Dilbert strip.
Most managers don’t really understand the modes of learning of their team members. If Priyanka learns by talking, the manager should know it and let her talk about the requirements. Forcing her to read the requirements will go nowhere. Similarly if Ramesh likes to read, his manager should pass his some reading material before he attends the seminar. The primary responsibility of a manager is to enable his or her team members to do their work as best they can, and knowing their learning modes can help with this.
Companies also like to talk about how employee oriented they are, and about their professional development policies, but in most cases this just means that they shove their employees through a couple of seminars a year, just because they have to.
Real professional development is a lot more than just sending everyone to a few seminars. Companies need to take a hint from colleges where most of the real learning takes place. They need a good library where the readers can hang out. They need cool co-workers so that the talkers can talk with each other and learn. They need ad-hoc groups of people who learn by doing to get together and do side projects. They need to create internal blogs so that the writers can write stuff, and of course, the good old seminars for the listeners to attend.
Any comments? How is it at the companies you work (or worked) at?
This post is a part of the selected archive.
Monday, July 18, 2005
Monday, July 04, 2005
NASA - Deep Impact
Check out these pages on the NASA Deep Impact mission. The mission was to hit the comet Tempel 1 with an impactor to clear the top layer of the comet. The spacecraft then makes measurements of the chemicals which are underneatg the comet's top surface. Cool huh?
Anyway, latest news is that the impactor has successfully hit the comet Tempel 1. Check out this image of the impactor colliding with the comet. The next phase is for the Flyby spacecraft to make its closest approach to the comet. Then the press conference in a few hours time.
Anyway, latest news is that the impactor has successfully hit the comet Tempel 1. Check out this image of the impactor colliding with the comet. The next phase is for the Flyby spacecraft to make its closest approach to the comet. Then the press conference in a few hours time.
Saturday, July 02, 2005
Counting The Miles
Counting The Miles: "The point is not that customers demand it or don't demand it, because that's absolutely not the viewpoint of Honda. When you are a philosophy-driven company, you don't ask the customer if they agree with your philosophy."
Friday, July 01, 2005
TheFeature :: The End of the Road
Just read todays article that TheFeature is going to be closing after 5 years.
TheFeature was an awesome site on mobile technology. It was not an ordinary news site, but featured a number of excellently written and thought provoking articles by some very talented writers.
From the site:
For those who used to visit it, see the comments for links to the personal blogs of the various authors.
TheFeature was an awesome site on mobile technology. It was not an ordinary news site, but featured a number of excellently written and thought provoking articles by some very talented writers.
From the site:
Now is the time for us to step back, and let the conversation and community move forward on its own. It's been a great ride, and we're glad that everyone could join us. So, would the last one out please turn off the lights...
For those who used to visit it, see the comments for links to the personal blogs of the various authors.
Tuesday, June 28, 2005
Friday, June 24, 2005
How frequent should the delivery be?
In a previous post I had written about frequent delivery. Sachin asks in this comment how likely it is that a customer would be willing to check delivery after delivery. This is a good question thats worth going into some more detail.
Customers worry about two things: (1) Is anything progress happening in their project and (2) is it going to turn out the way they want. The worst nightmare for a customer is to not hear anything about the project until the end when they are told its only 50% done, and then they wait more time only to see the final product and find it unusable. In short, they want visibility into the project.
Now, different customers want different amounts of visibility. If a customer doesnt care if they project succeeds or not, they may want only one delivery in the end. At the other extreme, some customers may be willing to dedicate one person for the entire duration of the project to see how it is going. In Agile terminology, this is called having an onsite customer. Ideally, this would be the best situation, but it's not always possible. These are the two extremes. Somewhere in the middle are customers who want to see the project once in a while, if only for their peace of mind.
The ideal delivery cycle depends on two factors: how often the customer wants to see the progress, and how often you can make a delivery.
If it's a web based project, a delivery cycle of 3 weeks is possible. If it's a complex project with lots of deployment for each release, the delivery cycle will be somewhere around once in 3 months, which translates to around 4 deliveries for a year long project. If you are creating a product, the "customer" may be the QA team or the evangelist/stakeholder for your product. They may be willing to spend more time looking over the software.
Its up to the team to negotiate a suitable delivery cycle depending upon the customers willingness, the complexity of project deployment and how fast the team can add and test features.
In they end, the customer is paying for the software, so they would be definately willing to see it before the final delivery, especially if they are told that this increases the chances of a successfull product. Most customers have gone through projects with no visibility with disaster at the end and they would be totally thrilled that someone is actually willing to show them the product as it comes along.
This post is a part of the selected archive.
Customers worry about two things: (1) Is anything progress happening in their project and (2) is it going to turn out the way they want. The worst nightmare for a customer is to not hear anything about the project until the end when they are told its only 50% done, and then they wait more time only to see the final product and find it unusable. In short, they want visibility into the project.
Now, different customers want different amounts of visibility. If a customer doesnt care if they project succeeds or not, they may want only one delivery in the end. At the other extreme, some customers may be willing to dedicate one person for the entire duration of the project to see how it is going. In Agile terminology, this is called having an onsite customer. Ideally, this would be the best situation, but it's not always possible. These are the two extremes. Somewhere in the middle are customers who want to see the project once in a while, if only for their peace of mind.
The ideal delivery cycle depends on two factors: how often the customer wants to see the progress, and how often you can make a delivery.
If it's a web based project, a delivery cycle of 3 weeks is possible. If it's a complex project with lots of deployment for each release, the delivery cycle will be somewhere around once in 3 months, which translates to around 4 deliveries for a year long project. If you are creating a product, the "customer" may be the QA team or the evangelist/stakeholder for your product. They may be willing to spend more time looking over the software.
Its up to the team to negotiate a suitable delivery cycle depending upon the customers willingness, the complexity of project deployment and how fast the team can add and test features.
In they end, the customer is paying for the software, so they would be definately willing to see it before the final delivery, especially if they are told that this increases the chances of a successfull product. Most customers have gone through projects with no visibility with disaster at the end and they would be totally thrilled that someone is actually willing to show them the product as it comes along.
This post is a part of the selected archive.
Thursday, June 23, 2005
Statue at Salisbury Cathedral
This statue is from the cathedral in Salisbury, England. Construction on the cathedral started in 1220 AD. The cathedral has the tallest spire in England at 123 meters. It also has one of the oldest working clocks in Europe. For more information, see this wikipedia article.
Wednesday, June 22, 2005
Truck Factor
One of the more informal metrics (if you can call it that) is the "Truck Factor" of the team. The Truck Factor measures the amount of spread of knowledge within a team.
Formally, the truck factor is the number of people that need to be hit by a truck before the project is in serious trouble. Of course, they don't actually need to be hit by a truck, they could leave the company, fall ill, or take a vacation.
The idea is that if only one or two people know the critical components of a system, then the project is in serious trouble should they leave. A Truck Factor of one is the worst, with most of the critical knowledge with just one person. Ideally everyone in the team should know every part of the system, but thats not very practical. An achievable goal is that at least 25% to 50% of the team knows any one component. Hopefully it won't be the same 50% who know every component :).
Small teams of under 10 people usually target a truck factor of 4-5 for most parts of the system (thats around 50% of the team). Larger teams will probably target a truck factor of around 8 (which would probably be around 25% of the team). This means that should a couple of critical people go on vacation or leave the company, there are enough people in the team who can cover for them.
Ironically, smaller teams usually have larger truck factors compared to larger teams. In teams of 5-10 members, there is a high chance that most of them know most parts of the system, with only a couple of modules having a low truck factor. In teams with above 20 people, chances are that a few people at the top (designer, architect, lead) know the system thoroughly and the rest only know about the couple of modules that they worked on. Should these people leave at around the same time, the project could be in serious trouble.
One of the things that we have been working on is increasing the truck factor. Every once in a while, we target areas with a truck factor of one and that person then gives a seminar to the rest of the team. Not only does it help with knowledge sharing, but it also means that the person can take a vacation without worry.
This post is a part of the selected archive.
Formally, the truck factor is the number of people that need to be hit by a truck before the project is in serious trouble. Of course, they don't actually need to be hit by a truck, they could leave the company, fall ill, or take a vacation.
The idea is that if only one or two people know the critical components of a system, then the project is in serious trouble should they leave. A Truck Factor of one is the worst, with most of the critical knowledge with just one person. Ideally everyone in the team should know every part of the system, but thats not very practical. An achievable goal is that at least 25% to 50% of the team knows any one component. Hopefully it won't be the same 50% who know every component :).
Small teams of under 10 people usually target a truck factor of 4-5 for most parts of the system (thats around 50% of the team). Larger teams will probably target a truck factor of around 8 (which would probably be around 25% of the team). This means that should a couple of critical people go on vacation or leave the company, there are enough people in the team who can cover for them.
Ironically, smaller teams usually have larger truck factors compared to larger teams. In teams of 5-10 members, there is a high chance that most of them know most parts of the system, with only a couple of modules having a low truck factor. In teams with above 20 people, chances are that a few people at the top (designer, architect, lead) know the system thoroughly and the rest only know about the couple of modules that they worked on. Should these people leave at around the same time, the project could be in serious trouble.
One of the things that we have been working on is increasing the truck factor. Every once in a while, we target areas with a truck factor of one and that person then gives a seminar to the rest of the team. Not only does it help with knowledge sharing, but it also means that the person can take a vacation without worry.
This post is a part of the selected archive.
Thursday, June 16, 2005
Sunday, June 12, 2005
Trip Photos
I'm back from my vacation. I've uploaded some photos to flickr. You can either click the thumbnail images on the top of this page to see the most recently uploaded photos, or click here to access the entire photostream. Most of the photos are from London and Paris, but a few are from other places.
I should add a small note that the photos that I've uploaded so far are only the photos that I really liked (around 15 I think), so although I did take photos of the popular sights (18+ rolls of film/slides), they have not been uploaded.
I should add a small note that the photos that I've uploaded so far are only the photos that I really liked (around 15 I think), so although I did take photos of the popular sights (18+ rolls of film/slides), they have not been uploaded.
Subscribe to:
Posts (Atom)