Code Responsibly

Plan for the future

When programming we often hardcode things but it's better to make them dynamic. Instead of burying such items deep in a function in some random file it's better to have them stored as variables in a centralized location.

Code securely

Don't store credentials in plain text without salting and hashing them. Remember to check your Git repositories and backups to prevent accidentally stored credentials. Don't send out emails which expose credentials. Make sure your applications have reasonable amounts of password security. Always change default credentials immediately. Don't share the same login across multiple systems (ie the database should be different than the webserver). Only give read or write access to things which need it and which can use it safely. Don't code as root. Don't hand out credentials freely and do revoke them frequently. Learn how to CHMOD properly. Don't take shortcuts with any of the aforementioned security risks.

Encrypt everything

End-to-end encryption is fantastic but there is more you can do. Keep user data private and don't expose it. Just because you CAN access user data doesn't mean you SHOULD access user data. Anonymize everything. Obfuscate data. Don't store all data in one easy-to-access location.

Don't abuse system resources & monitor performance regularly

When introducing new code it is important to monitor how that impacts performance. Users don't like to wait for slow websites. Search engines also use website performance as a site quality indicator. Additionally it is important to  reduce server costs and preserve available computing resources for other tasks.

Write regression tests for core parts of the code and run them regularly

Running automated regression tests regularly uncovers bugs before they get released into the wild. It is vital to create regression tests for the core parts of a project. For example, if your users are unable to signup or buy a product then you would be losing money.

Log important things

Monitor computing resources and use logs to track down the cause of various bugs. If your webserver logs a purchase but your database doesn't then that indicates a problem. If you didn't implement logs for both locations then you might not find the problem.

Leave good commit messages, code comments, documentation, and bug reports

Clear documentation is important. It isn't just for your coworkers or end-users. It's important to document your own work. Someday you will forget how or why you did something and will be thankful for documentation.

Follow coding standards

It's important to use the same coding style as your coworkers. If dozens of people are doing different things then it becomes chaotic and hard to figure out what's going on. Disparate coding styles can also introduce unintentional bugs.

Don't break other people's things without fixing them

You will break something. Don't panic! Do the right thing and fix it. Don't be afraid to seek help. Do take responsibility. People will respect you and you will learn from the mistakes.

Do code reviews

There are many pros and cons to code reviews. Some people don't like the tedium or the resources it requires. The simple fact is that code reviews will improve your code and the code of other people. Sharing is caring.

Implement multiple redundancies

If your backup is in the same building as the original data during a fire then both are lost. Clouds aren't infallible and can lose data. Back up often to multiple sources and verify the backups. You can never have too many backups.

Assume failure

Your code should not assume that transactions will be successful. It should assume that they will all fail. You need plans for when something goes wrong. You need to test that both positive and negative cases work as desired.

Keep your code DRY (don't repeat yourself)

Code should be shared rather than repeated. If you need to update code it's better to change it in one place than in twenty places. If code isn't DRY then several different processes might try to modify the same spot at the same time. Unnecessary bloat introduces bugs. DRY code is good code.

Keep compile / build / deploy times as short as possible

Imagine that each time you commit code it adds a second to your build time. Let's say that you commit that once per work day. After a month you've added 25 seconds to your build time. Twelve months later you've added 5 minutes to your build time. If you build twelve times per day then you've added an hour where you don't do anything but build. Multiply that by the number of people working in your office. It's important to keep your code repository clean in order to keep your build times small. Time is money.

Don't pollute files, folders, namespaces, etc

You wouldn't want to live in a trash pile. Nobody would be able to find anything. Looking for something would take forever. There could be dozens of the same type of thing in a trash pile and nobody would ever know. Stay organized and clean.

Name things based on what they do or are

This applies to variables, functions, methods, IDs, classes, branches, and more. Name things appropriately. If you name a fish "truck" then conversations are going to be very confusing. If you name a building "brown-box" then that probably isn't descriptive enough. A building named "car-factory" would be easier to understand. A fish named "flounder" would be easier to identify.

Proactively prevent code rot

Don't use deprecated functionality and do keep your libraries up to date. It's easier to make small software updates frequently than it is to wait forever and update hundreds of versions at once. Schedule a repeating calendar event for upgrading your software libraries. Whenever you work on an old piece of code try to update it to use improved code methods.

Respect your end user and their devices

Do everything you feasibly can to optimize your code in order to increase your userbase. It's unlikely that someone will buy a new device just for your app, therefore your app needs to work on their existing device. Keep filesizes small and only output as much application as a device can handle. Phones can have slow processors and tiny amounts of slow memory. In various markets data networks are slow and/or expensive. Your applications should work well independent of the input type. Some desktops have touchscreens. Some laptops have no touchscreen and less resolution than phones. There are no clear device targets anymore. My #1 tip is to make sure that all of your actionable targets (buttons) are "finger-friendly" and easy to use with various sizes of touchscreens. Apple UI guidelines for touchable elements suggest ~ 44 dp with adequate margins in-between (3dp on all sides of each touchable item, therefore 6dp between elements). 

Try to code accessibly

Remember that there are physiological differences in your userbase. Some people have bad eyesight. You should make fonts easy to read for them and use enough color contrast. Some people are color blind. You can't rely on color alone in order to convey meaning. Some people are blind. Use text to describe image content or don't rely on images. Some people are hard of hearing. Close caption your videos. Some people some people have poor motor skills which make it difficult to click elements which are hard to click or are too close together. Put in extra effort to make your program accessible by as many people as feasible. There are accessibility testing tools which make these kinds of things easier to implement.

Do the right thing

Responsible coders care about what they do. People who care about their craft produce better products. Don't take the easy way out. Do the right thing. Code responsibly.