While I enjoy coding in python and PHP, I’m nowhere near considering myself a coder – not after meeting exceptional software engineering managers all around the world. So I found great professionals who can give software engineering tips.
At WorkRemote, we are evangelizing remote work at scale. Content around remote working is divided into two groups:
- First Group: Downplaying it and make it look like a fun thing to do next to a pool with your laptop when you are not taking a sip from your mojito.
- Second Group: Ignoring all the enterprise knowledge, culture, and assets of the big companies and sharing high-level advice like async, full autonomy, etc which are hard to adopt for starters.
In this post, I’m going to share software engineering tips I’ve collected from 20 tested software engineering managers – all around the world. Some call these people exceptional talent, we call them our partners at Crossover. Talent and domain expertise have no zip code, so you might want to take notes.
These people are from different countries and cultures, besides being super smart, they have one more thing in common; they are all using FogBugz for issue tracking.
Software Engineering Tips
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.
Do you have other learnings? Share with thousands of WorkRemote visitors and subscribers in the comments!
Other pieces from ‘How to’ remote work content series
- How to drive a healthy remote sales culture
- 2 Critical Steps for Fortune 500 Managers Going Remote
- WFH: Establish Your Rules of Disengagement
- Daily Habits of a Successful Remote Manager
- How to find a full-time remote job
- How to fire a remote employee
- How to perform shrink-to-grow in a remote team
- How to hire your first remote employee