I think I've learned a technique related to this issue, or at least sort of related. When you decompose, or destructure a problem, when trying to solve it, go for brute force. Go for naive. Go for stupid even. Often you find yourself going "I have never done this before, how am I supposed to know what to do." - so mentally, you want to minimize how "big" the problem appears to be (without being nonchalant or dismissive about it). When you do, you will eventually find better solutions, because once you get something working, you now have built a frame of reference to which you can compare ideas to. And particularly for me, this frame of reference is incredibly important. "You" are not Einstein and you don't need to be either. You can be you, because you are good enough; with this mindset I've found it easier to actually become the "better self". On a side note and tangientially related to what I've written; The online void is filled with more or less self proclaimed geniuses and they aren't geniuses. Some of them are really talented. Most of them are trash people. Granted some of them have amazing experience and expertise, but that is not everything. Its why I profoundly like this channel (no, I'm not biased because I'm Swedish), there is a lot of empathy here, something which is *entirely* lacking from most of the online void, related to software development. And when we die, we don't get to bring our computers with us to program for eternity, all that matters is what life we lived and how we treated people. Mega tangent, but I just had to say that.
Thank you for sharing that. I'm always very impressed by your effectiveness and confidence when tackling these hard problems. As someone who struggles with procrastination and "just getting things done", it is encouraging to hear that you also had similar problems in the past. I really draw a lot of inspiration from your videos and will try to apply your divide-and-conquer approach to my job (which is not programming related). So thank you for that and enjoy your oatmeal :)
When I was a machinist, another "mentor" machinist was showing me the blueprints to a part that he made for a really precise microscope. The dimensional tolerances specified on this blueprint were just incredible to me. He told me when he first got the job he looked at the print and about had a heart attack. After a cup of coffee, he started breaking it down into the most basic steps. First he got some metal, next he squared the metal up, then he cut a side, and so on. Eventually he had a finished part and the customer was happy. This process of breaking hard problems down into easy ones is the way to get stuff done. Your videos definitely show that in action.
It's great to see all the people telling their little life stories under many of your Car talk videos. I appreciate you for making such a great cyberspace for discussing many relatable topics, and everyone that shares their honest thoughts. It's a nice reminder that Internet is not as dead as it seems sometimes.
As a manager its a nice reminder to not take that process for granted. This is exactly what I do for a large amount of my time. Sometimes its frustrating, but all it takes is that otherwise talented employee 'getting it' and slowly starting to break hard jobs down for themselves.
What I love about your videos is I know zero about OS development, but the sheer heart and sincerity with which you tell your story somehow "humanizes" the technology, making it more than just code.
I’ve faced the exact problem (being remote, trouble with large tasks) last summer when I was interning there remotely. Other engineers seemed to know exactly how to tackle problems and the onboarding and codebase left me completely lost. Glad to know how you got through it and really appreciate you sharing your wisdom here. I’m going to be starting in the summer at Apple so will surely be trying to practicing this :)
I think we break down problem naturally before we start working on it, the trick is to keep this strategy organized, to put it on paper, to define it, to pull it out from vague-conciounse. Loved the video BTW, thank you!
I can see how relaxing it would be to share your experienceike this 👍🏻, every time I watch these videos 1. Obviously I learn something new 2. I also want to share my experiences/feelings/thoughts
Thank you so much for sharing. This is extremely helpful to hear right now Your videos have been extremely helpful to me, when you first started working on the JavaScript interpreter something finally clicked inside of me in that "oh this isn't so bad" & I've now been working on my own language for ~5 semi-consistent months now & still excited about it! Which is completely new to me, I normally can't even last a few days on a project before getting overwhelmed & giving up. I'm still getting stuck a lot, but I'm coming back & this is exactly what I needed to hear right now
2 ปีที่แล้ว
Thanks for sharing this! This will be so helpful in my day to day life!
Good stuff and keep it up. And for anyone struggling it doesn't have to be a fight everyday just to accomplish something. Why not make it into a game and if that doesn't work you were meant to do something else.
Thanks a lot for sharing this. I am trying to get into OS programming and feels like the process you mentioned of chopping up complex tasks will work for me and make my learning process easy.
Thank you for this video. :) I recently joined an internship in a field which I have been interested in, but had little experience in since I'm just a 1st year CS student. I have been feeling like the tasks that get allotted to me seems very vague. It wasnt necessarily vague, just that the end product was not clearly defined, so I had a little trouble working with that, and I felt afraid of asking too many questions as to not annoy my mentor. Now I understand that the objectives of those tasks was that they wanted to see my ability to break down the problem into pieces, so that was why they did not care much about the final results themselves.
2 ปีที่แล้ว
Every developer have probably been in that situation, in projects with dead-lines. The main thing, don't stress out to much. And management by chopping it up into small part projects is good. Even in life management, having small to-do to mark off when done is satisfactory and keeps you going.
That’s right. Take time to absorb the enormity of the problem. Figure out various starting points. Build the simplest thing that you can get working. Then, the magic is that the solution to the smaller thing turns into a “platform” to “bounce off” into further progress. Also, just the act of doing the programming gives you knowledge about the domain; hence the famous “build one version to throw away”. Another experienced programmer told me something that bears repeating: premature optimization is the root of all evil. Decomposition. It’s the name of the game for us!
This is a such a basic approach to any kind of more complex work that is shame it's not more taught on elementary schools. It's part of many tasks, but sometimes is good to name it. For example in cooking anybody knows, that you need doing things in smaller steps, so for me it seems fairly clear that this approach is applicable in many jobs.
For me, whenever i'm feeling this way... well to be honest, my most common action first is to procrastinate and panic--even to this day--let's be real, but when I'm a little more fit to the task, I always think of merge sort. You just break down a problem to trivial parts and build it back up. I still remember learning merge sort what is now ages ago and being amazed. To a first time listener, it's just 'okay, so you have some individual thing with 1000 items, and now you have 1000 things with a single item... how does this help?", but it does.
When I was struggling with finishing my degree, I went to a time management seminar offered by my uni's psychological counselling service. There, I learned something similar to this divide-and-conquer approach you describe: We sat down and talked about creating a to-do list for preparing for some upcoming exam and filled it with the usual vague and opaque tasks: "Repeat all the exercises"; "Read the notes", etc. Then the simple, yet mind-blowing question was posed by the tutor: "How sure are you, in percent, that you can get task X done within a day?" "Well", I answered, "somewhere around 30%-40%." "Ok, that's good. How much would you have to reduce the task so that you are a *100%* sure you get it done in a day?" "100%? Then instead of 'repeat all the exercises' it should say 'repeat part a) of the first exercise'. But that's way too little!" "No, it's not. The amount you can absolutely, with 100% certainty, get done in a day, is exactly the right amount you should put on the to-do list" I don't know why, but that simple 'trick' showed me how I set myself these monolithic, daunting tasks instead of breaking them down into manageable pieces and really changed my thinking about project planning in a profound way!
Thank you!! This is the first video of yours I've seen. You're difficulty in sharing it shows and I'm not sure I would have had your strength to share it myself. I found it very helpful and although I may have known what you said in the back of my mind, it will be much easier for me to practice now that you have put this knowledge in the front of my mind. Thanks again!
I should show this video to my boss, maybe her boss too ... They have no clue about how to run the IT department... problems are solved from top to bottom which rarely work out
I think I've learned a technique related to this issue, or at least sort of related. When you decompose, or destructure a problem, when trying to solve it, go for brute force. Go for naive. Go for stupid even. Often you find yourself going "I have never done this before, how am I supposed to know what to do." - so mentally, you want to minimize how "big" the problem appears to be (without being nonchalant or dismissive about it). When you do, you will eventually find better solutions, because once you get something working, you now have built a frame of reference to which you can compare ideas to. And particularly for me, this frame of reference is incredibly important. "You" are not Einstein and you don't need to be either. You can be you, because you are good enough; with this mindset I've found it easier to actually become the "better self".
On a side note and tangientially related to what I've written; The online void is filled with more or less self proclaimed geniuses and they aren't geniuses. Some of them are really talented. Most of them are trash people. Granted some of them have amazing experience and expertise, but that is not everything. Its why I profoundly like this channel (no, I'm not biased because I'm Swedish), there is a lot of empathy here, something which is *entirely* lacking from most of the online void, related to software development. And when we die, we don't get to bring our computers with us to program for eternity, all that matters is what life we lived and how we treated people. Mega tangent, but I just had to say that.
Thank you for sharing that. I'm always very impressed by your effectiveness and confidence when tackling these hard problems. As someone who struggles with procrastination and "just getting things done", it is encouraging to hear that you also had similar problems in the past. I really draw a lot of inspiration from your videos and will try to apply your divide-and-conquer approach to my job (which is not programming related). So thank you for that and enjoy your oatmeal :)
Thanks for making this, its really encouraging that you're open about this and sharing your experience 🙏
When I was a machinist, another "mentor" machinist was showing me the blueprints to a part that he made for a really precise microscope. The dimensional tolerances specified on this blueprint were just incredible to me. He told me when he first got the job he looked at the print and about had a heart attack. After a cup of coffee, he started breaking it down into the most basic steps. First he got some metal, next he squared the metal up, then he cut a side, and so on. Eventually he had a finished part and the customer was happy. This process of breaking hard problems down into easy ones is the way to get stuff done. Your videos definitely show that in action.
It's great to see all the people telling their little life stories under many of your Car talk videos. I appreciate you for making such a great cyberspace for discussing many relatable topics, and everyone that shares their honest thoughts. It's a nice reminder that Internet is not as dead as it seems sometimes.
As a manager its a nice reminder to not take that process for granted. This is exactly what I do for a large amount of my time. Sometimes its frustrating, but all it takes is that otherwise talented employee 'getting it' and slowly starting to break hard jobs down for themselves.
kudos to your honesty. role model for me. stay well, andreas.
This is great piece of advice that needs to be often reminded, or at least I need to be reminded of often.
Thank you, needed that!
What I love about your videos is I know zero about OS development, but the sheer heart and sincerity with which you tell your story somehow "humanizes" the technology, making it more than just code.
I’ve faced the exact problem (being remote, trouble with large tasks) last summer when I was interning there remotely. Other engineers seemed to know exactly how to tackle problems and the onboarding and codebase left me completely lost. Glad to know how you got through it and really appreciate you sharing your wisdom here. I’m going to be starting in the summer at Apple so will surely be trying to practicing this :)
Great call out about breaking up larger tasks, thanks!!
Andreas, thank you! Literally after listening your advice I resolved an issue I was stuck with for several days!
I think we break down problem naturally before we start working on it, the trick is to keep this strategy organized, to put it on paper, to define it, to pull it out from vague-conciounse.
Loved the video BTW, thank you!
always great videos, love coming back to see what's new. keep it up (to the amazing people who work on serenity also)
I can see how relaxing it would be to share your experienceike this 👍🏻, every time I watch these videos 1. Obviously I learn something new 2. I also want to share my experiences/feelings/thoughts
Thank you so much for sharing. This is extremely helpful to hear right now
Your videos have been extremely helpful to me, when you first started working on the JavaScript interpreter something finally clicked inside of me in that "oh this isn't so bad" & I've now been working on my own language for ~5 semi-consistent months now & still excited about it! Which is completely new to me, I normally can't even last a few days on a project before getting overwhelmed & giving up. I'm still getting stuck a lot, but I'm coming back & this is exactly what I needed to hear right now
Thanks for sharing this! This will be so helpful in my day to day life!
nobody teach you how to teach. that's something you have to figure out by your self. good car talk! thanks!
Good talk. These conversations are needed from time to time. Keep it up man.
Good stuff and keep it up. And for anyone struggling it doesn't have to be a fight everyday just to accomplish something. Why not make it into a game and if that doesn't work you were meant to do something else.
Thanks a lot for sharing this. I am trying to get into OS programming and feels like the process you mentioned of chopping up complex tasks will work for me and make my learning process easy.
Thank you for this video. :)
I recently joined an internship in a field which I have been interested in, but had little experience in since I'm just a 1st year CS student.
I have been feeling like the tasks that get allotted to me seems very vague. It wasnt necessarily vague, just that the end product was not clearly defined, so I had a little trouble working with that, and I felt afraid of asking too many questions as to not annoy my mentor. Now I understand that the objectives of those tasks was that they wanted to see my ability to break down the problem into pieces, so that was why they did not care much about the final results themselves.
Every developer have probably been in that situation, in projects with dead-lines. The main thing, don't stress out to much. And management by chopping it up into small part projects is good. Even in life management, having small to-do to mark off when done is satisfactory and keeps you going.
Thanks Andreas. Happy new year
That’s right. Take time to absorb the enormity of the problem. Figure out various starting points. Build the simplest thing that you can get working. Then, the magic is that the solution to the smaller thing turns into a “platform” to “bounce off” into further progress. Also, just the act of doing the programming gives you knowledge about the domain; hence the famous “build one version to throw away”. Another experienced programmer told me something that bears repeating: premature optimization is the root of all evil.
Decomposition. It’s the name of the game for us!
This is a such a basic approach to any kind of more complex work that is shame it's not more taught on elementary schools. It's part of many tasks, but sometimes is good to name it. For example in cooking anybody knows, that you need doing things in smaller steps, so for me it seems fairly clear that this approach is applicable in many jobs.
Thanks for inspiration!
CAR TALK! AMAZING.
Thank you for sharing your experience 💪👏
For me, whenever i'm feeling this way... well to be honest, my most common action first is to procrastinate and panic--even to this day--let's be real, but when I'm a little more fit to the task, I always think of merge sort.
You just break down a problem to trivial parts and build it back up. I still remember learning merge sort what is now ages ago and being amazed. To a first time listener, it's just 'okay, so you have some individual thing with 1000 items, and now you have 1000 things with a single item... how does this help?", but it does.
When I was struggling with finishing my degree, I went to a time management seminar offered by my uni's psychological counselling service. There, I learned something similar to this divide-and-conquer approach you describe:
We sat down and talked about creating a to-do list for preparing for some upcoming exam and filled it with the usual vague and opaque tasks: "Repeat all the exercises"; "Read the notes", etc.
Then the simple, yet mind-blowing question was posed by the tutor: "How sure are you, in percent, that you can get task X done within a day?"
"Well", I answered, "somewhere around 30%-40%."
"Ok, that's good. How much would you have to reduce the task so that you are a *100%* sure you get it done in a day?"
"100%? Then instead of 'repeat all the exercises' it should say 'repeat part a) of the first exercise'. But that's way too little!"
"No, it's not. The amount you can absolutely, with 100% certainty, get done in a day, is exactly the right amount you should put on the to-do list"
I don't know why, but that simple 'trick' showed me how I set myself these monolithic, daunting tasks instead of breaking them down into manageable pieces and really changed my thinking about project planning in a profound way!
Thank you!! This is the first video of yours I've seen. You're difficulty in sharing it shows and I'm not sure I would have had your strength to share it myself. I found it very helpful and although I may have known what you said in the back of my mind, it will be much easier for me to practice now that you have put this knowledge in the front of my mind. Thanks again!
Is anyone else looking at the window thinking that it looks like someone with sunglasses sleeping?
I should show this video to my boss, maybe her boss too ... They have no clue about how to run the IT department... problems are solved from top to bottom which rarely work out
Thank you for sharing this.
thank you for posting this
Thanks a lot sir!
Thanks for sharing!
5:56 a technique called ???
Having a hard time making out what you said, but I'm curious to look into it 😅
“…technique all the time…”, I don’t know a specific name for it (but thankfully it’s very simple) :^)
@@awesomekling problem decomposition?
@@dsds-rj9rg Sure, that works!
ayy, the car talk is back again!
i see, so break problem to small one is a real deal.
"belated humiliation", its all relative (so to speak) - there was a lesson there, and you finally shared it, so "thanks for sharing"
Låter på ett grovt ungefär som jag försöker lära ut programmering i min skola.