Accountability is what separates a software engineer from a programmer

Software engineering, unlike any other engineering discipline, requires no examinations to pass nor any licenses to obtain. Virtually anyone can learn the skills needed to become a software engineer, and that unique aspect of the industry is one of its most defining (and positive) characteristics. The software industry has almost no barrier to entry, as opposed to certain other sectors (like finance or law).

But, when should you call yourself a "software engineer"? Does it involve passing some arbitrary amount of time spent learning code? Is it something that happens as soon as you start getting paid for it?

The University of Bonn Experiment

In a recent study by the University of Bonn, 43 freelance developers were tasked to implement a user registration system for a fake social networking site.

The design of this experiment was to assess how developers implemented password storage, as a metric of gauging coding quality, and also evaluating if the rate paid affected the quality and scope of the solution provided.

The developers were split into two groups, one of which was paid €100 for their time, and the other €200. Importantly, half of each group was prompted to implement a secure password storage method, while the other half was not explicitly instructed to do so.

Of the 43 freelancers - all of whom had at least two years of experience in programming - 25 initially chose to store the passwords in plaintext.

The results of the services rendered by the four groups created are shown below:

In a Reddit thread discussing the study, user Zerotorescue reached the top comment, summing up:

“Basically what can be concluded is that the people who do tasks at freelancer.com, at below-market rates, deliver low-quality solutions.”

That assertion simplifies an issue that is far more nuanced than the blunt matter of fair work for fair pay. And, it doesn’t really address the fact that the number of developers implementing plaintext password storage didn’t go down too significantly when comparing the higher paid groups to the lower paid ones — only two additional developers implemented it without being asked.

How many jobs posted on sites like Freelancer.com and Upwork.com offer hourly rates of $100+? Any freelancer will tell you it’s far from the majority. So, should all software engineers approach these lower-paying jobs with the same expectations and mindset that they'd have in a contract offering market-rate pay, where they are presumably offered the resources and time to produce quality engineering work? Certainly not. It’s fair for a coder not to expend great efforts to ensure a product will be foolproof and work wonderfully for the end user. Not when the budget is small, the hours limited, and the technical requirements vague.

But it’s also fair for a client to expect some level of responsibility and accountability from the developer, even if they’re not paying top dollar for services, so long as these expectations have been set and managed correctly.

The main question — and point of this article — is this: is the client expecting you just to code whatever is needed to get the “job” done? Or, are you being expected to act as an engineer, someone who is being relied on to architect and build a system that not only encompasses the code but also includes higher-level system design(s) for a fully-fledged solution/product driving a business? This system design involves everything from user experience to project management to scalability, and, yes, security.

Software engineering is more than just programming

All the developers in the University of Bonn’s study had at least two years of programming experience and, yet, the 25 individuals who implemented an insecure password solution really should not have advertised their services as a software engineer if they had done so. Not based on the quality of the work delivered for the task in the study, at least.

A software engineer saving passwords in plaintext is like a civil engineer building a bridge out of Legos.

If you’re not encrypting passwords or using a compatible service that does so, you’re not really engineering any solution that can actually serve and authenticate users robustly, although it might work with letting users log in and log out to a site.

Just like if you’re using Legos to construct a bridge, it might be able to hold a person or two without collapsing under the weight, but that’s not how a bridge is meant to function in the real world.

People inherently believe that entering their passwords in a system that asks for it is secure, because, it’s their password. How could you ask someone to provide something, that is meant to be kept secret, if it wasn’t protected or encrypted?

Making things stable, reliable, and with implicit measures of security/protection is something that all engineers need to be doing, in any of their professional work. If the client isn't allowing the time or budget for you to achieve those things, you should try your best to convince the client to do so, otherwise you may want to reconsider the money is worth having your name (and code) associated with such a risky project. Of course, in the real-world, people aren't able to just walk away from a job they don't like without looking back. But consider previous precedents where even large companies with seemingly vast resources pushed ahead with seriously inadequate engineering work, and the inevitable fallout that occurred

Not doing so will not only often end up hurting the client in the long run, but also negatively affect the users/customers as well. Software being widely-used doesn’t save it from being poorly built and unsafe, and no one needs a reminder of the disastrous consequences that can come with poor digital security.

Software engineering is accountability

As a software engineer you’re holding yourself accountable to the functionality and well-being of not just the codebase, but the company itself and its customers along with the user experience offered to those customers.

You might hear programmers referred to (negatively) as “code monkeys,” which sounds (and is) insulting, but how else could one describe the 25 freelancers choosing to implement password storage in plaintext?

“I was aware that the good practice is to store them securely, but the task didn’t mention anything about that.”

The above is a direct quote one of the freelancers and alone demonstrates the distinction between software engineering versus programming.

While many of the devs who, upon further request, added more robust security and produced satisfactory results, it wasn’t just technical ability but the accountability and responsibility of the freelancers who did implement secure authentication without being explicitly instructed to, that separated and defined them as working engineers.

Engineers take it upon themselves to adjust and rethink technical portions as needed. Communicating the changes they deem necessary to the managers is an art form in itself, and as such, sound engineers will practice improving communication skills in tandem with their technical abilities.

Software engineers are programmers, but not all programmers are software engineers. And the path from programming to software engineering isn’t necessarily one of personal advancement but can be based around the needs of the business/client.

Not all products may need a professional engineer, but the ones that do require a lot more than just translating specs directly into code. And when you have clients who can’t or won’t pay for work of acceptable quality, the right choice is to walk away altogether and let these projects dissipate before features become threats and eventually become breaches and failures.

Do you have any stories or thoughts to share on transitioning from programmer to software engineer? Or any horror stories from freelancers/contractors working under misguided expectations? Let us know your thoughts on Twitter to join the conversation!

‍