Real 10x Programmers Are SLOW To Write Code

[@HealthyDev]

Have you ever seen a programmer write fast code, but slow the project down? Are any of the strategies in this video new to you? What else have you done to be a more efficient programmer on your team?

[@r0ck3r4ever]

yes, the ones that don't know any design patterns, any coding standard, duct tape types that they think they know it better.

[@HealthyDev]

@@r0ck3r4ever isn’t that how we all were when we were new?

[@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.

[@SuperWarZoid]

What if they are constantly under attack from other jealous devs?? Do they remain nice or do they ever retaliate?

[@user-qr4jf4tv2x]

@@SuperWarZoid they leave the company which they should. your boss and co worker is not your family

[@bitshopstever]

Forcing patterns I'd disagree with to a degree - for example loosely coupled architecture or micro services we can't say nice things if people refuse to do their code following the pattern of the larger system. If you separate enforcing standards to another team member or manager then I agree with you.

[@JohnnyThund3r]

@@user-qr4jf4tv2x I mean that's the logical thing to do... if you're a 10X developer, it's really on your boss to make your working environment as enjoyable as possible and just get out of your way. If they can't provide that, you can land another Job in probably a few hours with your skill level, so why the hell would you tolerate a toxic working environment for even 5 minutes? If anything you owe it to every other developer to just quit because a company like that doesn't deserve to have any developers working for them, much less the 10X Dev.

[@laujimmy9282]

They are the best colleagues we can ask for and hope to become

[@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.

[@jearsh]

If it's clever, or requires docs, maybe it should be redesigned.

[@Domineas]

​@@jearsh The MVC pattern at one point in time required documentation so people could grok it. TDD is still a practice that is hard to train and requires a lot of documentation / coaching to teach. DDD as a concept has a mountain of books written on it. How does EventSourcing and CQRS work again? Even OOP at one point was new and novel and required a lot of documentation to teach. Case in point: Don't discount a "clever" or "innovative" design because it requires documentation and a process to teach and coach to make it viable. The designs you take for granted were once new and novel too. That said, I do generally agree with you that "clever" code is a bit of a smell and should at the very least make you reconsider your design decisions.

[@jearsh]

@@Domineas documentation to describe a concept is very different than docs to describe code.

[@Domineas]

@@jearsh And here I was thinking we were talking about the same things. :/ Silly me.

[@HealthyDev]

@Domineas Absolutely agree. I did an earlier episode on "Democratic Software Architecture" where I encouraged exactly this. Happy to hear your team gets to work with someone who understands this!

[@garrysimmons111]

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

[@r0ck3r4ever]

well, 10x could also mean duct tape code from chat gpt

[@Meritumas]

@@r0ck3r4ever 100%, seen this and I am sick of this type of devs

[@vitalyl1327]

Oh, crap, that's what I was doing wrong all along...

[@artemodintsov8675]

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 :)

[@KulaGGin]

Generalize it further: if thee asked to do something, thee shall first understand what kind of something they really want :)

[@AnimeReference]

@@KulaGGin Take it much further. They probably don't want a house. Find out what their actual problem is.

[@189Blake]

@@AnimeReference This is so true. They ask you for a house, because they want to store a lot of boxes... Sir, you need a depot, not a hosue.

[@thomasf.9869]

Sometimes the best thing to do is remove code!

[@garrettweaver3824]

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.

[@HealthyDev]

Thanks! Yeah, I guess that could be useful. I'd probably be taking some time to choose my words carefully that it doesn't come off like "I told you so!". But for sure, it might be an opportunity to open up to your suggestions down the road. Thanks for sharing, it's worth considering!

[@CrucialFlowResearch]

If they dont value your expertise, you can maybe start your own business and do it better

[@smallbig857]

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

[@kearneytaaffe7059]

This is why I don't do OOP programming anymore. I switched to functional programming. My life is so much better now. I also introduced the concept of, "You don't modify function inputs. First you create a copy. Then you modify the copy. Then you return the copy".

[@markw.schumann297]

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

