Your Manager Can’t Code? They Shouldn’t Be Your Manager

IT Crowd Episode 1 - Jen People Person

The post Your Manager Can’t Code? They Shouldn’t Be Your Manager appeared first on Qvault.

Managers who can’t code are an outdated artifact of corporate America circa 2005. The best managers that I’ve had spend ~80% of their time coding, architecting, or doing technical research. If your manager thinks coding is “beneath” them then they need a dose of humble pie. Your organization would likely be better off without them.

But Managers Manage People!

There is a long-running stigma associated with developers, that we are all geeks who can’t handle interpersonal relationships. Due to our code monkey nature, we need “people people” who can go to meetings for us and communicate our efforts effectively to the higher-ups.

introverted programmers are an outdated meme

While the above is still funny, it’s outdated. As the developer community has grown exponentially in the last 20 years, so too has the personality diversity amongst its members. In other words, it is not hard to find developers with the soft-skills necessary for management positions.

Managers Should Help

I am a firm believer in the following:

While the manager doesn’t need to be the most talented developer on the team, they must at least be technically literate. When a team member goes to their boss with a technical proposal, the manager should be able to give valuable feedback.

In this study from Harvard 35,000 employees from the US and Great Britain were polled about their job satisfaction, and metrics were gathered about what influenced their happiness at work. The results showed that the single greatest influencing factor on employee satisfaction was whether or not their boss was technically competent. I practice what I preach, so at the Qvault app, all engineering leadership will forever be responsible for pushing code.

Contrast the idea of a competent boss with the all-too-familiar experience of going to a non-technical middle-management type with an engineering problem, only to be stuck in a teaching session because the boss has never heard of a pub-sub system.

Managers Need Empathy

A good manager has empathy for those who report to them. If the boss doesn’t code or hasn’t written code in a long time, they won’t understand the daily problems that their team is faced with. A good engineering leader will not only understand modern problems, but they make it their role to actively seek technical solutions in an ever-changing innovative landscape.

INB4: “So the CEO needs to be able to code?”

No, but the CTO does!

I am sympathetic to the idea that the CTO will have plenty of business and product-related work to focus on, but they can’t let their technical chops slip. In order to run the engineering arm of an innovative company, the person at the top should have a firm mental grasp on the implementation difficulties. If this just means reviewing architectural diagrams and reviewing pull-requests so be it, but nothing beats hands-on engineering work to stay sharp.

Feedback Please

Have you had problems with non-technical leaders, or do you disagree completely with my opinions? Let me know through one of my social profiles.

Thanks For Reading

Follow us on Twitter @q_vault if you have any questions or comments

Take game-like coding courses on Qvault Classroom

Subscribe to our Newsletter for more educational articles

Related Articles:

The post Your Manager Can’t Code? They Shouldn’t Be Your Manager appeared first on Qvault.



source https://qvault.io/2020/07/14/your-manager-cant-code-they-shouldnt-be-your-manager/

Comments

Post a Comment

Popular posts from this blog

Why is Exclusive Or (XOR) Important in Cryptography?

Image
If you are getting into cryptography, or just trying to understand the fundamentals, you may have noticed that the exclusive-or operation is used quite often, especially in ciphers. What is XOR ( ⊕ )? XOR, or “exclusive or” operates on binary data. It returns true if both of its inputs are opposites (one false and one true), otherwise, it returns false. An example in go code would be something like: func exclusiveOr(a bool, b bool) bool { return a != b } XOR Cipher – The Perfect Cipher The XOR operation can be used as a simple cipher for encrypting and decrypting messages with a single key. This is known as symmetric encryption. It is interesting to note that if: The key is the same size as the message The key is kept secret and generated truly randomly Then the cipher is impossible to crack. This is known as a one time pad . However, a simple XOR shouldn’t be used in production due to the key length needing to be too long to be practical. Cipher Example A
Read more

What are UUIDs, and should you use them?

Image
The post What are UUIDs, and should you use them? first appeared on Qvault . A universally unique identifier (UUID) is a 128-bit format for creating IDs in code that has become popular in recent years, especially in relation to database keys. By using UUIDs, you ensure that your ID is not just unique in the context of a single database table or web application, but is truly unique in the universe. No other ID in existence should be the same as yours. Sorry to interrupt! I just wanted to mention that you should check out my new free Go course. It’s designed to teach you all the fundamentals of my favorite coding language. Learn Golang Now It is important to note that while the probability that a UUID will collide with another is not zero , its practically zero. The chances of collision are so astronomically low, worrying about it would be ridiculous. The total number of possible UUIDs is 2^128 or 340282366920938463463374607431768211456 . UUID Generator Online
Read more

6 Things to Avoid When Contributing to Open-Source Projects

Image
The post 6 Things to Avoid When Contributing to Open-Source Projects first appeared on Qvault . With #HacktoberFest being a thing, there has been an influx of devs desperately trying to contribute to their favorite Open-Source projects. Unfortunately, many of these pull requests have been a waste of time, with the maintainers ultimately unable to use the contributions. Maintainers don’t want to waste their time reviewing bad PRs, and contributors don’t want to waste their time writing code that will never make it into production. Let’s take a look at some common pitfalls that developers fall prey to when working on an open-source project. As a side note, we recently open-sourced the Qvault front-end, so take a look at that if you want to help out. 1. Don’t Start Work Without Approval If you hop into a Github repo and find something you don’t like, don’t immediately open a pull request. Follow these steps instead: Is there already an issue logged? If not, make one. If there
Read more