10 Common Mistakes for Young Developers
Matcha Design - Wednesday, December 31, 2014
As a companion piece to our previous blog post “10 Common Mistakes for Young Designers,” we decided to take a look at the more technical aspect of web development. Through our observations on different websites and our conversation with different developers over the years, we've identified ten of the most common development mistakes you can avoid. Without further adieu, here's our top the list, in no particular order.
1. Messy code with no comments
Many developers, especially one-person shows, feel like they can toss out code and just remember everything they did, making it a snap to maintain even years down the road. Here’s a hint from someone who’s been just this type of one-man show: this is extremely untrue.
Just because code runs doesn’t mean it’s maintainable. All developers should be in the habit of properly indenting their code, so if they need to come back to it they can at least get an overview of the program structure at a glance. Using constructs like trinary operators can help speed up development but also create code that can be difficult for humans to parse. This can be painful for any developer who might come along after you.
As a further courtesy to the next generation, we always recommend that developers comment their code, at least for the higher functions. Other developers, and probably even your future self, will thank you for your diligence.
We all like to seem exceptional, but we have to be careful not to bite off more than we can chew. “I can get that done in an hour!” sounds great to the boss … for the first hour. It’s important to always assess a situation thoroughly and build in enough time to fail. If you say two hours and get done in one, great! But if you say one hour and are still working on it in two … not great.
Sometimes called the Droopy Dog syndrome, this happens when developers can only see everything that can go wrong with a project. Consequently they build in too much time to take care of problems that don’t exist. After a few over-timed projects, the boss will stop listening to the developer’s assessment. As all experienced developers know, allowing management to single-handedly set programming deadlines is a sure-fire recipe for disaster.
The balancing act between over- and undercommitting is something developers pick up over time, and even highly experienced programmers can still get it wrong. As you gain experience, you'll eventually be able to make confident assessments that management will be willing to accept. Keep at it!
4. Ignoring security
It’s very easy to create a simple web form, and only slightly more difficult to make that form send an email or save its contents to an online database. It’s also very easy for a malicious user to break a simple web form, make it send spam to thousands of innocent victims, and delete (or download) the contents of an online database.
Without an eye for security, even the most innocuous form on the most obscure web page can become the vector for unfortunate behavior. Developers who ignore this possibility can put themselves and their clients at financial risk.
The PCI Security Standards Council maintains a common series of security standards for companies to follow, including web security. All developers who create or maintain anything web-related should familiarize themselves with these standards and try to keep current with them.
5. Ignoring version compatibility
Eventually, everything goes out of scope: operating systems, programming and markup languages, server software, browsers, everything. Good developers try to keep abreast of any upcoming changes and plan for the long game. But there’s another balancing act at work here, since the utmost bleeding edge technology is almost always the most buggy, and stacking new technology on top of new technology is just asking for trouble.
For the greatest safety, developers need to consider the best, most current versions of all their software, trafficking mostly with known good configurations. This doesn’t mean they shouldn’t experiment with exciting new technology, but it’s also easy to get swept up in the enthusiasm of the Next Big Thing and have trouble later. For production environments, it’s almost always best to play it safe.
6. No testing
This is a common problem in high-pressure, time-sensitive environments. However, developers who have even a little bit of time to spare are committing a grave error by not at least trying to test their software before release. Even finding and squashing one bug is that much less of a potential black mark on your record.
7. Using jargon in non-technical situations
We developers deal with a lot of complicated concepts that we have to get across in a small amount of time. In our insular areas, among our own kind, we use technical jargon to the point where people who haven’t immersed themselves in our lingo may wonder what language we’re speaking.
Jargon is fine, even necessary, in work situations. The danger, though, is thinking that just because everyone you work with understands your speech, that everyone in the world should understand you. This is annoying in itself, but the worse example is the developer who thinks that people who don’t understand their patter are somehow poorly educated, or who use their knowledge of techspeak to infer that they belong to a secret society. Some programmers eventually grow out of it, but others are a lost cause. Don’t be one of those people and you’ll go a lot farther in life.
8. Not knowing when to stop programming
In many ways, programmers are artists, creating new things with nothing but their minds. And like many artists, programmers can get caught up in the “one more tweak” mentality. It’s almost always possible to eke a little more speed or efficiency out of a program, but in the end, you just have to let it go (to release state, and then eventually to maintenance mode). We may pour our souls into a program but the result isn’t really our baby, no matter how we may talk about it. Get it done, get it tested, get it out the door, move on to something else.
9. Not retaining passwords
This will probably be the most controversial item on this list: Always retain your customers’ server environment and CMS passwords. If you maintain their email environment, it’s not a bad idea to retain those passwords too. Make sure the passwords are secure, of course, but never delete them unless a customer specifically asks you to. The time savings are immeasurable, especially if something catastrophic happens to their website long after you’ve deployed it. (Provided they haven’t lost the password in the meantime!)
10. Misconfigured server environments
This one is easy to do wrong and often a headache to fix. Setting up servers requires several things to come together at once. The domain name needs to be registered and pointing to the correct nameservers; the nameservers need to be pointing to the correct IP address; the IP address has to be set to the correct server; the server needs to be watching that IP address and prepared to load files from the correct local directory; the website needs to be uploaded to that specific directory; the database needs to be correctly built, populated and running; the programs all need to be pulling from the correct database with the correct permissions; the server needs to have an up-to-date certificate from a third-party authority if the website is secure; and so on and so on. If any one of these items is done wrong, is off by even one character, nothing works. Always double-check every entry before, during, and after launch, and you won’t wind up with egg on your face.
About Matcha Design
Matcha Design is a full-service creative agency specializing in web design, print, identity, branding, interface design, video production, still photography and motion design. Using our passion for excellence, multi-cultural background, and award winning practices, we consistently provide high-quality, custom, innovative solutions to meet the diverse marketing needs of our clients. For more information, visit www.MatchaDesign.com.