[@ld1601]

I’ve worked myself into a corner so many times because I just dove in to writing code under managerial pressure. It came back to bite me every single time. Now I tell management: There’s a time cost to this either way - you can either shift the time cost up front to do it right and save a lot of money later or you can shift it to the end and waste a lot of money to fix it. The same "do it right the first time" logic applies to documenting code; even just a short paragraph can save hours in future tracing and debugging in some cases. Thanks for yet another excellent video!

[@bmiller949]

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

[@styleisaweapon]

its that they use different colors when painting that big picture - some people make a heap, others sort a list

[@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.

[@benjamin-lieb]

"Measure twice cut once"

[@bitshopstever]

Realize those PRs after a few iterations are frustrating for everyone and often really hard to understand in the UIs, especially GitLab, sigh. Perhaps keep PRs to yourself a bit longer and make sure you are writing stubs to fill out once things are better understood if you really can note in code as far as elsewhere. I take a lot of # TODOs.

[@xlerb2286]

Quickly written code is almost always crap. I was always one of the slower devs on whatever team I was on, but when I submitted the code is was correct. It did what it was supposed to, it was performant, easy to understand and maintain. And I'll brag a little and say I had extremely few bugs written against my code through the years. You do that and get in with a company that recognizes and rewards the value of that code and you're golden.

[@AnimeReference]

There's cycles and waves. It's not always best to be slow and methodical. You need to adjust your style to the companies needs at the time. Or to whatever your direct superior prefers.

[@CallousCoder]

I disagree, I crank out code way faster than anyone in our team and my code is pretty darn good - surely faster and covering a lot more edge cases. But why is that?! Simply because I have written systems tools and migration tools for 30 years in any language from assembly to PowerShell and I sell my skills as a freelancer. I get paid 90-110 euros an hour if I’m slower than the l team is be way way more expensive. You pay me the big bucks because I get it done fast and reliably. Also fast developers tend to be more efficient developers. You don’t see me make large if else blocks. I knock out structures with function pointers for example.

[@llothar68]

Good for prototypes , many programmers are bad at prototyping because they already forget it is not final code

[@CallousCoder]

@@llothar68 then how come that most software that I see looks and feels like a prototype? 🤣

[@llothar68]

@@CallousCoder It's worse, they often even look like bad prototypes

[@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."

[@jerryknows7765]

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.

[@scifyry]

Did you get into it as a career change?

[@viophile]

Been there yes, the biggest problem is that developers want to use the newest patterns and technologies which often just complicate matters. My principle is KISS in all the code that I write. There might be a more complicated way to write the code that would look nice and adhere to the modern pattern but more than ofter these modern patterns bring no value to the project, just more complexity.

[@r0ck3r4ever]

my manager wants to use duct tape code from chatgpt, we are fucked if that's the way forward..I am thinking about changing my job and move without ever returning.

[@JanPavlikdr]

I guess I have some other profile named viophile which I’m not aware of?… those words are 100% from my head 😀😀😀 absolutely agree

[@effexon]

devs... midle aged people are often mocked, devs even more so.... yet they dont want to go to latest thing without a reason. TBF customers, bosses, colleagues think that kind of overly energic person is "good worker". Only handful can be linus torvalds or john carmack and get away with it.

[@effexon]

@@r0ck3r4ever ah, im waiting when they start "improving construction performance by AI" or something like that.... so every real life thing can suffer same dumb stuff software people had to tolerate for ages.

[@xlerb2286]

Yes, complexity should always prove that it needs to exist before it's added.

[@Scottz0rz]

The way I've always thought/said about it is that a 10x Programmer is different than a 10x Software Engineer.

[@sugaryxegnirys]

Feeling validated but also frustrated as I reflect on the 10x programmers as you described and they were the senior devs and tech leads on my team. They didn't share knowledge. They didn't document. They even won over the product managers in seeing that "estimating stories is pointless". So every task was assumed "leveled" for anyone to pick up. Thank you for creating a Discord. It's difficult to afford your coaching at this time, but I'd love to join a community with you a part of it!

[@turn1210]

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

[@CantPickTheNameIwant]

if you're a real 10x programmer, you need a team of same guys or you should start your own business

[@bitshopstever]

10x programmer may be 0.1x salesman or worse.

[@StephenBolger]

I definitely think continued consideration for the patterns you use for the code you share with a team is very important. It is frustrating to reverse-engineer someone's code to understand it. I think any code the team writes, it should look the same to the point you wouldn't know who wrote it, and it's still good of course.

[@benjaminthorp2208]

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.

[@HealthyDev]

I've also been a guilty intellectual masturbator MANY times. Took me many years of getting smacked by my own overconfidence to finally change.

[@jdhrzg]

​@HealthyDev I just hit this last Friday. Tried to speed up reflection using delegates in C# (sounds as complicated as it was)... spent hours on it... then stopped abruptly because it wasn't worth the time anymore. Was very hard to stop though. Woulda been so cool! Ha

[@HealthyDev]

@@jdhrzg I hate when that happens! The feeling of finding a great new pattern only to have to give up on it when you hit too many brick walls sucks. Good on you though realizing enough was enough!

[@saggygnaw]

I watch so many videos on guitar gear and software development that when I saw the Vox behind you I had to double check which channel I was watching 😂

[@HealthyDev]

Ah, a soul after my own heart ;). Nice.

[@krakulandia]

All the really efficient programmers I know constantly refactor their code. They don't save it for later date. They do it daily as they implement new features. So that's definitely one of the major things 10x coders do.

[@HealthyDev]

I do the same. Continuous refactoring is a great benefit to software!

[@geerliglecluse5297]

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

[@SufianBabri]

At my last job, there was a developer who would build things very fast but their code and also the implementation was super sloppy. For instance, they would provide the marketing team to open any screen via a push notification but fail to make sure that the app handled the bad inputs (e.g. a video player screen requires a valid video-id). If the higher management doesn't understand how software development works, or your manager is always pushing you to work faster only to get people above them happy, you're going to have a bad time.

[@NilsEckelt]

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

[@HealthyDev]

💯

[@Jollyprez]

Was recently declared by manager that I was not a "superstar" programmer. One guy designated as such - writes prodigious amounts of code, certainly. BUT - his code is overly complex, uses all kinds of arcane language constructs, and is very very very difficult for even experienced people to decipher. Ask me how I know.

[@Domineas]

You need a better manager. :)

