Software Engineer vs Software Developer

What is the difference between 'Software Engineer' and 'Software Developer'?

This question can be answered in the realm of engineering and software. But the full answer enters into sociology and psychology. Let's begin from this perspective of sociology and psychology.

Sociology and Psychology

Ever wonder why universities, especially the most prestigious ones, have such majestic structures and elaborate ceremonies? It's to instill this perception in peoples' minds that the difference in education they offer is so tangible that you can see and feel it. And of course, the most important aspect of making this difference real and physical is the paper degree that is awarded at the end. All of these mechanisms have the important effect of giving the receiver a sense that they are in the club of knowledge. One of the greatest benefits of this club is the networking. Very often, these traditional institutions are dominated by generations of the same families who have over-sized influence amongst their communities. This generational mechanism is codified in traditional institutions by what's known as Legacy Preferences. The converse effect of this club of knowledge mechanism is reducing knowledge sharing outside the club. This increases the power of traditional institutions of education and perpetuates this circle of generational protectionism, reducing a nation's breadth of innovation and opportunity.

The field of engineering has similar mechanisms for instilling this club mentality (for the purpose of information asymmetry a.k.a. knowledge withholding) that is reinforced through physical structures and elaborate ceremonies to make the boundary feel tangible in the minds of the people. Historically, these mechanisms evolved from occupational guilds. Adam Smith referred to guilds as a conspiracy against the public (1776 [1976], ch. X, pt. II, p. 152) for their actions beyond simply raising prices.

The breaking down of these imaginary barriers is inevitable and this process has been underway for decades. The internet is speeding up this process. A degree is no longer necessary to attain employment that would traditionally be considered prestigious. However, the treatment one receives after entering such employment is an open question because of the mentality of information asymmetry that has been instilled amongst the majority who did enter into the private sector via pipelines created by traditional institutions of education. It's for this reason that one must be cautious during collaborations.

These imaginary boundaries feel tangible to the people who work in their respective fields, such as engineering. They feel tangible to all members of society, as well. Peoples' entire world views are built around these boundaries. It's how they classify people as being in one class or another, and the vast majority of people have been raised to treat people differently based on their perceived class. It's for this reason that the opinions expressed in this blog post could invoke uncomfortable feelings in some people. But thanks to the internet, which is still in its infancy, this trend of the evolution of education is very likely to continue for the good of the majority of people. One might argue that there's tremendous misinformation and noise on the internet, but this problem will continue to be solved over time.

From a sociological and psychological perspective, the difference between software developer and software engineer is mostly imaginary, but great lengths have been taken (by creating majestic structures and elaborate ceremonies) to make it feel tangible in the minds of the people. Mostly imaginary, because we're still not at a point in human history where information is 100% free. The fact remains that traditional educational institutions conduct a great deal of research, and they are on the forefront of discoveries that push forward the boundaries of human knowledge. Today, it takes time for most of that information to be disseminated onto the internet. But over time, that loop will shrink, as it already has. Furthermore, it's important to note that this loop (of information from research to internet) is smallest in computer science and software engineering. In other fields, or even within certain specializations of computer science and software engineering, the loop is much larger and traditional institutions of education remain critical to these professional pipelines of human resources.

Now, let's explore from a technical point of view.

Software and Engineering

Depth

Engineers are often expected to have a deeper understanding of the underlying mechanisms of the tools they use. Modern software systems are essentially layers of black boxes nested within other black boxes and connected to even more black boxes. A software engineer is typically expected to understand not only how to use these abstractions but also how their internals work and interact.

That said, no single person can master every layer of every tool they touch—software is simply too vast. What distinguishes an engineer, in this sense, is the mindset of looking beneath the abstraction when necessary.

Breadth

Software engineers are also expected to take on a broader scope of responsibility. Their role often extends beyond writing code to include designing entire systems, understanding how those systems interact with others, and thinking holistically about architecture, performance, and maintainability.

Lifecycle

Another key difference lies in understanding and managing the software lifecycle. A software engineer is often expected to be involved from design through testing, release, and long-term maintenance. This broader lifecycle perspective ties closely to cross-team collaboration.

Information Asymmetry in Practice

Breadth and lifecycle responsibilities inevitably require engineers to rely on information from other teams. This is where information asymmetry — uneven distribution of critical knowledge — can make or break outcomes.

