What is your personal Programming ethics?

Jeffrey E. Uvero on April 27, 2018

markdown guide

Remember the consequences of "move fast and break things" mindsets aren't just occasional bugs. Developers hold the responsibility of users' data and our mistakes have consequences.

You can't un-leak data and you can't un-ruin peoples' lives.

I'm not sure if that answers the question but it's what comes to mind.


Alternatively: Move slow and ignore CVEs (I'm looking at you, equifax).

In other words, just because you're consuming code that other people wrote, and that is considered "stable," doesn't mean you can skirt responsibility when that code is found to be vulnerable.


Not intending to inflict Godwin's law, but the "Nazi soldier defense" is unacceptable. There is no just following orders, or if I do not do it, they will find somebody else. You simply do not do things which you think are wrong. Yes, that could mean that you might have to find a different job. As a software developer you are responsible for everything you create. You are also responsible for challenging designs/solutions handed to you.

There is a reason why the "true" engineering disciplines object to the term software engineer. It is because in general software developers do not respect the engineering ethics.

Within the software industry we have two major learned societies: IEEE and ACM. Both worked (and continue work on) a code of ethics for software engineering.

I cannot say I really have any personal ethics as I subscribe to the IEEE/ACM code of ethics, which covers pretty much everything really important.

I do have a bunch of mantra's I keep to (as much as possible):

  • Write code as if the person who needs to maintain it is a homicidal manic and knows where you live.
    • Or the less violent version: Write code you'd like to read in 6 months (you probably will).
  • Leave code behind nicer than you encountered it. (The boy scout rule).

I might be a tad extreme but I'm personally having issues about the fact that I work on an advertising based product where the actual customer is not the app user but the advertiser.


“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”

  • John Woods

Care for my users.

Sadly, it seems to be a less and less common move.

  • Code should be written so other people can take over it.
  • Stay consistent. Don't upper/lowercase random stuff.
  • Do you need to keep the data? If you have to really think about it, you don't.

Do you need to keep the data? If you have to really think about it, you don't.

You can never be sure what data will be valuable and how valuable it will be, both in case there's a bug and to the business.
That's why Event Sourcing is making an enormous comeback.


In short, build trust

  • write code that you personally can trust
  • document your work in such a way that over devs on your team can trust you
  • respond to your managers’ and users’ requests in a way that shows you care both about their needs and the engineering behind the product

If building trust is your foundation, best practices will come naturally (see Start with Why)


I quickly remember these 2 as ideals at work.

  1. Ensure quality in what we build - it will be tough to feel motivated to come to work if we don't feel pride in what we do.

  2. Never to look down or look up at anybody based on what they know or don't know - Having more knowledge does not make someone right all the time nor should we dismiss someone's opinion without analysing it because they are junior or not as proficient as yourselves.


Solve problems for people. Do not fetishize the tools or the problems.

code of conduct - report abuse