24 Software Engineering Tips from Remote Managers

You deliver your best work when you focus on a single task at a time. Always know your next task too and blockers won’t slow you down.

Comments under issues IS NOT A CHAT ROOM. Use it wisely, a high-quality message should not be causing question marks and the format should be answering all question marks.

If quality and productivity are both low in a team, fix the quality first. Do not accelerate low quality work. Accelerating chaos just gives faster chaos!

Get your goals straight. Get your facts straight. Figure your priorities. Never start actual work before this is done.

Before reading a long, complicated text, do a quick look over first – it may turn out to be irrelevant. Do a ballpark estimation of the proof of concept before starting a long, complicated task.

There is a difference in issue logging and issue tracking. Track issues, don’t just log them.

Doing a code review ignoring the overall impact is ignoring the release timeline.

When doing code review, don’t just point out errors. Explain why it’s wrong and offer potential fixes. Otherwise, the contributor will repeat the mistake in a different way.

Focus most of the effort on pre-coding activities like requirement gathering and design. It will reduce your coding and code reviewing effort. Like Abraham Lincoln said: Give me six hours to chop down a tree and I will spend the first four sharpening the ax.

When prioritizing the tasks with the same due date/urgency, prioritize the ones that will unblock others to do their work over the ones that are isolated.

Don’t try to make the code submitted to the code review perfect, but try to improve it. If the code submitted for code review has 4/10 in code quality – the good goal would be to improve the quality by 3 points to make it 7/10. Don’t try to make it 10/10.

Simplify complexity, deep dive to identify root cause, then automate solutions for scale.

A good code review should have a foundation on three main topics. Correctness: Does the code change fix what is suppose to be fixed and is well-tested? Regression: Does this change break existing functionality? Quality: Follow standard guidelines concerning code quality.

Deep dives are done when there are no more questions to answer.

Any task that is done at least once a month and can be automated worth getting automated. It prevents future issues, it documents processes, it saves time.

There’s no workplace with zero humans (yet), that’s why there is more value in the left part of “Individuals and interactions over processes and tools” having the right part being also important. Be human.

While doing a peer review, recognize the use of good judgment. Do not only point out the flaws.

The shortest way to get many things done is to do only one thing at a time.

Low performers are epidemic, if not dealt with early enough they infect everyone else.

Groom your project backlog (not just tickets assigned to you) at least once per week, there are always some overlapping, outdated and duplicated tickets that disperse focus from the real issues.

Assess and mitigate risks vigorously every day. Wishful thinking sank more projects than all other mistakes combined.

Asking for help is not a weakness, it is fundamental to team success. The same goes for saying ‘No’ with proper reasoning, which should at least produce a constructive discussion.

Whatever task tracking tool your team uses, always maintain your own, private, one-page-sized summary of your current scope.

Have a list of anything you are waiting for from other people with your internal due dates.