Speaking from experience as a self-taught engineer, the only customer-facing issue I’ve ever been conceivably connected to wasn’t caused by my code but by dependency coordination. Early on, I confirmed with the upstream owner that they would handle the upstream deployment via CLI, explaining that I didn’t have the necessary visibility. Despite repeated follow-ups across multiple channels, and a later attempt to hand off to the 24/7 on-call, the environment remained disabled and no one responded.

For more than two months I held the downstream deployment while seeking answers. During that period, senior project managers, managers, and teammates repeatedly pressed me to proceed, beginning as early as October; the senior PM was the most persistent. I nevertheless continued holding the deployment until the last working day before winter break in late December. The on-call rotation, responsible for weekly dashboard reviews, did not flag the issue, nor did they respond to my hand-off attempt. Given the repeated direction to deploy, the fact that this work was part of that year's planned delivery, and confirmation that a manager would handle deployments for the upstream component, I ultimately deployed the downstream component; the dependency break surfaced a few weeks later.

My mistake was assuming silence implied health when the team shifted discussion to Pre-Prod immediately after I’d asked about Prod. Escalations also went unanswered. Lesson: raise a manual high-severity alert when the on-call is unresponsive even if their weekly duty is to do the very thing you're asking. This was the most uncomfortable position I’ve been put in as an engineer. For context, I completed the code in a little over a week (on a three-month estimate), and it has run reliably since. A feature flag could have helped, but it would have also been dangerous because turning it off after turning it on would have caused negative customer impact. The best solution was the one implemented.

A discussion with ChatGPT places my responsibility around 10%, or 25% under "you build it, you own it". The loss was monetary, but thankfully, earlier that same year I saved a similar loss. Assigning 100% blame to the deployer oversimplifies responsibility in multi-team dependencies and is an extreme position. It can also create a de facto cut-throat environment. Although the formal process may emphasize blameless RCAs, informal social dynamics within teams often do not. Because social hierarchies influence corporate hierarchies (and promotions are zero-sum depending on the growth of the company) this can lead to misaligned incentives and interpersonal friction. It should be noted that each member of the team was responsible for some loss and overall, I was the most net-positive after all actions considered. This is one reason of why I was later moved to a team with much greater responsibilities and assured a promotion to Senior SWE. It’s also worth noting that nearly every engineer accumulates some level of operational error over a multi-year career; this case was not unusual in that regard. However, having now learned the principles of trust in the industry, I know this will be my one and only such error.

That greater amount saved was from a near-loss that was caused by issues downstream from my publishing code that surfaced during a routine audit. No change to my code could have automatically prevented the issue (a conclusion confirmed by multiple independent engineer reviews). Standard operating procedure would have been to accept the loss. My code has successfully published nearly $100 billion (includes internal non-discounted revenue) since running in production, although this code utilizes a client that handles most edge cases. Should note that I was a top contributor to the instructions for the client's usage. Should also note that deploying this publishing workflow was a one-way door. If things were configured incorrectly, no rollback path was available.

Incidents like this highlight that possession of a degree or a job title doesn’t guarantee full access to information. Many organizations have informal layers of "inner networks" (akin to fraternities or cliques) that control information flow. Navigating these murky waters requires a mix of technical rigor, soft skills, and possibly even acceptance of tribalism (for now, but I believe we must challenge it when safe).

Here are three practical strategies I’ve found useful:

1. Interpersonal and emotional intelligence – Build trust so others are more likely to share information proactively.
2. Obsessive due diligence – Verify every critical piece of information, especially if something feels "off" or incomplete. This can be difficult when you also have to double-check absolutely everything while information explicitly provided by teammates is sometimes incorrect.
3. Value balancing – Share information the other party doesn’t have but needs. Creating mutual value is one of the best ways to break down invisible walls.

Alternative Viewpoint

For balance, one could argue that I should have independently checked the dashboard for the downstream service after deploying, rather than relying on the on-call engineer to do so during at least one of the following two weeks, when they were expected to monitor it. This is a fair perspective. However, it does not fully account for the highly unusual circumstances surrounding this deployment.

The service in question was a periodic consumer/producer, not a continuously active pipeline. Given the repeated pressure from senior stakeholders to deploy beginning months earlier, combined with assurances that the upstream deployment would follow, it was reasonable to expect that the system would naturally pick up and reconcile once the upstream change went live. In other words, the design of the service itself implied delayed—but eventual—consistency once its dependency was satisfied.

More broadly, in complex systems, effective operation depends on a baseline level of trust in colleagues’ confirmations—particularly when those confirmations come from senior stakeholders and on-call ownership is clearly assigned. The fact that the upstream deployment remained disabled for months despite persistent pressure from senior leadership to deploy was highly atypical and fell well outside normal operating assumptions.

