4 ms·

I'm sort of curious how one could "learn" software engineering in a week. Judging from the article, it seems the course assumed very little prior knowledge abou

I'm sort of curious how one could "learn" software engineering in a week. Judging from the article, it seems the course assumed very little prior knowledge about SWE (teaching OOP at the beginning). Wouldn't it make more sense to teach a course assuming some basic background knowledge (like OOP and command line utilities) and use the teaching time to discuss architectural patterns, testing practices, etc?

asauce 7y ago
This is exactly what I was thinking. Software Engineering is a lot more than just writing code, however this blog post makes me think that he is teaching Software Engineering to a completely new audience. It is very easy to overwhelm software students when trying to teach a broad array of topics (especially in a week!). He mentioned that his students ran into challenges such as not understanding the difference between 'python foo.py' and 'python3 foo.py'. How can you expect these students to overcome these beginner challenges and then still learn topics such as git, CI, machine learning (!!), functional programming, concurrency, processes, etc! These topics can take years to learn properly, and require a good foundation. Maybe I didn't understand the purpose of this course, but it seems pretty insane
- ticmasta 7y ago
  It's a smell that a course that dedicates an hour to object-oriented programming even mentions UML. Wouldn't your audience be far better served if you offered dozens of focused sprint classes (1 topic; 1 hour) rather than some sort of eclectic marathon?