[@Jollyprez]

@@Domineas no argument from me.

[@imqqmi]

I've seen a fast programmer break an entire application. When he was working on it he made lots of changes and supposedly found lots of 'bugs' while I was struggling trying to understand what the application did, how it was setup etc. Months later when I was the lead dev for that project it turned out he broke the whole application and had to revert all the changes to make it work again. He didn't even check the unit tests that were in the project, most broke because of his changes. They may be 'fast' but also very negligent and they don't think things through or make an impact analysis etc. They are certainly quick to break a project.

[@Rcls01]

Someone once said that the developers at Google or any other big tech company aren't all that different to any other company. The best developers simply have a lot more discipline. They come to work on time, leave on time, they are punctual and most importantly: they help you when ever you ask. They rise up when you ask them to look at something, they brainstorm ideas with you, they teach you to be better. They bring up the skill level of the entire team.

[@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!

[@HealthyDev]

Thanks Rafal! It's just how I see people work on the teams I enjoy the most, and what I at least try to do myself.

[@petropzqi]

While I agree with what you say and find comfort in the words spoken. I do not agree with that .NET is not modern. .NET is hotter than ever and can do stuff that component based client side rendering stacks can only dream of.

[@Victoruvarov23]

What kind of things?

[@luaking84]

I was going to abandon .NET and move to Java/Spring but realized life's too short. I'm almost 40, I'll stick with .NET

[@HealthyDev]

@petropzqi I didn't mean to imply that .NET can't be used for new applications. Simply based on the history of when it emerged compared to the other technologies, they are more modern however. I hear what you're saying.

[@rayhon1014]

If your abstraction doesn't feel like removing enough mental burden from the team, ask if it is truly necessarily to give them an new set of api to do the job. When I first learnt about architecture, I like the analogy of designing a car dashboard. It gives us the minimum necessarily to operate a car. If you try to be smart and take away the steering wheel prematurely (perhaps you think you have the solution of FSD), you could create a mess instead.

[@HealthyDev]

Cool analogy! Never heard it explained that way, but totally makes sense.

[@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.

[@taylorallred6208]

Slow is smooth. Smooth is fast.

[@fluffysheap]

Nice, wonder how many will get this reference

[@NotMarkKnopfler]

I've been coding since 1984 (but not on the same program!). My approach is to get something _working_ first. _Then_ worry about making it better as i come to understand the problem domain better. Eventually you reach a point of diminishing returns against the effort required. That's when it's time to call the project done. I'm hitting the like button in honour of your Vox AC15 (or is it an AC30?). I've got an AC30 sat not even 6 feet away from me! 😊

[@HealthyDev]

Ha! Thanks. It's an AC15. Yeah an AC30 in this room would make me deaf lol!!!

[@Heater-v1.0.0]

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.

[@shikyokira3065]

I learned a lot from looking at the designs used by other industry pros. The best way is to use existing established patterns or naming to your new things. This made it so easy for many of my colleagues to jump into the new code base that I built with minimal documentation. It is also very easy to scale and add new features because they already know how it works in general

[@nERVEcenter117]

In my experience, the best way to be efficient is to parcel out to one person an entire component that can be invoked independently and communicates using standard data like JSON (minimize crossfire and toe-stepping while enabling the use of the best languages and tools), choose tools and languages that are best for the task (so any given feature uses the smallest amount of expressive code possible, given runtime environment and performance constraints), and keep the LOC under 50k and the files under 200 (slip over that, and you're straining the capacity of a single brain to hold everything). My work team has been very productive with this approach, but we also have no middle management layer hovering behind us, just one open-minded boss, so it works well.

[@PieJee1]

Sadly its still hard for the boss to figure out that a slow, but accurate developer is doing a better job. After all more support stories come from it and it looks like they develop more and more, while in reality they just fix all the shortcuts they take and the code is a mess for someone else to take over. I used to do things too fast, but other developers did not like how it was written. Now 90% of my time when developing i think about how an other developer would perceive it and it made me a lead developer right away. I still show off the speedy solution to other developers if they think they can do faster programming than me as a demonstration why it is worse in the long run and that it is not a skill. Of course you should not think too much without actually building something. Thats the fun of good software engineering to find the balance

[@HealthyDev]

Yup, productivity metrics are counterproductive in knowledge work. They may be helpful in manufacturing or other production domains, but they fight against productivity in software development.

[@oneadd7339]

True, I always write more readable and bug free code when working slower. However, my management and tight deadlines expect me to spit new features or expand existing features like damn machinegun. Fun thing is, most of the time, my manager is like, "Hey, we found bug in feature X, i know we told you to it is needed urgently, but actually it isn't. Take your time and fix it. ". Like I couldn't do it slower in the first place..

[@Immudzen]

The biggest impact I have seen on a team is unit testing. Having people use the code they just wrote makes them think about the code which makes better code. Teams I have been on almost completely eliminate time spent testing and it gives example for code usage to new developers.

[@marcusvrbergo]

Awesome

[@debugmeplease]

I talked about a 10x developer (well actuall 20x) in one of my videos. He is social competent, not too fast and not too slow in writing code and has deep knowledge in a lot of things. He supports younger devs, too.

[@vladluteen2299]

I've spent a lot of my career fixing the code of fast programmers.

[@HealthyDev]

Oh man, tell me about it…

[@johngagon]

Sometimes for me, slower means matching the rhythm of development. Starting a branch during deployment when everyone is merging is asking for tedious merge conflicts. Take the time there to read other PRs and go over best practices you want to use and get any questions you have distilled into bite-sized questions for the business or other experts. In sum, haste really does make waste. Good points and advice. Seen too often, myself included, going in "half-cocked" and find out soon that it's more than half wrong because they probably didn't finish distilling it when they handed it to you. It's more of a head's up. It can feel like "hurry up and wait" but that's kinda normal in a sprint cycled team.

[@gerhardruscher5067]

My last company said: we are working fast here .... two days after I saw a refactoring ticket of which I thought if made propperly, that would not be a ticket at all :))))

