How software developers can improve individual and team productivity

On October 14, 2022October 14, 2022

How a programmer can increase his productivity and thus become a superior programmer. A whole book can be written (and has been written) on this subject. This article describes some of the techniques you can use to improve individual and team productivity. At the end of the article, I recommend a soft work good book to you, can’t miss it!

As a software developer, you will spend most of your time using software development tools, and the quality of the tools has a huge impact on productivity. Unfortunately, the main criterion for choosing a development tool seems to be familiarity with the tool, not how applicable the tool is to the current project.

Keep in mind that when you select tools at the beginning of your project, you may need to have to use them throughout the duration of your project (or even longer).

For example, once you start using a defect tracking system, you may have a hard time switching to a different system because the database file format is incompatible, as can source control systems. Fortunately, software development tools, especially IDEs, are now relatively mature, and many are interoperable with each other, so you’re less likely to make the wrong choice.

Still, thinking carefully about how to choose a tool at the beginning of the project can save you a lot of follow-up hassles.

The most important tool for a software development project is to choose which programming language to use and which compiler/interpreter/converter to use. Choosing the best language is a difficult problem to solve. It’s easy to prove that some programming languages are correct because you’re familiar with them and you don’t need to learn them anymore; However, in the future, new engineers will have to maintain code while learning programming languages, and their productivity may be much lower.

In addition, choosing certain languages can simplify the development process and maximize productivity to make up for the lost time spent learning languages. As mentioned earlier, choosing a bad language can waste a lot of development time until you find that it doesn’t fit into the project and have to start over.

Compiler performance (how many lines of code per second can be processed for a normal source file) can have a huge impact on your productivity. If the compiler only needs 2 seconds instead of 2 minutes to compile a source file on average, then using a faster compiler may improve efficiency (although a faster compiler may lack some features that make it less efficient in other ways). The less time a tool has to work with the code, the more time is left to design, test, debug, and optimize the code.

It’s also important to use a range of tools that work well together.

Today, we take the use of an integrated development environment (IDE) for granted, which integrates editors, compilers, debuggers, source code browsers, and other tools into a single program. This allows us to quickly make changes in the editor, recompile source code modules, and run the results in the debugger within the same window of the screen, greatly increasing productivity.

However, you often have to work on certain tasks of the project outside of the IDE. For example, some IDEs do not support source control or defect tracking (although many IDEs do). Most IDEs do not provide word processing programs for writing documents, nor do they provide simple database or spreadsheet functionality to maintain demand lists, design documents, or user documents.

Most likely, you’ll have to use some programs outside of the IDE, such as word processing, spreadsheets, drawing/graphics tools, web design tools, and database programs, to do all the work required for the project.

Running programs outside of the IDE is not a problem, just make sure that the application you choose is compatible with your development process and the files generated by the IDE (and vice versa). If you move files between the IDE and an external application and you have to run a conversion program continuously, then your productivity will be reduced.

Can I recommend some tools for you? No. Because the needs of the project are diverse, I can’t give that kind of advice here. My suggestion is to take note of these issues at the beginning of the project.

But one piece of advice I can give is to avoid the idea of “why don’t we try this new technology” when choosing a development tool. After 6 months of using a development tool (and writing the source code based on it), if you find that it doesn’t get the job done, the consequences can be catastrophic.

In addition to considering product development, you should also carefully evaluate these tools, and only after you are convinced that the new tools are really useful, you can choose to use them. Apple’s Swift programming language is a case in point. Before the release of Swift v5.0 (about 4 years after Swift’s first release), using the Swift language had been frustrating. Every year, Apple releases a new version that is incompatible with the previous version of the code, forcing you to modify the old program.

In addition, many features were missing from earlier versions of the language, and some were not perfect. It wasn’t until version 5.0, released at the time of writing, that the Swift language became relatively stable. However, the poor people who pandered to this trend early paid the price for the immature development of the language.

