I also get to experience this same thing with students in my Intro to Robotics course. This course isn't just a bunch of computer science geeks doing geeky things: I use it to prepare my students to work well, both in their personal and professional lives, by teaching them essential life skills.
I know teaching life skills through robotics sounds far-fetched, so I'm going to prove it below.
In this course, one of the exercises I teach is the After-Action Review. This consists of five questions:
1. What was supposed to happen?
2. What actually happened?
3. Why did it happen?
4. What did we learn?
5. How can we do better next time?
On Monday, as I lead them through an After-Action Review, I wrote the answers to the final question on the board (as you can see on the left). The action under review was the students' preparation for their final in-class competition (which involved designing and building a robot in teams), but the answers they came up with also translate to work and life in general.
Note that these are not in order of importance or priority. They're all lessons learned. Here's what my students had to sayplus applies to best practices for life:
1. Decide what you want to build beforehand
Before you start, ask "what's the successful outcome?" What would "done" look like? If you don't have this clear from the start, especially on a major project (like building a robot), you'll waste a lot of time and effort.
2. Know your tools
For my students, this meant knowing the computers and robot parts they had to work with.
For you and me, this translates to knowing what you have to work with and how to use it. That's part of the K (Knowledge) in my V=KMT equation.
Whatever tools, systems, and resources you use, there are ways to learn how to use them better. This might be as simple as Googling "Microsoft Excel tutorial" or asking a senior coworker for some pointers.
3. Iterate and experiment with options
My colleague David Allen published his international bestseller Getting Things Done: The Art of Stress-Free Productivity over 12 years ago. Since then, he's continued to experiment with ways to tweak and improve his methodology (in fact, as you can see here, he's recently published a new edition).
In other words, never stop improving!
4. Record, review, revise, recalibrate
I think it's funny that one of my students' answers to the After-Action Review was essentially "do After-Action Reviews." They got it! Always be willing to examine and change how you do things.
5. Know what's in your kit
Know what you have to work with:
- Tools, machines, programs
- The knowledge you can access: what you know, who you know ,and what they know
6. Keep it simple and appropriate
"More complex" doesn't always mean "better." This Dilbert strip makes a great illustration.
7. Pace yourself
Working longer can actually make you less productive. Resting is an important part of doing valuable, effective work.
8. Study the problem
A little thinking ahead saves a lot of effort.
9. Save your fine-tuning for when you have a working solution
If you obsess with getting it right on the first draft, it'll take you much longer to get anything done. This would fall under the Method (M) of my V=KMT equation — that is, your practices and procedures for how you do things.
10. Use version control
My students would save each version of their robots' programming. That way, if a new version didn't work or had some serious flaw, they could go back to the previous version.
For you and me, this could be as simple as saving different versions of a Word document instead of continually overwriting the old one, and backing up the copies in different locations.. This way, when (not if) your computer crashes, you can go back to the last version instead of starting all over.
11. Keep a journal
It helps to record what you're building and changing and why. This way, if you come back to something months or years later and wonder, "Why did I do it this way," you can look it up in your journal. If you don't have this, you may end up learning the hard way.
It's especially helpful on long, complex projects to be able to go back and find what you and your team decided and agreed on.
For things like this, I use the automatic journaling feature in the eProductivity Reference Database.
12. Don't lose sight of the problem you are trying to solve
I'm amazed how many consulting problems are solved by the question "What are you trying to accomplish here?" Usually, everyone on the team has a different answer
That's the point that I'm able to guide my clients into figuring out a solution. Once we know what they're aiming for, we can figure out what needs to be done and make a plan.
13. Communication is key!
Don't assume that everyone on your team is on the same page. All of you should clearly know A) what you're all trying to achieve and B) who's responsible for what.
You've probably been in this situation: a meeting ends with everyone agreeing that we need to do Thing X. By the next meeting, Thing X hasn't been done, because it was never stated or agreed who was responsible for it. This leads to "I thought you were going to do it!"
14. Think outside the box
Of course, the hardest parts of this are usually 1) realizing there is a box and 2) figuring out where its walls are.
15. Reuse proven code (don't reinvent)
I've been using some of the same tools and content for many years, not because I'm too lazy or afraid to innovate, but because it still works. Knowing your proven solutions is key -- and not only that, but storing them in such a way that, even if you don't look at them for months or years, you easily find and use them again.
For example, if you get a certain question from customers every few weeks (or even every few months), there's no need to reinvent the wheel every time you answer it. You might keep responses to recurring questions in email folders and simply forward the same response every time you get the question.
Organizing your knowledge for quick and easy retrieval is also part of the "Knowledge" component of V=KMT.
16. If it ain't broke, don't fix it!
This is closely related to 15 above. Keeping a healthy tension between conserving what works and innovating new solutions can be an interesting balance.
Here's a piece of advice: if you're going to fix what ain't broke, use version control (#10). That way, if you break what was working, you'll have a working version to go back to.
Learning robotics, preparing for life
Not only does teaching robotics let me invest in young people at my alma mater, it's also a great way for me to sharpen my consulting skills. With a little thought, the lessons my students learn in class translate directly to real life at home and at work.
Robot hand image by Richard Greenhill and Hugo Elias [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons.
Speech bubble icon: free from ClipArt Best
Journal icon: public domain from Pixabay.
Discussion for this entry is now closed.