Ask HN: How to create good computer scientists and engineers?
8 comments
The systematic teaching of math at some universities doesn't make a whole lot of sense either. Why should linear algebra be taught after calculus? Why is number theory basically ignored by most of engineering and every other science at the undergrad level?
Something important for anyone engaged in technical design work is judgement. Ralph Peck, a famous geotechnical engineer has a good video lecture. It's a bit specific to civil engineering, but the broad strokes of exposure to history of your field, recent developments, a sense of proportion, and commitment to professional development are applicable everywhere.
https://peck.geoengineer.org/resources/videos/singleVideo/41
Something important for anyone engaged in technical design work is judgement. Ralph Peck, a famous geotechnical engineer has a good video lecture. It's a bit specific to civil engineering, but the broad strokes of exposure to history of your field, recent developments, a sense of proportion, and commitment to professional development are applicable everywhere.
https://peck.geoengineer.org/resources/videos/singleVideo/41
A suggestion of the lab course "Practical Computing". I have extended and revised a list I posted in response to a different thread. You could spend about 1 week on each.
Spend 10-30 minutes or so the first day talking about the wild ride that is hardware improvement up to the present.
Show them how to use VirtualBox, or some other platform to make Virtual machines, install an OS, etc. Explain what a virtual machine is.
Show them how to make backups, and test them. They need to have confidence that they can recover, and can't damage things beyond repair.
Show them how to use apt-get to install and remove things. This is essentially giving them all of the open source software in the world.
Show them how to use keywords with google, especially -searchterm. This will aid them when they want to find things. Teach them about the "magic words" and how to find them... i.e. annotation instead of markup, that kind of thing.
Set them up a git repository and Notepad++. Teach them how to use it, along with GitHub or some equivalent. Just use plain text until they understand how it all works. After all, source code is merely executable collated knowledge that the compiler happens to accept. This gives them a platform for working with files that they can use as a foundation, instead of the stack of sequentially numbered zip files we had to use in the 1980s.
Walk them through their first pull request and fork. Show them the value of good communication, and set some expectations about working with others.
Set them up with Excel or the Open Equivalent. Show them how purely declarative programming works. Then show them how macros work. Everyone should know how declarative programming works.
Show them how double entry book keeping works. How errors in entry are detected and corrected.
Show them your favorite programming language. Explain how you came to value it, it's strengths and weaknesses. Show them, if possible, some of your code.
Show them lisp, forth, basic and prolog, and explain the strengths and weaknesses of each.
Show them how test driven development works. Make sure they know how to write good tests.
Show them how gnu readline works, have them read the manual for it, and bash (this one is a new thing to me, as an old windows user. You would not believe how powerful that thing is)
For the love of all that is good in the world, teach them how to name variables correctly, how to write useful comments, and how to smell code.
Teach them pair programming, the experience of a few hours can help them skip months of grief. It can be quite a bit of fun to show your kids something new. Don't be surprised when they return the favor.
Most of those are elements that are, as someone pointed out in the other thread, CS adjacent. Outside of the theoretic understanding of CS, I think that being able to wrangle a system is something that everyone should be able to do. Just as EE students should be able to build a power supply, learn that the Red wire is positive (unlike accounting), etc. Think of this as lab time.
Spend 10-30 minutes or so the first day talking about the wild ride that is hardware improvement up to the present.
Show them how to use VirtualBox, or some other platform to make Virtual machines, install an OS, etc. Explain what a virtual machine is.
Show them how to make backups, and test them. They need to have confidence that they can recover, and can't damage things beyond repair.
Show them how to use apt-get to install and remove things. This is essentially giving them all of the open source software in the world.
Show them how to use keywords with google, especially -searchterm. This will aid them when they want to find things. Teach them about the "magic words" and how to find them... i.e. annotation instead of markup, that kind of thing.
Set them up a git repository and Notepad++. Teach them how to use it, along with GitHub or some equivalent. Just use plain text until they understand how it all works. After all, source code is merely executable collated knowledge that the compiler happens to accept. This gives them a platform for working with files that they can use as a foundation, instead of the stack of sequentially numbered zip files we had to use in the 1980s.
Walk them through their first pull request and fork. Show them the value of good communication, and set some expectations about working with others.
Set them up with Excel or the Open Equivalent. Show them how purely declarative programming works. Then show them how macros work. Everyone should know how declarative programming works.
Show them how double entry book keeping works. How errors in entry are detected and corrected.
Show them your favorite programming language. Explain how you came to value it, it's strengths and weaknesses. Show them, if possible, some of your code.
Show them lisp, forth, basic and prolog, and explain the strengths and weaknesses of each.
Show them how test driven development works. Make sure they know how to write good tests.
Show them how gnu readline works, have them read the manual for it, and bash (this one is a new thing to me, as an old windows user. You would not believe how powerful that thing is)
For the love of all that is good in the world, teach them how to name variables correctly, how to write useful comments, and how to smell code.
Teach them pair programming, the experience of a few hours can help them skip months of grief. It can be quite a bit of fun to show your kids something new. Don't be surprised when they return the favor.
Most of those are elements that are, as someone pointed out in the other thread, CS adjacent. Outside of the theoretic understanding of CS, I think that being able to wrangle a system is something that everyone should be able to do. Just as EE students should be able to build a power supply, learn that the Red wire is positive (unlike accounting), etc. Think of this as lab time.
Okay, so when a Daddy nerd and a Mommy nerd love each other very much…
I’d go with a student-selected-project approach. That taps into the student’s passion (or at the very least: interest) for some problem he or she can attempt to address or solve technologically. The learning I’ve done that has stuck with me the most is learning that happened while I was trying to DO SOMETHING or MAKE SOMETHING HAPPEN. A clear goal in mind is a remarkable motivator to study and retain new knowledge and information!
There are guides like https://teachyourselfcs.com/ but they are aimed at experienced developers.
Almost all guides assume that either you know programming or you will pick it up by looking at the syntax of a popular language and solving a few problems using it.
Mathematics is taught systematically at universities, but, I think CS doesn't get the same treatment. That's why we get so much junk in production systems.
If you were asked to design/teach a curriculum to CS students that teach both the science and the art (engineering) how would you design it?
Ordering of topics, books used, anything that comes to your mind. Shoot!