Unfortunately, in many projects, you can’t choose your own development tools. This decision comes from an order from a superior, or you inherit the previous tool of the product. Complaining about it will not only waste time and effort, but also reduce your productivity. Instead, you should make the most of the toolset you have and become an expert at using it.

For any project, we can divide work into two types: work that is directly related to the project (for example, writing code or documentation for the project) and work that is indirectly related to the project. Indirect activities include meetings, reading and responding to emails, filling out timecards, and updating schedules. These are day-to-day overhead activities that increase the time and cost of a project, but do not directly contribute to the completion of the work.

By following the approach described by Watts S. Humphrey in Personal Software Engineering, you can keep track of where time is spent during a project, and it’s easy to see how much time is spent directly on the project, as well as time spent on indirect overhead activities.

If your overhead activity lasts longer than 10% of the total time, then you should reconsider your daily activities. You should try to reduce or integrate these activities to reduce their impact on your productivity. If you don’t keep track of the time spent outside of your project, you’re missing out on opportunities to increase productivity by reducing administrative overhead.

If it’s not an imminent deadline, people tend to slow down their work and when deadlines approach, they go into “super mode” again, which is human nature. Without goals, it’s hard for people to get their work done efficiently. Without deadlines, it’s hard to get motivated to achieve these goals in a timely manner.

Therefore, in order to increase your productivity, be sure to have clear goals and sub-goals and attach them to milestones.

From a project management point of view, a milestone is a marker point in a project that represents the extent to which the work is progressing. A good manager always sets goals and milestones in the progress of the project. However, few time-schedule plans will provide useful goals for a single programmer. This is where personal software engineering needs to make a difference.

To become a super efficient programmer, you need to micromanage the goals and milestones in your project. Simple goals, such as “I’m going to do this before lunch” or “I’m going to find the root of this mistake before I get home today,” can keep you focused.

And other, larger goals, such as “I’ll finish testing this module next Tuesday” or “Today I’m going to run at least 20 test programs,” can help you assess productivity and determine if you’ve achieved your goals.

Whether you can improve your productivity depends on your attitude. While others can help you manage your time better or help you when you’re in trouble, the most important thing is that you have to take the initiative to improve yourself. You need to always pay attention to your own rhythm and constantly strive to improve your performance. By tracking your goals, efforts, and progress, you’ll know when you need to “cheer yourself up” and be more productive by working harder.

Lack of motivation can be one of the biggest barriers to productivity. If your attitude is “Ah, I’m going to do this today”, then you may spend more time on this task than your attitude is “Wow! That’s the best part! It will be fun! “More.

Of course, every task you do isn’t always fun. This is an area where personal software engineering needs to intervene. If you want to maintain above-average productivity, then you need to be self-motivated enough when a project makes you feel “unmotivated.”

Try to create some reasons to make the job more attractive. For example, create some small challenges for yourself and reward yourself when you’re done. An effective software engineer will often practice self-motivation: the longer you stay motivated by a project, the more productive you will be.

Focusing on one task and eliminating distractions is another way to significantly increase productivity. You should be able to “get into the state”. Software engineers who work this way are more efficient than those who are multitaskers. To be more productive, you should focus on one task for as long as possible.

In a quiet environment without any visual stimulation (except for the display), it is easiest to focus on one task. Sometimes, the work environment isn’t conducive to keeping you focused. In this case, putting on headphones and playing background music may help eliminate distractions. If the music is too distracting, you can try listening to white noise, there are some white noise applications on the network.

Whenever you are interrupted at work, you need time to recover.

In fact, it may take you half an hour to fully concentrate on your work. When you need to concentrate on a task, you can post a notice saying that only urgent things can interrupt you, or post “office hours” near your workstation, that is, the time you can be interrupted, for example, you can allow someone to interrupt you for 5 minutes.

Answering questions that colleagues can figure out on their own can save them 10 minutes, but this may waste you half an hour. You have to work as part of a team to be a good teammate, however, it’s also important to make sure that excessive team interaction doesn’t reduce your (and others’) productivity.