Requiring constant independent verification of every dependency, even after explicit positive confirmation from responsible parties, is neither scalable nor healthy in a large organization. That approach erodes trust, undermines role ownership, and leads to a mode of operation that is both inefficient and unsustainable.

Third Viewpoint

Another way to view the situation is simpler: I acted exactly as a team player is supposed to act inside a hierarchy. I made the deployment context and dependency known to the people involved, delayed the downstream deployment for an extended period while seeking confirmation, followed up repeatedly, attempted to hand off to the responsible on-call path, and ultimately moved forward when senior stakeholders continued to press for completion.

There is an important distinction between questionable direction from one individual and repeated direction from an organization in practice. If one person had pressed me to deploy under unresolved circumstances, it would have been much easier to treat that as an individual judgment that warranted continued resistance. Here, however, roughly five people were involved in pressing the work forward, most of them more senior than I was. This was also during my first year in the organization. For someone still learning the organization’s systems, norms, ownership boundaries, and escalation paths, repeated direction from that many mostly senior people carries substantial informational weight. At some point, continuing to assume that all of them are wrong—and that the relatively new engineer should override the collective direction of the people around him—becomes unreasonable. When the same course of action is reinforced across that many people and levels of seniority over an extended period, it is reasonable to understand it as organizational direction in practice.

I am proud of how I handled it. I did not conceal the deployment context. I did not ignore the dependency. I did not rush the work. I completed the technical implementation far ahead of schedule, held the deployment for months while seeking alignment, and then respected the direction of the organization. If that outcome is later treated as an individual failure, then the problem is not merely technical. It reveals something unpleasant.

Too often, “ownership” becomes a slogan used after the fact to push distributed organizational risk onto the last person who touched the deploy button. That is not engineering excellence. That is political convenience dressed up as accountability. Real ownership requires shared visibility, responsive dependency owners, functioning escalation paths, and leaders who do not treat the predictable consequences of their own direction as someone else’s failure. When leadership directs a course of action under known uncertainty, the resulting outcome may not be a deviation from leadership’s intent; it may be the tradeoff leadership chose.

To put it more simply, imagine if you were deploying a change to a service that is eventually consistent, where it is safe for processing to stop for a couple of hours because the service can catch up afterward. Your deployment depends on a corresponding upstream deployment. A colleague puts their hand on your shoulder and says, “Go ahead and deploy. I’ll take care of the upstream deployment for you.” So you deploy your change, relying on that explicit commitment. Your service stops processing, which is expected and temporarily safe while the upstream change is being deployed. But your colleague never deploys the upstream component. They simply go home. As a result, the service remains unable to process work for much longer than the safe recovery window, and that prolonged interruption causes customer impact. Broadly speaking, this is what happened.

I will never stop fighting civilly for a world where the innocent and naive can thrive without worry.

Internal Access Control

Internal Access Control is the process of creating security boundaries internally between permission groups that are assigned to different teams. There's a trade-off. Too much in too many environments creates too much red tape and increases the chance of problems arising due to lack of communication. Too little and unauthorized access becomes more likely. A balance that I like is having no internal access control for pre-prod environments that have no production data, but having strict internal access controls for environments that do have production data. This keeps development moving smoothly while decreasing risk of unauthorized access to production data. Strict internal access control in production does necessitate having engineers on 24/7 on-call rotations. There's a balancing act here that's necessary as well, depending on the company size and type of data stored.

Over time, I've come to align myself with the Third Viewpoint. I don't accept personal responsibility for the loss: after holding the deployment for months while seeking resolution, I ultimately carried out a course of action that had been repeatedly reinforced by more roughly five people, most of them senior to me, during my first year in the organization. Under those circumstances, there is a point at which continued refusal to follow the collective direction of the organization would itself become unreasonable. I therefore view what happened not as an isolated instruction that I chose to follow, but as organizational direction in practice. I do, however, take full ownership of what can be learned from the incident by proposing a systems-level solution: ephemeral, project-scoped permissions for neighboring services and accounts, with increasingly granular access as service complexity and organizational scale increase.

I enjoy using hyperbole in my language stylistically, but not here. The factual account above is presented as accurately and literally as I can state it.

Conclusion

The difference between software developer and software engineer is highly controversial. Many would say:

1. There is no difference.
2. The difference is in the scope of work.
3. The difference is based on credentials.

Updated: 2026-09-12