What is your personal Programming ethics?

Comments

[Ben Halpern]

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.

[Michiel Hendriks]

██ Oliver █ L██████

@eey0re

If you're collecting personal data, "how should I protect this?" is actually your third question.

"Should I collect this?" is only the second question.

The first question is "what would the worst people do if they got hold of this?"

03:49 AM - 04 Mar 2018

30837058

[W. Brian Gourlie]

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.

[Ben Halpern]

Ah yes.

[Michiel Hendriks]

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).

[🦄N B🛡]

“You can resolve to live your life with integrity. Let your credo be this: Let the lie come into the world, let it even triumph. But not through me.”

― Alexander Solzhenitsyn

scribd.com/document/118907026/Alek...

[rhymes]

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.

[Darryl Norris]

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

• John Woods

[digitaldags]

tabs, not spaces

[Hudson Burgess]

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)

[Ross Henderson]

• 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.

[Mihail Malo]

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.

[Dheeraj.P.B]

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.

[Steve Brownlee]

Be a professional, not a coder.

[jh]

Quality is not negotiable.