Yesterday I was at the local Sheetz and the person checking me out asked if I was ready for school to begin (I LOVE living in a small town!). My immediate response: I am ALWAYS ready fro the students to come back!!!
Don't get me wrong, I love my job and this summer I have worked on some really interesting projects. Yes, they aren't research (which would have been more fun) - this summer was spent on administrivia. I have worked with our administration on two REALLY important projects: I proposed the creation of the School of Engineering at Ship and worked with our facilities guys on a plan to renovate our old, unused (but very cool) steam plant to create an industrial/lab space for Mechanical and Civil Engineering.
My summer work was recognized yesterday when the university president announced the creation of the school and funding for the renovations!!! I was thrilled - this is a really big step for our engineering programs and I couldn't be prouder of the way I spent my summer.
While these things give me a sense of accomplishment, nothing compares to the return of the students in the Fall! After a summer of meetings and proposals, the joy of seeing the students is unmatched! Old students come back with tales from internships and travel, each having grown in some way. And freshman come in wide-eyed and enthusiastic if a little naive. And the campus comes back to life!!!!
I have colleagues who like the quiet of summer and who are renewed by the projects they work on in that quiet. I am renewed by the creation of new syllabi, planning for an upcoming semester's classes, the excitement in the faces of my students, and the noise they invariably bring.
I am always ready for the students to come back!!!
Wednesday, August 22, 2018
Wednesday, July 4, 2018
Computer Science vs. Software Engineering
Since we created the Software Engineering (SE) bachelors' degree five years ago, it has been interesting to watch the Computer Science (CS) and SE programs mature (and diverge). When they are both in the same degree (as is true for most CS programs), SE is one of the typically required topics - often as the capstone - of the degree. When you pull SE out into its own degree, two things happen: you have to define what CS is without an SE focus and you have to develop the full topic of SE. We have wrestled with these questions with some consternation and, for a while, worried that we had essentially killed our CS degree. Most of our students are going into industry, so why would they not be Software Engineers? It turns out that there is value, even at the undergraduate level, in both programs. I think we have come through this process with an understanding of the relationship between these programs that has allowed us to give each a unique, and valuable, identity. And, I think the definitions we have arrived at are the normal progression of these programs.
The way we describe how CS and SE are related parallels other engineering disciplines: CS is to SE like Chemistry is to Chemical Engineering or like Physics is to Mechanical Engineering. CS is the science of computation and SE takes that science and builds things. This definition gives each of our programs a unique perspective and allows our students to pick which program is best for them.
As the science, CS requires a broad understanding of the sub-disciplines of computing like artificial intelligence, databases, big data, graphics, etc. It is the CS students who will expand the knowledge base, so they also need a good grounding in computability theory and run time analysis. For us, the result is an interdisciplinary approach to computing because the problems that computer scientists attack are often related to other disciplines with examples like data mining in politics, AI in business planning, etc. It turns out that the traditional CS curriculum meets the needs of this discipline pretty well except in the capstone project. Freed from having a Software Engineering requirement, the research focus of CS manifests itself in our students' capstone project - an individual research project in which the student carries out an experiment following the scientific method just like all of the rest of the sciences.
It is important to note that industry has a need for undergraduate computer science students. They will be more prepared to develop efficient solutions to specific, topic-related, problems. They will have practice with looking for state-of-the-art algorithms and adapting them to solve new problems. Their knowledge of theory and run time analysis will help ensure that those solutions are efficient as well.
Software Engineers take the knowledge that Computer Scientists create and use it to build systems for industry. In general, this means that Software Engineers are working on teams to produce large software systems. In order to do that, SE students clearly need some CS content. An SE curriculum must contain topics like programming, databases, and algorithms, but there are two broad topics that are unique to SE. First, there is a design aspect to SE. In order for large systems to be robust, you have to plan carefully how the internal pieces of that system will work together to create the behavior you imagine. It's like designing the Freedom Tower. Not only do you have to think about how it will look and how people will use it, but you also have to think about how big a chase you create on the first floor to be able to run wires to get enough power to the hundredth floor. That internal, invisible to the user, design is part of SE. Second, if you are building a big system, you aren't doing it alone. SE requires a team development process with strong communication deciding who is working on what, measuring our progress, and ensuring that we are building what the customer wants. There are tools that SE teams use to coordinate multiple working on the software and managing the release of that software to customers. Clearly, that is a lot of material that is not in a traditional CS program.
When your goal is teaching SE, the resulting curriculum is VERY different from the traditional CS degree. And I'll talk about that next time . . .
The way we describe how CS and SE are related parallels other engineering disciplines: CS is to SE like Chemistry is to Chemical Engineering or like Physics is to Mechanical Engineering. CS is the science of computation and SE takes that science and builds things. This definition gives each of our programs a unique perspective and allows our students to pick which program is best for them.
As the science, CS requires a broad understanding of the sub-disciplines of computing like artificial intelligence, databases, big data, graphics, etc. It is the CS students who will expand the knowledge base, so they also need a good grounding in computability theory and run time analysis. For us, the result is an interdisciplinary approach to computing because the problems that computer scientists attack are often related to other disciplines with examples like data mining in politics, AI in business planning, etc. It turns out that the traditional CS curriculum meets the needs of this discipline pretty well except in the capstone project. Freed from having a Software Engineering requirement, the research focus of CS manifests itself in our students' capstone project - an individual research project in which the student carries out an experiment following the scientific method just like all of the rest of the sciences.
It is important to note that industry has a need for undergraduate computer science students. They will be more prepared to develop efficient solutions to specific, topic-related, problems. They will have practice with looking for state-of-the-art algorithms and adapting them to solve new problems. Their knowledge of theory and run time analysis will help ensure that those solutions are efficient as well.
Software Engineers take the knowledge that Computer Scientists create and use it to build systems for industry. In general, this means that Software Engineers are working on teams to produce large software systems. In order to do that, SE students clearly need some CS content. An SE curriculum must contain topics like programming, databases, and algorithms, but there are two broad topics that are unique to SE. First, there is a design aspect to SE. In order for large systems to be robust, you have to plan carefully how the internal pieces of that system will work together to create the behavior you imagine. It's like designing the Freedom Tower. Not only do you have to think about how it will look and how people will use it, but you also have to think about how big a chase you create on the first floor to be able to run wires to get enough power to the hundredth floor. That internal, invisible to the user, design is part of SE. Second, if you are building a big system, you aren't doing it alone. SE requires a team development process with strong communication deciding who is working on what, measuring our progress, and ensuring that we are building what the customer wants. There are tools that SE teams use to coordinate multiple working on the software and managing the release of that software to customers. Clearly, that is a lot of material that is not in a traditional CS program.
When your goal is teaching SE, the resulting curriculum is VERY different from the traditional CS degree. And I'll talk about that next time . . .
Wednesday, June 20, 2018
Engineering Students
In my last blog, I talked touched on the fact that I identify as an engineer, meaning that, when something needs to be done, I look for available resources and strategies, design a way to put those things together to solve the problem and then assess and redesign as necessary. This is true for developing software, creating academic programs, handling my academic department, parenting, and many other aspects of my life. It is also at the core of how I handle my teaching responsibilities.
My primary responsibility as a software engineering faculty member is to help my students become productive and successful software engineers. Part of achieving that goal is by continuing to improve our curriculum. We certainly do that - I don't think an academic year has passed where we did not revise the curriculum as the result of our assessment of student learning. But there are much more personal things that are necessary to really help our students.
When I am assigned to teach a course, my primary responsibility is measured by the ability of my students to meet specific learning objects by the end of that course. My academic freedom means that I am allowed to design the structure of my courses with that goal in mind and that no one else can tell me that I must lecture or the course must be flipped or anything else about how I must teach that course (other than the possibility of a common text book). That means that I engineer each course. I look for ways other people have taught the course, look through my two decades of experience teaching similar courses, and think about what experiences I should design for my students. At the end of the semester, the culmination of all of those experiences should allow my students to meet the given learning objectives. I put together the syllabus and start traversing the course with my students. Along the way, I assess how things are going and redesign the experiences as necessary.
About a decade ago, it was common for people to talk about what was the "product" of higher education. The general consensus was that the degrees or the courses were the product, but I disagree. For me, the capabilities of the students are the product. In some ways, teaching is the art of growing and connecting neurons. As a product, it's really hard to think about manufacturing that product. I can't produce a neuron with some mechanical or even biological process and then sell it to my students. Instead, I have to design experiences that allow the students to produce and connect those neurons. This analogy clearly demonstrates that teaching and learning is a process that requires engagement of both the faculty member and the students. The faculty member has to design the experiences and provide the appropriate support for the student. The student has to actively engage in those experiences, analyzing what is happening and connecting that with the things they already know. Neither of us can be successful without the other.
Of course, the students and I are engaged in that process in the classroom, and I work to serve them all there. However, there are a few students who honor me with the opportunity to teach them in other ways. These students challenge my directions, question the experiences I have designed, share their struggles with the material, and share more of themselves with me, and, as a result, we both learn much more than the learning objectives of a course specify. These are the students who are taking the best advantage of the opportunity college provides, in which I see the most growth, and who become an integral part of what I am. The students who come after them benefit from what I learn from them and, invariably, they become very successful software engineers. I remember a long list of them and am grateful for each one.
My primary responsibility as a software engineering faculty member is to help my students become productive and successful software engineers. Part of achieving that goal is by continuing to improve our curriculum. We certainly do that - I don't think an academic year has passed where we did not revise the curriculum as the result of our assessment of student learning. But there are much more personal things that are necessary to really help our students.
When I am assigned to teach a course, my primary responsibility is measured by the ability of my students to meet specific learning objects by the end of that course. My academic freedom means that I am allowed to design the structure of my courses with that goal in mind and that no one else can tell me that I must lecture or the course must be flipped or anything else about how I must teach that course (other than the possibility of a common text book). That means that I engineer each course. I look for ways other people have taught the course, look through my two decades of experience teaching similar courses, and think about what experiences I should design for my students. At the end of the semester, the culmination of all of those experiences should allow my students to meet the given learning objectives. I put together the syllabus and start traversing the course with my students. Along the way, I assess how things are going and redesign the experiences as necessary.
About a decade ago, it was common for people to talk about what was the "product" of higher education. The general consensus was that the degrees or the courses were the product, but I disagree. For me, the capabilities of the students are the product. In some ways, teaching is the art of growing and connecting neurons. As a product, it's really hard to think about manufacturing that product. I can't produce a neuron with some mechanical or even biological process and then sell it to my students. Instead, I have to design experiences that allow the students to produce and connect those neurons. This analogy clearly demonstrates that teaching and learning is a process that requires engagement of both the faculty member and the students. The faculty member has to design the experiences and provide the appropriate support for the student. The student has to actively engage in those experiences, analyzing what is happening and connecting that with the things they already know. Neither of us can be successful without the other.
Of course, the students and I are engaged in that process in the classroom, and I work to serve them all there. However, there are a few students who honor me with the opportunity to teach them in other ways. These students challenge my directions, question the experiences I have designed, share their struggles with the material, and share more of themselves with me, and, as a result, we both learn much more than the learning objectives of a course specify. These are the students who are taking the best advantage of the opportunity college provides, in which I see the most growth, and who become an integral part of what I am. The students who come after them benefit from what I learn from them and, invariably, they become very successful software engineers. I remember a long list of them and am grateful for each one.
Monday, June 18, 2018
I am an engineer
Today I was listening to a podcast that was talking about "identity" and people were giving ways that they define themselves. I was surprised when almost all of them used gender/sexuality, ethnicity, and/or ancestry as their definitions. I don't feel at all like those things define me. Some of that is from my history - my family really had no ethnicity. Ask us what we were and we would say, "American." Yes, clearly, at least most, if not all, of my ancestry is European, but we never said we were from Germany (which the only immigrant ancestor I know of came from nine generations ago ) or anywhere else - we are just American. I also understand that those things aren't important to me is that I am in the majority for most of those things: white, heterosexual, female is only unique within the world of engineering where there aren't many woman. That means I have had the privilege of fitting in every where I went, so these things didn't seem important in my definition of myself - they didn't get in the way of me doing anything and didn't make me particularly unique. Finally, when I talk about "defining" myself, the things I pick seem to be constraining who I am and I don't want to be (and don't seem to be) constrained by those characteristics.
That left me with a big question: how do I define myself? Clearly, I have characteristics that drive what I do: I have always been smart, driven, and a little socially awkward, but, again, those aren't things that constrain me (much). So, after a bunch of thinking, I decided I am engineer. By that, I mean a take things that exist, design complex ways to put them together and use that to build useful, reliable things.
My specialty is software engineering and, obviously, when I am build software, I am engineering. While software engineering isn't a traditional engineering discipline, it has all of the aspects of engineering: I put together pieces of existing technologies in complex designs to create software systems that solve problems, are easy to use, and robust. This aspect of "I am an engineer" is pretty obvious. However, I find that this self-definition goes well beyond this narrow part of my life.
As a professor, I engineer a lot of other things. The curriculum for a program is a bunch of interconnected pieces designed to create an overall experience for our students. When we think about curriculum, we have to weigh lots of constraints:
My time at Ship has been full and much of that is because we have been creating new engineering programs since 2011. Every new program requires that we engineer a curriculum, but creating a program requires much more to be engineered. As a couple of examples, we need to design facilities that meet the needs of both the new and existing programs (clearly that is engineering) and we need to design an argument for the value of creating the program and put together appropriate proposals and talking points to sell the program. In this case, we are really engineering a strategy for convincing the administration to invest in our program and for students to pick our program. I know that sounds like marketing or proposal writing, but, to me, I am looking at existing resources, figuring out what new things we need, gathering the people who will help the program thrive, and designing a strategy for how I can put all of that together to support the new program. That feels like engineering to me.
For me, this analogy goes much further. My husband is also an engineer and a large part of our strategy to parenting was engineering. When there was an issue, we would think about what is she good at, what we needed her to learn, what existing tools/strategies we could leverage to help her, and what new resources we needed so that we could come up with a plan for how we would address the issue. Again, we are taking pieces that exist, designing a way to put them together to achieve a usable and robust solution. In fact, I think our family continues to use this strategy: we are all pieces with unique needs and abilities and keeping our family strong means that we are all thinking about how the pieces are fitting together and, when there are points of friction, we are looking at those pressure points to refine the design of how the pieces of our family fit together.
Ok, at this point, I know I've got a bit off topic and carried this further than any of us expected me to, but I find it really interesting. Years ago, I used cross stitch and I loved it because no one stitch said anything on its own - it's only when all of those parts come together that you get a "functioning" result. That's really how I see the world, so, I am an engineer.
That left me with a big question: how do I define myself? Clearly, I have characteristics that drive what I do: I have always been smart, driven, and a little socially awkward, but, again, those aren't things that constrain me (much). So, after a bunch of thinking, I decided I am engineer. By that, I mean a take things that exist, design complex ways to put them together and use that to build useful, reliable things.
My specialty is software engineering and, obviously, when I am build software, I am engineering. While software engineering isn't a traditional engineering discipline, it has all of the aspects of engineering: I put together pieces of existing technologies in complex designs to create software systems that solve problems, are easy to use, and robust. This aspect of "I am an engineer" is pretty obvious. However, I find that this self-definition goes well beyond this narrow part of my life.
As a professor, I engineer a lot of other things. The curriculum for a program is a bunch of interconnected pieces designed to create an overall experience for our students. When we think about curriculum, we have to weigh lots of constraints:
- the end results that the students need to be able to do,
- the things the students already know
- the constraints about numbers of credits and course frequencies,
- restrictions the institution puts on the teaching loads of the participating faculty
- national curriculum standards and
- requirements of our ABET accreditation.
My time at Ship has been full and much of that is because we have been creating new engineering programs since 2011. Every new program requires that we engineer a curriculum, but creating a program requires much more to be engineered. As a couple of examples, we need to design facilities that meet the needs of both the new and existing programs (clearly that is engineering) and we need to design an argument for the value of creating the program and put together appropriate proposals and talking points to sell the program. In this case, we are really engineering a strategy for convincing the administration to invest in our program and for students to pick our program. I know that sounds like marketing or proposal writing, but, to me, I am looking at existing resources, figuring out what new things we need, gathering the people who will help the program thrive, and designing a strategy for how I can put all of that together to support the new program. That feels like engineering to me.
For me, this analogy goes much further. My husband is also an engineer and a large part of our strategy to parenting was engineering. When there was an issue, we would think about what is she good at, what we needed her to learn, what existing tools/strategies we could leverage to help her, and what new resources we needed so that we could come up with a plan for how we would address the issue. Again, we are taking pieces that exist, designing a way to put them together to achieve a usable and robust solution. In fact, I think our family continues to use this strategy: we are all pieces with unique needs and abilities and keeping our family strong means that we are all thinking about how the pieces are fitting together and, when there are points of friction, we are looking at those pressure points to refine the design of how the pieces of our family fit together.
Ok, at this point, I know I've got a bit off topic and carried this further than any of us expected me to, but I find it really interesting. Years ago, I used cross stitch and I loved it because no one stitch said anything on its own - it's only when all of those parts come together that you get a "functioning" result. That's really how I see the world, so, I am an engineer.
Friday, October 7, 2016
Getting Ready for the Next Phase
This is my twentieth year as a faculty member and my fifteenth year as a department chair. This summer I emptied my office and redecorated because it is time for a new beginning. I have always loved this job, but I don't want to let it become a mindless habit. I enjoy thinking about how I approach my job, my students, my faculty, and my administration.
So, to help make sure that I don't lose that focus, the goal of this blog is to help me remember to pay attention to the details even though I have done them for so long. Perhaps there is still a better way for me to present material, design assignments, grade exams, assess my classes, revise the curriculum, negotiate for budgets and staff, etc.
Subscribe to:
Posts (Atom)