Software Engineering Terms Explained Like I’m Five
I’ve created a small guide of some Software Engineering Vocabulary: explained like I would explain them to my friends while drinking wine, or the classic “ELI5”.
This past summer I interned for RStudio, creating a series of lessons to teach Data Science to Software Engineers. To be totally honest, the closest I’ve ever come to being a software engineer was all the interviews I’ve failed. I’d ran some unit tests before, and at least had enough self-awareness to know that my crappy research code didn’t qualify as engineering experience. Before I began my internship, I promptly panicked and thought to myself “okay learn all you can about software engineering as fast as you can!” With roughly 10 weeks to spare, I entered into UW’s Software Engineering Seminar. Each week we read and discussed a paper, something I’d done many times before in other seminars. But software engineering research was entirely new to me. I already had some doubts about myself being there; I’m not a Computer Science PhD student and I’m certainly not a software engineer. I don’t even have a Computer Science Bachelor’s degree. On top of all that, the seminar had been meeting for many quarters already, and I was the newcomer. Let me preface the rest of this with the fact that I’m so glad I took the seminar. Not only was I exposed to software engineering research and vocabulary, but I faced something that was difficult for me and pushed through it. This sets me up to continue pushing myself and developing a solid growth mindset.
But with anything new comes a bunch of new, specific-to-the-domain vocabulary words. There are so many words that made me feel out of the loop, despite the fact that they were simple enough concepts. So I’ve created a small guide of some Software Engineering Vocabulary: explained like I would explain them to my friends while drinking wine, or the classic “ELI5”. Never underestimate a group of PhD students drinking wine and watching YouTube videos about quantum physics or explaining Turing machines. We should get course credit.
“Never underestimate a group of PhD students drinking wine and watching YouTube videos about quantum physics or explaining Turing machines. We should get course credit.”
This guide can be used by anyone who is starting to delve into software engineering research, starting their new software engineering position (having come from research or something like that), project managers, people curious about all these terms, or your Mom, maybe.
assert
Let’s say that you know you scale your data somewhere, going from raw values to a 0–1 scale (like probabilities). You’re messing around with a bunch of other crap, so you add an assert statement like assert(sum(column)==1) to make sure it all adds up to 1. If it doesn’t, your program says “You’re a moron”.
unit testing
Making a bunch of those assert-like statements to make sure you’re not a total dingus. Yes, they’re hard to come up with sometimes. That’s why coming up with a proper test suite is important.
test suite
All the unit tests, in a group. But it sounds fancier to call it a test suite, like a fancy hotel room.
fuzzer
Why be clever with your unit tests when you can just throw random inputs at the program until it crashes? That’s what a fuzzer is. An automatic “let’s-throw-random-crap-at-this-program-until-it-fails” program.
TDD (Test-Driven Development)
Write the tests for what you think the software should pass before you write the actual code. Then write the code to pass the tests you made. It’s probably gonna get all gunked up; just keep going iteratively.
test-last
Write your code in small chunks but then quickly write your tests as you iterate, but after you wrote the code already. It’s probably gonna get all gunked up; just keep going iteratively.
agile-dev
Iterative design-test-code in smaller chunks where you re-evaluate your life priorities between iterations. A fancier way to say “we iterate and check-in once in a while to get on the same page. Stuff changes a lot.”
debugging
Trying to get your code to suck less, and find the problems that are making it suck. There are no actual insects, probably.
refactoring
Rewriting the code to suck less, probably after you learned something you wish you’d known the whole time.
sprint
The period of time where you work your ass off on things that aren’t gonna get done but everyone delusionally hopes it will.
framework
A bunch of code already written to do A Thing so that you do not have to write it from scratch. It contains a bunch of libraries and is like the skeleton of the application.
API (Application Programming Interface)
A bunch of abstracted functions for a specific Thing that give you a headache because the documentation is crap. It’s pre-written code that allows apps to talk to one another. Like, my crappy code can now be hosted on Facebook so everyone can use my crappy applications that tell you what your Astrological sign means in relation to your favorite french fry shape.
full stack
Writing web development code where you do all the user-interaction graphics stuff (“front end”) and also the database management and probably all the web hosting and whatnot (“back end”). I hear it’s a pretty “kush gig” to be honest. Basically, you’re making something legit deployable instead of some weird Frankenstein version of a website from your laptop, probably.
scrum
Regular meetings with a project manager and your team to keep everyone focused and on the same page, and committed to the iterative approach. You don’t actually have to be standing. You could sit. Or jump. Or row a boat. But you must at least look a little bit like you’re huddling, talking about something important.
waterfall development
Planning out the schedule of development ahead of time, and then following all the steps linearly. Different from the iterative, agile approach. Don’t worry, you’ll probably mess this one up too, it’s just easier to pretend like nothing went wrong until the end.