[@BigOlKnothead]

I like your philosophical takes on almost every subject you discuss and agree with tge sentiment behind alot of what you day in most videos. That said what I dont like is the way you constantly overuse qualificative language while speaking like youre trying to qualify your thoughts to yourself, which isn't such a bad thing when we take into the observation that while you may do some preplanning of your video scripts and do quite alot of stream of thought riffing, so filler to allow for thought is understandable. The thing I truly cabt stand is this sort of posturing and condescension toward- it can only be presumed- the people consuming ylur content. I get tbe stance of attempting to share helpful insightful productive tips, but its just. Always such a "true this" and "really true senior level that," and I know you ain't mean any of it the way it's coming off, but it does come off that way quite a dango lot buddy. Like the opposite of imposter syndrome, the everyone else but I are all imposters syndrome, only I am the true god of typpity typing stribg funct dynamically sourced data struct decorative repl king of all kings and. Know you aint mean to come off in that way and seem like a genuinely good dude. But honestly sometimes i get so damn discouraged by it I can't finish watching the video because Im teaching myself from a place of poverty from knowing nothing about it previously recovering from cancer surgery at 31, tryna learn game development with applications on my cheap ass cracked screen phone and borrowed wifi and almost have my first working game developed but like never gonna have a goddamn cock as long as yours and feels at times like that it's likely pointless for me to try to do this late in the game bcuz ill never be a fuckin "really true senior level team developer truly softwaring long cocked god of computer science," nearly good as you abd aint gotta shot in fucking hell of making aby development teams even as ab intern fetching coffee like. Like just. Seems just a bit lile putting yourself as a cut above us who ain't any less than you are, just havent maybe done it but the last 9months weve been in revovery attempting to do as much as we can without AI and feeling pretty good about our progress the 1/3rd the way through one of your videos I shut it off and walk away and cant even open up my application for a week bcause like. Tfs even the point....

