As many of you know, I've been working on making e-Learning an effective and attractive method for skill building in software testing. The number one thing I have learned is that there must be interaction with the instructor to make the learning effective. This interaction can take many forms - e-mail, phone, chat sessions, teleconferences, etc. That's why in my e-Learning courses I include live call-in teleconferences at talkshoe.com. My goal is to do 90% of my training this way!
One of the tools I use for creating e-Learning content is Articulate. It creates Flash presentations from PowerPoint and has a nice interface with many good features such as bookmarking, notes, attachments, etc. I ran across an interesting post on the Articulate blog recently about how one college professor compared the grades of two similar classes - one using traditional classroom teaching only and the other using blended learning (e-Learning with live reinforcement).
From the report: "A technical report from a University of Houston Department of Health and Human Performance researcher finds that students in a hybrid class that incorporated instructional technology with in-class lectures scored a letter grade higher on average than their counterparts who took the same class in a more traditional format."
You can read more here:
http://www.articulate.com/blog/use-articulate-get-better-grades/
So, why is this important to testers and managers? I think the way we build skills is as important as the skills we build. Training and skill building can be transforming and exciting, or it can be torture.
Some people look forward to a day of training (for more reasons than just getting away from work) while others dread it. When people get excited about learning, amazing things can happen. The link to the Articulate blog is interesting because it goes "behind the scenes" in the theory and practice of e-Learning.
As testers and managers, we must learn about learning. We need to understand the different learning styles, attention spans and what works in training adult learners. My observation is that it's the people that don't care about how to make training effective that are the worst trainers.
By the way, as my way of saying "thanks" for reading this post, here is a link to one of my conference presentations (The Risks of Risk-Based Testing) created using Articulate:
http://www.riceconsulting.com/articulate/risks_of_risk_based_testing/player.html
Best regards,
Randy
Tuesday, December 30, 2008
Monday, December 29, 2008
COTS Testing Course is Now Online
I'm excited to announce the launch of my 14th e-learning course, Testing Commercial Off-the-shelf (COTS) Applications. This online course gives you the approaches you need to test commercial software. Many organizations, especially government, have been building systems comprised of commercial software. However, problems arise when people try to integrate the products to work together. Many people work under the misconception that all you have to do is buy the software, install it, maybe configure a few things and then start using it. Unfortunately, the truth is that there are a lot of things the vendors can't test. This course will lead you through a process of testing COTS products all the way from selection through maintenance.
To see a free demo of this course, just visit http://softwaretestingtrainingonline.com/moodle/course/view.php?id=45. To buy a registration, go to https://www.mysoftwaretesting.com/ProductDetails.asp?ProductCode=COTS101.
To see all the details about my e-learning courses and how they can help you build your skills on your own schedule, visit http://www.riceconsulting.com/training/e-learning.htm.
Thanks!
To see a free demo of this course, just visit http://softwaretestingtrainingonline.com/moodle/course/view.php?id=45. To buy a registration, go to https://www.mysoftwaretesting.com/ProductDetails.asp?ProductCode=COTS101.
To see all the details about my e-learning courses and how they can help you build your skills on your own schedule, visit http://www.riceconsulting.com/training/e-learning.htm.
Thanks!
Wednesday, December 24, 2008
Merry Christmas!
Hi friends - Just a note to wish you all a very Merry and Blessed Christmas. To all my Jewish friends I wish a Happy Chanukah.
At this special time of year I will be thinking of all my friends around the world and will be enjoying time with family here in Oklahoma.
Regardless of your beliefs, my wish is that the Prince of Peace will be real to all of us this year.
Warm regards,
Randy
At this special time of year I will be thinking of all my friends around the world and will be enjoying time with family here in Oklahoma.
Regardless of your beliefs, my wish is that the Prince of Peace will be real to all of us this year.
Warm regards,
Randy
Tuesday, December 23, 2008
A Good Resource for Government Computing Projects
I am working on a new book project about software failures and I came across this resource from the Center for Technology in Government at the University at Albany especially aimed at government computing projects. The name of the report is Making Smart IT Choices - Understanding Value and Risk in Government IT Investments. You can get this at http://www.ctg.albany.edu/publications/guides/smartit2. In fact, you can download the entire book as a pdf file.
I like this book because it hits at the heart of IT projects - making the right choices based on risk and value. It's all common sense stuff tailored for the government sector. It proves that the answers are in plain sight. Now, the tough part is to actually act on them.
My experience is that the hard part is dealing with the stakeholders who want something different every day and the vendors who are more than happy to promise it to get more money by stringing the project out almost forever. We as taxpayers end up paying the enormous bill for this nonsense.
Doing the research for this even makes me sick, but I am glad there are those out there at least shining a light in the darkness of many IT projects.
I like this book because it hits at the heart of IT projects - making the right choices based on risk and value. It's all common sense stuff tailored for the government sector. It proves that the answers are in plain sight. Now, the tough part is to actually act on them.
My experience is that the hard part is dealing with the stakeholders who want something different every day and the vendors who are more than happy to promise it to get more money by stringing the project out almost forever. We as taxpayers end up paying the enormous bill for this nonsense.
Doing the research for this even makes me sick, but I am glad there are those out there at least shining a light in the darkness of many IT projects.
Tuesday, December 16, 2008
Book Review - Clean Code by Robert C. Martin
"Clean Code" by Robert C. Martin
Published by Prentice Hall
Buy at Amazon.com -
http://www.amazon.com/gp/product/0132350882?ie=UTF8&tag=randyricessof-20
(5 stars out of 5)
I knew I was going to like this book after I read the Foreword and
Introduction. I know not many people read those and as an author
myself this bothers me, but it gives insight to why the author has
written the book, which is a very important thing to understand. I
was hooked by the affirmation that details are important and that
the only meaningful metric is the number of "wtfs" per minute in a
code review. For a long time I have kept my "profanities per test
session" metric as a way to measure software usability.
Long before I was a software testing guy, I was a coder. Back in
those days it was common for rookie coders to sit next to guys with
gray hair and bad breath (or if lucky next to ladies with better
appearance and who smelled better) to learn the craft of writing
code. Yes, coding was a craft before the attempt to make it an
engineering discipline. Although there was a lot of bad code, there
were plenty of people who took pride in how they coded. This book
reminds me of what it was like to sit next to these intelligent
people as mentors.
I have often lamented that today's young coders don't have this
mentor/apprentice relationship. A reasonable facsimile would be to
read this book and practice these very sensible and helpful lessons
in coding. As a testing guy who has been through those 30 wtf/hour
code reviews, my bulletin to developers is that: Your code can be
better! This book can show you how!
Here's one example: Have meaningful names. Instead of a function
named "int d", how about "int ElapsedTimeInDays;"? There's a whole
chapter about naming things. It reminds me of the coder I knew that
liked to label COBOL paragraphs after towns and cities in Kansas.
Why? So he could write GOTOs that read "GOTO Topeka." He thought
that was cute but the rest of us found it confusing and not-so-cute.
I also appreciated the chapter on Unit Testing. As a tester, I love
it when testing is mentioned, but Martin actually has specific
guidance on what makes for good Test Driven Development and Unit
Testing.
This book is very readable, makes a lot of sense and would make
most coders better. For testers that sit in on code reviews, this
would be a great read for understanding how good code should be. I
wish every coder in college or tech school would read this book
before unleashing their creations upon the world.
Published by Prentice Hall
Buy at Amazon.com -
http://www.amazon.com/gp/product/0132350882?ie=UTF8&tag=randyricessof-20
(5 stars out of 5)
I knew I was going to like this book after I read the Foreword and
Introduction. I know not many people read those and as an author
myself this bothers me, but it gives insight to why the author has
written the book, which is a very important thing to understand. I
was hooked by the affirmation that details are important and that
the only meaningful metric is the number of "wtfs" per minute in a
code review. For a long time I have kept my "profanities per test
session" metric as a way to measure software usability.
Long before I was a software testing guy, I was a coder. Back in
those days it was common for rookie coders to sit next to guys with
gray hair and bad breath (or if lucky next to ladies with better
appearance and who smelled better) to learn the craft of writing
code. Yes, coding was a craft before the attempt to make it an
engineering discipline. Although there was a lot of bad code, there
were plenty of people who took pride in how they coded. This book
reminds me of what it was like to sit next to these intelligent
people as mentors.
I have often lamented that today's young coders don't have this
mentor/apprentice relationship. A reasonable facsimile would be to
read this book and practice these very sensible and helpful lessons
in coding. As a testing guy who has been through those 30 wtf/hour
code reviews, my bulletin to developers is that: Your code can be
better! This book can show you how!
Here's one example: Have meaningful names. Instead of a function
named "int d", how about "int ElapsedTimeInDays;"? There's a whole
chapter about naming things. It reminds me of the coder I knew that
liked to label COBOL paragraphs after towns and cities in Kansas.
Why? So he could write GOTOs that read "GOTO Topeka." He thought
that was cute but the rest of us found it confusing and not-so-cute.
I also appreciated the chapter on Unit Testing. As a tester, I love
it when testing is mentioned, but Martin actually has specific
guidance on what makes for good Test Driven Development and Unit
Testing.
This book is very readable, makes a lot of sense and would make
most coders better. For testers that sit in on code reviews, this
would be a great read for understanding how good code should be. I
wish every coder in college or tech school would read this book
before unleashing their creations upon the world.
Wednesday, December 10, 2008
Skills for Software Testers in the Future
Last month I delivered a keynote address at EuroStar on "Trends that May Impact the Future of Software Testing." There were some interesting questions following my talk, one of which I would like to discuss in this post. "What do you see as essential skills for testers in the future?" Great question.
First, let me say that the list could be long and your list probably will differ from mine and that's fine. In fact, please comment with your answers to this important question.
Skill #1 -Thinking Skills
Too many testers fail to think through what they are doing and why they are doing it. They also fail to use imagination and instead rely on a repository of knowledge somewhere that is probably outdated and incorrect. Sure, we can curse the darkness of bad documentation, but we've been doing that for over 30 years already so let's get over it. Let's light a few candles to illuminate the subject of hidden understanding.
So, for example, when doing a boundary test, ask, "Is this test meaningful?", "What will it prove or disprove?", "Are there more important tests that I haven't done yet?".
As testers we have to be very careful about falling into ruts and thinking the same way all the time. Learn to look at problems from different angles.
I like to play thinking games just to stay in practice. One game that is helpful for test teams is "20 questions for software". I improvised this game in a class on exploratory testing when only I had my computer at the front of the room. Here's how it works. The leader (perhaps you) are at the front of the room with an application projected on a screen. Then, go around the room in order (a u-shaped room or circle is best), with one person starting the questioning of the application. They should ask a question such as "What happends when you...(fill in the blank)?". Then, the person next to them asks a question based on their question. This continues around the room, maybe even multiple times. There are only two rules: 1) you must wait your turn, and 2) your question must be based on someone else's question or answer before you.
You may be surprised about how much you can learn about the application by doing this. You may also be surprised (perhaps dismayed) about the quality of questions. This gives the team leader insight into where to develop the thinking skills of the test team or individuals on the team.
I also like to work Sudoku puzzles because they require deducing, eliminating possible solutions to find the right number(s), and using other thought processes that are the same as used in exploratory testing. I've never tried to work one puzzle together as a group, but that would be an interesting experiment.
Skill #2 - Communication Skills
I believe that communication is the basis for everything else we do in IT. Without good communication, we can't even define the problem to be solved, much less define the solutions to the problem or the testing of the solutions. Ironically, communication is the last thing we take training for, or practice, or apply in the workplace.
Testers especially need to be good communicators in the following ways:
Accuracy - People must be able to trust the accuracy of test results and other information from testing. Once the accuracy slips, so does the credibility.
Timeliness - Timely communication helps people to form good responses to problems, take advantage of opportunities, and generally work together better. Sitting on bad news, hoping for it to become better news, is not a good approach.
Thoroughness - Telling only part of a story is as bad as giving inaccurate information.
Courtesy - How people say things is just as important as what they say.
Helpfulness - Overall, the information a tester provides should help the rest of the project team to fix issues, make improvements and deliver a great project on or ahead of schdeule.
Meaningfulness - The information must have value to the audience, otherwise people will disregard it as "just another report" that may or may not be read.
Skill #3 - Measurement Skills
When you think about it, testing is measurement. However, we as testers often struggle with what to measure, how detailed the measures should be, what to do with the measurements, etc.
It takes skill to know what to measure without going overboard. It also takes skill to make the correct interpretation from the measurements and metrics. But how does one build these skills? I'm going to suggest a radical approach. Don't start by reading books on measurement, unless they are basic.
Like many things, including testing, we are up against Parkinson's Law that says "work expands to fill available time." My variation on this is that simple things can become complex just by writing books, having conferences, etc. As an example, function points started as a fairly simple idea but then evolved into more complex ways to count and apply them. So when you read a book on measurement your first thought may be that you need a large set of measurements to "do it right."
Instead, simply look at what needs to be improved and find two or three things to measure that could show progress in meeting those goals. You can also consider a typical project and what you need to know to stay on track. This is the dashboard concept. Have five or six indicators at the high end.
Then, find ways to measure without being intrusive. This in itself can be a big challenge. That's why simple is good.
Skill #4 - Configuration Management Skills
CM has always been an essential skill for testers. After all, what good is it if you test the wrong version or configuration of the software?
With virtual environments, it is even more important to know how to manage them. At this point, you may be thinking, "Yes, but the tool has features for that." Consider though, that a tool is not a process.
So testers need to know how to control all the items in the environment - software, hardware, data, and any other system components.
Skill #5 - Technical Skills
This is an interesting debate. How technical does a tester need to be anyway? On one hand, it is the lack of technical perspective that gives testers the same view as users. Too much technical knowledge and they may apply workarounds that users would not think of, therefore not seeing problems from a true user perspective.
The term "Technical Skills" is a fuzzy one, so I'll clarify my meaning a bit. The technical skills I refer to here are those that allow testers to use new tools and approaches effectively. I don't believe that testers need to be coders, although sometimes that skill comes in handy. But, if a tester likes to code and they can maintain objectivity, it does open some options.
I believe it is a mistake to eliminate a tester from hiring consideration just because they can't code or work with a particular tool. There are simply too many other needed skills and attributes to limit the decision to technical skills alone.
It's like being in a swimming pool and being able to go in the deep end as opposed to just staying in the shallow end. While we can all be in the pool and have fun. Some will be able to do more advanced things, like diving and snorkeling. It's not about worth or value, but about the ability to experience different things. So, if an inexperienced swimmer gets thrown into the deep end, it's "sink or swim", and that can sometimes be a dangerous thing. You may have experienced that "over my head" feeling.
Another example is owning and driving a car. Some people are happy just driving the car and keeping it filled with gas and having the fluids changed on schedule. Others want to get more involved in their vehicle's maintenance and repair by doing things such as changing the oil, replacing air filters and spark plugs, replacing fan belts, hoses and brake pads, etc. A few braver souls with older cars get into major engine repair or replacement. All of these types of car owners can drive the car well. Some can perform maintenance but due to time issues prefer to have the work done for them. All are valid owners and I would rather be on the road with good drivers who know little about auto maintenance than bad drivers who can replace engines in a day.
At the end of the day, the answer to this question of should a tester have technical skills may be a firm "it depends!" It depends on the person and their abilities, the projects they work on and the types of testing their job requires them to perform.
Skill #6 - Business Skills
Testers need to be able to speak the language of business. How can we as testers expect to be invited into business-level meetings if we don't understand the culture and language of business? This is more than just understanding business processes. We must know what's important to the business - profits, market share, strategic goals, markets, growth, legal, return on investment, and trade issues.
So, these are some of the important skills as I see them. Agree or disagree? I would like to hear your comments and ideas!
First, let me say that the list could be long and your list probably will differ from mine and that's fine. In fact, please comment with your answers to this important question.
Skill #1 -Thinking Skills
Too many testers fail to think through what they are doing and why they are doing it. They also fail to use imagination and instead rely on a repository of knowledge somewhere that is probably outdated and incorrect. Sure, we can curse the darkness of bad documentation, but we've been doing that for over 30 years already so let's get over it. Let's light a few candles to illuminate the subject of hidden understanding.
So, for example, when doing a boundary test, ask, "Is this test meaningful?", "What will it prove or disprove?", "Are there more important tests that I haven't done yet?".
As testers we have to be very careful about falling into ruts and thinking the same way all the time. Learn to look at problems from different angles.
I like to play thinking games just to stay in practice. One game that is helpful for test teams is "20 questions for software". I improvised this game in a class on exploratory testing when only I had my computer at the front of the room. Here's how it works. The leader (perhaps you) are at the front of the room with an application projected on a screen. Then, go around the room in order (a u-shaped room or circle is best), with one person starting the questioning of the application. They should ask a question such as "What happends when you...(fill in the blank)?". Then, the person next to them asks a question based on their question. This continues around the room, maybe even multiple times. There are only two rules: 1) you must wait your turn, and 2) your question must be based on someone else's question or answer before you.
You may be surprised about how much you can learn about the application by doing this. You may also be surprised (perhaps dismayed) about the quality of questions. This gives the team leader insight into where to develop the thinking skills of the test team or individuals on the team.
I also like to work Sudoku puzzles because they require deducing, eliminating possible solutions to find the right number(s), and using other thought processes that are the same as used in exploratory testing. I've never tried to work one puzzle together as a group, but that would be an interesting experiment.
Skill #2 - Communication Skills
I believe that communication is the basis for everything else we do in IT. Without good communication, we can't even define the problem to be solved, much less define the solutions to the problem or the testing of the solutions. Ironically, communication is the last thing we take training for, or practice, or apply in the workplace.
Testers especially need to be good communicators in the following ways:
Accuracy - People must be able to trust the accuracy of test results and other information from testing. Once the accuracy slips, so does the credibility.
Timeliness - Timely communication helps people to form good responses to problems, take advantage of opportunities, and generally work together better. Sitting on bad news, hoping for it to become better news, is not a good approach.
Thoroughness - Telling only part of a story is as bad as giving inaccurate information.
Courtesy - How people say things is just as important as what they say.
Helpfulness - Overall, the information a tester provides should help the rest of the project team to fix issues, make improvements and deliver a great project on or ahead of schdeule.
Meaningfulness - The information must have value to the audience, otherwise people will disregard it as "just another report" that may or may not be read.
Skill #3 - Measurement Skills
When you think about it, testing is measurement. However, we as testers often struggle with what to measure, how detailed the measures should be, what to do with the measurements, etc.
It takes skill to know what to measure without going overboard. It also takes skill to make the correct interpretation from the measurements and metrics. But how does one build these skills? I'm going to suggest a radical approach. Don't start by reading books on measurement, unless they are basic.
Like many things, including testing, we are up against Parkinson's Law that says "work expands to fill available time." My variation on this is that simple things can become complex just by writing books, having conferences, etc. As an example, function points started as a fairly simple idea but then evolved into more complex ways to count and apply them. So when you read a book on measurement your first thought may be that you need a large set of measurements to "do it right."
Instead, simply look at what needs to be improved and find two or three things to measure that could show progress in meeting those goals. You can also consider a typical project and what you need to know to stay on track. This is the dashboard concept. Have five or six indicators at the high end.
Then, find ways to measure without being intrusive. This in itself can be a big challenge. That's why simple is good.
Skill #4 - Configuration Management Skills
CM has always been an essential skill for testers. After all, what good is it if you test the wrong version or configuration of the software?
With virtual environments, it is even more important to know how to manage them. At this point, you may be thinking, "Yes, but the tool has features for that." Consider though, that a tool is not a process.
So testers need to know how to control all the items in the environment - software, hardware, data, and any other system components.
Skill #5 - Technical Skills
This is an interesting debate. How technical does a tester need to be anyway? On one hand, it is the lack of technical perspective that gives testers the same view as users. Too much technical knowledge and they may apply workarounds that users would not think of, therefore not seeing problems from a true user perspective.
The term "Technical Skills" is a fuzzy one, so I'll clarify my meaning a bit. The technical skills I refer to here are those that allow testers to use new tools and approaches effectively. I don't believe that testers need to be coders, although sometimes that skill comes in handy. But, if a tester likes to code and they can maintain objectivity, it does open some options.
I believe it is a mistake to eliminate a tester from hiring consideration just because they can't code or work with a particular tool. There are simply too many other needed skills and attributes to limit the decision to technical skills alone.
It's like being in a swimming pool and being able to go in the deep end as opposed to just staying in the shallow end. While we can all be in the pool and have fun. Some will be able to do more advanced things, like diving and snorkeling. It's not about worth or value, but about the ability to experience different things. So, if an inexperienced swimmer gets thrown into the deep end, it's "sink or swim", and that can sometimes be a dangerous thing. You may have experienced that "over my head" feeling.
Another example is owning and driving a car. Some people are happy just driving the car and keeping it filled with gas and having the fluids changed on schedule. Others want to get more involved in their vehicle's maintenance and repair by doing things such as changing the oil, replacing air filters and spark plugs, replacing fan belts, hoses and brake pads, etc. A few braver souls with older cars get into major engine repair or replacement. All of these types of car owners can drive the car well. Some can perform maintenance but due to time issues prefer to have the work done for them. All are valid owners and I would rather be on the road with good drivers who know little about auto maintenance than bad drivers who can replace engines in a day.
At the end of the day, the answer to this question of should a tester have technical skills may be a firm "it depends!" It depends on the person and their abilities, the projects they work on and the types of testing their job requires them to perform.
Skill #6 - Business Skills
Testers need to be able to speak the language of business. How can we as testers expect to be invited into business-level meetings if we don't understand the culture and language of business? This is more than just understanding business processes. We must know what's important to the business - profits, market share, strategic goals, markets, growth, legal, return on investment, and trade issues.
So, these are some of the important skills as I see them. Agree or disagree? I would like to hear your comments and ideas!
Thursday, December 04, 2008
Leadership by the Book
I ran across this online article in Federal Computing Week. It's an interview with Dave Wennergren, deputy chief information officer of the Defense Department. It struck a chord with me because I'm such a believer in reading as a form of personal development and skill building.
It's not how much you read, but what you read and how you apply it. You could read a book in one day and get nothing from it, or you could read a page a day and get a nugget of wisdom each day.
Unfortunately, too few IT professionals read books or articles about our profession. Testers are no exception. When I meet people in IT or not, I can normally tell within 10 minutes if they read very much.
For the price and payback, books are a great value. A $50 book can well contain thousands of dollars worth of valuable ideas and advice.
When faced with a problem, I usually ask myself, "Who can I ask?", or "What can I read?" to get a solution.
Here's a great quote from this article:
"When I was the Department of the Navy CIO, I started a leadership forum called Expanding Boundaries, which I have now continued in my DOD job as Expanding Horizons. The idea is to get the leadership team together once every couple of months, read a good book and then discuss how we could apply the book, to our work and our lives. It’s been a great way to understand the art of the possible and best practices, but even more importantly, it has helped to align the leadership team, improve trust and serve an idea creation engine as we strategize about next steps in our information transformation work."
One challenge that teams have is to communicate together well. This would be a good venue to help break that ice.
So, here's the assignment. Read this article, then let me know your thoughts.
Thanks,
Randy
It's not how much you read, but what you read and how you apply it. You could read a book in one day and get nothing from it, or you could read a page a day and get a nugget of wisdom each day.
Unfortunately, too few IT professionals read books or articles about our profession. Testers are no exception. When I meet people in IT or not, I can normally tell within 10 minutes if they read very much.
For the price and payback, books are a great value. A $50 book can well contain thousands of dollars worth of valuable ideas and advice.
When faced with a problem, I usually ask myself, "Who can I ask?", or "What can I read?" to get a solution.
Here's a great quote from this article:
"When I was the Department of the Navy CIO, I started a leadership forum called Expanding Boundaries, which I have now continued in my DOD job as Expanding Horizons. The idea is to get the leadership team together once every couple of months, read a good book and then discuss how we could apply the book, to our work and our lives. It’s been a great way to understand the art of the possible and best practices, but even more importantly, it has helped to align the leadership team, improve trust and serve an idea creation engine as we strategize about next steps in our information transformation work."
One challenge that teams have is to communicate together well. This would be a good venue to help break that ice.
So, here's the assignment. Read this article, then let me know your thoughts.
Thanks,
Randy
Monday, December 01, 2008
The Sports Secret to Building Software Testing Skills
Every once in a while, I'll run across an airline magazine article that really catches my attention. Yesterday on my way to Harrisburg on Continental, I read this article about how collegiate and professional sports stars improve their skills. I couldn't help but think of all the parallels to many of the concepts I teach in my Becoming an Influential Test Team Leader tutorial. Namely:
1) To improve a skill, you must focus on it like a laser beam. Improvement often occurs a little bit at a time (painfully slow at times), but then sometimes you have a breakthrough moment.
2) You must be willing to move out of your comfort zone to improve. Don't just work on your strengths, but also your weaknesses. Actually, I teach becoming exceptional in your strong areas and not to worry too much about the weak points. While I still believe in this philosophy, I also believe that we can all work on our weaknesses to become more well-rounded.
3) A good coach is willing to place a player in a position to fail so they will learn and improve. The player must also have the mindset that failing is an essential part of improvement.
Here's a quote I liked in the article from Steve Bzomowski, a former NBA scout and founder of Never Too Late Basketball Camps: “Pros take themselves seriously. And even though recreational players aren’t going to become pros, there’s no reason for them not to take themselves seriously. We’re always preaching, ‘Respect the game.’ So when you don’t run the court, you’re not respecting the game. Play the game right.”
So, testers, take heart. Identify your strengths and weaknesses. Practice on both, remembering it's OK to try things and fail - if you learn and improve.
1) To improve a skill, you must focus on it like a laser beam. Improvement often occurs a little bit at a time (painfully slow at times), but then sometimes you have a breakthrough moment.
2) You must be willing to move out of your comfort zone to improve. Don't just work on your strengths, but also your weaknesses. Actually, I teach becoming exceptional in your strong areas and not to worry too much about the weak points. While I still believe in this philosophy, I also believe that we can all work on our weaknesses to become more well-rounded.
3) A good coach is willing to place a player in a position to fail so they will learn and improve. The player must also have the mindset that failing is an essential part of improvement.
Here's a quote I liked in the article from Steve Bzomowski, a former NBA scout and founder of Never Too Late Basketball Camps: “Pros take themselves seriously. And even though recreational players aren’t going to become pros, there’s no reason for them not to take themselves seriously. We’re always preaching, ‘Respect the game.’ So when you don’t run the court, you’re not respecting the game. Play the game right.”
So, testers, take heart. Identify your strengths and weaknesses. Practice on both, remembering it's OK to try things and fail - if you learn and improve.
Subscribe to:
Posts (Atom)