I think you're forgetting that Jesus freed you. Most of these people don't have (that much) faith. People, by themselves, are unable - see John 15:5. All good comes from God. All good. Remember that :) EDIT: Case in point: You and I are free from porn by the grace of God (and through custody of eyes to which He calls us - eg Job 31:1, Matthew 6:22, Matthew 5:30). Would we ever be without God? How many are free from it in the world? Abide in Jesus. 1 John 2:14-17
As someone about the same age as Prime, I think the maturity comment is on point, but also it’s potentially easier for our generation to ignore phones and notifications because we still grew up in a time when immediate, constant availability wasn’t the norm.
Imo, you're suffering the ability to understand an experience that isn't yours (which, is also a sign of maturity.) For me, I have adhd. On meds, I can function close to what you experience. Off meds, I have executive function disorder. Literally adhd. The problem with the distraction aspect isn't typically email notifications, but people walking into my office and talking to me destroys a complex mind palace that I can't easily rebuild. Now that I'm on meds? Significantly easier. Just because you can't relate to an experience does not mean that experience is invalid. I really respect your views overall and enjoy your content. This was just one bad take. Won't stop me from watching, and it was entertaining to watch you fumble over it, but it's real.
Let's not forget the requirements for the application are ever-changing. You're told to build a tiny house, so you start laying the foundation for a tiny house. Months later they want a freaking castle and wonder why you can't just insert said castle on that tiny house foundation. As a result, senior devs start making the mistake of over-architecting every single thing they build, just in case. Round and round we go.
And there is a fear of tearing something down and building anew. If the new requirements are so at odds with the system you have built, the answer should be to build a new system, not to make every possible system you ever build in your life extensible to the nth degree. Of course if you invest all of those resources into building your super extensible system, or building an ugly monolith despite it not being extensible, then it's going to start feeling really bad to tear down. I'd wager this is one of the reasons a lot of people like micro services and other distributed architectures. Build a system around a small amount of requirements, and if things get out of hand spin up another system. You might even be able to share libraries and other tooling, but otherwise don't have to care about the design decisions made on other projects. And even if you need to rewrite large parts of one of the services, it's going to be much easier to sledgehammer your way through a smaller more dedicated codebase and fix things as you are breaking them, than accommodating them in a giant monolith.
@@ShadoFXPerino It's far more common over-architecting leads to the project running over budget and over schedule, often never seeing the light of day. Seen it a thousand times. Especially these days w/ cloud, containers, CI/CD, micro-apps/services, DI, AOT, and on and on and on. So easy to get caught up in preparing for what-if scenarios and lose focus on the goal of the project. I heard this a while ago, and I really like it and try to adhere to it. Just in time is better than just in case. It's not a hard and fast principle, but it makes sense. There are an infinite # of what-ifs.
Many many wise people have said to me some variation of this same idea in multiple different fields, not just programming: You want to go fast. You go fast by going smooth. You go smooth by going slow. Slow is fast. That doesn't mean to dick around and waste your time, but being deliberate and actually thinking about what you're doing will save FAR more time than just shooting off at the hip and flying by the seat of your pants.
Prime is of the "go fast and break things" model, where he expects to just make a lot of mistakes no matter what, so it's about recovering from those mistakes quickly and building an intuition rather than a praxis for how to avoid making such mistakes going forward.
@@transformersloverjonWhile I'm barely a junior dev myself, I certainly seem to lean towards the latter, considering I just spent several hours on a relatively simple 'Brilliant.org' Python problem. Could I have 'brute-forced' my way into the right multiple-choice answer? Yup. Takes less than a minute to plug in numbers and eliminate the wrong answers. But I wanted to understand the concepts behind the problem, so that if a similar, yet more complicated version of that problem cropped up later, I could address it just as easily. I failed to do that, even after two hours, and because I'm still a noob, I barely understand where I failed. But in the process, I not only learned a lot but directly branded the concepts onto my psyche so I couldn't easily forget it. And it was absolutely worth it, because all that 'banging my head against a proverbial wall' made later problems a breeze.
11:35 Tim Cain(one the main people behind Fallout and other famous games) said that whenever he got distracted while coding he would put a "zzzzzz" comment in the code where he was at the time - later, when QA found bugs he observed more often than not those were near the "zzzzzz" spots. Mind you - Tim has been in the industry for about 40 years. So there's some truth to the statement how small distractions can cause issues with the code.
It is truth for any cognitive work. It is not about forgetting, but about keeping your working memory completely occupied by problem pieces. It is like doing test for memorizing random numbers and be suddenly distracted. Of course your retention will be terrible. But if problem is kinda easy for your skill, you restore context almost immediately.
@@CamembertDave Right! Not a bad idea to put your state of being writing something. I know I have wildly different zones of work. Like sometimes documentation is a breeze, it's what I'd prefer to do. Sometimes I would rather die.
about the 10 minute thing: you don't forget EVERYTHING. Yeah, you still remember your name and the country you're in. But to get as focused and in the zone as you were and as commited as you were, doing whatever you were doing... yes, it takes 10-15 minutes to get to that point. And this is not about code or work either, you can be reading a novel or watching a movie or whatever. And basically prime's argument against this is to be distracted all the time by twitch chat lol
I think the distraction thing is not so much about forgetting as it is about getting back into a flow state on the project you are working on. I may remember where I was, but the full brain stack frame is not restored, and I have to build it back up before I'm back to my peak efficiency. Usually that stack frame is not 15 minutes deep, but working on some complex features or debugging complex code can definitely be that way (especially if you work low level with hardware). But my biggest problem is usually that my brain spawns a new thread to mill over whatever task I was distracted for. Before I learned I have to use an external tool to remember these "pop-up" tasks I would just do them in the moment to make sure I don't forget them. This was great when there were many fires to put out, but bad when I had long-term projects that were important but not urgent (until they were). Prime hits a key point here that you need to have a "parking lot" to record these things and keep them out of your head. I have ADHD and have to rely heavily on this to not be distracted all day, but even normal folks need this to cope with distraction-heavy environments.
More often than not, that 15 minute break from the code is what I need to understand it. It's too easy to get tunnel vision and focus on parts that are irrelevant
for me! whenever I feel like my code is getting overwhelming or out of control. I instantly go to the gym... during my exercise all of a sudden a solution to problem I have been try to solve for days with no success pops into my head. basically distractions are necessary in my opinion!
Exactly! if your code is actually clean (not Clean™), then taking a break and coming back can be really good to reset. When you're staring at the code for hours you have all that old code floating in your memory, even if you've already finished it. If you get up from the computer and go do something else for 15-30 minutes, your brain will forget all the finished work that you've done and you can focus on the new, unfinished work you need to do. Human brains are like poorly written C code that doesn't free() the memory. You gotta reboot to clean up every so often.
This actually applies many problem solving issues. Math is also the same way! Many times, the solutions come when I'm on a break from studying, not thinking about it at all! My math teacher back in the day drilled this into us. That in our breaks, is when the brain finds all the solutions!
@@hardcorecode there is a difference between a distraction (not controlled by you) and a break (controlled by you), only the latter is helpful because you choose the time and can close the current context, basically saving your progress
There is a big difference between rest, get a coffee and go for a walk break and "hey, I need help with this issue" interruption. If you have to change the context in your brain for dealing with another scenario, this will kill your productivity, specially if you have to do it constantly.
On the matter of interruptions… task and focus switching is an executive function task that relies on short term/working memory to act as that swap space so that the context can be retrieved after the interruption. ADHD and other executive function disorders impact the availability/use of working memory, as well as the parts of the brain handling the memory juggling and focus switching. 10 to 15 minutes seems a bit of an exaggeration, but I can attest after 30 years of futile effort to get better at task switching and multitasking (because no one wants to suck at basic life skills that are frequently demanded by one’s environment) that I still experience this challenge. What would be a small disruption to others often is a substantial one for me. It is accurate though that just like some people are shite at multitasking for no fault of their own, some are amazing at it. So kudos to you, and thanks for using your talents to entertain us all :) (but also, could we not so casually dismiss different brain wiring as a valid excuse that people experience the world and function differently? Last I checked, dyslexia would also count)
I don't forget anything after getting distracted. But If I was in a hyperfocused effective flow state then I am unlikely to easily get back into that. I am sadly not able to enter that at will. But I don't often get distracted while in that state. Probably because I don't easily register when someone tries to contact me when I am in that state and most usually take the hint that I am busy.
1 - AFAIK this 10-15 minute distraction thing is based on research. I'm not be able to give you the reference because I've probably read this in a magazine some 15 years ago, but AFAIK this is solid. And no, it doesn't have anything to do with any disorder, this is how human concentration work. 2 - try this yourself. Start to read a novel and notice how long it'll take for you to be as focused on it as you were before the interruption (I did sth similar when I read about it the first time). It has nothing to do with code, or with working for that matter. It's how the brain works. Now writing code is a VERY unusual and concentration intensive task. It seems pretty logical your code would suffer from distractions. Again AFAIK, this is the same process behind the usual attention span being 50min on, 10min off. And the same process also behind how hypnosis work. 3 - this is all without taking into account we live in the era of distraction, social media and smartphones. Not checking your phone (almost forgetting it exists) also help with concentration, productivity AND less bugs in your code. Most people do not have the 1 hour attention span anymore - I have to retrain myself from time to time with a time, actually. And people usually consider me a pretty focused person.
@@segueoyuri Perhaps it was unclear, but my comment wasn't addressing the 10-15 minute statistic. It was addressing the comments dismissing that there might be neurological differences that impact one's ability to improve their attention and focus. I was just pointing out that there are disorders that impact the wiring of the parts of the brain that manage focus and attention, and anyone with such a condition would be impacted in their ability to overcome attention and focus issues through sheer effort and discipline. Not that they shouldn't try, or that effort and discipline wouldn't improve things. Just that the ROI for effort and willpower applied isn't going to be the same for everyone.
9:15 "No plan survives contact with the enemy, but the act of planning is invaluable." It's just worth knowing that your plan WILL be thrown out and that if spend too much it's just a circle jerk, but it's worth hitting a strategic vision getting everyone on a close enough page to start working.
7:30 this is called the fence principle: if you walk by a fence, you should ask yourself why it's there in the first place and understand it before even thinking about removing it.
You know, I had this take on writing in 3rd grade, that you should try not to draft anything. Drafts are bad. It makes your writing more concise and clean because you don't try to go ahead of yourself until you know you're ready to move on.
Rich for a guy who constantly gets sidetracked off topic on his videos when someone randomly says something to be like “why do you get distracted from notifications?” That’s what notifications do, they are designed to get your attention. They’re not so they “stay there later”, it’s literally to notify you that something might require your attention. And you don’t know if they’re some random spam or your boss saying you are about to get fired or your spouse telling you the house is on fire, it could be any of those so your brain will give it the same attention, at least until it figures out if it’s important or not. So basically every time your notification go off you have to go? Is this important? What’s the app/sender? Should I check it now or later? And even if you don’t open them, that’s already attention that got taken away from the work you’re doing into weighing this out, the notification will still be there later when you turn them back on, so by turning them off you just makes sure to not get distracted while you’re working, so what’s the advantage of keeping them on?
I think the problem with interuptions is not that you forgot a lot and need to go from the beginning, it's more like after one interruption you're more likely pick up your phone or whatever and continue the chain of interruptions.
or if something is complex enough forgetting one detail may lead to you writing a solution that just falls apart and then having to rewrite or just keep glueing on fixes
The final boss of interuption is when someone messages you. You answer 2 minutes later then they ghost you. Now that totally kills my focus because now I am actively waiting for them to reply back, so I can get them out of my mind and I don't even know when I am going to get a reply, so I can't get my mind off it easily
re: notifications/distracitons, I think both chat and you had different interpretations of what that really means. there are teams where you will be called out (and spam called), seriously reprimanded, or fired under the guise of "not being able to multi-task" when you don't answer notifications, or you work in an office where someone is at your desk 99% of the time. not everywhere is netflix.
Agree with this, I think it also depends on who the notification is from. If it is from a boss, PM or executive for example, it can feel like it needs to take precedence and if you aren't the most comfortable with office politics responding can take a lot of brain power and be seriously distracting. Especially if you are fairly new somewhere and still trying to actively manage impressions. Like you implied, these people's opinions are often more important to keeping your job than writing good code. Sure if its just some bs from a co-worker then it should be easy to ignore, but notifications from some higher ups that require non-obvious or undesirable answers give me more anxiety than a bug I don't understand at all.
Earlier in my dev days I’d lose track when I was interrupted and took a while to get back, but looking back a lot of it was due to me trying to think too many steps ahead without plotting my though process and option down in paper (or pseudo code comments). Nowadays when I’m interrupted it’s less obtrusive because I’ve left enough breadcrumbs to jump back on the horse. However if trying to work with clean code and you have 25 functions instead of 20 lines, this methodology can get tricky.
100%, people are using ADHD as a crutch for this argument. I’d posit, that if you’re truly unable to resume, you did not fully understand the problem/solution. Eureka moments don’t just come from nothing, but lots of small decisions, you should be able to work back from one of those decisions points. Writing things down if your memory is fuzzy or you’re easily distracted, is a phenomenal way to do that (as you also stated). I keep paper, whiteboards or a writing tablet next to me at all times and treat it like a git commit to help create nodes in my head, not necessarily to read.
Saying that "you just need to be more mature" and "I got over addiction so I know what is working" is like saying "well, it works on my computer" That being said, there is something to be said about having an infantile outlook on life.
About the focus/interruptions, I think that being in a flow state is a thing where you are at your most productive and a small interruption can take you out of that. It can take a while to reach the "flow state" again after being interrupted like they said, but the flow state is not the 'normal' level of productivity that this argument is usually made for. I have always found issues with having tricks to be more productive rather than just doing the work. I used to do this all the time where I would spend so much time figuring out when/where to work and get timers setup for breaks etc. But when I learned to just sit down and do it I was 400% more productive than when I tried to optimize my productivity.
You know, an interesting IDE feature might be to expand function calls inline so if you do have a bunch of functions all over the place, you can follow what's going on as long as you start from the top. That might not always work for interfaces/abstract classes and the like. But, it could be a nice to have. Even if it is solving a manufactured problem...
When I write code, I "optimize" for one thing: making it as easy as possible (for somebody else) to understand it. Sometimes that's a on line function. Sometimes that's a 50 line function. Some it's a whole paragraph as a comment because the thing (which can be literally one or two lines of code) can't be dumped down into a handful of words (luckily very rare, but happens, but interestingly enough, the more the existing code base follows "Clean Code", the more likely this happens).
The greatest skill you can get as a professional programmer is looking at a message/notification and being like “that can wait”. It’s hard because socially you don’t want to seem like you are ignoring someone
I don't think I "forget" the code when I get an interruption, it is more that you just lose the sense of the layout and control flow that you've built up that allows you to write the next bit without explicitly thinking about the surrounding code. Like when you are on the motorway for a while and you maybe stop checking your mirrors (even though you should never do this) because you've been on there long enough to have built up a map of what is around you and you know nothing is going to suddenly appear in a blind spot because you've been keeping a general eye out far behind you for ages, and for something to be in that blind spot they'd have had to approach you for a while and you'd have noticed. So when you get a code interruption you switch from the effortless "flow" state programming into a much more effortful attempt to build up that map again, where you have to think more explicitly about the structure and where the control flow is going and what the edge cases were etc and remember why you did all the minor bits. You don't completely forget what you were doing, you can probably remember what the next task was, and you remember your overall plan, but you are writing at a much slower pace than you were prior to the interruption. The more complex the logic the more you are relying on this sort of subconscious map of the code to proceed I think, because it's difficult to hold everything in your limited conscious working memory. If someone interrupts me whilst I'm writing some validation for a form it will have no impact, if someone interrupts me whilst I am investigating a complex bug that is occurring somewhere in the interactions between 20 different micro services, or whilst writing something algorithmically complex, it probably does cost 15-25 minutes (although you aren't sitting there doing nothing for that time, you are just less productive for the next 45 mins or so) And also you have to factor in those days when you are just continuously being interrupted and can never get into that state to begin with, and you can get through a whole day of work having done an amount of work you could do in 2 hours on a day without continuous interruptions.
The distraction thing is real. I think ADHD plays a role into your ability to switch back 100% of your attention to what you're doing. I don't have ADHD but I have asperger, so the only thing that really affects me like that are ideas. If I don't write down ideas, think about them seriously and write the result down, I am unable to focus on something I don't find that exciting at the moment. Even sleeping is in that category. I think for "normal" people, they have the same issues with distractions, except they don't have a way to quickly clear the "cache".
Re: 4:11 -- exactly. No amount of boxes and lines on a board can change that, no UML, no clean code, no DDD, no TDD, no any other alphabet soup combination, if the problem is new to you (and your team), you just have to get to it and learn from your prototypes.
15:25 This hits so hard actually. I'm allergic to notifications. I gotta check and get rid of them as soon as they arrive so I don't see that stupid blinking light
To answer one of his questions, you can cover a function/method/black box you don't understand before refactoring relatively easily, that's called golden master testing. You keep the old, unreadable, but correct code (your golden master), in parallel of your new refactored code (that starts as a copy of the old one), then you write a test comparing the outputs (and mutations if any) of the two given all possible combinations of inputs and underlying/external code's outputs (just mock them). That's eventually a lot of combinations but you can bruteforce it without even using your brain, you can even generate it automatically. And if your language is untyped then you're cooked, no way to know the possible inputs and outputs without reading xD. I used it really rarely in my ~10y of experience, a dozen of times maybe, but it saved me when I did. And yes, sorry, the rest is technically TDD ;D (well, more like test driven refactoring)
it depends on the person interrupting me and the interruption. If the person put no effort into the question, now you have to do their job for them, and they do it on a regular basis, the distraction can waste a lot of time. If the person always tries their hardest, clearly put in the effort, and you work with them to figure out the answer, then there is almost no downtime.
@@lifelover69I worked with people in China for the better part of a decade. The language certainly does make it harder but its not really in the same realm of distraction, I'm not frustrated because some one from china doesn't know English very well, I get frustrated because some one tells me the data is good and its a problem with my program, and I spend hours on it only to find out that the data is infract not good and my program is fine
13:11 for me, I'm not just a dev, so I'm looking at 3 year old code, starting to get my head around the old code that I may or may not have written. Then the distraction comes and while, yes I'm aware of what I was doing, I have to refresh the mindset I started to get understanding the old code.
the distraction thing is context dependent. Most of the time, you are right, distractions only cost a bit of context but there are definitely times when you are right at the limit of your 7/8/9 things on your brain stack... maybe you are deep diving some edge case where an open source lib 3 transitives deep made a stoopid decision, maybe you are debugging some complicated bug with a script, in a container that calls a java function, which you have mocked......etc you get it right? when a distraction pushes you over that limit and all the cards fall on the floor.
Complexity grows with every line of code written. The only way to keep it manageable is to make an intentional effort to reduce that complexity at every opportunity. Unfortunately no software team working in commerce does this, ever. "Clean code" and "clean architecture" take the wrong approach of ADDING more artifice to make the complexity manageable while not actually reducing it. I have never seen this work in all of the decades following this mentality. I'm now embracing a theme of minimalism and SUBTRACTING code wherever possible.
13:10 unironically after thousands of years pen and paper are still the best tool. It helps me sleep an night knowing I wrote down my ideas, it helps me redesign the code architecture knowing that I can unwrap my idea partially, leavet it to sit cold, come back 15 minutes later and continue with minimal effort.
I think a lot of those issues are related. *If* your codebase is a mess, then context takes a lot of time to develop, because your code no longer behaves as a coherent state machine, but as a convoluted mess of state machines with thousands if not millions of possible states. In my experience people who love to use debuggers have this issue way more often, since they rely on being “in the moment”, executing synchronously with their machines.
I think that focus argument is taken slightly wrong by Primeagen (or maybe I misunderstood cuz I didn't hear what the man in the video was saying properly). But basically, I'd say a 30 sec distraction can break your flow. Then, getting back into the flow/zone can take you another 10mins.
@@hardcorecode I may have thrown that number in without much thought, but I can't imagine it's not b/w 5-10 mins. Getting into your flow zone where you code at lightning speed requires you to keep all of your concurrent train of thoughts and decision variables in my mind simultaneously. You can lose them quite quickly, and then you gotta rebuild that. That does take that much time for me, maybe I'm dumb.
Yeah, it seems like he's talking about focus as simply avoiding being distracted, but there is a wide gulf between having all your attention on the code and having all awareness of yourself and your surroundings dissolve away leaving only your mind directly interfacing with the code. Snapping back from a distraction to the former may only take a second, but the latter takes more than an hour with no interruptions.
@@jimhrelb2135 no no, getting into flow is significantly harder than getting back into flow. It very well takes coding on the order of hours (for me it's about an hour give or take) to break into it.
12:20 15-minute break is not the same as a 15-minute distraction. Like distraction require you to shift focus and think about a new task, sometimes with you still thinking about it after it happens.
7:44 Alternatively, you could be the guy that wrote logic to all the edge cases, your coworker could be the one opening the code thinking its hideous, then they rewrite the entire thing and hand it back to you telling you its refactored. Only there is one problem, you're the one who has to use it. Now you get the choice of rolling back all of their proposed changes and giving a lecture on why it won't work this way or writing in the edge cases to their refactor (which, contains, new bugs).
"just be mature" great advice from prime here. "lol just get 10 years of extra life experience and how to fight addictions" Gen Z has grown up with a lot of anxiety and very easily distracted brains. It's a good step to try and reduce distractions in the process of learning how to overcome this.
9:15 I don't forget what I'm working on, but I generally suck at focusing. If I'm locked in and someone comes in and I get sidetracked, I find it kinda hard to get really focused again. Granted, if I ever get focused in the first place its a miracle. And of course, there's almost nothing I'm working on that is life or death, so spending some time to get back into the zone isn't a big deal, telling other people to generally leave me alone because I need to focus is CRAZY. 16:30 Edit - Damn I guess I'm not free lol
9:32 I once read in a book that a task( train of thought ) that is interrupted causes 7 times the amount of time it would take to complete the task while in the zone, compare not having been interrupted. The length of the interruption does not matter, the derail itself does. I would really like to find this book again, it must have said a lot more on this topic.
5:42 I was fully expecting Kevlin Henney's quote from his 2022 Refactoring Is Not Just Clickbait (49m29s) talk where he basically shreds the Gilded Rose kata (that Sandi Metz used in 2014 All The Little Things) with It's a table driven problem, it's not an object oriented problem, it's not even a control flow problem. 9:20 Perhaps the segment of the population that is monotropic is much larger than we are prepared to admit …
It is not about whether i forget what I am working on. It is about the cost of context switch. If I have 1000 units of working left in me 60 goes into just context switching and the more it happens the more it costs.
11:41 It's not about short term memory, it's about workflow and process. If we define normal people as people with associative minds( people seeing a bird and thinking of flight, ) a distraction is like a dissociative trip( yet suddenly flight is no longer on the table, however a set of broken hammers is the natural progression of the sighting of the bird. )\ To a train of thought there is a full procedure: There is a boot procedure *1, there is a reload all the right parameters in the right order procedure *2, and then there is the doer potential *3. 1) If somebody entered the room smelling of cigarettes will the boot procedure be possible at all? 2) Will these parameters load in the right order if your boss had a rant on the state of the company during this break? 3) Are the prerequisits met?
I love the concept of goldfish-driven-development xD never had the issue that i forget my context even after a 15m meeting... over the weekend though... almost everything is lost (drinking a lot of beer there)
On the whole distraction thing. I think Prime you're a bit of an exception here. I know a few developers with very good focus, but they are quite rare. I have a book recommendation for you: Stolen Focus by Johann Hari.
I think the "Focus" thing is more about flow-state, and less about going 10-Second-Tim on the problem. Of course I still remember the context. But depending on the amount of stress the distraction causes, it can take varying amounts of time to get back into flow - up to 15 minutes. And there are certain people in my life that I swear sometimes have a timer set for every 15 minutes...
Prime about clean code: "I hate this" Prime about CodeAesthetic (which is just the Chapters of the book borderline plagiarized into videos): "I love this"
Regarding the 15 mins interruption, try writing a complex routine in assembly. The idea is that when you are interrupted, it takes you 10-15 mins to get back into it.
16:30 Well, there are also the types of bosses who throw a fit when you don't immediately answer. I at least managed one of my former ones either call or walk to my desk when it's urgent.
As a junior developer at my first job i can remeber when i really struggled to understand the code base, it was like a mental overload, and interruptions used to make me forget my train of thought which was very taxing mentally, combined with being rusty after taking a three months break from coding between graduating and getting a job it made everything even worse. I think its easy to forget how it was being new ill probably do the same but my point is this really depends on the circumstances
Interruptions can take a lot time of your time. Some tasks require you to enter in the 'zone', and that can takes up to an hour depending on the case. Any distraction takes you out and you have to star over again.
The focus part is just about getting into the same zone that you were in before you were interrupted, it has nothing to do with forgetting what you did - just about finding your pace or stride again. Apparently people who are interrupted tend to work faster with more stress and frustration after being interrupted, as a means to try and make up for the missed productivity, which also leads to more errors. That is iirc, it was quite a few years ago that I read the study which I believe was from Uni of California.
Characterisation tests are black box tests in the given a set of inputs here's the output. If you make changes to the codes and you get the same outputs for a given set of inputs the test passes. You don't have to understand the behaviour. You can use them as a safety net to make sure you don't change the behaviour of the code when you refactor it
You can't write a blackbox test when you don't know all the specific cases that can happen in that code. If you can write a test for a code you don't understand, you could probably just safely refactor it without that test.
Something that wasnt mentioned during the distraction part was that no matter how good you are at ignoring distractions, you will always have to spend a certain amount of energy to ignore them. Your brain has to process the notification, then look at it to determine whether or not its important and then switch back to the task at hand. So even if you can quickly determine that a notifcation doesnt need to be responded to, its still going to cost you brain power every single time the notification goes off. Our brains really dont like this, even if we can quickly switch back to the task at hand, just being in an environment where you can be distracted at any point leads to achieving less due to your brain constantly waiting for that distraction to come. And its not something you would be consciously aware of.
Re. that "interruption causes half an hour of loss of productivity," that drastically overlooks the benefits of occasionally stepping away from something hard, getting a refresh, and getting back into it. Sometimes you just need to sleep on it. Who hasn't woken up at 4 am with the solution to a problem they were bludgeoning their head against a brick wall for 8 hours trying to solve while awake?
I recently read a sequence of web pages that described Hamiltonian and Lagrangian physics within the realms of classical, relativistic, and quantum mechanics variants and then about Noether’s theorem and its implications regarding symmetries. The volume of information was just too great for me to track and know it all right away, but that is because I am not good with my memory and unlike some people, I cannot do multidimensional differential equations in my head to appreciate the implications of what is being said on the web page articles about these topics. I already knew I was not a genius, but this just confirmed it. Maybe if I was younger and had a better memory, then I could slog through this stuff and come out unscathed on the other side of it and proceed to examine Richard Feynman's contributions next.
My first workplace as a Software Developer, I open up a monolith of a solution, first class I open, first line of the first method: // temporary fix next class // To be removed next class // Beware ye who enter here, for here lies madness. next.. // To be removed next release (2013-11-27) I am still at said company, and I now know and understand each of those lines and why they are there. And I would dare anyone to remove them and keep functionality as it is today - it is just not possible unless you redesign the entire solution, and good luck getting that budget approved or ever completeing that project. Sometimes design may look bad or temporary, but let it live for long enough and you will either deal with it and build around it or you quit the company
I cannot recall where I read this quote, but I remember that from the moment I heard it, I lived by it. “Write code three times. Once to understand the problem. Again to understand the solution, and finally, to implement it.”
The problem is that people are getting used to being blated with information and lured in by something new. If you train it, you can resist, but generaly it's very hard. BTW, Prime is right, cuz he dropped his addictions, so he's probably winning this argument
I'm fighting one of the same addictions as Prime did (the worst one), and I can confirm that it does make you mature well and train your willpower. And then you realize how polluted with distractions, information and trends the world is. Once you understand where Prime comes from, you understand that he really is right here.
You can say that, but someone could respond by saying the person that never got addicted, in the first place, is the one who better understands their own willpower... Nobodies winning a subjective argument...
For every people who beaten his addictions there are people who didn't. It's insane to assume that people fail to beat their addictions due to some internal weakness due to the fact that people experience the subjective urges and wants differently depending on their biological makeup, not "sOuL". Example: I stopped smoking cold turkey, but I will never go around telling "just don't smoke bro 4Head" that's ignorant. All nuance is lost to oversimplify things in a "just reach for the switch and turn it off, I did so everyone can". People are way too complicated to have switches.
@@meltygear5955 we are talking about being distracted and you suddenly relate it with a drug addiction and equalize it... If you think that people who's addicted to media and mobiles don't need to grow up we are not in the same path. Also, growing up, isn't only to grow in statute but mature and confront your problems and try to solve your life to have a better and happier life
Lack of focus is not synonymous with remembering what you were doing. It's the ability to remain focused without wandering thoughts when you're fully absorbed back into what you're doing. That's my understanding - and I can attest to that.
On interruptions: the thing i do to wake up the next day and pick up from where i left off (if you consider sleep an interruption) is to write like 3 lines of text on a piece of paper and put it on top of my keyboard. Usually allows me to get back into it within some minutes. I am 37, so i'm sure people like 15 years younger can handle that even better.
I like to break things down into Input and output. Nothing matters except this. When writing APIs, Wrapper, functionality itself. Tests... Now. If you are coding on a larger product with different teams. How do you communicate? How do you contain your mess? Clean code and TDD? No, you simply acknowledge the fact that there is inherently mess within, but it can appear clean to the outside. By just communicating bigger features, section-off your application in terms of inputs and output. Each team can go wild in there respective features, New features can also be easily added always, bcs you never write anything coupled to business logic. Everything is simple transmutations on input to output. No magic. New features can be consumed and built out ahead of time in terms of their input and output, then the feature will be written to that spec.... (Yeah kinda sounds like TDD, but its not out of the test you derive and write the feature, you write it out of development need. Yes, obv you can markup your feature as a test bcs a test should always only be concerned with a things inputs and outputs) There it is. I'm still totally baffled how people write code that "should" know better than me. I'm just straight out of uni, but learned it from really old school people. Especially webdev is foreign to me. When people write "tests" for their components, to see if component returns component of type component. Im asking myself what are we trying to solve here? Or general notions of webdev. like "magic" functions without any arguments, that pull/spawn stuff out of seemingly nowhere. Its hard to grasp even what's going on. Reading linux kernels is more straight forward.
I code dirty. My conclusion is that a significant software work is like a masterpiece. A Mona Lisa. The person/persons who made it have amazing talent and vision. They have spent years honing their skills. After all that a beautiful thing emerges that people appreciate for many, many years. Well, looked at like that one does not come to them when their masterpiece is done and ask them to add this and change that. No, if you are lucky and they are still alive and you can pay them enough you might be able to get them to create an entirely new masterpiece. Perhaps like the old one but with new bells and whistles included. In short the notion of expecting software to be infinitely and easily malleable and expandable is silly. The notion of trying to build a masterpiece so that it can be transformed into something else later makes no sense. All these self-professed software architecture gurus are selling snake oil that promises to enable us to do the impossible.
Controlling your thoughts is not a 'will' thing. It's a neurotransmitter thing. You can't 'willpower' neruotransmitters into existence. Willpower is how we act on our thoughts, not the very thoughts we have....
I was on the other end of a rewrite recently. I came up with a good design for something, I implemented it, then some of the more senior devs decided my code was "messy". They rewrote it completely. at the end they had the exact same thing I did. I won a bet off it though
Not being able to follow the code but being able to do tests actually happens more often than not. Especially when using complex mathematical equations that I read through thoroughly over a weekend, implemented it and then forgot the math behind it. As long as the tests don't fail and it does what it does, I don't need to understand it fully.
Regarding being distracted, for me I find it's a lot easier to be distracted when I'm doing really mundane work; data entry stuff primarily. If it's something more complex, that I can really engage with, then it is sort of automatic to push everything else aside. I also have the bad habit of ignoring all notifications, so turning them off isn't really an issue for me. That said, focus is a skill, and it can be developed. It's discipline, but I believe also practice.
I've also never understood people that have to check every notifcation or respond to every text immediately. The sole purpose of asynchronous communication is to check it when you've got the time for it and not immediately. It's not a call that you have to pick up or it's gone. There's a simple rule I follow: Call if it's urgent, text if it can wait. Simple as that.
I don’t think you’re wrong prime that people should have better self-control and mental focus, but saying it’s easy for others to behave like you is BS. Playing the victim towards the end about your own struggles doesn’t justify your claims at all either.
16:25 I really struggle with this. Not because I can't ignore it, that is really easy, but my management REALLY wants me to answer emails/messages/etc. I sometime schedule PTO to clear my calendar and cancel it just so I can focus for the day.
There's usually a call stack in my head of several interrelated things that I'm figuring out at once to get to the actual goal, and that stack falls over like a mixed metaphor of Jenga blocks when the interruption happens. Apparently you don't have that issue. Nice!
There are solutions that I can be close to, where a distraction in focus can derail me to the point where it could take days before I find my way back onto that trail of thoughts. For me it's mostly noticeable when I'm working on a very challenging task that requires a lot of original thought that needs original architecture and patterns in order for all the pieces to fall into place.
Sometimes you can settle for at least using readable variable names in some horrific code so it is readable and faster to go through by the next person. Or simplify awkward if else structures and just comment the gotchas and unobvious code bits.
I was on a team that managed a piece of our backend that handled translation with some external endpoints that required PCI and iso compliance. They practiced scrum, TDD, and clean code. All the things devs hate. They were the most efficient team I’ve ever had the pleasure of being on. Extremely clean, easy to read code, scrum calls that were short and direct, and responsive. They had a clean workflow with QA, and a release/versioning process that all but managed itself. All of them were plucked by other companies, including the original lead that set the whole system up(I soon left after that). Anywho, it’s proof that good programmers that work well together can make quality code, even if they’re using systems that are generally considered slow, backwards, or a general hindrance to programming. One of the things the lead att stressed were effective code reviews.
I feel like the thing at @13:00 -ish someone had to be misunderstanding what was meant by "a distraction". Like is a distraction someone coming up to you and asking you a question you can answer instantly or for help that takes 2 minutes? Or is it a new problem pops up in the form of a task someone has for you that is going to take a solid thirty+ minutes of effort to solve? If it's the former, I'm with prime, it's not hard. If it's the latter and the task you were distracted from is complex then I can see it taking 15 minutes to get back into a flow. But not every time, it sounds like that guy was saying it happens all the time with any distraction, which doesn't make any sense.
The problem with "what you lack is maturity" is that maturity, like experience, is not a thing you can consciously obtain, it comes with time as you go through hardship
9:00 his whole point is just something you said earlier in the video, which is that no amount of planning will tell you what you're going to run into when you actually start writing the thing
9:50 the point isnt that you already spent 1-2 hours on it, the idea is that every 25 minutes for those first 2 hours you're being interrupted for 5-15 minutes. then you have 3 meetings with 30 min downtime in between each meeting and now it's already the end of the day
if the maturity comments hurt you, perhaps you need a bit of maturity to hear such things
You should offer a free "Adulting" course on Frontend Masters
I think you're forgetting that Jesus freed you. Most of these people don't have (that much) faith. People, by themselves, are unable - see John 15:5. All good comes from God. All good. Remember that :)
EDIT: Case in point: You and I are free from porn by the grace of God (and through custody of eyes to which He calls us - eg Job 31:1, Matthew 6:22, Matthew 5:30). Would we ever be without God? How many are free from it in the world?
Abide in Jesus. 1 John 2:14-17
You’re dumb
As someone about the same age as Prime, I think the maturity comment is on point, but also it’s potentially easier for our generation to ignore phones and notifications because we still grew up in a time when immediate, constant availability wasn’t the norm.
Imo, you're suffering the ability to understand an experience that isn't yours (which, is also a sign of maturity.)
For me, I have adhd. On meds, I can function close to what you experience. Off meds, I have executive function disorder. Literally adhd.
The problem with the distraction aspect isn't typically email notifications, but people walking into my office and talking to me destroys a complex mind palace that I can't easily rebuild. Now that I'm on meds? Significantly easier.
Just because you can't relate to an experience does not mean that experience is invalid.
I really respect your views overall and enjoy your content. This was just one bad take. Won't stop me from watching, and it was entertaining to watch you fumble over it, but it's real.
Let's not forget the requirements for the application are ever-changing. You're told to build a tiny house, so you start laying the foundation for a tiny house. Months later they want a freaking castle and wonder why you can't just insert said castle on that tiny house foundation. As a result, senior devs start making the mistake of over-architecting every single thing they build, just in case. Round and round we go.
Extensibility 👍🏻
Well can you blame them?
Well yeah if the over-architecting pays off and the ridiculous request is delivered up on then over-architecting happens more often
And there is a fear of tearing something down and building anew. If the new requirements are so at odds with the system you have built, the answer should be to build a new system, not to make every possible system you ever build in your life extensible to the nth degree.
Of course if you invest all of those resources into building your super extensible system, or building an ugly monolith despite it not being extensible, then it's going to start feeling really bad to tear down.
I'd wager this is one of the reasons a lot of people like micro services and other distributed architectures. Build a system around a small amount of requirements, and if things get out of hand spin up another system. You might even be able to share libraries and other tooling, but otherwise don't have to care about the design decisions made on other projects. And even if you need to rewrite large parts of one of the services, it's going to be much easier to sledgehammer your way through a smaller more dedicated codebase and fix things as you are breaking them, than accommodating them in a giant monolith.
@@ShadoFXPerino It's far more common over-architecting leads to the project running over budget and over schedule, often never seeing the light of day. Seen it a thousand times. Especially these days w/ cloud, containers, CI/CD, micro-apps/services, DI, AOT, and on and on and on. So easy to get caught up in preparing for what-if scenarios and lose focus on the goal of the project. I heard this a while ago, and I really like it and try to adhere to it. Just in time is better than just in case. It's not a hard and fast principle, but it makes sense. There are an infinite # of what-ifs.
Prime: I don’t forget
Prime: Side tracks for 10 seconds, forgets to read an entire paragraph.
what are we talking about?
lol
"Lemme read that big ass paragraph once more"
Hahahah
HAHAHAHHAHAHA
Prime doesn't believe in "Flow" state when working cause he's hopped up on G-Fuel and breastmilk
Many many wise people have said to me some variation of this same idea in multiple different fields, not just programming:
You want to go fast.
You go fast by going smooth.
You go smooth by going slow.
Slow is fast.
That doesn't mean to dick around and waste your time, but being deliberate and actually thinking about what you're doing will save FAR more time than just shooting off at the hip and flying by the seat of your pants.
Prime is of the "go fast and break things" model, where he expects to just make a lot of mistakes no matter what, so it's about recovering from those mistakes quickly and building an intuition rather than a praxis for how to avoid making such mistakes going forward.
@@transformersloverjonWhile I'm barely a junior dev myself, I certainly seem to lean towards the latter, considering I just spent several hours on a relatively simple 'Brilliant.org' Python problem.
Could I have 'brute-forced' my way into the right multiple-choice answer? Yup.
Takes less than a minute to plug in numbers and eliminate the wrong answers.
But I wanted to understand the concepts behind the problem, so that if a similar, yet more complicated version of that problem cropped up later, I could address it just as easily.
I failed to do that, even after two hours, and because I'm still a noob, I barely understand where I failed. But in the process, I not only learned a lot but directly branded the concepts onto my psyche so I couldn't easily forget it. And it was absolutely worth it, because all that 'banging my head against a proverbial wall' made later problems a breeze.
11:35
Tim Cain(one the main people behind Fallout and other famous games) said that whenever he got distracted while coding he would put a "zzzzzz" comment in the code where he was at the time - later, when QA found bugs he observed more often than not those were near the "zzzzzz" spots.
Mind you - Tim has been in the industry for about 40 years.
So there's some truth to the statement how small distractions can cause issues with the code.
It is truth for any cognitive work. It is not about forgetting, but about keeping your working memory completely occupied by problem pieces. It is like doing test for memorizing random numbers and be suddenly distracted. Of course your retention will be terrible. But if problem is kinda easy for your skill, you restore context almost immediately.
I might have to start doing this.
This is just adorable and looks fun
@@CamembertDave Right! Not a bad idea to put your state of being writing something. I know I have wildly different zones of work. Like sometimes documentation is a breeze, it's what I'd prefer to do. Sometimes I would rather die.
Prime would say it doesn't matter in the long-term because "all code is shit code."
about the 10 minute thing: you don't forget EVERYTHING. Yeah, you still remember your name and the country you're in. But to get as focused and in the zone as you were and as commited as you were, doing whatever you were doing... yes, it takes 10-15 minutes to get to that point. And this is not about code or work either, you can be reading a novel or watching a movie or whatever.
And basically prime's argument against this is to be distracted all the time by twitch chat lol
Remember, kids, you should be writing clean code, not Clean Code. There is a difference.
Now get off my lawn.
I think the distraction thing is not so much about forgetting as it is about getting back into a flow state on the project you are working on. I may remember where I was, but the full brain stack frame is not restored, and I have to build it back up before I'm back to my peak efficiency.
Usually that stack frame is not 15 minutes deep, but working on some complex features or debugging complex code can definitely be that way (especially if you work low level with hardware).
But my biggest problem is usually that my brain spawns a new thread to mill over whatever task I was distracted for. Before I learned I have to use an external tool to remember these "pop-up" tasks I would just do them in the moment to make sure I don't forget them. This was great when there were many fires to put out, but bad when I had long-term projects that were important but not urgent (until they were).
Prime hits a key point here that you need to have a "parking lot" to record these things and keep them out of your head. I have ADHD and have to rely heavily on this to not be distracted all day, but even normal folks need this to cope with distraction-heavy environments.
More often than not, that 15 minute break from the code is what I need to understand it. It's too easy to get tunnel vision and focus on parts that are irrelevant
for me! whenever I feel like my code is getting overwhelming or out of control. I instantly go to the gym... during my exercise all of a sudden a solution to problem I have been try to solve for days with no success pops into my head. basically distractions are necessary in my opinion!
Exactly! if your code is actually clean (not Clean™), then taking a break and coming back can be really good to reset. When you're staring at the code for hours you have all that old code floating in your memory, even if you've already finished it. If you get up from the computer and go do something else for 15-30 minutes, your brain will forget all the finished work that you've done and you can focus on the new, unfinished work you need to do.
Human brains are like poorly written C code that doesn't free() the memory. You gotta reboot to clean up every so often.
This actually applies many problem solving issues. Math is also the same way! Many times, the solutions come when I'm on a break from studying, not thinking about it at all!
My math teacher back in the day drilled this into us. That in our breaks, is when the brain finds all the solutions!
@@hardcorecode there is a difference between a distraction (not controlled by you) and a break (controlled by you), only the latter is helpful because you choose the time and can close the current context, basically saving your progress
There is a big difference between rest, get a coffee and go for a walk break and "hey, I need help with this issue" interruption.
If you have to change the context in your brain for dealing with another scenario, this will kill your productivity, specially if you have to do it constantly.
On the matter of interruptions… task and focus switching is an executive function task that relies on short term/working memory to act as that swap space so that the context can be retrieved after the interruption.
ADHD and other executive function disorders impact the availability/use of working memory, as well as the parts of the brain handling the memory juggling and focus switching.
10 to 15 minutes seems a bit of an exaggeration, but I can attest after 30 years of futile effort to get better at task switching and multitasking (because no one wants to suck at basic life skills that are frequently demanded by one’s environment) that I still experience this challenge. What would be a small disruption to others often is a substantial one for me.
It is accurate though that just like some people are shite at multitasking for no fault of their own, some are amazing at it. So kudos to you, and thanks for using your talents to entertain us all :)
(but also, could we not so casually dismiss different brain wiring as a valid excuse that people experience the world and function differently? Last I checked, dyslexia would also count)
I don't forget anything after getting distracted. But If I was in a hyperfocused effective flow state then I am unlikely to easily get back into that. I am sadly not able to enter that at will. But I don't often get distracted while in that state. Probably because I don't easily register when someone tries to contact me when I am in that state and most usually take the hint that I am busy.
If i’m working on debugging a memory image of a process, that already almost takes the IDE 10 minutes to even load 😅
@@kkiimm009 "I am sadly not able to enter that at will" nobody is
1 - AFAIK this 10-15 minute distraction thing is based on research. I'm not be able to give you the reference because I've probably read this in a magazine some 15 years ago, but AFAIK this is solid. And no, it doesn't have anything to do with any disorder, this is how human concentration work.
2 - try this yourself. Start to read a novel and notice how long it'll take for you to be as focused on it as you were before the interruption (I did sth similar when I read about it the first time). It has nothing to do with code, or with working for that matter. It's how the brain works. Now writing code is a VERY unusual and concentration intensive task. It seems pretty logical your code would suffer from distractions. Again AFAIK, this is the same process behind the usual attention span being 50min on, 10min off. And the same process also behind how hypnosis work.
3 - this is all without taking into account we live in the era of distraction, social media and smartphones. Not checking your phone (almost forgetting it exists) also help with concentration, productivity AND less bugs in your code. Most people do not have the 1 hour attention span anymore - I have to retrain myself from time to time with a time, actually. And people usually consider me a pretty focused person.
@@segueoyuri Perhaps it was unclear, but my comment wasn't addressing the 10-15 minute statistic. It was addressing the comments dismissing that there might be neurological differences that impact one's ability to improve their attention and focus.
I was just pointing out that there are disorders that impact the wiring of the parts of the brain that manage focus and attention, and anyone with such a condition would be impacted in their ability to overcome attention and focus issues through sheer effort and discipline. Not that they shouldn't try, or that effort and discipline wouldn't improve things. Just that the ROI for effort and willpower applied isn't going to be the same for everyone.
9:15 "No plan survives contact with the enemy, but the act of planning is invaluable." It's just worth knowing that your plan WILL be thrown out and that if spend too much it's just a circle jerk, but it's worth hitting a strategic vision getting everyone on a close enough page to start working.
7:30 this is called the fence principle: if you walk by a fence, you should ask yourself why it's there in the first place and understand it before even thinking about removing it.
Specifically, "Chesterton's Fence"
You know, I had this take on writing in 3rd grade, that you should try not to draft anything. Drafts are bad. It makes your writing more concise and clean because you don't try to go ahead of yourself until you know you're ready to move on.
Rich for a guy who constantly gets sidetracked off topic on his videos when someone randomly says something to be like “why do you get distracted from notifications?” That’s what notifications do, they are designed to get your attention. They’re not so they “stay there later”, it’s literally to notify you that something might require your attention. And you don’t know if they’re some random spam or your boss saying you are about to get fired or your spouse telling you the house is on fire, it could be any of those so your brain will give it the same attention, at least until it figures out if it’s important or not.
So basically every time your notification go off you have to go? Is this important? What’s the app/sender? Should I check it now or later? And even if you don’t open them, that’s already attention that got taken away from the work you’re doing into weighing this out, the notification will still be there later when you turn them back on, so by turning them off you just makes sure to not get distracted while you’re working, so what’s the advantage of keeping them on?
I think the problem with interuptions is not that you forgot a lot and need to go from the beginning, it's more like after one interruption you're more likely pick up your phone or whatever and continue the chain of interruptions.
In my experience, it's less forgetting everything and needing to restart, and more forgetting some little thing which then introduces a bug.
or if something is complex enough forgetting one detail may lead to you writing a solution that just falls apart and then having to rewrite or just keep glueing on fixes
The final boss of interuption is when someone messages you. You answer 2 minutes later then they ghost you. Now that totally kills my focus because now I am actively waiting for them to reply back, so I can get them out of my mind and I don't even know when I am going to get a reply, so I can't get my mind off it easily
re: notifications/distracitons, I think both chat and you had different interpretations of what that really means. there are teams where you will be called out (and spam called), seriously reprimanded, or fired under the guise of "not being able to multi-task" when you don't answer notifications, or you work in an office where someone is at your desk 99% of the time. not everywhere is netflix.
Agree with this, I think it also depends on who the notification is from. If it is from a boss, PM or executive for example, it can feel like it needs to take precedence and if you aren't the most comfortable with office politics responding can take a lot of brain power and be seriously distracting. Especially if you are fairly new somewhere and still trying to actively manage impressions. Like you implied, these people's opinions are often more important to keeping your job than writing good code. Sure if its just some bs from a co-worker then it should be easy to ignore, but notifications from some higher ups that require non-obvious or undesirable answers give me more anxiety than a bug I don't understand at all.
Earlier in my dev days I’d lose track when I was interrupted and took a while to get back, but looking back a lot of it was due to me trying to think too many steps ahead without plotting my though process and option down in paper (or pseudo code comments). Nowadays when I’m interrupted it’s less obtrusive because I’ve left enough breadcrumbs to jump back on the horse. However if trying to work with clean code and you have 25 functions instead of 20 lines, this methodology can get tricky.
100%, people are using ADHD as a crutch for this argument. I’d posit, that if you’re truly unable to resume, you did not fully understand the problem/solution. Eureka moments don’t just come from nothing, but lots of small decisions, you should be able to work back from one of those decisions points. Writing things down if your memory is fuzzy or you’re easily distracted, is a phenomenal way to do that (as you also stated). I keep paper, whiteboards or a writing tablet next to me at all times and treat it like a git commit to help create nodes in my head, not necessarily to read.
Saying that "you just need to be more mature" and "I got over addiction so I know what is working" is like saying "well, it works on my computer"
That being said, there is something to be said about having an infantile outlook on life.
About the focus/interruptions, I think that being in a flow state is a thing where you are at your most productive and a small interruption can take you out of that.
It can take a while to reach the "flow state" again after being interrupted like they said, but the flow state is not the 'normal' level of productivity that this argument is usually made for.
I have always found issues with having tricks to be more productive rather than just doing the work. I used to do this all the time where I would spend so much time figuring out when/where to work and get timers setup for breaks etc. But when I learned to just sit down and do it I was 400% more productive than when I tried to optimize my productivity.
You know, an interesting IDE feature might be to expand function calls inline so if you do have a bunch of functions all over the place, you can follow what's going on as long as you start from the top. That might not always work for interfaces/abstract classes and the like. But, it could be a nice to have. Even if it is solving a manufactured problem...
When I write code, I "optimize" for one thing: making it as easy as possible (for somebody else) to understand it.
Sometimes that's a on line function. Sometimes that's a 50 line function. Some it's a whole paragraph as a comment because the thing (which can be literally one or two lines of code) can't be dumped down into a handful of words (luckily very rare, but happens, but interestingly enough, the more the existing code base follows "Clean Code", the more likely this happens).
The greatest skill you can get as a professional programmer is looking at a message/notification and being like “that can wait”. It’s hard because socially you don’t want to seem like you are ignoring someone
I don't think I "forget" the code when I get an interruption, it is more that you just lose the sense of the layout and control flow that you've built up that allows you to write the next bit without explicitly thinking about the surrounding code. Like when you are on the motorway for a while and you maybe stop checking your mirrors (even though you should never do this) because you've been on there long enough to have built up a map of what is around you and you know nothing is going to suddenly appear in a blind spot because you've been keeping a general eye out far behind you for ages, and for something to be in that blind spot they'd have had to approach you for a while and you'd have noticed.
So when you get a code interruption you switch from the effortless "flow" state programming into a much more effortful attempt to build up that map again, where you have to think more explicitly about the structure and where the control flow is going and what the edge cases were etc and remember why you did all the minor bits. You don't completely forget what you were doing, you can probably remember what the next task was, and you remember your overall plan, but you are writing at a much slower pace than you were prior to the interruption.
The more complex the logic the more you are relying on this sort of subconscious map of the code to proceed I think, because it's difficult to hold everything in your limited conscious working memory. If someone interrupts me whilst I'm writing some validation for a form it will have no impact, if someone interrupts me whilst I am investigating a complex bug that is occurring somewhere in the interactions between 20 different micro services, or whilst writing something algorithmically complex, it probably does cost 15-25 minutes (although you aren't sitting there doing nothing for that time, you are just less productive for the next 45 mins or so)
And also you have to factor in those days when you are just continuously being interrupted and can never get into that state to begin with, and you can get through a whole day of work having done an amount of work you could do in 2 hours on a day without continuous interruptions.
The distraction thing is real. I think ADHD plays a role into your ability to switch back 100% of your attention to what you're doing. I don't have ADHD but I have asperger, so the only thing that really affects me like that are ideas. If I don't write down ideas, think about them seriously and write the result down, I am unable to focus on something I don't find that exciting at the moment. Even sleeping is in that category. I think for "normal" people, they have the same issues with distractions, except they don't have a way to quickly clear the "cache".
Take, by fighting an addiction you’ve learned a skill that you HAD TO learn to escape despair that others have not had as a motivator.
Re: 4:11 -- exactly. No amount of boxes and lines on a board can change that, no UML, no clean code, no DDD, no TDD, no any other alphabet soup combination, if the problem is new to you (and your team), you just have to get to it and learn from your prototypes.
15:25 This hits so hard actually. I'm allergic to notifications. I gotta check and get rid of them as soon as they arrive so I don't see that stupid blinking light
To answer one of his questions, you can cover a function/method/black box you don't understand before refactoring relatively easily, that's called golden master testing.
You keep the old, unreadable, but correct code (your golden master), in parallel of your new refactored code (that starts as a copy of the old one), then you write a test comparing the outputs (and mutations if any) of the two given all possible combinations of inputs and underlying/external code's outputs (just mock them).
That's eventually a lot of combinations but you can bruteforce it without even using your brain, you can even generate it automatically. And if your language is untyped then you're cooked, no way to know the possible inputs and outputs without reading xD.
I used it really rarely in my ~10y of experience, a dozen of times maybe, but it saved me when I did. And yes, sorry, the rest is technically TDD ;D (well, more like test driven refactoring)
it depends on the person interrupting me and the interruption. If the person put no effort into the question, now you have to do their job for them, and they do it on a regular basis, the distraction can waste a lot of time.
If the person always tries their hardest, clearly put in the effort, and you work with them to figure out the answer, then there is almost no downtime.
Great point. And there is even more effort needed in a multi-national workplace, because of the language barrier.
@@lifelover69I worked with people in China for the better part of a decade. The language certainly does make it harder but its not really in the same realm of distraction, I'm not frustrated because some one from china doesn't know English very well,
I get frustrated because some one tells me the data is good and its a problem with my program, and I spend hours on it only to find out that the data is infract not good and my program is fine
13:11 for me, I'm not just a dev, so I'm looking at 3 year old code, starting to get my head around the old code that I may or may not have written. Then the distraction comes and while, yes I'm aware of what I was doing, I have to refresh the mindset I started to get understanding the old code.
the distraction thing is context dependent. Most of the time, you are right, distractions only cost a bit of context but there are definitely times when you are right at the limit of your 7/8/9 things on your brain stack... maybe you are deep diving some edge case where an open source lib 3 transitives deep made a stoopid decision, maybe you are debugging some complicated bug with a script, in a container that calls a java function, which you have mocked......etc you get it right? when a distraction pushes you over that limit and all the cards fall on the floor.
"I forget everything when someone stops me" dude how the fuck do you go to lunch? Do you end your work day in the morning?
Complexity grows with every line of code written. The only way to keep it manageable is to make an intentional effort to reduce that complexity at every opportunity. Unfortunately no software team working in commerce does this, ever. "Clean code" and "clean architecture" take the wrong approach of ADDING more artifice to make the complexity manageable while not actually reducing it. I have never seen this work in all of the decades following this mentality. I'm now embracing a theme of minimalism and SUBTRACTING code wherever possible.
13:10 unironically after thousands of years pen and paper are still the best tool. It helps me sleep an night knowing I wrote down my ideas, it helps me redesign the code architecture knowing that I can unwrap my idea partially, leavet it to sit cold, come back 15 minutes later and continue with minimal effort.
I've adhd. 1 second of distraction means a whole day of distraction.
I think a lot of those issues are related. *If* your codebase is a mess, then context takes a lot of time to develop, because your code no longer behaves as a coherent state machine, but as a convoluted mess of state machines with thousands if not millions of possible states.
In my experience people who love to use debuggers have this issue way more often, since they rely on being “in the moment”, executing synchronously with their machines.
I think that focus argument is taken slightly wrong by Primeagen (or maybe I misunderstood cuz I didn't hear what the man in the video was saying properly).
But basically, I'd say a 30 sec distraction can break your flow. Then, getting back into the flow/zone can take you another 10mins.
What ?? No, 10 minutes! ..... that's crazy!
@@hardcorecode I may have thrown that number in without much thought, but I can't imagine it's not b/w 5-10 mins. Getting into your flow zone where you code at lightning speed requires you to keep all of your concurrent train of thoughts and decision variables in my mind simultaneously. You can lose them quite quickly, and then you gotta rebuild that. That does take that much time for me, maybe I'm dumb.
Flow for me is 2 hour. I think I don't deserve my position then...
Yeah, it seems like he's talking about focus as simply avoiding being distracted, but there is a wide gulf between having all your attention on the code and having all awareness of yourself and your surroundings dissolve away leaving only your mind directly interfacing with the code. Snapping back from a distraction to the former may only take a second, but the latter takes more than an hour with no interruptions.
@@jimhrelb2135 no no, getting into flow is significantly harder than getting back into flow. It very well takes coding on the order of hours (for me it's about an hour give or take) to break into it.
12:20 15-minute break is not the same as a 15-minute distraction.
Like distraction require you to shift focus and think about a new task, sometimes with you still thinking about it after it happens.
Prime teaching us how to not be a slave to the notification brain for 16 minutes.
7:44 Alternatively, you could be the guy that wrote logic to all the edge cases, your coworker could be the one opening the code thinking its hideous, then they rewrite the entire thing and hand it back to you telling you its refactored. Only there is one problem, you're the one who has to use it. Now you get the choice of rolling back all of their proposed changes and giving a lecture on why it won't work this way or writing in the edge cases to their refactor (which, contains, new bugs).
"just be mature" great advice from prime here. "lol just get 10 years of extra life experience and how to fight addictions"
Gen Z has grown up with a lot of anxiety and very easily distracted brains. It's a good step to try and reduce distractions in the process of learning how to overcome this.
9:15 I don't forget what I'm working on, but I generally suck at focusing. If I'm locked in and someone comes in and I get sidetracked, I find it kinda hard to get really focused again. Granted, if I ever get focused in the first place its a miracle. And of course, there's almost nothing I'm working on that is life or death, so spending some time to get back into the zone isn't a big deal, telling other people to generally leave me alone because I need to focus is CRAZY.
16:30 Edit - Damn I guess I'm not free lol
9:32 I once read in a book that a task( train of thought ) that is interrupted causes 7 times the amount of time it would take to complete the task while in the zone, compare not having been interrupted. The length of the interruption does not matter, the derail itself does. I would really like to find this book again, it must have said a lot more on this topic.
@18:00 depends on the pecking order you’re in. Those on lower rungs have to appease the egos of those above.
Prime: Your brain is different from mine? STOP!
5:42 I was fully expecting Kevlin Henney's quote from his 2022 Refactoring Is Not Just Clickbait (49m29s) talk where he basically shreds the Gilded Rose kata (that Sandi Metz used in 2014 All The Little Things) with
It's a table driven problem, it's not an object oriented problem, it's not even a control flow problem.
9:20 Perhaps the segment of the population that is monotropic is much larger than we are prepared to admit …
It is not about whether i forget what I am working on. It is about the cost of context switch. If I have 1000 units of working left in me 60 goes into just context switching and the more it happens the more it costs.
I really like that idea of importance hierarchy. That was a nice takeaway for me.
11:41 It's not about short term memory, it's about workflow and process. If we define normal people as people with associative minds( people seeing a bird and thinking of flight, ) a distraction is like a dissociative trip( yet suddenly flight is no longer on the table, however a set of broken hammers is the natural progression of the sighting of the bird. )\
To a train of thought there is a full procedure:
There is a boot procedure *1, there is a reload all the right parameters in the right order procedure *2, and then there is the doer potential *3.
1) If somebody entered the room smelling of cigarettes will the boot procedure be possible at all?
2) Will these parameters load in the right order if your boss had a rant on the state of the company during this break?
3) Are the prerequisits met?
I love the concept of goldfish-driven-development xD
never had the issue that i forget my context even after a 15m meeting... over the weekend though... almost everything is lost (drinking a lot of beer there)
On the whole distraction thing. I think Prime you're a bit of an exception here. I know a few developers with very good focus, but they are quite rare. I have a book recommendation for you: Stolen Focus by Johann Hari.
It is really strange how Prime comments about this guy's solution before actually letting us hear the proposed solution. Let the guy speak, dammit.
Rare quality in a video - great coding insights AND great life insights (in addition to the usual entertainment value).
Well worth the 23 minutes.
I think the "Focus" thing is more about flow-state, and less about going 10-Second-Tim on the problem.
Of course I still remember the context. But depending on the amount of stress the distraction causes, it can take varying amounts of time to get back into flow - up to 15 minutes.
And there are certain people in my life that I swear sometimes have a timer set for every 15 minutes...
Prime about clean code: "I hate this"
Prime about CodeAesthetic (which is just the Chapters of the book borderline plagiarized into videos): "I love this"
Regarding the 15 mins interruption, try writing a complex routine in assembly. The idea is that when you are interrupted, it takes you 10-15 mins to get back into it.
"whenever i see code that looks really bad", quickly glances at my code at the other screen
16:30 Well, there are also the types of bosses who throw a fit when you don't immediately answer.
I at least managed one of my former ones either call or walk to my desk when it's urgent.
13:28 "I'm- I guess I'm acoustic" 😂😂 cracked me up
As a junior developer at my first job i can remeber when i really struggled to understand the code base, it was like a mental overload, and interruptions used to make me forget my train of thought which was very taxing mentally, combined with being rusty after taking a three months break from coding between graduating and getting a job it made everything even worse. I think its easy to forget how it was being new ill probably do the same but my point is this really depends on the circumstances
Interruptions can take a lot time of your time. Some tasks require you to enter in the 'zone', and that can takes up to an hour depending on the case. Any distraction takes you out and you have to star over again.
The focus part is just about getting into the same zone that you were in before you were interrupted, it has nothing to do with forgetting what you did - just about finding your pace or stride again. Apparently people who are interrupted tend to work faster with more stress and frustration after being interrupted, as a means to try and make up for the missed productivity, which also leads to more errors. That is iirc, it was quite a few years ago that I read the study which I believe was from Uni of California.
I find that the ai assistants really help me not miss things when writing code, I ask for pseudocode, and it will give me a good baseline
Characterisation tests are black box tests in the given a set of inputs here's the output. If you make changes to the codes and you get the same outputs for a given set of inputs the test passes. You don't have to understand the behaviour. You can use them as a safety net to make sure you don't change the behaviour of the code when you refactor it
You can't write a blackbox test when you don't know all the specific cases that can happen in that code. If you can write a test for a code you don't understand, you could probably just safely refactor it without that test.
@@JanVerny you absolutely can if you use code coverage tools to make sure you are exercising all branches with different inputs
Something that wasnt mentioned during the distraction part was that no matter how good you are at ignoring distractions, you will always have to spend a certain amount of energy to ignore them. Your brain has to process the notification, then look at it to determine whether or not its important and then switch back to the task at hand. So even if you can quickly determine that a notifcation doesnt need to be responded to, its still going to cost you brain power every single time the notification goes off. Our brains really dont like this, even if we can quickly switch back to the task at hand, just being in an environment where you can be distracted at any point leads to achieving less due to your brain constantly waiting for that distraction to come. And its not something you would be consciously aware of.
Re. that "interruption causes half an hour of loss of productivity," that drastically overlooks the benefits of occasionally stepping away from something hard, getting a refresh, and getting back into it. Sometimes you just need to sleep on it. Who hasn't woken up at 4 am with the solution to a problem they were bludgeoning their head against a brick wall for 8 hours trying to solve while awake?
I recently read a sequence of web pages that described Hamiltonian and Lagrangian physics within the realms of classical, relativistic, and quantum mechanics variants and then about Noether’s theorem and its implications regarding symmetries.
The volume of information was just too great for me to track and know it all right away, but that is because I am not good with my memory and unlike some people, I cannot do multidimensional differential equations in my head to appreciate the implications of what is being said on the web page articles about these topics. I already knew I was not a genius, but this just confirmed it. Maybe if I was younger and had a better memory, then I could slog through this stuff and come out unscathed on the other side of it and proceed to examine Richard Feynman's contributions next.
My first workplace as a Software Developer, I open up a monolith of a solution, first class I open, first line of the first method:
// temporary fix
next class
// To be removed
next class
// Beware ye who enter here, for here lies madness.
next..
// To be removed next release (2013-11-27)
I am still at said company, and I now know and understand each of those lines and why they are there. And I would dare anyone to remove them and keep functionality as it is today - it is just not possible unless you redesign the entire solution, and good luck getting that budget approved or ever completeing that project. Sometimes design may look bad or temporary, but let it live for long enough and you will either deal with it and build around it or you quit the company
I cannot recall where I read this quote, but I remember that from the moment I heard it, I lived by it.
“Write code three times. Once to understand the problem. Again to understand the solution, and finally, to implement it.”
The problem is that people are getting used to being blated with information and lured in by something new. If you train it, you can resist, but generaly it's very hard.
BTW, Prime is right, cuz he dropped his addictions, so he's probably winning this argument
I'm fighting one of the same addictions as Prime did (the worst one), and I can confirm that it does make you mature well and train your willpower. And then you realize how polluted with distractions, information and trends the world is.
Once you understand where Prime comes from, you understand that he really is right here.
If you can't resist to check a simple phone notification you have a bigger problem than just being distracted.
You can say that, but someone could respond by saying the person that never got addicted, in the first place, is the one who better understands their own willpower...
Nobodies winning a subjective argument...
For every people who beaten his addictions there are people who didn't. It's insane to assume that people fail to beat their addictions due to some internal weakness due to the fact that people experience the subjective urges and wants differently depending on their biological makeup, not "sOuL".
Example: I stopped smoking cold turkey, but I will never go around telling "just don't smoke bro 4Head" that's ignorant. All nuance is lost to oversimplify things in a "just reach for the switch and turn it off, I did so everyone can". People are way too complicated to have switches.
@@meltygear5955 we are talking about being distracted and you suddenly relate it with a drug addiction and equalize it... If you think that people who's addicted to media and mobiles don't need to grow up we are not in the same path. Also, growing up, isn't only to grow in statute but mature and confront your problems and try to solve your life to have a better and happier life
The maturity take is the most beautiful thing 99% of people need to hear.
The inspirational music is inspiring UA-cam to ignore that it's huge blocks of other people's content.
Lack of focus is not synonymous with remembering what you were doing.
It's the ability to remain focused without wandering thoughts when you're fully absorbed back into what you're doing.
That's my understanding - and I can attest to that.
there are a million clips that teach you how to go from 0 to 20.you are the first that pushes you to be your best.
On interruptions: the thing i do to wake up the next day and pick up from where i left off (if you consider sleep an interruption) is to write like 3 lines of text on a piece of paper and put it on top of my keyboard. Usually allows me to get back into it within some minutes. I am 37, so i'm sure people like 15 years younger can handle that even better.
7:16 The principal you are talking about is known as “Chesterton’s fence”
I like to break things down into Input and output.
Nothing matters except this.
When writing APIs, Wrapper, functionality itself. Tests...
Now.
If you are coding on a larger product with different teams. How do you communicate?
How do you contain your mess? Clean code and TDD?
No, you simply acknowledge the fact that there is inherently mess within, but it can appear clean to the outside.
By just communicating bigger features, section-off your application in terms of inputs and output.
Each team can go wild in there respective features,
New features can also be easily added always, bcs you never write anything coupled to business logic.
Everything is simple transmutations on input to output. No magic.
New features can be consumed and built out ahead of time in terms of their input and output, then the feature will be written to that spec.... (Yeah kinda sounds like TDD, but its not out of the test you derive and write the feature, you write it out of development need. Yes, obv you can markup your feature as a test bcs a test should always only be concerned with a things inputs and outputs)
There it is.
I'm still totally baffled how people write code that "should" know better than me. I'm just straight out of uni, but learned it from really old school people.
Especially webdev is foreign to me.
When people write "tests" for their components, to see if component returns component of type component. Im asking myself what are we trying to solve here?
Or general notions of webdev.
like "magic" functions without any arguments, that pull/spawn stuff out of seemingly nowhere.
Its hard to grasp even what's going on.
Reading linux kernels is more straight forward.
I code dirty.
My conclusion is that a significant software work is like a masterpiece. A Mona Lisa. The person/persons who made it have amazing talent and vision. They have spent years honing their skills. After all that a beautiful thing emerges that people appreciate for many, many years.
Well, looked at like that one does not come to them when their masterpiece is done and ask them to add this and change that. No, if you are lucky and they are still alive and you can pay them enough you might be able to get them to create an entirely new masterpiece. Perhaps like the old one but with new bells and whistles included.
In short the notion of expecting software to be infinitely and easily malleable and expandable is silly. The notion of trying to build a masterpiece so that it can be transformed into something else later makes no sense.
All these self-professed software architecture gurus are selling snake oil that promises to enable us to do the impossible.
You are not a professional, are you? Can't imagine your attitude works for larger projects.
Im annoyed if someone disrupt me, but it takes me AT MOST 1 minute to get back, unless the interruption ended upp in a 2 day trip somewhere.
Controlling your thoughts is not a 'will' thing. It's a neurotransmitter thing. You can't 'willpower' neruotransmitters into existence.
Willpower is how we act on our thoughts, not the very thoughts we have....
I was on the other end of a rewrite recently. I came up with a good design for something, I implemented it, then some of the more senior devs decided my code was "messy". They rewrote it completely. at the end they had the exact same thing I did. I won a bet off it though
Not being able to follow the code but being able to do tests actually happens more often than not. Especially when using complex mathematical equations that I read through thoroughly over a weekend, implemented it and then forgot the math behind it. As long as the tests don't fail and it does what it does, I don't need to understand it fully.
Regarding being distracted, for me I find it's a lot easier to be distracted when I'm doing really mundane work; data entry stuff primarily. If it's something more complex, that I can really engage with, then it is sort of automatic to push everything else aside. I also have the bad habit of ignoring all notifications, so turning them off isn't really an issue for me.
That said, focus is a skill, and it can be developed. It's discipline, but I believe also practice.
I've also never understood people that have to check every notifcation or respond to every text immediately. The sole purpose of asynchronous communication is to check it when you've got the time for it and not immediately. It's not a call that you have to pick up or it's gone. There's a simple rule I follow: Call if it's urgent, text if it can wait. Simple as that.
I don’t think you’re wrong prime that people should have better self-control and mental focus, but saying it’s easy for others to behave like you is BS. Playing the victim towards the end about your own struggles doesn’t justify your claims at all either.
16:25 I really struggle with this. Not because I can't ignore it, that is really easy, but my management REALLY wants me to answer emails/messages/etc. I sometime schedule PTO to clear my calendar and cancel it just so I can focus for the day.
When you have so many duties, you have to give priority for work and that means ignoring notifications until it is time to be attended to
There's usually a call stack in my head of several interrelated things that I'm figuring out at once to get to the actual goal, and that stack falls over like a mixed metaphor of Jenga blocks when the interruption happens. Apparently you don't have that issue. Nice!
There are solutions that I can be close to, where a distraction in focus can derail me to the point where it could take days before I find my way back onto that trail of thoughts. For me it's mostly noticeable when I'm working on a very challenging task that requires a lot of original thought that needs original architecture and patterns in order for all the pieces to fall into place.
Sometimes you can settle for at least using readable variable names in some horrific code so it is readable and faster to go through by the next person. Or simplify awkward if else structures and just comment the gotchas and unobvious code bits.
Why are you using non readable variable names?
@@dandogamerright? Could be Matlab dev
I was on a team that managed a piece of our backend that handled translation with some external endpoints that required PCI and iso compliance. They practiced scrum, TDD, and clean code. All the things devs hate. They were the most efficient team I’ve ever had the pleasure of being on. Extremely clean, easy to read code, scrum calls that were short and direct, and responsive. They had a clean workflow with QA, and a release/versioning process that all but managed itself. All of them were plucked by other companies, including the original lead that set the whole system up(I soon left after that). Anywho, it’s proof that good programmers that work well together can make quality code, even if they’re using systems that are generally considered slow, backwards, or a general hindrance to programming. One of the things the lead att stressed were effective code reviews.
From my experience, a team with a good spirit, trust, and clear communication can make any methodology work :)
Iregulary forget things, but I'll suddenly remember it all again if I'm stumbling into the context again
I feel like the thing at @13:00 -ish someone had to be misunderstanding what was meant by "a distraction".
Like is a distraction someone coming up to you and asking you a question you can answer instantly or for help that takes 2 minutes? Or is it a new problem pops up in the form of a task someone has for you that is going to take a solid thirty+ minutes of effort to solve?
If it's the former, I'm with prime, it's not hard. If it's the latter and the task you were distracted from is complex then I can see it taking 15 minutes to get back into a flow.
But not every time, it sounds like that guy was saying it happens all the time with any distraction, which doesn't make any sense.
"some saturday afternoon database change".. THROAT CHOP!
The problem with "what you lack is maturity" is that maturity, like experience, is not a thing you can consciously obtain, it comes with time as you go through hardship
Good talk on addiction and saying "no" on this one, Prime. Comments on freedom are super true.
"Goldfish-driven development" is the funniest thing I've heard all week
9:00 his whole point is just something you said earlier in the video, which is that no amount of planning will tell you what you're going to run into when you actually start writing the thing
9:50 the point isnt that you already spent 1-2 hours on it, the idea is that every 25 minutes for those first 2 hours you're being interrupted for 5-15 minutes. then you have 3 meetings with 30 min downtime in between each meeting and now it's already the end of the day