Ethics and Disclaimer

Promises

I always provide my best work, leveraging all my experience.

Where published, my work will include a clear statement of who funded the work.

Technical Issues

The code I write will probably have some kind of errors in it. That is an unfortunate fact of life for all software engineers; I always try my best to write error-free code. Sometimes it might be too expensive in terms of time to fix a particular error. It might require hours of additional feature work that aren’t worth the time, or the error might occur so rarely that would be appropriate to handle if you were e.g. building a rocket ship, but not common web software. I’ll try to use my best judgment about this tradeoff, but I could make a mistake.

When researching the right way to solve a problem, I need to make a tradeoff between spending more time to research a solution, and beginning to implement the best solution I have so far. I have been building software for a fair amount of time, and have an idea of how to solve a lot of common problems. I have also had to make this tradeoff a fair number of times in the past, and consider:

• The costs of getting the implementation wrong
• The current solution’s ability to solve the problem
• The likelihood of a better solution
• The potential benefits of a better solution.
• It’s possible the solutions I’ve used in the past aren’t optimal, or I might get the tradeoff wrong.

I can give you an estimate of how long it will take to implement a feature. This estimate may be too low. This is a wider problem in software engineering. I’ll try to estimate based on how long similar tasks took me last time, and break a large task into smaller tasks that are easier to estimate. When I have been consulting longer, I will publish a record of my estimates, and their accuracy (currently the sample size is too small).

Security

No code is completely immune from security vulnerabilities. I may write code that has security vulnerabilities. They may compromise data security or user privacy. It is possible that I would not be able to write software that can prevent a sophisticated government attacker from compromising a system.

I am more familiar with modern information security than the average software engineer. I have written white hat viruses, engineered against many kinds of attacks, and stay up to date on important findings in the security community.

Conflicts of Interest

Occasionally I may do a short experiment with a new or unfamiliar technology, even if I know I can implement something using an existing tool. I will benefit more from this than you will - it might not work, and I might have wasted a little time. In the long run, trying new things has made me a much more effective consultant than always staying in my lane. (Also, it’s possible the new technology will work really well!)

If I have a choice between two solutions to a problem that are equivalent in implementation time/error rate/etc, I will choose the one that is more likely to advance my career, or lead to a future talk/blog post. I’m happy to credit you as a sponsor if I develop a blog post or talk based on something I’ve learned while working with you.

Unethical Requests

I do not do work I believe is unethical. It can be difficult to enumerate all possibilities, but a few of the types of work I will not participate in:

• Anything illegal within its area of jurisdiction.
• Build something that implements a dark pattern in an egregious way.
• Steal work, or copy from other intellectual property holders without due credit.
• Cheat people out of money they are duly owed.
• Violate end users reasonable expectations of privacy.
• Put users in a place where their data is obviously insecure.
• Deliberate lying about real data or statistics. (Normal marketing is expected)