On a typical workday, there are many scheduled work interruptions, such as meal times, break times, meetings, administrative management (such as processing e-mails and time accounting), etc. If possible, you can try to schedule other activities around these events.

For example, turn off any email alerts because it’s rarely necessary to reply to an email within seconds, and if there’s an emergency, someone else will find you in person or call you.

If someone really wants you to respond quickly, you can set an alarm to remind yourself to check your email at a fixed time (as well as text messages and other distractions).

When you get a lot of non-urgent calls, you can consider muting your phone and checking your text messages every hour or so during breaks.

How you do it depends on your personal and professional life, but the less disruption you have, the more productive you will be.

Sometimes, no matter how motivated you are, you’ll get bored with your work and have trouble concentrating, and your productivity will drop dramatically.

If you can’t get into the state and can’t focus on the task, then take a break and do something else.

Don’t use boredom as an excuse to go back and forth between tasks without getting much work done.

But when you really run into obstacles and can’t move forward, try to switch to something more productive you can do.

You should try your best to work on all the tasks assigned to you. While this won’t improve your productivity, it can reduce their productivity if you keep asking other engineers for help (remember, they also need to stay focused and avoid distractions).

If you’re doing a task that requires more knowledge and you don’t want to interrupt other engineers as often, you have the following options:

Take the time to teach yourself so you can get the job done. While this may affect your short-term productivity, the knowledge you gain will help you accomplish similar tasks in the future.

Go meet your manager and explain the problem you’re having. Discuss whether it’s possible to reassign tasks to more experienced people and then assign you a task that you can handle better.

Schedule a meeting with your manager and ask for help at a time that doesn’t affect the productivity of other engineers (for example, in the morning of a weekday).

Sometimes, your self-reliance may be a bit excessive. You may be spending too much time on a problem and your teammates only need a few minutes to solve the problem.

One aspect of being a great programmer is recognizing that you’re stuck and need help to move on.

When you’re stuck, the best way to do this is to set a timed alarm clock – ask for help after you’re stuck on the issue for minutes, hours, or even days.

If you know who to turn to for help, then ask for help directly. If you’re not sure, talk to your manager.

Most likely, your manager will direct you to the right person so you don’t bother with people who can’t help you anyway.

Team meetings (daily or weekly) are a great place to ask team members for help.

If you have several tasks to do and you’re stuck on a specific task, you can put it aside, do other tasks (if possible), and leave your question to the team meeting to ask.

If you finish the work before the meeting, you can ask your manager to assign some other work so you don’t have to bother with others. In addition, you may find solutions as you work on other tasks.

Nothing kills a project faster than low morale among team members. Here are some suggestions to help you overcome your low morale:

Understand the business value of your project. By understanding or reminding yourself of the actual use of the project, you will be more enthusiastic and interested in the project.

Responsible for the project (your part). When you take responsibility for the project, your pride and honor are tied to it. No matter what happens, make sure you can always talk about your contribution to the project.

Avoid putting effort into project issues beyond your control. For example, if management makes some bad decisions that affect the progress or design of a project, then do your best within those limits. When you can work on a problem, don’t just sit around and complain about those management decisions.

If your personality is causing problems for your morale, discuss it with your manager and others affected. Communication is key. Allowing the problem to continue will only lead to a greater morale problem.

Always be vigilant about situations and attitudes that may lower morale. Once the morale of the project team begins to decline, it is often difficult to recover. The sooner you deal with morale issues, the easier it is to fix them.

Sometimes, financial, resource, or personal issues can demoralize project participants. As a great programmer, your job is to jump in, overcome challenges, continue to write great code, and encourage others in your project to do the same. It’s not always easy to do this, but no one has ever said that being a great programmer is easy.

This article is excerpted from the book The Way to Programming Excellence (Volume 3): Software Engineering!

Want to learn how to better develop your software and excel?

How software developers can improve individual and team productivity

Leave a Reply Cancel reply