[@HealthyDev]

Hey there. Sounds like you're having a tough time, sorry to hear that. Keep going! As far as "overqualificative language" this episode might give you some insight into why I talk like this. It has to do with the audience, as you surmised: kzbin.info/www/bejne/jn_LhY2PocSkqa8

[@PhrontDoor]

Call yourself a 10% programmer instead. It looks like 10x but less pressure, imo.

[@JohnnyThund3r]

The 10X Developer term really only applies to Solo Game Dev's I think, as most of the things you said wouldn't apply to anyone doing solo game dev, like needing to communicate with the team better, etc, etc... Like when I say I wanna be a 10X developer, I really mean I need to solve all of my Games coding problems 10X faster then a normal Game Dev would and this is pretty much true of any solo game dev.

[@bobbycrosby9765]

2 & 4 are a large part of my job. Sometimes they go hand in hand - people don't always realize the complexity of their requirements because it's requested in an ambiguous fashion. Usually I get a high level idea of what they want to achieve and propose a solution that solves it in a user friendly way that is as simple as possible on the tech end. The funny thing for #4 is that, while I don't achieve it by actually writing code, I achieve it by going through what it would look like if I were to write the code.

[@christianbaer2897]

We had this person on the team. Officially a working student, but in reality he was putting out half the code of the team. He was really good at understanding the requirements and putting that into code. It did work and he did not have a higher failure rate, as anybody else. He also understood his code perfectly. Well... He was alone in this. We had a hard time figuring out his clever loops and sometimes the ++i and i++ was so easy to overlook. You spent minutes and hours understanding his code. It did not take me long to realise, that this is not the goal.

