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 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 production 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 pressed to proceed; the senior PM was the most persistent. On the last day before winter break, I initiated the deployment. The on-call rotation, responsible for weekly dashboard reviews, did not flag the issue, nor did they respond to my hand-off attempt. Believing two months was sufficient for upstream readiness given the pressure from management, as well as confirmation that a manager would handle deployments for the upstream component, I 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 (something I didn't know you could do at the time). 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 much greater 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) this can lead to misaligned incentives and interpersonal friction.

That much 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.

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.

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.

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: 2025-11-13