Capstone classes and "real" engineering
I'll attempt a bit of subterfuge and obfuscation here so I don't inadvertently ruffle too many feathers...
Better he was there than me. I'd have lost my shit if an engineering prof said something like that to me.
I get what he's saying- that the journey is the point, not the destination- it's just that for everything else these students will ever do that is dead wrong. And I'll agree with one thing: for a microcontroller class, Arduino is the wrong choice because it does abstract away important concepts. But this isn't a microcontroller course, it's the capstone course, which is as close to an actual "design-a-solution-to-this-problem" assignment as most of these kids will get before they find their way into a workplace.
Giving these kids the (mistaken) idea that solution A (which requires 5 hours to realize because you used an Arduino) is somehow inferior to solution B (which requires three months to realize because you have to select a microcontroller, design, fab, populate, and respin a PCB, write code mostly from scratch, and do all this without a tremendous body of prior work and community support which is directly applicable to the code and hardware you're working on) is only going to cause trouble down the road- trouble for them, for the more experienced engineers they are hired to work with, and trouble for clients whose dates get missed because using solution A feels like "cheating" or "not real engineering".
I was taught that the point of an engineering education is to get a person to learn how to solve problems, not how to use tools (cross reference Isaac Asimov's wonderful short story "Profession"). The point of a capstone class, IMO, is to take the gloves off, put the students in the ring and expect them to beat the problem into submission through any means they see fit.
This idea, that the "easy" solution is wrong, undermines a core tenet of engineering- the "right" way to do something is any way that comes in fully functional, on time, under budget, and which is set up to perpetuate those three things into the future (i.e., is maintainable). I've known plenty of engineers who were so caught up in doing something the "elegant" way that they would never dream of not writing their own floating point library (in assembly!) for their microcontroller of choice even though there's a perfectly good library already written.
Done is beautiful.
A friend just sent me a summary of the EE capstone projects from this year's crop of students at a university that shall go unnamed. Bright-eyed young engineers, fun problems, innovative solutions, yadda-yadda-yadda. Pretty much anyone reading this has a pretty good mental image of what might have been in the e-mail, and many of you LIVED it. But then, right at the end, was an incredibly troubling BTW:
PS: professor's name here told me that he does not allow Arduinos to be used on these projects, since it makes things too easy (at this level of education, they're supposed to be learning the stuff that Arduino hides from you).
Better he was there than me. I'd have lost my shit if an engineering prof said something like that to me.
I get what he's saying- that the journey is the point, not the destination- it's just that for everything else these students will ever do that is dead wrong. And I'll agree with one thing: for a microcontroller class, Arduino is the wrong choice because it does abstract away important concepts. But this isn't a microcontroller course, it's the capstone course, which is as close to an actual "design-a-solution-to-this-problem" assignment as most of these kids will get before they find their way into a workplace.
Giving these kids the (mistaken) idea that solution A (which requires 5 hours to realize because you used an Arduino) is somehow inferior to solution B (which requires three months to realize because you have to select a microcontroller, design, fab, populate, and respin a PCB, write code mostly from scratch, and do all this without a tremendous body of prior work and community support which is directly applicable to the code and hardware you're working on) is only going to cause trouble down the road- trouble for them, for the more experienced engineers they are hired to work with, and trouble for clients whose dates get missed because using solution A feels like "cheating" or "not real engineering".
I was taught that the point of an engineering education is to get a person to learn how to solve problems, not how to use tools (cross reference Isaac Asimov's wonderful short story "Profession"). The point of a capstone class, IMO, is to take the gloves off, put the students in the ring and expect them to beat the problem into submission through any means they see fit.
This idea, that the "easy" solution is wrong, undermines a core tenet of engineering- the "right" way to do something is any way that comes in fully functional, on time, under budget, and which is set up to perpetuate those three things into the future (i.e., is maintainable). I've known plenty of engineers who were so caught up in doing something the "elegant" way that they would never dream of not writing their own floating point library (in assembly!) for their microcontroller of choice even though there's a perfectly good library already written.
Done is beautiful.
I would like to keep in touch with a fellow Asimov fan here, and I have to read that short story again. It was one of my old favorites.
ReplyDeleteI very much agree with you here, ran into this problem at the workplace as well actually.
ReplyDeleteI can mock that up with arduino in 2 hours or so, using other micro maybe 2 days, but my boss didn't like atmegas for some reason, comfort I think.
I do think that this does beg a bigger question:
how does one approach finding interesting open source code and then not be able to use it because their project is close source.
Unbelievably individual pleasant website.
ReplyDeleteTEFL and TESOL in Pakistan