Developers spend a lot of time writing code. Many developers also spend time doing a variety of other things such as designing systems, maintenance, testing, and debugging. Writing reports, tracking time, and attending meetings are also often on the list of things developers spend their time doing.
As a developer juggles their time and delivers the demands of projects and end-users, there are ten areas where many developers could spend more time. Hopefully, many of these are areas where you already dedicate time; unfortunately, that is likely not true of many other developers.
10: Developers Should Create Backups
Let’s start with the obvious. Many developers use version control to maintain a history of their applications. In addition, to maintain version control, it is also important to make sure you retain backups of your code. This includes backing up repositories as well as any current items being developed.
In addition to backing up the code, however, developers need to also back up other items. This involves backing up communication, documents, and supporting materials for projects. Having backups of communications can be helpful when the project is completed, and there are questions about missing requirements or other issues.
9: Developers Should Plan
Measure twice, cut once. While we live in an Agile, iterative world, it is still very important to plan before jumping into coding. Some developers like to open a code editor or IDE and jump into building a solution before fully thinking through the details of what needs to be done. Data has shown that earlier planning reduces the amount of rework and errors that come later in the software development lifecycle.
8: Developers Should Fail Fast – Test
Related to planning is testing. When it comes to testing, it is important to:
- Fail fast
- Break things
Failing and breaking things are not generally considered mantras to live by, nor are they tasks that most developers strive to spend more time doing. However, these are important concepts for developers to be aware of, understand, and not shy away from. Failures and the actions of fixing broken things are huge learning opportunities. Failing happens, so if there is a chance it can happen, make it happen fast. But, use the failure to learn so that you don’t fail in the same way in the future. Similarly, breaking code results in code that needs to be fixed. Breaking code is simply a small failure that can also be a learning moment.
Of course, failure and breaking things lead to the topic of testing, which is something some developers might tend to neglect. Testing, however, is important, and the earlier you do it – and the more thorough you do it – the faster you’ll find issues, and the quicker they can be resolved. Testing can help reduce the chance of things falling later in a project cycle when the cost is more expensive to fix.
There are many articles that discuss the cost of not testing early. These articles provide information on the amount of time and effort, which are then associated to a cost for fixing an issue. Catching and fixing an issue earlier in the development process can provide relative costs savings. The cost of not finding an issue until after you are into coding can be as much as five times more than the relative cost of finding it in planning. The cost of not finding an issue until you are in integration or component testing or even into system acceptance testing can be 10 to 15 times more costly than during planning. And, of course, an issue that makes it to production can be more than 30 times more costly. In short, a little bit of extra time planning and testing early in the project can save substantially more time should an error get through later in the project.
7: Developers Should Focus on Education
Most developers focus on getting the coding done and the solution delivered. It is, however, important for developers to take time to learn new things. Technology is constantly changing and evolving, so to remain relevant, a developer needs to evolve by learning new things or becoming aware of changes not only in technology but also in approaches to application development. A developer still doing COBOL programming using a waterfall methodology is in much less demand today than 30 years ago.
While a few high-paying maintenance jobs are available for COBOL developers, it’s not an area doing the most leading-edge new development. To have a better chance at the forefront of development projects, developers need to stay aware of changes in the industry. This can be done in a variety of ways that don’t require spending any money. What it does require, however, is time and effort on the part of a programmer.
Note: In my next article, I’ll cover ways to self-educate as a developer.
6: Developers Should Communicate with Other Programmers
Developers can be introverted, isolated creatures at times. It is essential that developers take time to interact with other developers. This goes back to the educating mentioned in point seven; by interacting with others, you not only gain resources that might be able to help you when you run into a difficult bug to resolve, but you also have the chance to learn what others are doing. Such learning has the potential to provide insights and ideas that might help you with your future projects.
This communication with developers, however, should not just be those in your same organization. Instead, developers should also interact, engage, and communicate with other developers outside of their organization.
5: Developers Should Create Documentation
Developers hear it all the time: comment your code! Many developers do comment their code, but some also do the bare minimum or do not follow commenting best practices. Additionally, many developers comment on what the code does but don’t always provide additional details, such as why the code is doing what it does.
Even if it is just simple notes and comments in the code, creating documentation should include details such as why something is being done (and not just the how) and include details including what other code might be impacted. This will help other developers in the future who may need to update or alter the codebase.
Repeating the obvious, while the code might be obvious to you, other, less experienced, developers might need a little more help. You never know when you will be moving to a different role or company, so leaving information for the next developer will help improve the odds that the code continues to function even when you do move on.
It’s also important to remember that when you do a quick hack or fix to also include a comment or note on what you changed and why. While a version control system might make it easy to roll back the change if there is an issue, comments simply help make it clearer what was done so that if there is a future error, it can be learned from and not repeated.
Finally, remember that commenting code is just one form of documentation. Providing documentation outside of the program code can be exceedingly helpful and a time saver as well.
Read: How to Comment in Python.
4: Developers Should Spend More Time Creating Better Names
While it is fair game to name your kids whatever you want, the same isn’t always true when it comes to naming variables, functions, methods, programs, and other coding-related items. While using variable names like x, y, or i might seem more concise and quicker to create, the readability and understandability aren’t always as clear to other programmers. Similarly, when using a variable, class, method, or function changes, it is crucial to make sure the name is changed to reflect the current usage. With the ability of modern tools to refactor such changes – and with the ability of most interpreters and compilers to optimize names internally – there is little reason not to have programs with clearly written, descriptive naming conventions.
Read: Python Best Practices.
3: Developers Should Explain What You Do to Non-Programmers
A key part of most development roles is building solutions for end-users, most of whom are not savvy to what it takes to create a program. While most end users won’t want to know the ins and outs of how pointers and memory management work, helping them understand many of the things that go into building a solution will help them better understand the time it takes and the risks that occur when schedules are cut short.
Additionally, by spending more time with non-programmers having discussions, developers will better understand what non-programmers consider necessary when building solutions. There are times when, after having a conversation with an end-user that you find that the best solution for what they want isn’t a glitzy application, but rather simply a pencil and a piece of paper next to their computer (true story – that was the solution provided for a request I had in my early programming days).
The one thing that is almost always true is that the more time you work to understand what is important to the end-users – and the more time you spend helping them understand your role and what you and other programmers do – the more likely you will build a better working relationship that will lead to better communication, which, in turn, will further lead to a higher chance of successful applications being delivered.
2: Developers Should Be Nice
Developers can be complex creatures. Many developers are used to the logical, direct approach to discussing topics, including coding. With actions like peer reviews, many developers spend time reviewing each other’s code and providing direct, candid feedback. This development environment can lead to a number of issues, including criticisms.
As a developer, it is important to be able to take criticism with ease. At the same time, it is crucial when providing feedback to avoid coming across as rude instead of constructive. Developers tend to develop a thick skin, but at the same time, they can also develop a level of cynicism or even frustration depending on an organization’s rules. This frustration can lead to a more callous approach to communicating and interacting with others. It is helpful for developers to keep this in mind so they can avoid becoming pessimistic. Simply put, it is important to remember to be nice. You can rarely be too nice.
1: Developers Should Ask for Help
Development is a broad field that touches on a vast amount of information. Many programming languages and tools change regularly. It can be tough to keep up. Additionally, developers are expected to learn the rules and procedures that are associated with the solutions they are developing. There is a lot to know, and there is often a lot more to know than what a single person can keep up with.
Simply put, sometimes you need to be able to say, “I don’t know.” Sometimes you need to ask for help. Often asking for help or clarity can save you a ton of time and help avoid errors and issues later in a project.
0: What Else Should Developers Do?
As you have gone through this list, you likely thought a few things did not fit or ring true for you. Several, if not most, of these you likely already do, which is great! You might also have thought of things that are not listed which developers need to do more often. If that is the case, post a comment on what you believe most developers should be doing more often!
