Jeffrey E. Uvero

Posted on Apr 27, 2018

What is your personal Programming ethics?

#career #discuss #webdev #productivity

Top comments (15)

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 • Apr 27 '18

██ 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 • Apr 27 '18

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 • Apr 27 '18

Ah yes.

Michiel Hendriks • Apr 27 '18

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🛡 • Nov 19 '20

“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 • Apr 27 '18

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 • Apr 27 '18

“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 • Apr 29 '18

tabs, not spaces

Hudson Burgess • Apr 27 '18

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 • Apr 27 '18

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 • Sep 24 '18

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 • Apr 28 '18

I quickly remember these 2 as ideals at work.

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