I have a double major in Management Information Systems and Finance. My first real job was as a research intern at a nonprofit, where I spent the spring of 2018 cleaning data files in Stata for a project I didn't fully understand. My second was at a bank in Dhaka, where I sat through interviews with managers about a credit risk system and wrote up their answers in a Word document.
If you'd asked me at the time what I wanted to be when I grew up, I would have said "consultant" or, in a more honest moment, "I don't know." Software engineer would not have been on the list.
The slow drift
Looking back, the drift toward engineering happened in small, almost embarrassed steps. The Stata data cleaning kept feeling repetitive, so I wrote templates. The credit risk interviews kept producing requirements, so I started prototyping the system in Justinmind to see if I'd understood. The case competition I worked on with friends turned, somewhere around 2 AM, into me building a working Power BI dashboard while everyone else wrote the slides.
None of this felt like "becoming a developer." It just felt like the thing in front of me was easier to build than to describe.
If you keep finding yourself building the thing instead of writing about it, that is information about who you are.
What business school was unexpectedly good for
It took me a few years working in software to realize that the business degree had quietly given me a few things that the CS-from-day-one folks I worked with often had to learn the hard way.
Comfort talking to non-engineers. A lot of internal software is built for people who don't think in terms of databases. The business courses I took were entirely about understanding what stakeholders actually want, which is — in some sense — the whole job. I never had to overcome a reluctance to sit in a meeting and ask "but what is this really for?"
A built-in suspicion of complexity for its own sake. Finance courses were a relentless drumbeat of simplify until you can't, then explain. That instinct has saved me from a lot of overengineered code. The fanciest possible solution is almost never the right one.
Reading numbers, fluently. When I set up Grafana for the CRM at Temple, the part where I had to explain the dashboards to leadership was the easy part. I'd been reading those kinds of charts since freshman year.
What I had to learn the hard way
None of this is to say the path was efficient. It very much was not. I learned data structures by reading the introductions of textbooks at 11 PM. I learned design patterns by writing the same wrong code three times in a row. I learned testing by shipping a bug to production and watching the queue of tickets it generated, in real time, on the dashboard I'd built. Twice.
I'm now finishing an M.S. in Computer Science at Temple, which is the formal patch for the gaps — but the gaps were real, and they slowed me down. There's a humility to the non-traditional path that I think is healthy, but it's also genuinely a longer road.
What I'd say to someone in the same place
If you have a non-CS degree and you're trying to break into engineering, here's the only thing I'd say with any confidence: build the things in front of you. The internships I had weren't engineering jobs. They didn't have to be. The work that mattered — that ended up on my résumé and in conversations with hiring managers — was the work I made into building, when I could have just written a report.
The CS degree is useful. The credentials are useful. But the only thing that actually compounds is the habit of, when faced with a problem, instinctively reaching for code.
Everything else can be filled in later.