Developer

10 bad habits to break if you want to become a great developer

New to the tech development field? Here are 10 bad habits to break before taking a job.

Pursuing a career as a developer is a wise choice: The US Bureau of Labor and Statistics predicts software developer jobs will grow 17% between 2014 and 2024—much faster than the average rate of other professions. Meanwhile, front end developers, full stack developers, mobile developers, and back end developers are all currently in the top 10 hardest to fill tech jobs, according to data from job search site Indeed.com.

However, a number of common mistakes arise for those who are new to the field that could make your entry to a successful career more difficult. Here are the 10 most crucial bad habits to break when you first become a developer.

1. Assuming you know the user, or the environment the product will be used in

This is "the worst thing a developer can do," according to Karen Panetta, IEEE fellow and associate dean of the school of engineering at Tufts University. "If there is a functional specification for the product not fully specified for every scenario, wrong assumptions can kill the product," Panetta said. "In some cases, the people funding the development of a product may not be tech savvy and that's why they pay the experts who can anticipate their needs. Gathering this information only happens through outstanding communication and presentation skills and the ability to convey your concepts to any level of audience."

Further, many customers do not know the details of how something should work. Thus, developers need to understand how to communicate and work with people without intimidating them with the details of technology, Panetta said. "The golden standard to strive for this should be, 'Could I do a TED talk on my design and have people walk out informed and excited?'" she added.

SEE: How to become a developer: 7 tips from the pros

2. Failing to test your code

It's incorrect for developers to assume that "if the software compiles, it works," Panetta said. "This is one of the biggest complaints I hear from employers about new-hired developers," she added. "Understanding robust testing and regression testing is essential. If you fix something, how do you know you didn't break something else?"

Developers who design for test produce more reliable, robust code, Panetta said. Testing for unanticipated scenarios, such as the user hitting an unanticipated key, or the device's power shutting down, is also important.

3. Not documenting your work

Not documenting changes or neglecting to leave comments in the code for yourself or your colleagues is a major mistake, according to Megan Leese, director of web strategy and development at The James Agency. "In school it is easy to keep track of the work you have done and recall the entire history of a project or job," Leese said. "Working professionally in a fast-paced development job it is easy to forget why you developed something the way you did and have to spend hours figuring out what you did in order to make an edit to a completed job."

Developers should build structured and documented applications that other people can follow and use later, said Tom Coughlin, IEEE senior member and founder of Coughlin Associates. "Break a problem down to pieces, then build and test these separately and then together."

Failure to be detail-oriented can be detrimental to the entire workplace, said Mark Tuchscherer, president of Geeks Chicago. "We run across so many developers, or people that want to become developers, that think all they need to do is write code," Tuchscherer said. "They don't want to deal with documenting the code they worked on and pushed to the server. This can turn any project into a nightmare. We had to let go of a lot of great developers that made everyone else's job three times as hard because they couldn't break these bad habits."

4. Expecting work on the job to be the same as at school

Coming into a new position expecting the work to be the same as you were taught in school or experienced it in your last position is problematic, said Gene Richardson, COO of Experts Exchange. "Each company is different, and each company will implement or code their own technology solutions," Richardson said. "Essentially, you need to drop all old habits and approach the job with an open mind while trying to both embrace and understand why they do what they do. Once you are there for at least 90 days, you can then start making suggestions on how things could be improved. Be sure you know what you are talking about and can back your stance up with facts."

5. Staying static

Being a strong developer means being proactive with your learning, said Eugene Brodsky, head of software development at SaferVPN. "Always focus on learning, following the latest news, and reading at least five articles a day about what is going on in the industry," he said. "Make sure you pick the areas that you like as well as something you're less familiar with in order to get a broad range of information."

Besides cultivating and maintaining a passion for your idea, it's important to take advantage of and understand all of the tools available to you, Brodsky added—don't just stick to one program, tool, or news outlet.

"Don't think you will ever master anything—development these days is just continuous education," said Christopher Mendy, CTO of Evus Technologies. "If you're in an office with other developers, listen first, then speak. It's the quickest way to learn."

SEE: How to become a Unity developer for VR and AR

6. Multitasking

Multitasking is a dangerous habit that can threaten your career as a developer, according to Dmytro Moroz, digital marketing strategist at Kanbanize. "In a job that requires full mental concentration and extreme focus, you can't afford any interruptions," he said. "The cost of context-switching for your mind and its effect on your productivity is much more serious than you would think." Becoming a great developer means learning to "singletask," and say no to external distractions or new work requests while completing a project, Moroz added.

7. Writing large functions

For new developers, it's common to begin writing line after line of code into a function that gets bigger and bigger, said Andrew Magee, development manager at Enigma Digital. While this may seem easier, it makes your code more difficult to read, it reduces the amount of code that is reused, and it makes it more difficult to test, he said. "A function should do one thing and one thing only," Magee said. "If it does more than one thing it lacks focus."

8. Changing more than one element at a time

Sometimes, developers will change too much when implementing a new feature or enhancement to a system, said John Chapin of Capital Technology Services. "Developers have to look at each change like walking up a single stair in a flight—anyone would obviously feel that walking up 10 stairs and then jumping from the top would be a high risk move," Chapin said. "The same thing applies to making multiple changes to a software system. Make as many safe small changes and integrate them back into the codebase as quickly as possible."

Making small changes and committing changes to individual files also makes it easier to trace which change to a system is responsible for any unwanted behavior, he added.

9. Working in a silo

Collaboration is important for new developers, Leese said, but many are afraid to ask for help when they don't know how to do something. "Often they feel they have failed or are incompetent if they cannot figure out how to solve their coding problems," she said. "Most senior developers would prefer a new developer ask too many questions instead of spinning their wheels and not asking for help. Similarly, working alone and not checking in with team members can lead to wasted effort when a potential problem could have been caught by others early on in a project."

10. Forgoing security measures

Developers need to be increasingly aware of security measures in their code. "One very bad habit is blindly incorporating third party libraries with known vulnerabilities into the code base, either through legacy carryover, which is very common, or through failing to assess security at the time of selection of new libraries," said Mike Ahmadi, global director of critical systems security at the Synopsys Software Integrity Group. "This, as well as developing code without a basic understanding of the tenants of building secure code leads to a proliferation of insecure software that spreads throughout the entire software supply chain, leaving each successive developer, and ultimately end user, with a huge mess to either clean up, if possible, or live with."

Also see

istock-508417304.jpg
Image: iStockphoto/DeanDrobot

About Alison DeNisco

Alison DeNisco is a Staff Writer for TechRepublic. She covers CXO and the convergence of tech and the workplace.

Editor's Picks

Free Newsletters, In your Inbox