Intro to Software Engineering for Electrical & Computer Engineers

Nick Felker
6 min readMay 1, 2022


The opinions stated here are my own, not those of my company.

Engineering Hall, Rowan University

I went to college majoring in Electrical & Computer Engineering. I also decided to get a minor in Computer Science. At my university, the CS and ECE courses are taught by two different departments. While there was some overlap, the CS courses were much more aligned with the day-to-day work of a software engineering position.

While I did a lot of great stuff in my undergrad, like building a processor from scratch and launching rockets, I have to admit that not all of it was that helpful in my day-to-day work. In fact, I’ve not had any luck with referring classmates to work with me. If they didn’t get a CS degree, they are just not going to have enough practical skills to do the work.

I realize it’s contentious whether courses should be teaching the fundamentals or the applications. A class on databases may go into more basics than necessary, but a class just on MySQL and PHP might feel outdated. Personally I believe a good class is going to prepare you to learn about the pragmatics in your job, preparing you for whatever that might be.

That being said, I’m not sure my university’s engineering program sufficiently teaches software engineering skills, and while software is not specifically part of the scope of Electrical & Computer, it would prepare students for a world that is quickly being eaten by software. This may work as an elective, for those who may want to better pursue software engineering as their field.

Module 1. Intro to Toolchains: Git, Bash, LaTeX, Markdown

Markdown logo

In a standard 13-week semester, you can break down the curriculum into six parts, with an extra week for a final exam and/or a final project.

This first module gives a brief introduction to a number of common tools that engineers may use in their work day-to-day.

Git is certainly among the most important, as it is used near universally regardless of one’s tech stack. They don’t need to get a deep knowledge of how everything, but students should be able to sufficiently create good, contained commits using the command line or GUI software. While GitHub is the most popular host, knowing how to use git should let them work with other hosts. Teaching them about conventional commits would help them form better messages.

Bash is also commonly used, mainly in Linux (or WSL) environments to do a series of tasks. Having a pre-requisite of a programming class might help familiarize them with what can be done so they can focus more on specifically language capabilities.

LaTeX is probably less commonly used in software engineering, unless students go into academia, but I put it in this section as well. If this is taught at a freshman or sophomore level, knowing LaTeX would be useful for future classes. Being able to isolate your content from the format makes writing reports much easier. A brief introduction to BibTeX makes the writing process even better.

Markdown is the last basic tool you’ll want. Many projects will write their documentation in Markdown and being familiar with the syntax and getting them away from WYSIWYG tools like word processors will make the transition to industry easier.

Module 2. Porting Code

A lot of code is written in languages like PHP and Cobol even though they aren’t used in modern tech stacks

Learning how to port code is a skill that is really useful even though it may rarely come up. Yet the ability to understand the different syntax between languages and following logic prepares students for the industry, where you might be expected to write code in a language you’re not familiar with. You aren’t going to always be able to pick your tech stack, and if it’s handed to you, you’ll have to understand how basic software tasks map to the syntax.

In this module, the students should be given a number of basic programs and be asked to port from one language to another. Alternately they might be asked to move from one library to another (such as swapping out an HTTP library).

The first week might focus on taking a provided program and replacing the libraries. Then the second week might do a major rewrite from Java to Kotlin, or something. It might be best to stick to something like that, where the libraries won’t change because both are Java-based languages.

Module 3. Creating and using APIs

The Internet is full of APIs, and there are plenty of REST-based APIs and tools out there. Yet it might require a few classes to explain how to use them and concepts like POST and GET.

A class project should show them how to interact with a provided API to perform basic CRUD operations. They might need to interact with some sort of console to get an API key or setup OAuth, two parts of API usage commonly found in the real world.

Knowing how to use APIs will help them create their own in a way that is well-designed and useful towards their final project.

Module 4. The Web

While you can create a mobile app or Python script, the web is going to be easiest and most accessible deployment platform for students to share projects. Basic knowledge of spinning up a web server to host static and dynamic HTML content will help them no matter where they are hired.

This can be broken down into a few parts: hosting static content, hosting APIs, JavaScript, DOM, and CSS. Each of these might be worth a module or class on their own, so they’ll need to get the abridged version here. But it would be good to make connections to previous modules. Rather than teaching HTML directly, you should also show how to serve Markdown files. Your API module should blend straight into serving APIs themselves.

JavaScript and CSS might require their own lectures on their own, but it might be better to give a lighter overview and refer them to Mozilla’s excellent documentation. In fact, demonstrating how to read reference docs might be a good skill to teach in this module too, as trying to cover minutia in a lecture is a bad use of time.

Module 5. Refactoring & Legacy Code

When you are hired by a company, you will likely not write code from scratch. Instead you need to deal with existing code bases which might have been built up over years with many dependencies. Companies can’t afford to have things break either, so you will need to navigate around a complex project to change things with a light impact.

Classwork in this module might include giving them a pre-existing project that requires libraries to be updated, even though these libraries may introduce a breaking change. Alternatively, consider having a commonly used function now require an extra parameter. How does this affect the number of changes throughout the project and the stability?

Legacy code may also be present, a function or section of code that was written long ago and now just needs to keep working. This may be in the form of an obfuscated library or undocumented JAR file. Adding new functionality with this “black box” is something that happens with surprising regularity.

Module 6. Packaging and distribution

The final module revolves around going from development to production. In apps this may revolve around compiling and signing. For libraries this might be creating a new version and publishing. For websites this might be running a web bundler and pushing to a server.

In all of these there are best practices like continuous integration and continuous deployment which should be followed. Running tests on each commit can catch errors early. Monitoring errors in a web service can help identify regressions. Publishing a changelog can help communicate to others what changes are expected and what are bugs.

Final Project

Throughout the semester, students should work in groups to build a project. Bonus points if teams can work together to make some sort of singular meta-project. This is harder than it seems, as they need to work to agree on standard APIs, but it does give them experience in roles like technical lead and product management.

At the end of this course, they should have an understanding of the software lifecycle. Not just releasing once, but knowing how to maintain code over a period of time. This may include introducing quick hacks and plenty of refactoring. It should definitely prepare them for the world of software engineering if they do wish to go into that.



Nick Felker

Social Media Expert -- Rowan University 2017 -- IoT & Assistant @ Google