[@HealthyDev]

It's totally understandable. We usually don't know someone like this is on the team in the status meetings. We find out when we need to review their code. Did y'all do code reviews occasionally on that project, or was there maybe not time?

[@christianbaer2897]

@@HealthyDev We started and it became more and more apparent. It got better over time, but still his code was more trickier to read and change than others. He left long before I left, but I could still take a look at code and go like "If I turn on git blame, I know whose name will show up, because my brain needs to work extra hard for this class/method" So yes, we tried to mitigate this (not only because of this one person), but especially in the beginning it was a rewrite project. So the work was paralleled as much as possible.

[@HealthyDev]

@@christianbaer2897 sounds like y'all did what you could given the situation. That's a tough one to handle, to be sure.

[@CrucialFlowResearch]

Sometimes a 10x programmer works alone instead of a team, because a team would slow down a 10x programmer. Sometimes, it's 10x to just work alone without all the politics slowing it all down.

[@JanPavlikdr]

Personally, fast coding problem solving start in the head without 1 line of code, happened to me so many times, that just thinking about the issue and joining dots in head take me whole day, and solution can be add 1 simple 20-30 lines function. It’s difficult to answer management, that you didn’t start yet spending hours of thinking instead of coding, but I guess they got used to it as results are delivered (mostly) on time.

[@heyyrudyy404]

Writing code fast is only possible for the solution you have beforehand. Even if it feels good to write code fast in the beginning, in the long run it becomes exhausting. If you don’t believe me, try to constantly writing code fast and you will see.

[@purdysanchez]

I have written a lot of code in Python because the PhDs who wrote the system only know Python.

[@Mad3011]

Writing code is to programmers as cutting wood is to carpenters. Would you judge a carpenter by the ability to cut wood super fast? All you will get is a heap of scraps. Measure twice, cut once also applies to coding.

[@TubeAccount-b1f]

i've been coding for long enough to understand how little I know yet I teach others daily with humility whilst coding at pace. I'm not in control of what others think about me and their opinions will vary however remains consistent with those that have worked with me. Fast code's nemesis is in the detail of complex logic and is heavily reliant on integration testing with fast bug to resolution iterations. I would be of the opinion that fast is fast but not without known shortcomings however, it is first to market for testing in a controlled environment. as fast iterative feedback and bug resolution is applied in qa. It's a highly debatable topic. Remember, complexity cannot be undone, it can only be moved. "better moved into one less world renounwed architecture" than a thousand small ones.

[@robfielding8566]

you spend $100k to get a 4 year CS degree. you get tons of experience. then you encounter what we now have..... you either need a super-high security clearance for gov work, or you need to pass leetcode tests that measure how fast you can solve random puzzles. whatever you make mandatory you will get. but what is NOT mandatory gets filtered out as a side-effect. so you get tons of people that un-carefully spit out code. i got a friend that loves leetcode puzzles, and he is super super smart. but he works for CrowdStrike, and the stacktrace of the crash that took down a huge percentage of the world's windows machines... it passed through a lot of his code. God help you if every single person you hire got in on the basis of solving 4 puzzles in an hour; but experience doing highly dangerous work did not matter.

[@HealthyDev]

I am right there with you. I believe our industry needs to experience more failures, and more pain, before things will change. The leetcode interview process is ridiculous as you say.

[@brucerosner3547]

I've been a software engineer for over 40 years and completely disagree. I find its much easier to iterate over code or refactor if you prefer. Writing original code is hard but changing is easy. So when faced with a problem I write as quickly as possible with many stubs. Than I go back and fix the most difficult part. I do agree that minimal code is best for broadly speaking the amount of bugs is proportional to lines of code. I also disagree about researching solutions for even if you have a done a similar problem before others might have a better solution. As Einstein said about Newton - if we can do better it is because we are standing on the shoulders of the giants who came before.

[@xlerb2286]