kemiller2002 7y ago
I agree. It's a nice attempt, but I don't see how this is practical. It falls into the same trap people looking in from outside the software development have been falling into for years. They assume that it's easy because they can do an excel macro and such. Software development is actually really hard. Complex systems are hard. A parallel to this would be something like, "You built a bird house out of wood. We'll teach you how to build a skyscraper in a week." It's just not possible.
- watwut 7y ago
  You learn to be software developer by starting to learn one small thing at a time until over time you accumulated a lot. This course is a collection of such starter things and there is nothing wrong with that. I don't think people who go there expect to come out as experienced engineers. They expect to learn some this so that they can learn more later.
  - hermitdev 7y ago
    I think this a very good point. This is giving them knowledge of how to start, and hopefully the resources to continue to improve. Most computer science curriculums don't teach you how to become a software engineer. They teach you theory, probably with some practical by ways of labs and projects. Hell, when I got my degress in computer and electrical engineering, I don't think version control was ever mentioned, let alone continuous integration. I learned about this on the job as an intern, well, about VCS. CI wasn't popular back when I interned. The amount of practical learning accelerated my first few years as a full-time developer. Went from barely using nix to spending nearly all my time there except for time spent in Outlook. Went from a cursory knowledge of C++ to having a beyond intermediate knowledge. Learned Python (back at version 2.2!). I think a big point of a course like this is not to give you a full knowledge of the domain, but rather how to learn* about the domain. Software is constantly changing; to be effective, you have to be able to keep up. Which means a lot of reading. When I first started, Google wasn't a thing. Meant a lot of dead tree edition books (ebooks weren't a thing yet). I got my starting points when I was in high school from early forums and mailing lists circa 1995. Took a long time to research things at 56kbps. Also took an effort to convince my parents to buy me programming books at $40 a pop even in the 90s, but when they saw me reading them cover to cover instead of watching TV (easy to get motivated - we only had 2 TV channels) and spending hours slaving away on the computer on programming instead of playing Civ 1, they were more willing to buy the books.
highwind 7y ago
Biggest thing that needs to be taught as one of the fundamentals for software engineering is approaching problems with scientific method. Design, testing, and debugging (which takes up more resources than writing code) require skill in forming good hypothesis and methodical way to test that hypothesis. These type of courses should be designed more towards those skill sets than just learning to write code.
- cyberflunk 7y ago
  I completely agree with you! I have only been in industry for about 3 years now, and quickly learned that I would be spending most of my time solving problems and investigating large, complex issues. Do you know of any resources where I can learn more about forming good hypotheses and methodical way of testing? Maybe books or online courses, or is this sort of knowledge only learned through experience?
- rb808 7y ago
  disagree, here is a great talk about how Software is more about French Poetry than Physics https://www.youtube.com/watch?v=9LfmrkyP81M https://www.youtube.com/watch?v=9LfmrkyP81M
- sreque 7y ago
  I've actually been thinking at work recently that our work is very much in line with making and testing hypothesis. When we add code or edit existing code, we hypothesize that the program behavior will change in specific ways, and then we test those hypothesis via various means of manual and automated testing. I would actually add to the above though that I think it's important people learn to approach problem-solving from a mathematical perspective. Unfortunately, a lot of people that get into software engineering don't like math, and they would generally be averse to learning about software engineering this way, but I think a lot of bad code gets written because the person writing it didn't approach the problem with the right structure or rigor.
  - chrisweekly 7y ago
    Where you say "mathematical" I'd suggest "logical". Also, formal logic (Aristotelian, sentential, predicate...) is distinct from mathematics per se. Agreed that fundamental problem-solving skills are in too-short supply.
mixmastamyk 7y ago
You study the material up front, practice for ten years. Then study the material again, and practice ten years. Rinse, repeat.
lliamander 7y ago
Judging from the course materials and course description, it looks like it's a class for scientific researchers who can code, but only in a crude manner to support their other research activities. The course is intended to help these researchers to understand software design and collaborative tools like git to be more effective at writing code.
- dmurray 7y ago
  I had trouble reconciling the presentation of the course as an introduction to software engineering with the claim that it will become "the basis for doctoral training programmes in research software engineering at Oxford". Shouldn't candidates for a PhD in software engineering know this stuff already? But it means "engineering of research software", not "research into software engineering".
pdovy 7y ago
Yeah, it seems like this would be better served to be split into two (or more) courses if you're assuming almost no prior knowledge. "Software Engineering" is a pretty ill-defined term, but I'd generally think of it as the _process_ of developing good software, and that sort of presupposes you can develop _any_ software. Coming in with some ad hoc ability to program (and probably some bad habits!) would be a plus - then the "process" part is actually solving a problem, rather than just feeling onerous.

asauce 7y ago

This is exactly what I was thinking. Software Engineering is a lot more than just writing code, however this blog post makes me think that he is teaching Software Engineering to a completely new audience. It is very easy to overwhelm software students when trying to teach a broad array of topics (especially in a week!). He mentioned that his students ran into challenges such as not understanding the difference between 'python foo.py' and 'python3 foo.py'. How can you expect these students to overcome these beginner challenges and then still learn topics such as git, CI, machine learning (!!), functional programming, concurrency, processes, etc! These topics can take years to learn properly, and require a good foundation. Maybe I didn't understand the purpose of this course, but it seems pretty insane

ticmasta 7y ago
It's a smell that a course that dedicates an hour to object-oriented programming even mentions UML. Wouldn't your audience be far better served if you offered dozens of focused sprint classes (1 topic; 1 hour) rather than some sort of eclectic marathon?

kemiller2002 7y ago

I agree. It's a nice attempt, but I don't see how this is practical. It falls into the same trap people looking in from outside the software development have been falling into for years. They assume that it's easy because they can do an excel macro and such. Software development is actually really hard. Complex systems are hard. A parallel to this would be something like, "You built a bird house out of wood. We'll teach you how to build a skyscraper in a week." It's just not possible.

watwut 7y ago
You learn to be software developer by starting to learn one small thing at a time until over time you accumulated a lot. This course is a collection of such starter things and there is nothing wrong with that. I don't think people who go there expect to come out as experienced engineers. They expect to learn some this so that they can learn more later.
- hermitdev 7y ago
  I think this a very good point. This is giving them knowledge of how to start, and hopefully the resources to continue to improve. Most computer science curriculums don't teach you how to become a software engineer. They teach you theory, probably with some practical by ways of labs and projects. Hell, when I got my degress in computer and electrical engineering, I don't think version control was ever mentioned, let alone continuous integration. I learned about this on the job as an intern, well, about VCS. CI wasn't popular back when I interned. The amount of practical learning accelerated my first few years as a full-time developer. Went from barely using nix to spending nearly all my time there except for time spent in Outlook. Went from a cursory knowledge of C++ to having a beyond intermediate knowledge. Learned Python (back at version 2.2!). I think a big point of a course like this is not to give you a full knowledge of the domain, but rather how to learn* about the domain. Software is constantly changing; to be effective, you have to be able to keep up. Which means a lot of reading. When I first started, Google wasn't a thing. Meant a lot of dead tree edition books (ebooks weren't a thing yet). I got my starting points when I was in high school from early forums and mailing lists circa 1995. Took a long time to research things at 56kbps. Also took an effort to convince my parents to buy me programming books at $40 a pop even in the 90s, but when they saw me reading them cover to cover instead of watching TV (easy to get motivated - we only had 2 TV channels) and spending hours slaving away on the computer on programming instead of playing Civ 1, they were more willing to buy the books.

highwind 7y ago

Biggest thing that needs to be taught as one of the fundamentals for software engineering is approaching problems with scientific method. Design, testing, and debugging (which takes up more resources than writing code) require skill in forming good hypothesis and methodical way to test that hypothesis. These type of courses should be designed more towards those skill sets than just learning to write code.

cyberflunk 7y ago
I completely agree with you! I have only been in industry for about 3 years now, and quickly learned that I would be spending most of my time solving problems and investigating large, complex issues. Do you know of any resources where I can learn more about forming good hypotheses and methodical way of testing? Maybe books or online courses, or is this sort of knowledge only learned through experience?
rb808 7y ago
disagree, here is a great talk about how Software is more about French Poetry than Physics https://www.youtube.com/watch?v=9LfmrkyP81M https://www.youtube.com/watch?v=9LfmrkyP81M
sreque 7y ago
I've actually been thinking at work recently that our work is very much in line with making and testing hypothesis. When we add code or edit existing code, we hypothesize that the program behavior will change in specific ways, and then we test those hypothesis via various means of manual and automated testing. I would actually add to the above though that I think it's important people learn to approach problem-solving from a mathematical perspective. Unfortunately, a lot of people that get into software engineering don't like math, and they would generally be averse to learning about software engineering this way, but I think a lot of bad code gets written because the person writing it didn't approach the problem with the right structure or rigor.
- chrisweekly 7y ago
  Where you say "mathematical" I'd suggest "logical". Also, formal logic (Aristotelian, sentential, predicate...) is distinct from mathematics per se. Agreed that fundamental problem-solving skills are in too-short supply.

mixmastamyk 7y ago

You study the material up front, practice for ten years. Then study the material again, and practice ten years. Rinse, repeat.

lliamander 7y ago

Judging from the course materials and course description, it looks like it's a class for scientific researchers who can code, but only in a crude manner to support their other research activities. The course is intended to help these researchers to understand software design and collaborative tools like git to be more effective at writing code.

dmurray 7y ago
I had trouble reconciling the presentation of the course as an introduction to software engineering with the claim that it will become "the basis for doctoral training programmes in research software engineering at Oxford". Shouldn't candidates for a PhD in software engineering know this stuff already? But it means "engineering of research software", not "research into software engineering".

pdovy 7y ago

Yeah, it seems like this would be better served to be split into two (or more) courses if you're assuming almost no prior knowledge. "Software Engineering" is a pretty ill-defined term, but I'd generally think of it as the _process_ of developing good software, and that sort of presupposes you can develop _any_ software. Coming in with some ad hoc ability to program (and probably some bad habits!) would be a plus - then the "process" part is actually solving a problem, rather than just feeling onerous.