Build to Learn is an initiative by a group of volunteers to help people learn programming by building useful micro-products. Our motto is – Build to Learn and Learn to Build.
Anyone who wants to learn or build or do both can participate. We plan to meet a few times a week in 3-4 hour coding sessions and build useful products.
The setting is informal. You can start with a simple one paragraph definition of a product and recruit volunteers to work with you on the idea. We do not have any rigid processes. The team can decide how to interact.
We had the first session on the 3rd of February and 10 of us were present. We started 4 projects. We hope you can all join and either learn or help others learn.
Who can participate? Anyone who wants to help define a product, code, design, and test.
I was talking to a group of faculty members at KCG Tech on why we should ask schools to host An Hour of Code.
The Hour of Code started as a one-hour introduction to computer science, designed to demystify “code”, to show that anybody can learn the basics, and to broaden participation in the field of computer science. It has since become a worldwide effort to celebrate computer science, starting with 1-hour coding activities but expanding to all sorts of community efforts.
Here are some reasons why you should be interested in hosting an hour of code or help schools to host it.
- This grassroots campaign is supported by over 400 partners and 200,000 educators worldwide.
- It is an international movement to get people interested in learning to code.
- The first step in teaching programming is to get the learner engaged. Next steps include creating curiosity and giving them a sense of wonder. Show them what they can do with the code in a few minutes.
- Students will do something different and have a lot of fun while learning. In the past couple of instances where we conducted an hour of code, many 7th graders went beyond the hour, refusing to leave the computer lab.
- The program will be run mostly by student volunteers and techies. We are trying to get students involved in social causes. We believe the best form for students to learn, is by teaching.
From the Institute of Play On Games for Learning
Education in the early part of the twentieth century tended to focus on the acquisition of basic skills and content knowledge, like reading, writing, calculation, history or science. Many experts believe that success in the twenty-first century depends on education that treats higher order skills, like the ability to think, solve complex problems or interact critically through language and media.
Institute of Play makes a compelling case for games in education to build these higher order skills. It is an experiment worth trying in schools and colleges.
On a winter day in Boston, I sat through a two hour lecture on B-Trees. There was snow outside and we all sat spell bound as Greg Basset, our instructor taught us how Digital’s RMS-11K (the record management system) worked. The concept of incremental loading, fill factors, splitting data and index buckets and compression of duplicate keys, is still fresh in my memory. I gave that talk several times later in my life when I was teaching the subject. In each repetition, I learned a little bit more, answering questions. A few years later, I had the chance to use many of the ideas when we built C-Trieve and Objectrieve, two record management systems on top of which we built an SQL relational database. That was more than a couple of decades ago.
Looking at the Programmers Competency Matrix brought back lots of those memories. I think I am going to make a custom version of this matrix, make a poster and put it up on the wall of my class. A lot of these topics are not needed for the application programming today. But for a few of those intensely curious students, this is a kind of road map.
Reddit is a great source of interesting posts, especially for programmers. I should thank the kind soul who posted this link.
I was watching this video of Malcolm Gladwell’s talk over the weekend and enjoyed every minute of it. Malcolm has the uncanny ability to look at problems in new ways. He was talking about the challenges in finding the right people to hire in various professions. He calls it the “mismatch problem” According to Malcolm, the problem exists because:
- Our desire for certainty in a world where uncertainty is the norm
- The growing complexity of every profession increases mismatch
He points out, how, in various fields from sports to teaching, metrics used to select candidates do not really reflect the reality of the changing requirements of the job.
In software we do the same. We try to measure some of the basic skills like knowledge of software development including programming, conceptual understanding, ability to solve simple problems. The true attributes, however, are more complex and are not easy to measure in a test or in a few interviews. These include the ability to work in a team, ability to learn and communicate, a healthy curiosity and a certain amount of pride in work. Our challenge is to figure out how to train our employees in these new skills.
In the Next Programming Skill You Should Learn, Scott Hackett talks about the ability to communicate well, especially in writing. I totally agree. The post is certainly worth a read.
An unexpected bonus in this post is Scott’s tips on the golden rule of documenting software design.
The golden rule of documenting software design
Try to document whatever you are working on. It doesn’t have to be the worlds most perfect UML and you don’t need an expensive tool to do it. In fact, Wordpad and Paint are sufficient, and don’t tell me you don’t have those. Write in a way that best expresses your intent and your thought process in coming to the design decisions you did. I have a golden rule of documenting software design:
Describe your design to others as you would have others describe their design to you.
When you spend the time to do this, you’ll find that many benefits will follow. You’ll get feedback from others that may have tried to solve a similar problem and have insight you may not have thought of. You’ll leave a clear trail to follow for those that work on the code after you. Most importantly, you’ll shed light on your work, which everyone who depends on your work will appreciate. Even if no one else reads what you write, you’ll still have worked through problems in your head that can only lead to better design in the long run. There is no downside to documenting your designs.
One of the experiments I am conducting with a set of interns is to make them write a LearnLog and ProjectLog – just a few bullets or short sentences. We do this in a wiki so that every one in the project has access to it. It is also one of the easiest and most effective ways to communicate asynchronously with the team.
In the Project Log, they are supposed to write the following:
- Design decisions
- Decision to use libraries/tools and why
- Problem areas and stumbling blocks and how they solved it
- A list of links to the resources they used
It is still an uphill battle but we are getting better gradually.