I don't think doing that is in disagreement with the concept of taking your time and thinking it through. I also like iterating. That first iteration helps me understand the problem, gain a feel for how good the structure of the code I'm using fits the problem, where the issues are, etc. And then with that better knowledge I iterate on it, or as I call it "hammering out the kinks". But I don't submit those iterations. I just keep working on the code until I'm satisfied it is everything it needs to be.

[@bitshopstever]

I think part of why you disagree is it sounds like you have the business experience to know where the stubs should be and how they should work. Most devs would have to pause and figure those out is how I interpret what he said. The ability to think in code and stubs seem exceedingly rare. It's easy to do in some contexts but other days businesses' describe their desires in very non coherent ways making it hard to understand, especially when they come at us with non written specs.

[@Meritumas]

Unless BS managers prize individual contributors, and, what's worse punish them for doing stuff "slower" (aka "it took you 2 sprints and why so long"). Slower means, well thought, tested first and without bugs. Yet at the same time some lads "banging keyboard", produce something in 2-3 days. Then the individual contributor needs to fix or re-do stuff. But, by then the "quick lads" are promoted or/and moved to other teams.

[@thomas6502]

Good info. Thanks! Strangely, "10x programmer" is a surprisingly unscientific notion for a field that runs on science... I've heard colleagues jokingly ask users of that phraseology, "Did you mean ${n}x programmer?" (Because sometimes 10 is actually -10 and the distinction can be important.)

[@Rockyzach88]

That's the thing though, most devs aren't scientifically trained.

[@markwalker3484]

If they call themselves 10x... they're not.

[@RockTo11]

Less code does not make something better or more efficient.

[@StephinTech]

I type slow… what should my wpm be 😢 self taught web developer here.

[@ShawnMcCool]

Yes, the more "modern" stack...

[@1906aldo]

I've been strugl

[@Jabberwockybird]

I would like to see Primaegen react to this video

[@HealthyDev]

Post it to www.reddit.com/r/ThePrimeagen/

[@ahmedghost4010]

I learned my lesson. Less is more. Just stick with the solution that works.

[@Baller1412]

Where’s the discord link to your channel?

[@HealthyDev]

You get it through a Patreon or KZbin membership. Check out the description for this episode if you want to read about them and consider supporting the channel.

[@SchkuenteQoostewin]

I am taking these bast iches to the EEOC, I onlyu have one hand and they want coding test done in 20 minutes with no regard to the ADA. May they know thy wrath

[@istovall2624]

/* this is where the magic happens */ that was a real comment, both in a meme and irl i found in the wild. software engineering should be a licensed thing like being a M.D.

[@turn1210]

Cannot agree more.

[@eotikurac]

for $160 per hour over a whole year i would make the apps and "s" their "d" and say thank you

[@harambetidepod1451]

self documenting code

[@andyl2895]

Doesnt exist

[@RomeTWguy]

Cope

[@Roboprogs]

Documented code. At least, based on research / empirical evidence.

[@KulaGGin]

You do good design following good design tech such as DDD, Clean Code. Clean Architecture, I. Jacobson's Object Oriented Software Engineering, or any really. Then you TDD your code. That's what makes 10x programmers. If you don't do any of those things you're essentially just shit coding where your code isn't tested and isn't following any of the good principles and patterns. So what is really the difference between you and gazillion of shitcoders out there? For me the answer is that I can do all the things I described above and many more: design patterns, algorithms, SOLID and GRASP principles, agile, just to name a few. That's what really sets me apart from all other programmers. And I actually do those things in my projects. I wrote tests and TDD'd it on the last code I wrote today, for example. Then I refactored the code and pressed play in Resharper and all tests still run and everything works and life is green.

[@HealthyDev]

Maybe it's just been my experience. But I find the things you mention are part and parcel for any decent senior developer. Basically that stuff is just the price of entry (I'm not a fan of Clean Code, but that's another discussion). This episode was meant to elucidate the things I keep seeing "principle consultant" and "senior architect" people fail to do when they think being versed in all the essential technical approaches makes them truly productive. They forget about the team.