Here’s my spicy take for the day: if you’re advising a smart high school senior on what to study in college, stop defaulting to computer science. Tell them to get a business degree. If they want to work in technology, they should get a minor in CS.
I know that sounds backwards. I’ve spent 20+ years building software, leading dev teams, and turning around broken engineering organizations. The most important skill in this industry has never been writing code. It is understanding the problem you’re solving.
Some top developers solve deep technical problems. They leverage deep computer science and framework knowledge to deliver innovative and game-changing solutions. Years ago, an acquaintance of mine used .NET to write a new networking protocol with incredibly low latency. A good friend of mine from high school works on the software that drives top-end IBM SANs.
Other top developers make businesses better through the solutions they build. They build tools that make businesses run smoother. They automate manual processes. They give customers new functionality that makes the overall product more attractive. They understand the business and what it needs to succeed.
There has always been a major gap between these two kinds of developers. Most devs spend their career somewhere in that gap. AI just made that gap a canyon.
Most Companies Don’t Do Computer Science
I’ve long said that there are two kinds of companies: companies that use software to solve business problems, and companies where software is the business problem. There’s a third type: the ones where computer science is the problem. Understanding which one you work at, and your role in it, is one of the most important things you can figure out early in your career.
Computer science is algorithms, computational theory, data structures, operating systems, compiler design. It’s the deep math and logic behind how computers actually work. That matters if you’re working at NVIDIA on GPU architectures. It matters at Apple and Microsoft building operating systems. It matters in the narrow slice of FAANG/MANGO where you’re designing distributed systems at planet-scale. These are the third type of companies and the place where most developers will never spend time.
The overwhelming majority of companies are of the first two kinds. They either use software to solve business problems or they create software businesses use. The vast majority of the second kind only vaguely touch on anything resembling serious computer science. More decisions are made about product functionality and market fit than linked lists and memory addresses. Almost nobody in academia wants to say what that means out loud: most software jobs have very little to do with computer science.
That SaaS platform managing insurance claims? Not computer science. The logistics app optimizing delivery routes? Closer, but the hard part usually is not the routing algorithm. It is understanding the constraints of a driver’s actual day. The internal tool tracking inventory across warehouses? That is a business problem expressed through software. The vast majority of this industry is translating business needs into working software. The technical core of a CS degree is standardized. The business-translation work varies sharply by program, and it rarely receives the same depth.
What CS Programs Optimize For
A four-year CS degree optimizes for understanding how computers work. That is, unquestionably, valuable. Algorithms, data structures, computational theory, operating systems, and compiler concepts all help you understand the machine at a deeper level. However, most software jobs do not ask you to write a compiler or even understand how one works. They ask you to understand a business process, identify the user need, decompose the work, decide on trade-offs, and turn all of that into software the organization can actually use.
This is where the gap shows up.
A CS program optimizes for technical correctness inside the machine. It may give you one semester of software engineering. It may ask you to write applications whose main purpose is proving that your code compiles. It may teach you how to reason about runtime complexity. It usually spends very little time teaching you how to sit with non-technical stakeholders, refine ambiguous requirements, prioritize competing needs, explain trade-offs in business language, or understand the financial and operational context behind a technical decision.
Most software careers optimize for something else: judgment inside a business system. You need enough technical knowledge to make good engineering decisions. You also need enough business knowledge to know which decisions matter.
Recently, I reviewed code from a mid-level developer for a process that runs every 15 minutes. The process pulls a set of records, then performs three lookups and two updates for each record. Because of timing constraints, the batch size needed to stay around 150 records per run. The code was correct. It was functional. It would perform within reasonable bounds. But it treated each record as the unit of work.
Once we looked at the process differently, the shape of the solution changed. The three lookups could be done for all 150 records in batches, and those batches could run in parallel. The update payloads could be created in parallel. The API updates could then be queued and run in parallel or in controlled batches, depending on API rate limits and how much pressure we wanted to put on the downstream system.
That is not really a compiler problem. It is a process-shape problem. It requires technical knowledge, but the important move is understanding the workflow, the constraints, the throughput, and where work can safely happen at the same time.
I’ve led teams where brilliant CS graduates couldn’t write a story that made sense to anyone but themselves. Not because they lacked intelligence. They could solve the technical problem in front of them. What they could not do, however, was translate the business problem into a clear, testable unit of work. Nobody had taught them to think from the business side of the table.
AI Changes the Equation Permanently
Here is where it gets uncomfortable for CS purists: AI can write code. Good code. It’s getting better every quarter. In my own work, I have found that AI with proper guardrails can write better, cleaner code faster than nearly anyone I know. The gap between what an AI can generate and what a junior developer produces is shrinking to zero for most standard application development. What AI cannot do is carry your business context the way a human can.
I frame this for people as a context problem. Yes, modern AI systems can have enormous context windows. Some can hold a million tokens during a session. That’s a huge short-term memory and dwarfs what a human can hold. The long-term memory for AI is terrible, however. Humans have a great long-term memory. We reference it many times a day. We load information into our short-term memory, use it, and let it go. There are products trying to solve this. Some are useful. None have solved the full problem.
Robert C. Martin recently made the same point from the perspective of control. You do not get clean agent output by asking for it. You define the measures, test the result, and require correction. He has even argued that, when constraints are strong enough, line-by-line reading of agent output becomes the bottleneck. That does not eliminate human responsibility. It moves human judgment earlier: into the standards, specifications, quality gates, and definition of done.
The developers who will thrive in an AI-native world aren’t the ones who understand code the deepest. They’re the ones who understand the problem the deepest. A business process does not live by itself. It sits inside the people, the history, the incentives, the politics, the customer expectations, the operational habits, and the ethos of the company. All of those subtle details shape good decisions. They do not fit cleanly into a prompt, and they cannot be reloaded perfectly every time an AI session starts.
The person who understands the business can frame the problem correctly. That framing is what AI needs to build the requirements and then the solution. The entire chain from problem to production starts with someone who can articulate what needs to happen and why. AI is increasingly strong at the how. A person who understands supply chain logistics and knows how to work with AI will often get better results than a stronger coder who has never talked to a customer. That is not hypothetical. That is the trajectory we’re already on.
The Developers I Turn Around Aren’t Missing CS Knowledge
Here’s where this gets personal. I coach engineering teams for a living. I walk into organizations where sprint completion rates are in the 20-30% range, developers are working in isolation, and nothing ships on time. I’ve turned those teams into high performers: 85%+ completion, double the output, predictable delivery. The problem is never that the developers don’t understand enough computer science.
It’s that the system around them doesn’t connect the work to the business. Stories are poorly defined because nobody taught them to think about the user’s actual problem. Sprints fail because the work was scoped by someone who understood the code but not the business constraint. Features get built and sit in UAT for months because developers shipped what was specified without understanding what was needed.
This problem is exacerbated in small startups where developers are often expected to fill the role of product owner and develop full features from concept to shipping. Being able to understand the needs of users and deliver on that is far more important, especially when trying to get traction, than knowing how to perfectly implement a microservice architecture with CQRS.
Every single time, the turnaround involves building a bridge between the technical work and the business context. The teams that cross that bridge fastest are the ones with developers who can think in both languages. A CS degree doesn’t teach that. A business education does.
What I Actually Recommend
If I were advising a student heading to college today and considering a career in software, I would tell them to major in business and minor in computer science. Management information systems, operations management, and general business administration are all strong paths. The CS minor gives enough foundation to understand what AI is producing, read code critically, and spot structural problems. It also gives a foundation to build upon if new technical learning is required. The CS minor helps with how the software is developed. The business major teaches why the software exists in the first place.
If the student is already in a CS program, I would tell them to get a serious business minor at minimum. Take accounting, operations, project management, and strategy. Learn how a P&L works. Learn what executives actually care about. Technical skill may get the first job. Business fluency compounds over the rest of the career.
One practical caveat: a CS degree still gets candidates through many early-career hiring filters. Recruiters and applicant-tracking systems use it as a blunt proxy for technical ability, especially when a candidate has no professional track record. That bias is real, and students should account for it. I expect it to weaken as leaders get clearer about where AI creates leverage and where human business judgment remains scarce.
The organizations that learn the distinction will give more weight to a candidate’s ability to frame, validate, and deliver a business outcome than to a degree title alone. Until then, a business-major, CS-minor path should include visible technical work: projects, internships, a portfolio, and evidence that you can use the tools.
For hiring managers, the same principle applies from the other side. Stop requiring CS degrees for roles that are really about business problem-solving. The best developer on the team might be the person who worked in the industry for five years before learning to code. They already understand the domain. The code part is increasingly the easy part.
The Exception
I’ll be honest about where this breaks down. If you want to work on GPU compilers at NVIDIA, you need a CS degree. Probably a master’s. If you want to build operating systems at Microsoft or work on core infrastructure at Google, computer science is the right path. The same applies if you’re looking to work at Anthropic, OpenAI, or any of the myriad AI model startups.
However, those jobs represent a tiny fraction of the industry. If you’re one of the rare people drawn to that kind of work, you already know it. You were the kid who wanted to understand how the computer itself works, not just what it can do. For everyone else, and that’s most of you, the computer is a tool. The programming frameworks like .NET, Node/React, and Java are tools. Learn enough about a tool to use it well. Spend the rest of your education learning about the problems it can solve.
This Isn’t Hypothetical Advice
I’m not theorizing. I lived this. I graduated high school in June 1995 and started college as an Asian Studies major. Switched to Graphic Design. Dropped out and spent most of my career without a degree at all. What I did do, during those years, was take every business class I could find and read everything I could get my hands on: management, operations, strategy, finance. I gave myself the business education I knew I was missing. I finally finished my degree in January 2025. I did not earn a CS degree. I earned a business degree: a Bachelor of Business Administration in Computer & Information Management.
By the time I finished it, I had already spent 20 years leading software teams, turning around broken engineering organizations, and building systems that actually deliver. The CS knowledge I needed, I picked up on the job. The business knowledge is what made me effective.
My computer science knowledge came from self-study. I learned what I needed to when I needed it or when my curiosity got the better of me. When I needed to design a database from scratch, I took some database management classes and read a lot about data design theory. I used to regularly read a variety of newsletters and blogs to stay current with emerging technologies. When I wanted to understand how List
I gave this exact advice in March 2026 to a college freshman who is majoring in CS. He’s the friend of my stepson, a smart kid who likes technology and figured CS was the obvious path.
I told him: at the very least, pick up a strong business minor. Better yet, consider flipping it. The CS fundamentals he needs to collaborate with AI and read code critically would fit in a minor. The business knowledge he needs to build a real career (understanding how organizations work, how decisions get made, how to translate between technical and non-technical stakeholders) is a full major’s worth of education.
The world does not need more people whose only value is writing code. AI is increasingly handling that. The world needs people who understand what code should do, and can prove it matters to the business.
That’s a business education.
Receipts
- Software work begins with user needs: The U.S. Bureau of Labor Statistics describes software-developer work as analyzing user needs, designing software to meet those needs, planning how application pieces work together, and maintaining the result after release. Occupational Outlook Handbook
- The degree filter is real: BLS says software developers typically need a bachelor’s degree in computer and information technology or a related field. Its January 2026 Occupational Requirements Survey estimates that 75.8% of software-developer jobs require a bachelor’s degree. That supports the early-career hiring-filter caveat, although it does not prove a CS major is required. BLS education guidance, Occupational Requirements Survey
- What CS curricula emphasize: ABET’s 2025-2026 criteria require substantial coverage of algorithms and complexity, computer science theory, programming-language concepts, and software development. The criteria also require professional and general education components, which is why this essay argues about emphasis rather than claiming business context is absent from every program. ABET Computing Criteria
- AI gains depend on the setting: Randomized field experiments at Microsoft, Accenture, and a Fortune 100 company found productivity gains from generative AI, with larger gains among less-experienced developers. Management Science study
- The counterexample matters: METR’s randomized study of experienced open-source developers using early-2025 AI tools found a slowdown. The result reinforces the practical point that model capability, context, workflow, and verification all shape the outcome. METR study
- Practitioner signal, not proof: Robert C. Martin has argued that agent output should be measured and corrected against explicit quality constraints, and that a sufficiently rigorous test and quality gauntlet can replace line-by-line human reading of agent output. Those are experienced-practitioner views, not controlled research, but they reinforce the essay’s argument that judgment moves into the standards and verification system. Measuring agent cleanliness, the quality gauntlet
- Standards in daily use: My current team uses the open-source CodeMetrics.AI package and its associated code-scorecard skill for all new development. Legacy code is exempted. The scorecard gives human and AI developers the same measurable architectural and quality feedback.
- First-party turnaround data: At a financial services SaaS provider, a six-person team averaged 39% sprint completion across 25 sprints. After capacity-based planning, smaller stories, and shared ownership practices, it reached 86% in the first sprint and averaged 85% across the next 11. Completed work per sprint nearly doubled, and team-happiness scores rose from 5.5 out of 10 to 10 within six weeks.