Real 10x Programmers Are SLOW To Write Code

If you've ever been jealous of programmers who seem to write code faster than you - take heart. The myth of the "10x programmer" is misunderstood in many software teams and tech companies.

What's important to companies is NOT that you're actually 10x faster at writing code. It's that you help the company produce features 10 times faster. Wake up call - you're not the only member of the team!

Over my career, I've met software developers who come into companies and write code super fast - but end up slowing the project down. They bossed around the other junior developers and thought they were God's gift to programming. It was a real disaster.

Instead, use these 6 techniques I learned as a software consultant. They'll speed up the project, make you popular on your team, get results for your company - and actually make your tech job easier! Besides, what's more important: that you can write code fast, or that you can avoid writing more code in the first place?

CHAPTER MARKERS

0:00 Introduction
1:36 6 Techniques Used By True 10x Programmers
1:50 1. Technological Empathy
3:29 2. Negotiate Streamlined Features
5:06 3. Cross-Technical Insight
7:59 4. Reject Ambiguity
9:42 5. Minimize Architectural Complexity
11:53 6. Document Innovation

#programming #programmer #softwareengineer

[viophile]

I have seen a few real 10x developers, all in common with them is the humility towards fellow developers. They don't brag about their skills nor force anyone to use a certain pattern, instead they encourage and teach fellow developers.

[artemodintsov]

The most important lesson that I've learnt: If you are asked to build a house, try first understand what kind of house they really want :)

[modolief]

I used to work for a self-taught programmer who was very ambitious and hard working. He was a consultant and billed at a very high rate. He didn't even finish high school, just got into the professional world. Real hard-ass and super impatient. But one day, about ten years into knowing him, working with him off and on over time, he had learned something. He said to me, simply: "Sometimes you need to slow down in order to speed up."

[Domineas]

I've been writing software professionally for over 18 years. I agree with all of this with one big caveat. If you are introducing new patterns or a "clever" or "innovative" architecture, it's important to document this first, float it with your team for buy-in, adjust the design based on their feedback, make a "go/no-go" decision *together* on whether or not to adopt the new changes and ONLY THEN actually implement it. It's a major mistake to introduce things first, thinking you will be able to get buy-in and support it with your team without getting the agreement and alignment beforehand.

[Heater-v..]

A few decades ago I had a very bright ten X developer on my team. He did not make a show about it, he just got on with stuff at a rapid rate. Pretty complex stuff too. Likely some of the most complex features we had in the product (A PCB CAD system). Really impressive. Problem was that after one year he had some kind of nervous breakdown. Was off work for weeks, When he returned he was totally different. Like a 0.1 X developer. He never recovered and eventually the company had to let him go. It was a very sad episode. So take it easy guys. It's not worth getting over stressed about, especially not for long periods.

[markw.schumann]

11:00 Seen it many, many times. "Simplifying" abstractions that _do not simplify._ They just move the complexity somewhere else.

[garrettweaver]

This is one of your best videos yet.

There’s another advantage to suggesting streamlined features, even if your product manager says no to your proposal. If the feature doesn’t work out, or you hit issues with it, this gives you the opportunity to shift more responsibility back to your PM. You can say you suggested an alternative, it was not taken, and the outcome was that did not work out. It gives you the option to say if we had streamlined it, it would have been simpler, not hit as many issues, or we would have found issues sooner.

[dizzysnakepilot]

Wouldn't call myself a 10x programmer, but I've found I do my best work if I have everything clear in my head first, then the actual coding can happen very fast and results in no significant bugs. Also I tend to write a lot less code than most of my peers to accomplish the same thing. Coding 45+ years.

[smallbig]

"The implementation of abstraction is more complicated than if didn't abstract" - what a brilliant thought!

[turn]

Diving in straight away and writing code is a huge red flag if you ask me

[NilsEckelt]

One measure of professionalism is trying to make oneself obsolete. A good programmer writes code so well, that anyone could continue their work.

[geerliglecluse]

This is real-world sensible stuff. Very few videos of this quality level on YT these days tbh....

[bmiller]

I think the one aspect is when "the big picture" is not fully understood by the group.

[JaePlay]

this is def something i notice i need to work on. I plan and write code VERY quickly, but i end up needing to do multiple code reviews, testing and PRs that could have easily been avoided.

[garrysimmons]

As you noted, "10X" refers to productivity (getting the right stuff done quickly) not lines of code.

[benjaminthorp]

Great video. I’ve been so guilty of the over abstraction due to obsession with DRY. I was told “dude stop being a plumber” and that snapped me out of it. But still have the urge, because it’s fun as a thought exercise.

[thomasf.]

Sometimes the best thing to do is remove code!

[RafalAndHisThoughts]

I really like and appreciate your approach to work as a software developer. You're doing a great job by sharing your thoughts. Congrats!

[acasualviewer]

The book Peopleware talked about some developers being 10x more productive that others. But they also found out that it was irrespective of levels of experience, technology used, or other such individual factors. The main productivity factor to become 10x was company culture and having a quiet place to work (like individual offices).

Of course, everyone forgets the main thesis of those research results and makes up myths about the 10x developer.

I mean, if we're going to talk about 10x developers, how about some research to back it up. Because Peopleware (which did do research) was talking about something different.

[jerryknows]

This video is really helpful. I am now in my third year of my career, and it gives me confidence that I am on the right way.