Technological civilization depends on engineers who can think creatively, work on teams, design experiments, build new products, support existing systems, talk to users, and contend with questions of the proper use of technology in society. How can people with technical talent and interest learn all of these skills? Does this learning need to happen in a traditional college setting? Could it happen elsewhere, or continue throughout one’s life? How can we make such learning accessible to as many people as possible?
This “Open Software Engineering Curriculum” is an iterative approach to answering all of these questions within the domain of software engineering. In addition to the core knowledge of computer science, it aims to set out the professional skills required to succeed as an engineer. A large part of this will be the curation of existing resources with new content developed as necessary. This will draw from my experience at Olin, at Amazon, and own personal reflection. In particular, this effort aims to contribute to Olin’s “revolution in engineering education” by explicating its mostly unwritten theory and comparing it to what is needed in practice.
Envisioned Outcomes
Who is the “whole new engineer” (WNE) described in Olin’s vision documents?
In my own formulation, the WNE:
- Has competency in all stages of the product life cycle, which we call “Explore, Learn, Conceive, Design, Implement, Operate“.
- Works to improve the well-being of the product’s users and society.
- Understands management of a venture or business and how engineering fits into the advancement of its goals.
- Works effectively in teams.
- Is a capable communicator in writing, oral presentations, and documentation.
- Reflects on how engineers learn and develop their skills, and understands engineering as a discipline that is open to improvement.
Who could become this WNE? It should not just be high school students who enter a Bachelor’s program designed with these goals in mind. It ought to be anyone who wants to develop an engineering mindset, whatever their state of life.
Principles
To promote this, OSEC as a project will be:
- Accessible: All internal works will be in the public domain. External works referenced as part of OSEC should be accessible as digital files, should preferably be in the public domain or under permissive licenses, and if not be low-cost.
- Complete: Completeness of content is more important than avoiding repetition.
- Iterative: The content will improve over time. It is more important to cover all relevant topics adequately and solicit feedback for improvement than to make each segment perfect on first publication.
- Reviewable: Resources will be structured to allow for in-line commentary and easy response.
- As of 2023/09/24, this is using the in-line commenting feature on the constituent documents, attached at the end. This will evolve in the future.
- Curated: External content referenced as part of OSEC will be reviewed thoroughly and contextualized within the broader project. Every piece of content will have explicit justification for its inclusion. This will be most of the effort.
- Shareable: The internal OSEC content will be distributable as a single file by minimizing resource size and using common formats, or as a repository.
- This content will likely move to github eventually.
- Opinionated: While it will integrate content and feedback from many sources, this OSEC as a compendium will be one person’s work to maintain coherence. Its placement in the public domain will allow extension or remixing by others as they see fit.
OSEC’s three main parts will be a curated software engineering curriculum, a collection of essays on engineering practice and how to develop a learning community outside of the typical structure, and meta-commentary on the design of such a curriculum and pedagogical theory.
Contents
- Pedagogy and Curriculum Structure
- Engineering Practice
- Core Content
Mike's Engineering Blog 