TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Teaching Programming the Way It Works Outside the Classroom

47 pointsby gkuanalmost 12 years ago

9 comments

mathattackalmost 12 years ago
My impression at school was they were teaching CS more like math, rather than aiming for anything useful. The professors were looking more for beauty than real world applicability. Nothing is wrong with that goal, but one shouldn&#x27;t confuse that with practicability. One professor even mentioned that students going to corporate jobs weren&#x27;t as important as those going to Phd programs.<p>We had one two semester sequence that involved a real world project of our choice, and that did involve all of the listed steps from the article. And more - we had to do real documentation: requirements, design, test cases, etc.
评论 #6201072 未加载
fnordfnordfnordalmost 12 years ago
This is pretty much how my &quot;programming class&quot; goes (it is an junior college intro to microcontrollers course). We usually start with a fresh OS install, Linux, VirtualBox, Windows VM, a bunch of other stuff, lots of hand-holding, step-by-step list. It is sometimes a very annoying disaster. There are always a few do-overs, sometimes from the clever ones, usually though it is the ones who are marking time.<p>Show them what a file is (look at it with a hex editor). Then work through the first couple chapters of K&amp;R. Some scripted tasks. Try to get them to notice a little bit about what&#x27;s really going on. Try to get them to understand the work flow (write, compile, test, etc). Show them some common pitfalls with data types, integer division, etc. Then on to &quot;blink&quot; with an Arduino, (working out the bugs of introducing hardware as we go). Work through a few examples, of increasing complexity. Start working on examples with external hardware. Then they propose an individual mini-project. We keep working on Arduino stuff, eventually involving serial comms with the device via Python, or Java (Processing) while coaching them through their mini-project. Also do some, data logging, plotting their data, pushing data out to the web (Pachube&#x2F;Cosm&#x2F;Xively).<p>Several times during the semester, students will be given a task, but not given any direction (at least not at first) on how it is to be done. Some students do exceptionally well. Some &quot;A&quot; students wind up with their first &quot;B&quot; or &quot;C&quot; because the format&#x2F;structure is completely foreign to them. Others fight tooth and nail against the format, and probably against some of the other things I do that they were not prepared for.
edtechdevalmost 12 years ago
I tried to comment on the article but the comment form wasn&#x27;t working with chrome or firefox, but:<p>The article is forgetting a couple of things - in the real-world you also have a purpose, a goal for what you are trying to create or a problem you are trying to solve. You also have a wealth of background and tacit knowledge about the constraints and affordances of programming. If you just had students mimic the actions of how programming is done in the real world, they would be doing it without understanding the reason for it.<p>Another point: none of this is new - there is actually a field of study for education research. Search for example for &quot;problem-based learning&quot; for more information on approaches in education that have students work on real-world, messy problems.
RogerLalmost 12 years ago
We don&#x27;t really need more &#x27;hack a stack&#x27; programmers. Somebody needs to write that code in the first place, and that is the hard, but rewarding work. Teach students how to program, how to reason, how to run experiments (yes, a semester in physics lab or EE lab (I did both)), how to code in assembly, and so on, will take them much further. It&#x27;s not that hard to google and download a bunch of API&#x27;s, just tedious. If you don&#x27;t understand why a one choice might be worse than another, you have no chance. If you understand algorithms, math, design, and so on, you will probably make a pretty good choice even if all you are doing in this specific instance is gluing a bunch of code together.
zenbowmanalmost 12 years ago
I don&#x27;t think its a good idea. There&#x27;s value in doing things from scratch when you are learning. It helps you learn to stay organized.<p>There&#x27;s plenty of people who can tweak and cajole code into working. There&#x27;s a lot fewer people who understand the principles behind software and can manipulate those principles to create what they want, instead of tweaking little bits of code and copy-pasting.<p>Yes, most of your time in industry will involve working from an existing codebase, and a lot of time will be spent cajoling and tinkering, but if you have experience building semi-large projects from scratch, that isn&#x27;t hard to pick up. Going the other way, on the other hand, forget about it.
mknappenalmost 12 years ago
This style of programming also goes by the name &quot;code quilting&quot;. Part of the difficulty with moving this workflow method into the classroom is that it requires schools to redefine &quot;cheating.&quot;
评论 #6204282 未加载
wbillingsleyalmost 12 years ago
We&#x27;ve had a course running for a couple of years now that seeks to addresses these issues, as well as the inherently collaborative nature of software engineering.<p>It&#x27;s a second year course that in its first two iterations had approximately 70 students working on a common code-base: tinkering, extending, integrating their work, etc. This year we have 170 students. And we&#x27;re on a path towards opening the course to the world.<p>(This also means that rather than have students work on small greenfield exercises, they&#x27;re working on a project that in terms of numbers-of-programmers is possibly larger than some of them will work on in their first post-degree jobs.)<p>It&#x27;s a follow-on to a more introductory programming course -- we expect students to come in to our course knowing the basic syntax of the language.<p>papers for those who might be interested:<p>Billingsley, W. &amp; Steel, J. 2013. A comparison of two iterations of a software studio course based on continuous integration. ACM conference on Innovation and technology in computer science education (ITICSE). 213-218<p>Süß, J.G &amp; Billingsley, W. 2012 Using continuous integration of code and content to teach software engineering with limited resources. International Conference on Software Engineering (ICSE). 1175-1184<p>(I also posted this as a comment on the article itself, so apologies if you see it in two places.)
moron4hirealmost 12 years ago
Well, I personally start most of my projects from scratch. To me, there are 4 phases to a project cycle, and the cycle is always repeating:<p>First, is information collection: I want to know as much about the problem as possible. I&#x27;m not even looking at code yet.<p>Second, is fitting that information together. This could involve code to test theories, or writing documentation to communicate them to others. I&#x27;m trying to understand how the constituent parts of the problem fit together. I&#x27;m usually working with a subject matter expert on the problem domain, as the subject matter expert on software development. I&#x27;m usually going to end up telling the person I&#x27;m working with that some aspect of their problem or how they do work--as currently stated--will be difficult to encode as a program, but a small change in business practice would make it simpler.<p>Third, <i>we</i> come to a decision on how to progress. At this point, we basically have a few proposals for how to proceed, involving some initiatives for writing code and some initiatives for changing business practice. It <i>has</i> to be that way. You can&#x27;t write code to completely synthesize an organic process. The best human processes will seek to build redundancy into the system. The best computer systems will seek to eliminate redundancy.<p>And finally, we act on it. We don&#x27;t second guess our decisions until we&#x27;re done doing it. We don&#x27;t add to it, we don&#x27;t take away from it, because that would all be changing the plan without collecting new information and understanding it in the greater context.<p>Then we start over from scratch. We always, <i>always</i> need to go back to collecting as much information as possible, which now includes &quot;how well does the current software fit our expectations&quot;.
whiddershinsalmost 12 years ago
When i code like that, it can feel a lot more miserable. It is a process of constantly wrangling and finagling rather than creating. I always wonder if I should have done more from scratch.
评论 #6202959 未加载