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: 

  • 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.
So, when we modify the curriculum (or come up with a curriculum for a new program), we have to take existing courses and topics and design an interconnected web of these courses to achieve the goals we set of our students.  The result has to be usable (able to be completed in four years and within the constraints of the institution) and robust (we don't want to change the curriculum more often then necessary).  So, when I am revising or creating curriculum, I am engineering.

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.

No comments:

Post a Comment