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?
Programmers who write code fast and slow the project down? That's a minus 10x developer. A -10x developer is the only 10x developer I've ever met. They bang out a bunch of code without testing it and immediately check it in to source control. Everything they touch is a dumpster fire. I've created a few fires myself when I've lost perspective. You can very easily lose the forest for the trees. Especially when you have a deadline. I would argue that the main traits needed for a good developer are thoroughness, patience, and openmindedness. These are traits that are very hard to teach. Design patterns, coding standards, encapsulation, etc. are all great, but the best way to speed up is to not put bugs in the code in the first place. All the patterns, standards, books and courses in the world won't keep you from putting the bugs in if you're not patient and thorough. Finally, openmindedness helps you identify when you need to stop digging when you're taking the wrong approach.
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.
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.
@@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.
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."
This I've burned out myself in some really heavy weeks, but following the advices of my GF (who gets really mad about me overworking myself for free) I decided to not make any extra hours never, and to squeeze the hell out of my mornings. I plan what I want to do in my mornings, the plans of what I need to develop this morning, then at the end of my morning, a small summary of how much I achieved. After that, the next hours of my shift are just useless meetings and stuff, but now I know I gave my all that morning
@@189Blake There's also scope creep - they want you to build a depot that can work as an AirBnB rental on weekends or holidays. Point is, make them think and tell them what's feasible and what's not. If they demand everything, drop the client and run. EDIT: or make a plan to milk their stupidity for a few months or years :)
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 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.
@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!
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.
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.
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.
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!
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!
@@antoniofuller2331 I would like to object: documentation is most effective when it is concise and to the point. Is it really necessary to write two paragraphs or more for each method? If the method or class is complex, then detailed documentation is justified. However, most methods and classes are simple, as they should be in well-designed architectures. Additionally, having too many comments inside methods can be a code smell; good code should be simple and self-explanatory.
Learning not to give into managerial pressure to make it quick is an important skill. 1/2 the bad code I wrote in the first 3-4 years at my current company was because of all the times my manager told me to "keep it quick and simple". We lost a few major clients and even had to fully refund one project because he talked me out of my project plan in favor of something that would "save time". The biggest improvement I've made in being a developer is not in getting better at coding, but becoming better at standing by doing things the right way, we've not lost a single client for quality reasons since I've stopped changing project plans to "keep it quick and simple".
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".
Removing code is so satisfying, but if it's code from someone else it can become a pride issue for that person - even though there is nothing personal about it.
I love red commits. There's a truth that as old as the programming itself -- it is inevitable to introduce bugs and bugs are introduced by writing code. If you remove code, it's very probable that you just removed a bug or exploit that was just waiting to blow up in the worst moment possible.
Writing code fast is like building houses fast. Which houses do you think are better planned, sturdier, and last longer? The ones that were built very quickly, or the ones that were built within an expected construction time for a project that big? Remember: Anyone can be a fast driver and crash the car right into the next tree. But when you're in the car, you want a good, safe, reasonable ride, don't you? Speed comes in third place, because only if you get to the correct destination and get there in one piece, will the question be how fast you got there. If you end up in the wrong place or in pieces, who cares how little time it took?
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.
We had a guy like that at my last job. He was "a war machine" but everytiMe I passed behind him, I spend 1h refactoring his mess. He also used lots of overly complicated constructs on top of that.
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.
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.
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.
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.
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.
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.
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.
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.
@@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.
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.
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.
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 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
@@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!
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.
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!
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.
Less code is always the best metric for the best code provided it is as maintable and extensible. This also applies to reducing the number of dependencies as well unless they meaningfully also contribute to the above. Fast code often does become big code, especially as you immediately enter technical debt where no one wants to refactor or rewrite. Refactoring and deleting to less code lines is for me, and should be for everyone, the most enjoyable thing to do, and no one should have any problem removing said code. My Projects always have scratch (for replaced snippets) and Unused (for replaced classes and components) folders, not in the build, whether checked in or not!
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.
Creating code, documenting, auditing, communicating. It's all part of the 'get it done as soon as possible'. Getting the job done 'too fast' sure creates false expectations as it makes others think you (or your team) can get difficult tasks completed in less time than what is realistically possible. No sooner do you complete the first task; another is on your plate. It just begins to snowballs on you.
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.
I have seen that as well! Less experienced people often do the bare minimum to mark their jira as done even if it means they are adding to the spaghetti code, while more experienced programmers tend to do a bit of cleanup or refactoring at the same time where it makes sense. I definitely prefer that approach as opposed to needing a big bang refactor later on which could introduce more bugs.
I'm learning as a dev student and literally took the longer route- I got sidestepped on asynchronous and wondered why and how and found out the history of mathematics of European context and the old world studies they did in early civilizations. Long story short, the result and trick to get there and short cuts have been over simplified, gone far without explaining, and we have ultimately learned no fundamental approach to solving many problems. This helped with my problem in my early studies in logical thinking and concepts we used that I began digging in my own culture base for solutions for entropy. It's easy to explain and is something we need worked on. Thanks! Love the videos!
You are absolutely right on all the points. It's really frustrating seeing new developers come in and try to rush things, thinking that they will look better if it's done faster (except it's 95% of the time done badly so it either needs iterations or someone else has to fix it later). Some people also like to show off with the latest tech or pattern they just learned about even though it does not apply to our project at all or adds unnecessary complexity. It becomes a maintenance nightmare in the long run when the next people working on the project don't understand how it works. I try to code and document in such a way that someone else would be able to understand and maintain it, because that will end up being true more often than not. It also saves you time as people won't have to rely on you constantly and training new hires won't be as tedious.
Nice summary of some of the most important lessons I've learned in my career - and things I spend the most time trying to convey to less senior folks. Hear hear.
I have coded millions of lines for over 45 years. I can code very fast, but now with AI I can finish a full stack, mobile, ML or one of various other types of apps in a small fraction of the time it took last year. I recently wrote 98% of my final Zoom clone, but with AI transcription and AI video enhancement features, S&F, and other features in a weekend using AI (DeepSeek+Claude+Graph RAG extended 405B Llama 3.1). I have built a Zoom clone before, but I would have taken me at least 16 weeks before AI to build this, and I can only imagine where AI will be next year.
Being fast at writing code is like been able to lift heavy stuff as a construction worker these days. It does not matter becasue the bulldozer does it for everyone. I advise you to do 3 things: 1. Check out Cursor AI. 2. For future refernce, when you talk about software development, dont talk about coding, because it is now the easist part of software development. Becasue machines can do it. 3. Check out Cursor AI.
Just wanted to come by and say thanks... I was walking and listening this episode and...when the section about ambiguity went, I was like...I recogniced that this is my situation now and I thought at first "oh come on it's a waste of time I'll just do it somehow and patch later". But...I decided ok, I will try to ask and clarify and see where that goes. And of course something quite drastically different was required. So, we walk over the requirements and nooooow I begin to understand what was needed. Literally hours maybe days of time and energy are saved. I will practice this more. I want to just thank you for this advice a lot.
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.
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..
All very good. 5 definitely took me a while to get. Here's 7. Communicate expectations better. Most of the people you work for have no idea how long things should take. When you tell them you can do it in 5 days and it takes 7, they see you as slow. When you say, you were slow, they believe you. Learn how long things take and be more transparent.
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! 😊
My routine is if I return to some code after a long while and it gives me any trouble understanding it, I will either add some comments and/or refactor it to tidy it up. Super tidy code with clear uncluttered comments is the best time saver. If it is difficult to read and understand, then chances are that will introduce bugs later on.
Yep. I'developed massive ~1M line systems by myself, and I usually don't code fast. I painstakingly think the design through first. But, then I code it right, so I almost never have to rewrite it. All "fast" coders I've seen *look* more productive, but they have to rewrite things 50 times, and then debugging the code takes 10x more effort.
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
Some clients, especially first-time coop, will worry (like crazy) if they didn't see any progress in a week or two. The vital skill I developed for this is to write dirty-fast code to make them happy, then silently refactor it.
Not to oversimplify, but one of the things I’ve come to learn over the years is to try to resist using too many variables to solve a problem. I’ve recently had to convert tens of thousands of lines of Javascript to Angular Typescript. The developer who wrote the original Javascript used so many variables it was very difficult to keep track of what the code was doing. The migration was a nightmare. So unless you need the additional variables for performance reasons such as caching, it’s best to try to functionally retrieve the information you need as much as possible.
Creating an information system is a learning process. It's like climbing: you can learn more about a topic because you have learned a lot before but are ready to leave that behind. The current knowledge freezes into code that new knowledge breaks. Over decades, I distilled silly mantras like "structure eats code" or the 3P: "Yesterday's pride, today's power, tomorrow's problem. What is it? Everything I do". My advantage is that sometimes I can't write a line for days. That's when I do something much more important: by letting previous experience come back, I think ahead. So I avoid repeating a similar learning process and skip writing code that I would delete later...
Creating a document may seem like a detour, but creating a document allows us to see the entire process, so it's actually more reliable and faster than coding first.
The key thing is to write the code, tests, and documentation assuming that it needs to be clear to someone else how it works and why it is self-evidently correct without needing to ask you or study an extra cs module.
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.
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.
I currently work at the largest mobile banking company of my country. There are thousands of abstraction in the codebase with absolutely no documentations whatsoever. I admit we do have very rich documentation for APIs, feature stories, Edge cases of all the features, BUT no documentation for the codebase where people put weird fantasies and abstractions. We literally waste a week or two reading and trying to make sense out of what the previous owner of the code was thinking, and then if it clicks, we start developing the feature and send it to QA with finger crossed. IMO the big corporates are doomed with the fake 10x developers.
100% on ambiguous requirements. I can't think of many better ways to waste time and energy than trying to guess what a spec wants, only to find out the "real" requirements once you're finished.
Hey Jayme, I've been a fan of your channel for years now, and this might be your best video yet (in my opinion). I've known each of your points in first person and I know that if I can think and act as you suggest in my job I'll become a much better developer. Thank you for sharing your wisdom!
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.
The concept of a 10x programmer introduced by IBM is more similar to what is now called a tech lead. It was someone that was assigned a team that he would direct to achieve a goal. His output was multiplied in that way and his guidance would help the team as a whole move faster.
Writing code faster helps to iterate over the problem and basic debugging faster. It’s like a scientist on an exploration stage of experimenting. If experiment is ok, tests are ok, performance are ok, you can refactor if you don’t like something (like violating dry principle which is meh, everything dry is not always good)
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.
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.
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.
A suggestion: do not jump to the next topic/chapter without a pause. For example at 3:28 you immediately started talking about the next point. You could also use the pause to show a slide with the summary of the previous chapter. I find text useful for people who have visual memory.
I blew it. I took several programming courses, didn't understand what was going on, and ChatGPTed my way through, scoring very well but not knowing how to do anything without the AI. I will have a degree soon and zero programming knowledge. At least my other computer knowledge is real, though. Do in-person coding boot-camps exist that enforce a no-outside-help rule to force everyone to learn to code correctly?
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
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.
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.
@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.
My little story is, I always get pressured to implement this and that , and then I do it and it works to some extend but it’s messy and hard to expand upon .. Programming but MOSTLY DESIGNING the program / system takes time.
Holy shyte I didn't realize you were in Austin. We're just south of you in the 'city of red headed step children' (by Austin's standards anyway). This is definitely one of your best vids. All well said and yep, all true, and well said.
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.
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?
@@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.
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.
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.
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.
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 :))))
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.
That's a cool idea. By the way, how many job interviews have you had lately? How quickly can you solve a leetcode medium? How do you distinguish between bad advice and good advice?
I've been working at an architect level for the past 25 years. And the latter 17 as a consultant. So I don't teach people entry to mid-level interviewing skills. I mostly work with more experienced people and teach them how to get conversational interviews that demonstrate higher value. The junior to senior interviewing process is just broken. There are plenty of people out there who specialize in that kind of advice who are great at it, but I'm not the person to talk to. I know what I can help with, and what I can't. It's not leetcode ;)
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.
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.
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.
You're wrong. My father had a true 10x programmer on the small team that he leads who did write code incredibly fast and it was very good code. Writing code fast doesn't contradict anything on your list, these are all different skills and writing code fast is another one of them. You are right that it's not that important. Above all are writing good code and arriving at good design decisions, because bad code and bad design lead to negative productivity and doing it faster won't help.
You have to solve the problem beforehand, and start coding only when you already got the solution. I am talking about real programming problems, not CRUD or screen-coding.
Hey, I have a question regarding rejecting ambiguity. I found myself in some sort of similar situation where for example things are unclear or whatever and i have to wait for an answer from the client or a manager, and i wont have that answer right away, sometimes it takes like a week. What do you do in the mean time that you have to wait for that clarifying answer. If you dont have other feature or project to work on... you just roll your thumbs, waste your time on youtube ?
The best code is LESS code, and the only time when we (programmers) dont introduce bugs is when we don't write code in the first place. Also, DON'T reinvent the wheel and defenitely DON'T over engineer things thinking that you are clever with your solution, while you are in fact introducing Anti-patterns and devil bugs.
Hey there. You specifically get access to me, other people who support the channel, and clients who've done 6 or more coaching sessions with me to improve their career. So basically you're getting access to people who have a similar view and goals on career progression as I do. If you don't find value in that, don't join! It's there if you need it. If not, free communities are great too.
Idk of thats a good or bad trait as it makes my homework take significantly more more time.. often, i rewrite the same fkin shit until i find the most perfect way of writing it and usually that involves making some methods that react approprietely to every situation i can think of, and i often try to make them adapt to different situations, by having alot of generic types but usually when im done I have a function that can be used flawlessly through out the project. Its satisying but yeah, not very efficient time wise, i mean it could be efficient if i wrote those somewhere and reused them throught multiple projects idk.
Another way to be a productive developer: don't waste time watching TH-cam videos that purport to share some big, innovative secret, but which just explain things that should be obvious to the average person.
More and more i feel sure in my stance that every dev should spend 6 months in support before doing any kind of dev work. You learn Never to make assumptions How crap it is not to have documentation of functionality How to communicate concepts of varying complexity to multiple levels of understanding How clients think and what makes sense to them How terrible it feels to have to shrug and tell a client i dunno just wait i guess or nothing we can do about this. How difficult it is to go through 4 different teams trying to find an answer about how some data goes from point a to b. Because there's no documentation about it.
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?
yes, the ones that don't know any design patterns, any coding standard, duct tape types that they think they know it better.
@@r0ck3r4ever isn’t that how we all were when we were new?
Programmers who write code fast and slow the project down? That's a minus 10x developer. A -10x developer is the only 10x developer I've ever met. They bang out a bunch of code without testing it and immediately check it in to source control. Everything they touch is a dumpster fire. I've created a few fires myself when I've lost perspective. You can very easily lose the forest for the trees. Especially when you have a deadline.
I would argue that the main traits needed for a good developer are thoroughness, patience, and openmindedness. These are traits that are very hard to teach. Design patterns, coding standards, encapsulation, etc. are all great, but the best way to speed up is to not put bugs in the code in the first place. All the patterns, standards, books and courses in the world won't keep you from putting the bugs in if you're not patient and thorough. Finally, openmindedness helps you identify when you need to stop digging when you're taking the wrong approach.
@@HealthyDev Nope, some of us did study then program. Anyway, tech bros will not understand.
Found in most companies IT dept. don't know what they were doing!
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.
What if they are constantly under attack from other jealous devs?? Do they remain nice or do they ever retaliate?
@@SuperWarZoid they leave the company which they should. your boss and co worker is not your family
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.
@@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.
They are the best colleagues we can ask for and hope to become
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."
This
I've burned out myself in some really heavy weeks, but following the advices of my GF (who gets really mad about me overworking myself for free) I decided to not make any extra hours never, and to squeeze the hell out of my mornings.
I plan what I want to do in my mornings, the plans of what I need to develop this morning, then at the end of my morning, a small summary of how much I achieved.
After that, the next hours of my shift are just useless meetings and stuff, but now I know I gave my all that morning
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 :)
Generalize it further: if thee asked to do something, thee shall first understand what kind of something they really want :)
@@KulaGGin Take it much further. They probably don't want a house. Find out what their actual problem is.
@@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.
@@189Blake There's also scope creep - they want you to build a depot that can work as an AirBnB rental on weekends or holidays. Point is, make them think and tell them what's feasible and what's not. If they demand everything, drop the client and run. EDIT: or make a plan to milk their stupidity for a few months or years :)
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.
If it's clever, or requires docs, maybe it should be redesigned.
@@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.
@@Domineas documentation to describe a concept is very different than docs to describe code.
@@jearsh And here I was thinking we were talking about the same things. :/ Silly me.
@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!
11:00 Seen it many, many times. "Simplifying" abstractions that _do not simplify._ They just move the complexity somewhere else.
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.
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.
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.
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!
If they dont value your expertise, you can maybe start your own business and do it better
Diving in straight away and writing code is a huge red flag if you ask me
I think the one aspect is when "the big picture" is not fully understood by the group.
its that they use different colors when painting that big picture - some people make a heap, others sort a list
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!
Show me on the doll where it bit you
Code can never have too much comments. Document as much as possible. I'll read two paragraphs for a method in a class
@@antoniofuller2331 I would like to object: documentation is most effective when it is concise and to the point. Is it really necessary to write two paragraphs or more for each method? If the method or class is complex, then detailed documentation is justified. However, most methods and classes are simple, as they should be in well-designed architectures. Additionally, having too many comments inside methods can be a code smell; good code should be simple and self-explanatory.
Learning not to give into managerial pressure to make it quick is an important skill. 1/2 the bad code I wrote in the first 3-4 years at my current company was because of all the times my manager told me to "keep it quick and simple". We lost a few major clients and even had to fully refund one project because he talked me out of my project plan in favor of something that would "save time". The biggest improvement I've made in being a developer is not in getting better at coding, but becoming better at standing by doing things the right way, we've not lost a single client for quality reasons since I've stopped changing project plans to "keep it quick and simple".
"The implementation of abstraction is more complicated than if didn't abstract" - what a brilliant thought!
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".
As you noted, "10X" refers to productivity (getting the right stuff done quickly) not lines of code.
well, 10x could also mean duct tape code from chat gpt
@@r0ck3r4ever 100%, seen this and I am sick of this type of devs
Oh, crap, that's what I was doing wrong all along...
@@Meritumas really shows you how little some devs actually know how to program
@@jamess.2491yeah
Sometimes the best thing to do is remove code!
Removing code is so satisfying, but if it's code from someone else it can become a pride issue for that person - even though there is nothing personal about it.
I love red commits. There's a truth that as old as the programming itself -- it is inevitable to introduce bugs and bugs are introduced by writing code. If you remove code, it's very probable that you just removed a bug or exploit that was just waiting to blow up in the worst moment possible.
@@limbo3545 Less is more! (I say that after spending the day in debug mode sifting through a bloated and poorly documented framework.)
One measure of professionalism is trying to make oneself obsolete. A good programmer writes code so well, that anyone could continue their work.
💯
Also makes it easy to come back to the project if it's been awhile since you worked on it.
The way I've always thought/said about it is that a 10x Programmer is different than a 10x Software Engineer.
Writing code fast is like building houses fast. Which houses do you think are better planned, sturdier, and last longer? The ones that were built very quickly, or the ones that were built within an expected construction time for a project that big?
Remember: Anyone can be a fast driver and crash the car right into the next tree. But when you're in the car, you want a good, safe, reasonable ride, don't you? Speed comes in third place, because only if you get to the correct destination and get there in one piece, will the question be how fast you got there. If you end up in the wrong place or in pieces, who cares how little time it took?
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.
You need a better manager. :)
@@Domineas no argument from me.
We had a guy like that at my last job. He was "a war machine" but everytiMe I passed behind him, I spend 1h refactoring his mess.
He also used lots of overly complicated constructs on top of that.
This is real-world sensible stuff. Very few videos of this quality level on YT these days tbh....
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.
"Measure twice cut once"
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.
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.
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.
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.
Good for prototypes , many programmers are bad at prototyping because they already forget it is not final code
@@llothar68 then how come that most software that I see looks and feels like a prototype? 🤣
@@CallousCoder It's worse, they often even look like bad prototypes
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.
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.
I guess I have some other profile named viophile which I’m not aware of?… those words are 100% from my head 😀😀😀 absolutely agree
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.
@@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.
Yes, complexity should always prove that it needs to exist before it's added.
Having good architecture solves issue of client wanting different features every time you talk to them
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.
Did you get into it as a career change?
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.
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.
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.
I've also been a guilty intellectual masturbator MANY times. Took me many years of getting smacked by my own overconfidence to finally change.
@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
@@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!
@@HealthyDev"intellectual masturbator" 😂
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.
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!
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.
Cool analogy! Never heard it explained that way, but totally makes sense.
Less code is always the best metric for the best code provided it is as maintable and extensible. This also applies to reducing the number of dependencies as well unless they meaningfully also contribute to the above. Fast code often does become big code, especially as you immediately enter technical debt where no one wants to refactor or rewrite. Refactoring and deleting to less code lines is for me, and should be for everyone, the most enjoyable thing to do, and no one should have any problem removing said code. My Projects always have scratch (for replaced snippets) and Unused (for replaced classes and components) folders, not in the build, whether checked in or not!
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.
Creating code, documenting, auditing, communicating. It's all part of the 'get it done as soon as possible'. Getting the job done 'too fast' sure creates false expectations as it makes others think you (or your team) can get difficult tasks completed in less time than what is realistically possible. No sooner do you complete the first task; another is on your plate. It just begins to snowballs on you.
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.
I do the same. Continuous refactoring is a great benefit to software!
I have seen that as well! Less experienced people often do the bare minimum to mark their jira as done even if it means they are adding to the spaghetti code, while more experienced programmers tend to do a bit of cleanup or refactoring at the same time where it makes sense. I definitely prefer that approach as opposed to needing a big bang refactor later on which could introduce more bugs.
I'm learning as a dev student and literally took the longer route- I got sidestepped on asynchronous and wondered why and how and found out the history of mathematics of European context and the old world studies they did in early civilizations. Long story short, the result and trick to get there and short cuts have been over simplified, gone far without explaining, and we have ultimately learned no fundamental approach to solving many problems. This helped with my problem in my early studies in logical thinking and concepts we used that I began digging in my own culture base for solutions for entropy. It's easy to explain and is something we need worked on. Thanks! Love the videos!
I really like and appreciate your approach to work as a software developer. You're doing a great job by sharing your thoughts. Congrats!
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.
You are absolutely right on all the points. It's really frustrating seeing new developers come in and try to rush things, thinking that they will look better if it's done faster (except it's 95% of the time done badly so it either needs iterations or someone else has to fix it later). Some people also like to show off with the latest tech or pattern they just learned about even though it does not apply to our project at all or adds unnecessary complexity. It becomes a maintenance nightmare in the long run when the next people working on the project don't understand how it works.
I try to code and document in such a way that someone else would be able to understand and maintain it, because that will end up being true more often than not. It also saves you time as people won't have to rely on you constantly and training new hires won't be as tedious.
Nice summary of some of the most important lessons I've learned in my career - and things I spend the most time trying to convey to less senior folks. Hear hear.
Call yourself a 10% programmer instead. It looks like 10x but less pressure, imo.
I have coded millions of lines for over 45 years. I can code very fast, but now with AI I can finish a full stack, mobile, ML or one of various other types of apps in a small fraction of the time it took last year. I recently wrote 98% of my final Zoom clone, but with AI transcription and AI video enhancement features, S&F, and other features in a weekend using AI (DeepSeek+Claude+Graph RAG extended 405B Llama 3.1).
I have built a Zoom clone before, but I would have taken me at least 16 weeks before AI to build this, and I can only imagine where AI will be next year.
AI makes you a 100x programmer if you're already a 10x lol.
Being fast at writing code is like been able to lift heavy stuff as a construction worker these days. It does not matter becasue the bulldozer does it for everyone.
I advise you to do 3 things:
1. Check out Cursor AI.
2. For future refernce, when you talk about software development, dont talk about coding, because it is now the easist part of software development. Becasue machines can do it.
3. Check out Cursor AI.
Just wanted to come by and say thanks... I was walking and listening this episode and...when the section about ambiguity went, I was like...I recogniced that this is my situation now and I thought at first "oh come on it's a waste of time I'll just do it somehow and patch later". But...I decided ok, I will try to ask and clarify and see where that goes.
And of course something quite drastically different was required. So, we walk over the requirements and nooooow I begin to understand what was needed. Literally hours maybe days of time and energy are saved. I will practice this more.
I want to just thank you for this advice a lot.
You're very welcome!
if you're a real 10x programmer, you need a team of same guys or you should start your own business
10x programmer may be 0.1x salesman or worse.
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.
Fascinating! I will be looking into this, was unaware.
@@HealthyDev I'd say it's one of the top 10 classic software engineering related books.
The authors are Tom DeMarco and Timothy Lister.
Thank you!
This is a very invaluable reference! Thank you.
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..
All very good. 5 definitely took me a while to get.
Here's 7. Communicate expectations better. Most of the people you work for have no idea how long things should take. When you tell them you can do it in 5 days and it takes 7, they see you as slow. When you say, you were slow, they believe you. Learn how long things take and be more transparent.
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! 😊
Ha! Thanks. It's an AC15. Yeah an AC30 in this room would make me deaf lol!!!
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 😂
Ah, a soul after my own heart ;). Nice.
My routine is if I return to some code after a long while and it gives me any trouble understanding it, I will either add some comments and/or refactor it to tidy it up. Super tidy code with clear uncluttered comments is the best time saver. If it is difficult to read and understand, then chances are that will introduce bugs later on.
Yep. I'developed massive ~1M line systems by myself, and I usually don't code fast. I painstakingly think the design through first. But, then I code it right, so I almost never have to rewrite it.
All "fast" coders I've seen *look* more productive, but they have to rewrite things 50 times, and then debugging the code takes 10x more effort.
They are probably lacking in unit test. If you code fast and can write unit test then it's a game changer.
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
Some clients, especially first-time coop, will worry (like crazy) if they didn't see any progress in a week or two. The vital skill I developed for this is to write dirty-fast code to make them happy, then silently refactor it.
Not to oversimplify, but one of the things I’ve come to learn over the years is to try to resist using too many variables to solve a problem. I’ve recently had to convert tens of thousands of lines of Javascript to Angular Typescript. The developer who wrote the original Javascript used so many variables it was very difficult to keep track of what the code was doing. The migration was a nightmare. So unless you need the additional variables for performance reasons such as caching, it’s best to try to functionally retrieve the information you need as much as possible.
Creating an information system is a learning process. It's like climbing: you can learn more about a topic because you have learned a lot before but are ready to leave that behind.
The current knowledge freezes into code that new knowledge breaks. Over decades, I distilled silly mantras like "structure eats code" or the 3P: "Yesterday's pride, today's power, tomorrow's problem. What is it? Everything I do".
My advantage is that sometimes I can't write a line for days. That's when I do something much more important: by letting previous experience come back, I think ahead. So I avoid repeating a similar learning process and skip writing code that I would delete later...
Creating a document may seem like a detour, but creating a document allows us to see the entire process, so it's actually more reliable and faster than coding first.
The key thing is to write the code, tests, and documentation assuming that it needs to be clear to someone else how it works and why it is self-evidently correct without needing to ask you or study an extra cs module.
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.
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.
I currently work at the largest mobile banking company of my country. There are thousands of abstraction in the codebase with absolutely no documentations whatsoever. I admit we do have very rich documentation for APIs, feature stories, Edge cases of all the features, BUT no documentation for the codebase where people put weird fantasies and abstractions. We literally waste a week or two reading and trying to make sense out of what the previous owner of the code was thinking, and then if it clicks, we start developing the feature and send it to QA with finger crossed. IMO the big corporates are doomed with the fake 10x developers.
Ouch, that's a pretty extreme situation.
100% on ambiguous requirements. I can't think of many better ways to waste time and energy than trying to guess what a spec wants, only to find out the "real" requirements once you're finished.
Hey Jayme,
I've been a fan of your channel for years now, and this might be your best video yet (in my opinion).
I've known each of your points in first person and I know that if I can think and act as you suggest in my job I'll become a much better developer.
Thank you for sharing your wisdom!
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.
The concept of a 10x programmer introduced by IBM is more similar to what is now called a tech lead. It was someone that was assigned a team that he would direct to achieve a goal. His output was multiplied in that way and his guidance would help the team as a whole move faster.
Writing code faster helps to iterate over the problem and basic debugging faster. It’s like a scientist on an exploration stage of experimenting. If experiment is ok, tests are ok, performance are ok, you can refactor if you don’t like something (like violating dry principle which is meh, everything dry is not always good)
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.
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.
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.
A suggestion: do not jump to the next topic/chapter without a pause. For example at 3:28 you immediately started talking about the next point. You could also use the pause to show a slide with the summary of the previous chapter. I find text useful for people who have visual memory.
I blew it. I took several programming courses, didn't understand what was going on, and ChatGPTed my way through, scoring very well but not knowing how to do anything without the AI. I will have a degree soon and zero programming knowledge. At least my other computer knowledge is real, though. Do in-person coding boot-camps exist that enforce a no-outside-help rule to force everyone to learn to code correctly?
Just exactly what I faced with my team senior. Who just don’t want to write tests or docs in product company where I worked.
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
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.
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.
What kind of things?
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
@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.
My little story is, I always get pressured to implement this and that , and then I do it and it works to some extend but it’s messy and hard to expand upon .. Programming but MOSTLY DESIGNING the program / system takes time.
Holy shyte I didn't realize you were in Austin. We're just south of you in the 'city of red headed step children' (by Austin's standards anyway). This is definitely one of your best vids. All well said and yep, all true, and well said.
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.
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?
@@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.
@@christianbaer2897 sounds like y'all did what you could given the situation. That's a tough one to handle, to be sure.
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.
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.
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.
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 :))))
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.
That's a cool idea. By the way, how many job interviews have you had lately? How quickly can you solve a leetcode medium? How do you distinguish between bad advice and good advice?
I've been working at an architect level for the past 25 years. And the latter 17 as a consultant. So I don't teach people entry to mid-level interviewing skills. I mostly work with more experienced people and teach them how to get conversational interviews that demonstrate higher value.
The junior to senior interviewing process is just broken. There are plenty of people out there who specialize in that kind of advice who are great at it, but I'm not the person to talk to. I know what I can help with, and what I can't. It's not leetcode ;)
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.
I have been rejected due to the speed of my coding on more than one occasion. In my experience, getting it right takes time.
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.
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.
You're wrong. My father had a true 10x programmer on the small team that he leads who did write code incredibly fast and it was very good code. Writing code fast doesn't contradict anything on your list, these are all different skills and writing code fast is another one of them. You are right that it's not that important. Above all are writing good code and arriving at good design decisions, because bad code and bad design lead to negative productivity and doing it faster won't help.
Sometimes I feel like a 0.1x programmer, though I've been doing this for 20 yrs.
The only difference between you and most people, is they don't admit it.
Secret of 10x orogrammer is simple, first research, then make a plan if you do not have it, then implement it.
Also fast coding hurts hands.
You have to solve the problem beforehand, and start coding only when you already got the solution. I am talking about real programming problems, not CRUD or screen-coding.
Hey, I have a question regarding rejecting ambiguity. I found myself in some sort of similar situation where for example things are unclear or whatever and i have to wait for an answer from the client or a manager, and i wont have that answer right away, sometimes it takes like a week. What do you do in the mean time that you have to wait for that clarifying answer. If you dont have other feature or project to work on... you just roll your thumbs, waste your time on youtube ?
The best code is LESS code, and the only time when we (programmers) dont introduce bugs is when we don't write code in the first place. Also, DON'T reinvent the wheel and defenitely DON'T over engineer things thinking that you are clever with your solution, while you are in fact introducing Anti-patterns and devil bugs.
Less code is often better code, and less code takes more time to write.
Prototypes can be implemented fast. Alas, there is a tendency of those getting shipped to customers as final products.
What additional value do I get from joining you community for money that I can't get from joining an open free community?
Hey there. You specifically get access to me, other people who support the channel, and clients who've done 6 or more coaching sessions with me to improve their career. So basically you're getting access to people who have a similar view and goals on career progression as I do. If you don't find value in that, don't join! It's there if you need it. If not, free communities are great too.
Idk of thats a good or bad trait as it makes my homework take significantly more more time.. often, i rewrite the same fkin shit until i find the most perfect way of writing it and usually that involves making some methods that react approprietely to every situation i can think of, and i often try to make them adapt to different situations, by having alot of generic types but usually when im done I have a function that can be used flawlessly through out the project. Its satisying but yeah, not very efficient time wise, i mean it could be efficient if i wrote those somewhere and reused them throught multiple projects idk.
What I’ve learned… most companies value the fast but sloppy developer who delivers “story points” with loads of Tech Debt to be never be cleaned up 😅
I've spent a lot of my career fixing the code of fast programmers.
Oh man, tell me about it…
Another way to be a productive developer: don't waste time watching TH-cam videos that purport to share some big, innovative secret, but which just explain things that should be obvious to the average person.
More and more i feel sure in my stance that every dev should spend 6 months in support before doing any kind of dev work. You learn
Never to make assumptions
How crap it is not to have documentation of functionality
How to communicate concepts of varying complexity to multiple levels of understanding
How clients think and what makes sense to them
How terrible it feels to have to shrug and tell a client i dunno just wait i guess or nothing we can do about this.
How difficult it is to go through 4 different teams trying to find an answer about how some data goes from point a to b. Because there's no documentation about it.
I knew I was 10x 😂. My slowness is a plus not a minus 😂.