In honor of Freedom of Information Day, we wanted to look at some of the things developers can do to make the Internet a better place. Full stack developer Matt Warner, who's been in the field for over a decade now, took some time out of his schedule to shed a little light on the subject. While Matt wasn't the least bit shy about telling us that he doesn't think anyone can do anything to make the Internet a better place “or it wouldn't be the Internet,” he did offer some excellent advice on the topic, and we're sharing seven of our favorites.

1. Get rid of old business strategy ghosts

It isn't just IT that suffers from outdated business strategies, but the effects of such stale practices in this area can often feel far more damaging. If you've been stuck on an old way of doing things, or if you're consistently encountering issues that can be resolved by taking a different approach, it's probably time to exorcise those ghosts.

Here's Matt:

Development - and more broadly, IT - has a number of old business strategy ghosts haunting it. Ranging from reactive instead of proactive thinking causing impossible delivery schedules, to the everlasting issue of sales or management above the development teams promising features resulting in scope creep, undue stress, and burnout.

2. Protect, educate and test

Security is a big issue for everyone, and it feels like we're constantly hearing about attacks now. The best way for developers to make things more secure for both users and organizations is to move away from the old way of doing things (there are those pesky ghosts again) and instead adopt a “Protect, educate and test” model.

Here's Matt:

Security for a long time was a hushed issue that was rarely regarded as anything other than an acceptable risk for many organizations. Now it's become the behemoth of the 21st century that will only grow as we continue to push further into a connected world. The number of attacks have been fairly consistent over the last 10 years in the grand scheme of security, but, it took a multitude of incredibly high-profile attacks to garner responses in organizations or education for users. Developers and their respective management teams that haven't already need to start moving away from the Are we required by compliance to do this model and into a Protect, educate, and test model. Budgets and development time need to be allocated toward enforcing stricter security models even as simple as more complex passwords and two-factor authentication as well as penetration testing, vulnerability management programs, and monitoring for attacks when possible.

3. Equip your belt with many tools

Sure, we hear plenty of talk about all the tools developers should have in their belts, but are you actually making good use of those you currently have? For example, sanitizing input is a solid first step in protecting data, but efforts to prevent attacks shouldn't end there.

Here's Matt:

We've seen a number of penetrations tests where the input is being sanitized either incorrectly, on the front end via JavaScript making it useless, or only in text input fields while ignoring other form fields that still pass data. Overall, to depend purely on sanitization increases potential security risks and damages your security posture. The focus on prepared statements and similar methods as well as clean tested code interacting with your data means holding off an SQL injection attacks isn't based purely on your sanitization functioning with exact precision. Someone attempting to gain access to your data isn't going to give up after trying one method of injection and they have much more time to bang on your front door than you do to create the master of sanitization.

4. Avoid burnout

Easier said than done, we know, but starting off on the right foot can, at the very least, help you prevent a meltdown. While deadlines play a major role in technology, critical examination is essential to look at all angles of the project, and not solely from the technology perspective.

Here's Matt:

While we're all at the mercy of Moore's law to some extent in technology, development should - whenever possible - be structured so all movements within the development projects are critically examined and decided upon. Maintaining a strong Software Development Life Cycle (SDLC) is a great way to provide everyone involved with the framework they need to not only examine what is best for the project from a technology perspective, but to maintain a sane scope, avoid burnout and provide clear timelines. Forcing a timeline on a project or a reactive feature request has never resulted in a great project and will more often result in a tired developer and annoyed manager.

5. Keep it clean

There's no single “best” way for developers to maintain clean code, but it is important to find your groove and see what works for you.

Here's Matt:

Developers range so much when it comes to the cleanliness of their code it's hard to pinpoint what's the best way for each person. Some great ways to maintain a clean codebase is to ensure that all code is commented whenever possible, unit tests are utilized within the project, and time is allotted during the initial development for identifying bottlenecks and resolving the issue. In the grand scheme of a project there will always be going back and improving code, it's one of the best parts of development, realizing you can do something better.

6. Be flexible

Being flexible is quite possibly one of the best things you can practice in all areas of your life, as the ability and willingness to bend will prevent you from breaking. It's especially true for developers, and is a great thing to keep in mind when considering the user experience.

Here's Matt:

Unless the project will only be used by machines the user experience is one of the most important aspects of UI-based applications. Ranging from a solid user interface to the speed of queries and responsiveness of the website, users can be picky when it comes to their decision to continue to utilize the application. At this point developers and their designer counterparts are expected to provide a good-looking website that will function seamlessly and extra time and effort should be put into making sure that comes across clearly. Be careful with experimentation of new front-end techniques with less-technical users, and similarly, be mindful that just because your audience will be technical, that they may not want everything all the time. Being flexible and providing a user experience that can reach to a number of audiences, on a number of devices, can go a long way.

7. Don't be too hard on yourself

It may be tempting at times to label yourself or other developers “bad” or “good,” but this kind of black-and-white thinking won't do you any favors. Instead of jumping to an unfounded conclusion, consider that code, whether bad or good, can be the result of several different factors, not just its creator.

Here's Matt:

While there are plenty of situations that many of us in the development field have been placed into where we look at code, and wonder, what was happening to the person's brain when they came up with this, it doesn't necessarily make the creator a bad developer. Like many areas in the world it's a fairly large gray area and sometimes bad code can be a product of poor management or burned out developers. On the other hand, that developer in a nurturing environment with a realistic schedule may put out code that would be considered great development work. There is of course seemingly maliciously bad code out there which may be the work of just flat out not-good developers, but we need to take a look at the profession as a whole. Moving development in the direction of providing solid education, good mentorship, and healthy environments to move the people who are legitimately not able to provide good work into other areas.