How I Would Design a Programming Degree(kodefuguru.com)
kodefuguru.com
How I Would Design a Programming Degree
http://www.kodefuguru.com/post/2012/05/24/How-I-Would-Design-a-Programming-Degree.aspx
8 comments
This is not radically different from most (ABET accredited) undergrad CS degrees.
Intro programming sequence: - Critical Thinking - Logic - Imperative Programming - Object-oriented Programming
Databases: - Relational Data - Object-relational Mapping
Technical communication & ethics: - Professional Communication - Professional Conduct
Software engineering sequence: - Human-readable Data (also in databases) - Refactoring - Object-oriented Design Patterns - Requirements and Specifications - Organizing
Software testing (elective): - Unit Testing
Senior design projects: - Develop Software
Misc:
- Declarative Programming --> We learn regex in an intro to Linux course, XML in software engineering, etc.
- Tools of the Trade --> Picked up on your own, from profs, TAs, teammates, etc.
Which leaves only the following courses unaccounted for:
- Optimizing --> General optimization strategies aren't really taught at my university without looking for specific elective courses.
- User Interface Design --> Sadly, CS does not seem to concern itself much with the front-end of software; I wish this were not the case.
Intro programming sequence: - Critical Thinking - Logic - Imperative Programming - Object-oriented Programming
Databases: - Relational Data - Object-relational Mapping
Technical communication & ethics: - Professional Communication - Professional Conduct
Software engineering sequence: - Human-readable Data (also in databases) - Refactoring - Object-oriented Design Patterns - Requirements and Specifications - Organizing
Software testing (elective): - Unit Testing
Senior design projects: - Develop Software
Misc:
- Declarative Programming --> We learn regex in an intro to Linux course, XML in software engineering, etc.
- Tools of the Trade --> Picked up on your own, from profs, TAs, teammates, etc.
Which leaves only the following courses unaccounted for:
- Optimizing --> General optimization strategies aren't really taught at my university without looking for specific elective courses.
- User Interface Design --> Sadly, CS does not seem to concern itself much with the front-end of software; I wish this were not the case.
That's pretty much what my CS undergrad was about (european university).
In addition to everything mentioned by the author, we also had algorithm design, a lot of math (analysis, linear algebra, probabilities, statistics, topology, graph theory from the top of my head), economics, law fundamentals + intellectual property law, project management, communication + marketing, economics, english as a second language, and electives in our final years (computer graphics, etc.).
In addition to everything mentioned by the author, we also had algorithm design, a lot of math (analysis, linear algebra, probabilities, statistics, topology, graph theory from the top of my head), economics, law fundamentals + intellectual property law, project management, communication + marketing, economics, english as a second language, and electives in our final years (computer graphics, etc.).
This seems sensible. Of course many people could quibble about things they wish were included or dropped, but almost all of this stuff I've had to learn the hard way. Having most of this information presented to someone in an organized way would go a long way towards making them a formidable hire.
What about functional programming? I quite liked my class on it.
Also, at my school, we have a course on realtime programming on embedded systems. It's a cool class, I would like to still see it around.
Also, a class on bash and unix would be good.
Functional programming falls within the realm of declarative programming, so he's got that covered actually.
Courses in organizing and tools of the trade but no data structures?
no formal study of the analysis and design of algorithms?
See the section titled "On the Glaring Omission."
From my perspective, the point of a Data Structures class is not so that students can implement a red-black tree or skip-list off the top of their head- it's so that the performance characteristics of those structures and their associated algorithms will be deeply engrained. I've never needed to implement a hashmap from scratch in industrial code, but I've sure as hell needed to understand how they work beyond simply memorizing "insertions and lookups approach constant time". Algorithms is a similar story. I think leaving those courses out of a programming curriculum will result in mediocre programmers at best.
I would add the course: "Reading Code."
Algorithms and Data Structures needn't be about existing ones, although they are great examples. Algorithm design skills are a prerequisite for getting anything done efficiently, quickly and readably. Design patterns and software development models are secondary.
The case of data structures being available in libraries will lead to confusion as students will lack the ability to select the one with most appropriate performance characteristics. To them the only difference will be syntax. You could argue that one can look up complexity characteristics, but then how can you teach someone what is complexity without doing algorithms and data structures?
Algorithms and data structures are so prevalent, that they drive design issues that on the surface seem unrelated. Why map reduce is the query format we are using; how Clojure can have immutable, persistent yet still fast data structures; why public key cryptography is safe? And more importantly, algorithms and data structures teach us about tradeoffs.
It's not by accident that top companies test algorithm skills in interviews.