Part II: Professionalism, feedback and collaboration in technical teams

In part one of this two-part series, I look at the importance of professionalism, feedback, and collaboration in technical teams. In part two, I'm expanding on these thoughts by looking at ways to reduce the effort for others in this context. 

Try to reduce efforts for others instead

I once worked on a project to help clients build a platform for internal development management. The platform managed almost all aspects of the software lifecycle: from design to coding, continuous integration, deployment and maintenance.

One of the requirements was to build a tool to detect the code smell of the code developers committed to the platform. The input: source code, which could be written in any well-known programming language, like  C++ or Java. It then analyzed the code structure and detected potential issues. Finally, it evaluated the code to some grade. 

To be honest, the tool itself was not that complex. The test cases, on the other hand, were the main problem we faced... there are too many potential ways of writing code, aren't there? The number of unit tests from developers was limited, but a QA needed more than that. The problem is, the QA didn't know as much about the C++/Java as the developers did. Not to mention that multiple abstractions in C++ is a mess by itself.

I spent about two hours building a simple tool. By specifying some parameters, like how many levels of the hierarchy of classes enable multiple abstractions or not, the tool could generate some valid files to pass compiling. It could also generate header files separately, making sure the inter-file reference was correct. The QA loved this tool, and they were more confident about the code under testing.

Automation: testing tools

Another interesting example is a project related to developing a large form (questionnaire). There are a lot of questions in that form, so we put them into three tabs with several questions in each. The first tab is something about personal details like name and DoB, while the second tab has something linked to the first tab. Some questions only show up if you choose A from the first tab, while others only if you choose B.

The new requirement comes from something in the third tab. We have to fulfill all the fields to reach the third tab, and every time we make some changes in code, we have to walk through all the previous steps, one by one.

There were no such things as HMR (Hot Module Replacement) or state management at that time, so you had to refresh manually anyway.

Once the team realised the pain point, they decided to create a chrome extension that could fulfill the form by some predefined values (by simulating the mouse click) and can stop at any defined question. That reduced our debug time significantly and saved many testing efforts as well.

You can see similar situations in any real projects you work on. Some additional effort can make other roles in the team (or people from downstream teams), or even the maintenance work much easier and goes a long way to being professional.

Help others, help yourself

In an agile project, when a story is finished in development, we would usually gather Dev, QA, BA, or UX together to do the Desk Check. Most of the team would insist on this practice, however the result varies from team to team.

I can still remember the nerves about my first Desk Check. Since we didn't prepare enough, when people came and surrounded my peers and I, we hadn't opened the Jira yet. We found that we missed one of the Acceptance Criteria (AC) when walking through them one by one in the face of the whole team. The cross-browser check had yet to be done, and we started to debug in dev-tools when we saw something going wrong.

From that time on, I particularly put more effort into that to make the Desk Check as smooth as possible. Rehearsing the Desk Check is definitely a great way to help catch issues earlier. Actually, the more you prepare in advance, the smoother you will be during the Desk Check. Before you collect people together, you should check all the AC, run feature tests and unit tests. At the very beginning of the Desk Check, try to describe the context of the story, especially business scenarios and business values. If you find anything new, comment in Jira in case it's been forgotten.


Since a BA and QA are usually working in parallel with other things, you have to make sure everyone is on the same page from the very beginning.

If cross-browser is part of the story, it would be better to open all the mainstream browsers and switch to the page you are working on.

That preparation can reduce the switch cost between context, allow people to look into the story itself, and reduce the potential problems. In fact, most of the problems will be resolved during the preparation, and you can fix any minor issues during the next story.

Prepare test data in the right way

When dealing with test data, especially working with a BA, you must be very careful. Ten digital ID Card numbers or phone numbers with letters are definitely something you must avoid. There is even test data (and you should avoid using randomly generated text as screen copy) that doesn’t look thoughtful from a BA's perspective, and can make their job harder to understand.

In some situations, when you want to test that the ellipsis shows up when text length is exceeded, you have to design the test case carefully to make it look real. Imagine if you read the product name as Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod? How would you like it?

The good news is that there are many tools that can simplify the preparation of the test data, without diminishing your professionalism. For example, Faker (a port of famous Perl library Data::Faker) in Ruby can help you generate most of the examples in the real world.

require 'faker'

Faker::Name.name      #=> "Christophe Bartell"
Faker::Bank.iban #=> "GB76DZJM33188515981979"
Faker::Internet.email #=> "kirsten.greenholt@corkeryfisher.info”

By using tools like this, all you have to do is add some code snippet, and you can easily generate test cases that fit real business scenario examples, and again, look more professional.

Details in mockups

All of those details not only apply to developers, but are also valid for other roles in a team. Take UX for example. When you're designing something along with your client, there are many simple things you can do to avoid people thinking you are not professional enough.

For example, in any of UX Hi-Fi mockup, you should consider:

• avoiding typos
• correct usage of terminology 
• the meaning of numbers
• visual consistency (font-face, typography)

The audience can feel your attitude and care just by seeing that you have gotten those details correct. Since that's about visual, a tiny feat can lead to a big issue. In a mockup, you used grey, 24pt Consolas for every heading, but in one place you mistakenly used 18pt bold. These kinds of issues can be easily identified and can potentially lead to bad feelings.

Understanding the business terminology

Compared to the incorrect usage of business terminology, misunderstanding the numbers can lead to more severe problems. For example, in the advertising industry, one of the most important figures an advertiser cares about is frequency. Frequency is measured by dividing Page View (PV) divided by Unique View (UV). Since the page view is always greater than the unique view, the frequency would always be greater than (or equal to) 1. If you put something like 0.68 on the mockup, that means you don't understand the business at all.

Similarly, when you design a pie chart, make sure all parts add up to 100%. Also, avoid 25% looking like 1/3 visually.

Design the mockup to be developer-friendly

Additionally, in design, try to think about more than the happy path. You should put as much variation as possible into a mockup, which can reduce potential conflict and help developers. In the product list, the first item could be the happy path, and the second one shows when some fields are missing, the third one is about what happens when the title is too long (ellipsis or wrap the line).

Every detail counts, and impacts whether you are someone people would like to work with or not.

In summary

I've listed many examples from real projects. Some are about development practices, and some are about how to help others succeed in their field. All the skills are however, about one thing: being someone that others can rely on. That means that even inside an organisation, you have to play a professional service role. You should consider the perspectives of other people, and try to reduce the efforts of others when you have to collaborate on something. 

Additionally, dealing with details properly is a must because professionalism is often hidden in the details. From adasdfsdf in the test data, to typos in the mockup, these details show if you treat the work respectfully.