Part I: Professionalism, feedback and collaboration in technical teams

In this two-part series, I look at the importance of feedback and professionalism as the basis for effective teamwork using practical technology examples and how to reduce the effort for others in this context. 

It's easy to have conflicting opinions when you look at the same thing from different perspectives. You see this in almost every project.

From a client's point of view, for example, feature A is a must-have because it may lead to brilliant KPIs in their performance view (which could potentially see a revenue increase). To the delivery team, however, it's nearly impossible to make it happen in the given timeframe. The delivery team is in favor of new and exciting technology, but clients have to consider training costs and even recruitment strategies to make it a success.  

It could become an even worse scenario when there is a lack of communication and trust – the delivery team becomes frustrated and the client loses their trust. So what would you do if you were in a similar situation? 

My story 

I've received a variety of positive feedback from a lot of awesome co-workers during my relatively short career. Some appreciated my sophisticated command line tricks, and others thought I was able to write high-quality code quickly. People liked the customisation of my vim plugins, and someone once told me that she turns out to be more effective at PowerPoint composition when sitting next to me. Out of all the feedback, my favorite one is that when I was working within the team, even if I did not write any code, people still felt confident and enjoyed working and sitting next to me. 

I like this feedback the most because being a professional colleague that others can rely on is something I have been pursuing. Jason Fried, one of the authors of Rework, has a concise and neat description of what it means to have a professional work ethic:
 
However, high-level principles like these could lack the 'how-to' when you try to apply them in your daily work. Just like knowing ‘high cohesion, low coupling’ alone will not help you to write better code in practice. In this article, I'd like to take some real-world examples, trying to give the term professional worker a better definition by using concrete examples.

Working as a professional worker generally means being a reliable person that others feel comfortable to work with. So let’s start with some ground rules.

Respect your work

A job is not only something that an employee relies on for a living, it's also the basis for the company and their customers to add value to society. If the product the company produces can solve someone's problem, improve efficiency and bring value to society, it is worthy of respect.

Once you're involved in a particular project, and it's not against your values to be working on it, you should contribute your real passion and expertise to it. In contrast, no one can force you to work on something you don't believe in or respect (like building a monitoring/tracing application to investigate what the employee is doing when they work for example).

For most of the newbies, the biggest misunderstanding of the term respect is that it only means following rules. For example, in a delivery project, the tech lead makes a decision that you believe to be risky, potentially causing the team to fail. As a team member, you should stand up and argue your point clearly and try to help the team approach things in a better way. If you pretend that it’s out of your reach to correct it or pretend it was the right way to go, that kind of respect is actually the most disrespectful thing you could do.

Your proposal may be rejected, but you can still learn from it. Maybe there are some significant drawbacks you didn't realise in your solution, maybe there are some other trade-offs you don't know about, but there is definitely something great you can learn from it.

Don’t make additional work for others

If you want to walk fast, walk alone. If you want to walk far, walk together. -- African proverb

You're likely to work in different roles, with people, from different backgrounds on a daily basis. In a team, you have to follow some conventions and work with others to make things happen – teamwork. The first rule of teamwork? Don't make your colleague’s job harder than it is; try to make it easier. You should reduce the work of others as much as you can. Trust me; you would love to work in a team where people have this mentality.
 

How to share the URL of CI

Let's see what professional means in an imagined scenario. You have been working in a team, and people share work-related information like build failure notification, and meeting room details via chat tools like Slack or Microsoft Teams. Questions like “What's the URL of our CI?” are frequently asked. Let's say, a new member joined your team two days prior, and asks if someone could 'send the URL of CI'.

Now, what would you do? I originally sent it to the team mail, could they search for it? That's a viable solution, however one that still needs:

• the keyword of the title or
• the keyword of the content

And that's just for the search. The team member needs to log in to Webmail first, and of course, login needs the username/password, probably two-factor verification on the phone as well. It could get even worse if the VPN is isolating the working network and other networks.

Instead, take a few seconds to do the search by yourself, and send them the URL. It would be appreciated if you can also tell them the username/password pair is the same as the domain account they use to log in on the laptop. Also, if you have these questions asked more than twice, you might also want to document it somewhere that can be easily accessed like README in the github/confluence page.

I think the difference between these two approaches is obvious.

What about accessing an external API?

Let's make it more complicated: someone wants to send a request to a particular API endpoint in postman. To access that endpoint, one has to provide a variety of HTTP headers. You could open up your postman and take a screenshot.

Unfortunately, one of the headers named x-api-token has a 256 has as its value. A screenshot is simply not working in this case, but you are not expecting someone to type them by hand, right? Another way is to send the headers separately in text format (you probably have to copy-paste a few times).

On step further, you can send him a cURL with all the headers in one shot:

$ curl -H "x-api-token: token" -H "Accept:application/json" https://host:port/top-security-resources/1

Looks better. But imagine someone tomorrow asks the same question, and you don't want to do all this again. So you take a look at the manual provided by the postman and find that it supports export/import of the requests. Furthermore, it supports you defining some variable to distinguish different environments as well. So you can do this on all your requests and save them to the codebase, and anyone else who wants to do this now only needs to import it into postman.

This last solution can make everyone happy, and it has more flexibility and extensibility. The only disadvantage is that it can take more time, and you have to learn additional tools. But I would rather do that because it can lead to more practice and more ability to solve problems, which can be used in other scenarios too.