This Is Why Managers Don't Trust Programmers...

Have you ever seen another programmer who wasn't as skilled as you get promoted? Did you tell yourself management was making a mistake?

Earlier in my career I didn't realize I was doing some things that caused managers to lose confidence in me. I would spend all my time writing code and never think about how I came across to other people.

In this episode, I share some harsh truths I've learned about how being a software engineer can cause us to do things we think the company wants - that actually hurt our reputation in the long run.

Companies are actually paying you for confidence as a programmer. And this episode is full of practical strategies for making sure you don't fall into traps that stop you from getting recognized for the great code you write as a programmer - before your career is really getting started!

Support me on Patreon:

TechRolepedia, a wiki about the top 25 roles in tech:

The Healthy Software Development career guide:

Learn about one-on-one career coaching with me:

CHAPTER MARKERS

0:00 Introduction
1:19 1. What Companies Really Want From Programmers
2:12 2. How To Build Employer Confidence as a Programmer
2:22 2.1 Minimize Communicating Problems and Doubt
5:42 2.2 Repeat Management's Desires
7:46 2.3 Anonymize Blame on Dependencies
10:57 2.4 Reduce Your Throughput
14:52 2.5 Elevate Your Coworkers
17:05 2.6 Over-communicate Status
20:11 2.7 Highlight Discovered Shortcuts
22:20 2.8 Document Verbal Decisions
26:58 Episode Groove

#programmers #managers #trust

[HealthyDev]

Did you make the mistake of thinking just writing good code is what management really wants? How are you building confidence in you at work?

[tarlkudrick]

Just remember that most adults are not really adults. They are young children in larger bodies. When you are lucky enough to work with a true adult, treasure it.

[dremaul]

Everything described in this video is more commonly referred to as “Playing the game”. I have often been told “If you want to last at this company, you gotta play the game.”

[Create-The-Imaginable]

I predicted all of the numerous problems we encountered but my Manager did not want to listen or believe me! Managers have a lot of trouble with that!

[michaelmammoth]

The "don't highlight problems" is so true and only becomes more true as you move up the management chain. In most businesses, it's better to let a dumpster fire continue to burn rather than be the one that points out the fire. It's not healthy or good for the business but in terms of career advancement, you'll never be rewarded for pointing out problems unless you've already solved them. If you need help or it requires cross-team effort to fix...just don't say anything. The safer path is to let things fail and have enough documentation to prove it wasn't your fault.

[GenericInternetter]

I hate all the points raised in this video, but most of all I hate the fact that he's completely correct.

Its a sad world we live in where productivity and efficiency are held back by mismanagement.

[Alex-hrdf]

I can't stress enough how accurate and valuable some of these advices are! As a software developer, I often voiced concerns only to be dismissed as negative or naggy. Over time, I learned to play along and celebrate our disastrous projects as if they were brilliant. Ironically, this facade earned me promotions and respect. It's a sad and ridiculous truth.

[ironuckles]

This can be subtitled, "How to survive in a dysfunctional organization." I also see a lot of overlap here with Robert Greene's book "the 50 laws of power." Finding that book opened my eyes to why I was being constantly passed over in promotions at work despite getting positive reviews and completing a reasonable workload.

[briford]

"Elevate Your Coworkers", number one best piece of advice. This is the best "long term gain" technique in my experience, in the short term, it may or may not pay off, but in the long term it always pays off.

[CondorJohnson]

I have made this mistake. I predicted a 18 month overrun on the project. I was given a warning letter for "negativity." I told them they were punishing good engineering knowledge.

BTW the project overrun 2 years so I was overly optimistic in fact

[oMo]

typical sprint cycle at my old job:
> get assigned task for an idea that clearly won't work
> tell boss your boss that an idea won't work
> write an essay why it won't work
> still get assigned the task


It took just 5 years of this for the hair loss to set in

[YellowToucan]

"Reduce throughput". That's a tough one to hear but it is very true. I use to "over-produce" and it just bites you in the arse. Management begins to believe every code-change, feature, bug-fix, should be completed in a few days. When I recognized
this, management was asking me to complete mid-size projects in one - two weeks - managers who have ZERO s/w development experience. This is where I began to negotiate lengthier commits to "train management" that writing quality code takes time.

[thomasf.]

What he is describing is basically bad management. Sadly there is too much of it in the software industry. The real problem is that there are not enough managers with over a decade of engineering experience under their belt. This is a symptom of a young industry. Imagine an oil and gas firm, say Chevron, where all the people managing engineers and engineering projects have zero engineering experience. The result would be a disaster, from a safety hazard standpoint and commercially. Maybe it was like that back in the "wild cat" early days of oil and gas, but not now. Look what happens when an established engineering company is managed by non-engineers. I give you Boeing. What happened to the share price this year? ... I am sure you get the point.

[GoldPhoenix]

I've been a software engineer for 6 years at a Fortune 100 company, a small start up, and then at a FANG company. This video is unreasonably true. The definition of a "good developer" to leadership is one that makes management feel good in that moment. You have to internalize that, you have to go on a journey of discovery to understand what makes the management feel good in this moment, and you to comport yourself to that standard. If you don't you will be punished for it 99% of the time. How much you enjoy working at a company is intrinsically tied up in this. How much your mental health is affected is tied up directly in this. How much your career progresses in the company is directly tied up with this. No amount of personal effort, no amount of beautiful code, knowledge of the best new framework, nor indeed how many LeetCode problems you've solved will ever change this fact.

[Erik_The_Viking]

I've worked on so many projects where something unexpected comes up for any number of reasons. All too often managers yelled at me, called me incompetent, and much more as a result. This was even showing them what the issue was, potential solutions, and decisions that need to be made. As for "Jamie isn't responsible for Operations" - the lazy manager would typically come back and say "well, that's still your problem and you need to work with them to figure it out!"

[DuRoehre]

Actually, I have been warned about a toxic culture in US companies. Allegedly, there is a usual "game" in big tech where the middle management tries to attack the messenger (the one who reports issues in their deliveries) and downplay the issue, while at the same time their engineers are already secretly working on a fix; when the downplaying works then the fix is released secretly, and if not (and the issue is escalated to higher management) then there is a good chance that they can present themselves as those who found a solution "just overnight".

[xzybit]

Oh man, it's like you have done this video for me. I'm really getting frustrated with my management not seeing value in what I do, the several languages and technologies I have to juggle with, the problems I communicate.

[danielgilleland]

You are doing a tremendous service to people in our industry! Thank you!!

[perfectionbox]

An old saying is "if you surface a problem, also propose one or more solutions."

[SM-sbtr]

These are good tips but always apply them In balance. I've seen people super successful at playing this game for a year or so until they got let go with adjacent reasons: "Not delivering enough", "Not highlighting problems early enough", "Not ambitious enough - cause they are not committing to enough things" and even: "Lack of leadership material" because of the fact that they were not specifying which dependencies were acting as blockers.