On MIS & Software Engineering

Lately, I’ve had requests for advice from peers whether becoming a software engineer with an MIS¹ degree is realistic. I recognize, especially for new graduates, there’s a lot of uncertainty behind the question because I had a version of it myself. In regards to their question, I lead with yes, but the more interesting question is what the degree prepares you for and what you have to deliberately learn yourself.

I’ll be upfront while MIS laid great foundations on data, systems, and baseline fluency for technology, I didn’t have all of it figured out entering my first internship with an edtech startup. My first 3 months there were heavily focused on self-studying through online courses, networking with engineers, and closing the gap on some fundamentals where a CS degree provides more depth. The return-offer came from immediately applying those lessons to build proof-of-concepts and team up with an engineer to propose an LLM-based tutor compared to workflow-driven, conversational bots. So, there’s no hiding there’s a great deal of work involved to build mental models of production systems and the execution necessary to show working demos.

On the other hand, the business context and strategy driving these production systems were more relevant to engineering than I initially appreciated. As I grew in ownership and influence in my organizations, technical decisions were ultimately deeply rooted on the context: user experience, impact, and adoption to name a few. Defense of tradeoffs mattered beyond the code. The degree has trained me to begin with intended impact of the project than only one or two narrow components of the system.

I’ve always wanted to start a company and I was able to spend the first 6-7 months building 0-1, talking to users, and iterating on a paid product. There were many technically interesting things, but it’s an anti-pattern to spend all of my effort only on those. What to build, who to talk to, how to distill customer feedback, change directions, and making bets on ambiguity were harder challenges to tackle. To me, it became clear my work became more valuable, in both a company I own and in my engineering career, when I’m able to have mental models on the deep technical issues and taking steps back to “zoom-out” on the context of the problems I’m solving.²

As I grew, I’ve come to more easily identify the gaps between a mid-level to senior-level engineer based on their behaviors than simply writing code. Senior engineers care about technical depth, but also ownership, unblocking themselves, leading with proposals, solving ambiguity, and defending decisions. I’ve come to learn career growth is not simply solving harder technical problems. Increasing seniority means increasing the radius of impact, or in other words, leverage.

I’d like to illustrate leverage in an engineering context. Suppose you’re tasked with reducing the overall errors on a web application and you’ve deduced a narrow problem: different components fetching data inevitably hit an error, but its blast radius is large enough to cause the entire page to return an error. The estimation of an engineer’s seniority is below and purely meant to illustrate rather than propose a rubric:

1. Junior/mid-level: solve the bug by limiting the blast radius to its own component and handle the fallback case reasonably. With some unit tests and local dev checks, the app no longer goes down when a single component on that page breaks.
2. Senior: Introduce the same fix as above, but conduct an audit on the rest of the website. Suppose you build tooling or another process with which QA team can be conducted prior to merges to fully prevent the problem reappearing on the site. The harness is reusable and other teams are improved by your change.
3. Senior+: Take the same auditing and fix approach but enable other engineers through writing documentation and best-practices. Pitch and get adoption on your approach so future developers and teams can adopt your thinking beyond only this narrow problem, but as a framework to solve future problems. Leverage here came from code you will never write or review compared to the senior engineer.

Hopefully the example illustrates how MIS comes in: some of the organizational-change material was abstract in college, but starts to look surprisingly relevant to senior/staff engineering, where influence often extends beyond your own code. Advocating change and mitigating risk, these are all tools for creating leverage and organizational change.

The cost of implementing code is falling, which increases the relative importance of specification, tradeoff judgment, verification, and accountability. Plausible PRs are opening at a higher rate than ever before, but code-reviews have become an industry problem where humans —even with LLM reviews— are inundated. Boris Cherney, who leads Claude Code, has gone so far as to argue that “coding is largely solved,” (link) however software engineering isn’t solved. What’s now scarce is judgment and engineers creating leverage.

Technical depth helps you judge whether a solution works. Product/business understanding helps you judge whether it’s the right solution. Writing and communication help you turn that judgment into action. Andrew Ng shares a similar sentiment about software engineering fundamentals where he argues deeply about why they’re essential in this age of coding agents (link). Therfore, generalists with enough technical depth to discern the implications of the decisions that these models make will find tremendous opportunity; it’s the fluency to know where AI struggles as the frontier of capabilities improve.

So, “can an MIS major become a software engineer?” is ultimately too narrow to have a binary answer. I think regardless of the degree background, there exist a finite set of skills that your background possibly contributes to. The work is to examine the gaps and deliberately build the missing components.

The degree is a starting point than it is a career assignment. The long-term goal is not merely to become technically capable, but to develop enough depth, judgment, and leverage to create meaningful change.