Why visual tools sucks on large engineering teams

As a Lead UI for our team, I find this frustrating and annoying when we have to put down fires on our codebase with my juniors and mid-level engineers.

While visual tools can enhance A LOT the work we do in refactoring or adding new features, those tends to be a hindrance in the long run. It makes people LAZY AS F💢💢💢 to not understand what lies behind of the right click that triggers a git action.

I don't want to sound disrespectful or blunt, but speed matters when you need to deliver your piece of work. Unless it is scripted, what makes you think that by doing a right click to commit a file is faster than the cli tool all the team of seniors uses?

Here some thoughts on why this happens.

1. People is lazy to learn.

I can put you the most beautiful and engaging Power Point presentation, but because you are used to do things outside of the paradigms of the team, honestly you won't think about it or at least put the effort to practice the cli basics.

I see my juniors and mid-developers to ACTIVELY using visual tools (For F💢💢💢 sake, Tortoise is a damn dinosaur... at least make me less mad by using Sourcetree). So, when I catch them, I actively ask to them over what is happening behind scenes. The answer I get most from juniors or mid-developers is that it is "faster", and that they feel comfortable with that.

To place growth in your team, developers have to engage in responsibilities that improve the speed of development without leaving behind what lies on a right click of their favorite visual tool. One rule that I found useful is the onboarding documentation of the stack used by the team.

I quote from my ADR:

"It is expected that you need to be familiar with git cli commands and that you can properly commit, rebase or merge code as needed in your feature branches."

With this in mind, I leave the message clear that using cli commands is the preferred way to work. If the team of developers comes to an agreement; some tools might come to be used as far it is proven that:

• Developers understand what the purpose of the tool is.
• Developers understand what is happening behind of scenes.
• Developers provide metrics of its usage to understand how effective the tool is.

That can be added to an ADR (Architecture Decision Record) to indicate what is the final decision of the team. (And I love these ones to put dots on the I's of people who don't want to move on)

You want to be Senior? You need to put hands-on experience in your cli tool and show up and shine on my eyes.

In a large team, Leads looks for the wolves who can lead the pack (or to help babysit juniors and new ranks with tricky problems). That said there should be an inherent desire to learn to go up in the organization.

2. People fears changes.

This is more a natural, instinctive behavior human beings has. Putting you out of your comfort zone and adapting to a new situation is part of growing in personal and professional life, and it is interesting to see people defending old protocols that might not be the best for the team as a whole.

I noted that people who uses visual tools, at lease understand the concepts behind its usage in certain flows, but in most cases:

• I don't have the time to check the cli logs in a successful command scenario, because I trust it works fine
• I don't need to go over the cli tool because the UI tool supplies all my needs, but happens I see the console to see what happens.

Knowing your codebase approaches you as a developer to know your tooling, through simplistic problems:

• I got a .har file (10MB) from my websocket record (Chrome devtools -> Networking -> right click on your websocket -> save as .har) and is humanly impossible to read (Need to extract the sequence of messages), so I am downloading a JSON formatter for VSCode.

This, lady and gentleman, is FEAR TO CHANGE not to explore other alternatives aside of what we inherently know about solving a problem.

You could obtain the same result, faster, without adding a VSCode extension by simply using prettier cli:

npx prettier ./localhost.json --write

and that pretty much fixes the file of 10MB to make it humanly readable. No need to download extensions or clog the memory of my PC by abruptly making VSCode to do something probably is not intended to do.

By extending knowledge of your codebase, you will be prone to learn what you can do. YOU CAN LEARN new things by exploring your cli tooling.

Again, shine by showing you learn new things aside of your right click on downloading a useless extension.

3. People is not motivated to learn.

When people are in a comfortable position, there is no realistic stress to make them move on. You know what you have to do, and you pretty much can do what is requested in the team. Seniors tends to be avid readers, consume volumetric amounts of information to keep themselves on top of the pack, and SHARING is an excellent way to learn.

Juniors and mid-developers pretty much falls into three groups:

• those who just want to get the job done
• those who have the job done and document its progress (+1 for learning: Documenting is a good way to acquire learning)
• those who find enough motivation to not only finish the job, but also to think about how a novel solution could contribute to the team.

The last group will find the time, no matter if it is past 2:00 AM watching The Primeagen reading tech articles about programming and cracking our butts in the process or watching Jack Herrington's videos about learning some novel frontend architecture or reading/watching Matt Pocock about some TypeScript sorcery we never knew existed. The amount of information available is absurd to calculate, and these people find motivation to learn in their area of comfort and bring the best of their findings to the team.

If they come with novel Cli knowledge that can speed up their process: wonderful. ANYTHING that can boost productivity is very welcome.

If you want to shine, motivation needs to be found by each individual on the team to advance.

4. People tied to foreign workflows.

This one pesters any team regardless of its size and complexity. Stubborn engineers will have workflows that are not aligned with the team. For what reason we need Tortoise in a Git repo? (I hate tortoise, it is not realistically practical unless you are tied to an SVN repo) or I can't find a reasonable reason why some developers gets some dark-hole software to do tooling you can easily do with the right knowledge?

We go again with the onboarding documentation, and aligning your team to use the appropriate tools and approved workflows is a way to take down some of the old bad habits of foreign workflows. In big enterprise level teams, measures are in place to make teams to use the authorized tools for your daily job.

Conclusion

I was pestering on developers using too much visual tools, but at the end of the day, not knowing what happens behind of your beautiful right click is a sword of double edge: depend too much on it and you might not understand why at certain times it doesn't work as expected.

That right click commit on your UI tool has more than the eye shows, and you should be curious on what is happening behind scenes. That right click refactor does something you might now, and it would be good idea to know how it works.

Be curious, don't be a damn conformist afraid of not knowing what is happening. Glory waits for you if you have enough motivation to learn what happens behind scenes.