Reqs, Specs, Design, etc.

Note: This is cross-posted from my blog at work, edited for some Amazon-internal content

Officially I got a bachelor of science in Software Engineering, although for all practical purposes at the time, it was the same as a CS degree except more limiting for graduate studies. Meaning that with a BS in CS you could easily do graduate studies in CS or SE, but with a BS in SE I think you'd probably have a hard time getting into some graduate CS programs, given the lack of theory requirements. Either one seemed to be fine for pursuing a job in industry.

But anyway, the nominal purpose of a SE degree as opposed to a CS degree is to get more experience in the areas listed in the title of this post, as opposed to a straight curriculum of coding, coding, and more coding but in a different language. The idea was to get your feet wet in some industry techniques, and to be better positioned to jump right in to a job in the industry working on software projects (at least, that was my impression of it, you can read the RH CSSE curriculum descriptions here (CS) and here (SE)). Specifically, there were 6 core SE classes:

• 371 Software Requirement and Specification
• 372 Software Project Management
• 373 Formal Methods in Specification and Design
• 374 Software Architecture and Design
• 375 Software Construction and Evolution
• 376 Software Quality Assurance

371 and 372 were required for all CS and SE majors, while 373-376 were required for SE majors and were actually blacklisted for CS majors (with the justification that the CS majors should be more diversified in other areas of CS).

So did the degree achieve its goal? I was in only the 3rd graduating class of the SE program, so it's fair to say it was still in its infancy. I think 371 was valuable and gave a good insight into some of the basics of gathering requirements and writing specs. I barely remember 372, other than the giant book, and generating Gant charts. 373 was, in my opinion, completely useless unless you were going into research on formal specification methods. I also barely remember 374. 375 and 376 were my favorites out the 6, because they both involved hands-on software work in the context of the subjects being learned. The other 4 classes involved no actual coding, just writing docs and the like. From talking to some professors after I graduated, I think they are trying to take this approach with all of the courses now, which I think is a good thing, although I'm sure it's challenging to fit in all of the same content and add programming at the same time.

So where am I going with this? I'm supposed to be working on the design piece of a pretty big refactoring/migration project that my team will be embarking on next year. It's a great project, something I've been wanting to do since about 3 months into my Amazon career. We could never get the project resourced on my old team, but when my current team was formed the project was given priority.

So why can't I get my brain engaged on it? I've been working on it for most of December and have very little to show--I need to have something for our external dependencies (both ways) to look at pretty soon, and it's pretty far away from being in that state. I show up at work and I just don't want to work on it. Notably, this is the first large piece of non-coding, planning/designing work I've been tasked with at Amazon, and these skills are key to moving up the SDE job ladder. This is the kind of stuff I got an SE degree for, and I can't seem to get excited about it, or even apply myself marginally well to it. And here is where my stream of consciousness seems to run out. I'll get back to you when I figure it out, or just trudge through it.