EVERYTHING takes longer than it seems
ฝัง
- เผยแพร่เมื่อ 10 มี.ค. 2024
- get.hazelengine.com
Live ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
Video Editor application ► forms.gle/x41NvMciExurK4939
Hazel ► hazelengine.com
🕹️ Play our latest game FREE (made in Hazel!) ► studiocherno.itch.io/dichotomy
🌏 Need web hosting? ► hostinger.com/cherno
💰 Links to stuff I use:
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK
Let me know what you think of this dev log format with the edited streams! ❤
Feels like a long story arc of this channel has been about getting a balance between coding and vlogging. I think it's pretty well done this way.
I'd watch them daily.
I like it!
Keep posting this stuff and enjoy not having to edit!
these would work better if you focus on more interesting topics.
the usual procedure in the industry is, you take your estimate of what you think how long its gonna take, and add ten percent of leeway to that. then you double that value.
Or estimate with the fibonacci numbers: if you think it will take 3 days -> plan for 5, if you think it takes 5 days -> plan for 8 etc...
I switched from a developer position to a user of what I used to develop.
When we had to outsource work I told my new colleagues I'd count on twice the time they proposed to do it in.
In the end they took about 180% of the time so I was slightly pessimistic. My ne2 colleagues now taoe me serious and ask me to estimate times a dev project will take.
@@00wheelie00 being in a management position, this only gets harder, as you now have to estimate how long $otherPerson is going to take to complete the task.
Only double? We teach our devs to triple it XD
I multiply with pi xD
It's ironic, when you are motivated to do something, learn something, then it feels like it takes forever to get anywhere; but at the same time life passes by so quickly.
When solo developing you need to treat your future selves as other team members.
oh nice way of thinking!
I often find it's as difficult to communicate with my future self as it is to communicate with a current teammate.
@@jasonthorpe3470 just screw over ur future self and write sucky code that works
"Time just passes, like time has this thing that it does where it just continues, like you cant stop it, you cant stop the train of time"- Yan Chernikov
Been loving the devlogs format, keep it up 💪🏼
Thank you for keeping up for so long with this youtube channel, especially with all the things going on, editing, ea and so on. I feel so motivated to push forward every time I watch your videos and see how dedicated you are. Your let's make a game in java series and the whole youtube journey are probably one of the sole reasons I became a programmer which led my life into an industry that I love. Good luck with this years schedule and keep up the good work!
Thank you Cherno for sharing all sides that it takes do develop a game engine. Really interesting for me. Love your content since the start of my computer science studies
Wow, true I noticed the same thing.
I personally like these kind of mixed devlogs
Its amazing we want to see more dev logs
I was dying laughing at the thumbnail anecdote, it's so relatable and I appreciate the openness in admitting this. I'll have the balls to do engine development myself soon and it's partially thanks to you
It would be great to have a video dedicated to visual studio useful shortcuts and navigation through the program in general. Been watching your videos and you do a lot of stuff that I dont even know how to do that fast (selecting things, navigating to different code files, etc...). Hope to have some compilation of all the shortcuts you use.
Exactly the same conclusions I arrived at (the project development goes for 3rd year now). You WILL forget how things work, so write documentation for public API, but also write internal documentation for when you need to return. Some people say "code should speak for itself". Mhm, let's agree to disagree. Code can be very complex, design decisions could take many factors into account, often subtle. Comments complement complex code nicely. I wrote a GPU memory allocator in the first year. I thank myself I heavily commented it, each time I go back to it (luckily not often :D ). And of course, when you work in a team, on a big project, other people will require that sweet documentation to keep the ship sailing smoothly.
Thorough docs/comments are so nice to have even in simpler projects sometimes I'm just tired and need it spelled out to me.
Also: if you add automatic tests then they are also kinda documentation. Especially if they test specific scenarios / stories (BDD) - or when they tests public API (for given input assert certain output etc). The more such tests you have the less documentation you need IMO.
In my experience with developing web apps, backend systems, and a game engine, I have come to a realization that, this issue is exclusive to game engines (or other low level system development).
When planning web, mobile apps or backend apis, estimations are typically very close to reality. While estimating anything in a game engine, I am always either overestimating or underestimating.
I think game engine's problem space is so large and broad that, building assumption and intuition within this space is really hard and requires massive amount of experience in low level system design.
Yeah, I think in general what allows good estimates is familiarity. Basically if you're mostly doing something very similar to something else you've done, or repeating a process, that you can estimate. But if you're doing something new, then good luck.
Really fun to get the streams recapped like this!
Looking forward to more (correctly oriented) thumbnails in the future lol
A quote I like to keep handy when it feels like progress is imperceptible:
"The years teach much which the days never know."
- Ralph Waldo Emerson
19:20 perfect example of code that lacks a comment explaining "why". Any time you have such hardcoded values it's a good idea to explain why they were used. I mean you did mention it in the intro of the video, I just wanted to point to a good example.
At 12:00 your answer is coroutine support. After you get the boiler plate out of the way and create some kind of async callback manager on the main thread, it could be as simple as checking a predicate and continuing the coroutine.
Well known phenomenon in psychology. A popular thing to do to show this off is to give students a simple task, let them make a time estimate and then have them be surprised by them taking way longer than they thought.
"Good code is self documenting" is a saying that only applies to general applications.
If you program an engine or other high performance application where you are trying to maximize the performance of the product, this goes flying out the window.
The infamous inverse square root is always a great example. Some super low level bit hackery that ended up being an extremely good as an approximation and flipping fast at that.
That code is the opposite of self-documenting, but it is still great code (if you ignore the undefined behavior of what is essentially a reinterpret_cast from int to float).
Some documentation within the code will always be required just by the nature of some functions and concepts in these fast applications being extremely low level optimizations.
"I am the problem not the code" --- The Cherno
this is like the next level of "it's the users fault"
Nailed it!!!
I've learnt that taking your estimate, multiplying it with PI will give you a surprisingly accurate estimate
It's more like pi times the estimate squared for me... :(
@@Christian___ so you work in squared time? Must be trippy
Good documentation is something that nobody wants to write, and every body loves to have.
Also, for time estimates, my boss from an internship from a few years ago would always ask us: "how much do you think it'll take you?"
and without exceptions, if you said like 3 days he would just tell you to take 5 days for it
Visual stuff like this is always what I dread debugging. Rarely does the debugger help you with that and then you need to put extra time into creating complex debugging visualisation tools just for you to realize you failed to name things and messed up cache invalidation all at the same time
"Time have this thing that it does where it just continues"
--- The Cherno
I love how a clear plan ends up with a completely wacky bug of random images showing upside-down.
The life of a software developer is so weird sometimes
This video style may not have the same viewer retention as some of the fluff that other people post about programming, but I love it. I think you've built the type of audience that will enjoy this form of content.
One of my managers convinced me to write down how long I think a task will take before diving in, and then write down how long it took afterwords (not for reporting, just for myself). Im not convinced it save me time going down required rabbit holes, but does help me identify the unnecessary ones and not dive in (even though my neurotic perfectionist self really really wants to...)
please continue stream highlights like this
In the industry, estimation is a dark art. Product management teams muddy this up even more as well usually by bringing in different forms of estimations.
-Mr. Scott, have you always multiplied your repair estimates by a factor of four?
-Certainly, sir. How else could I maintain my reputation as a miracle worker?
Likeing it so far
I like the style of the video
This taking longer than it seems. This is true, because "It is what it is", but here is what they don't tell you about the rest of this thought, it is what it is, "But Things are not what they seem". Yo great speech bro. Bravooo...
Very good video. I enjoyed it!
Ironically I'm developing a game with a mechanic in which you can control the time , but same as you I struggle focus and finish things by the deadline
re: code comments
We all encounter this philosophy of avoiding putting comments in code quite frequently. It's a very vehemently expressed, strongly held view. It's so frequently and vehemently expressed that the victim of this verbal bludgeon is in danger of being gas-lit into believing this is the prevailing consensus among all developers! Or at least all "good" developers.
This faddish "self documenting code" notion puts me in mind of that cartoon in which Sheldon from "Big Bang Theory" is reading code. "Why..?" he says. Then in the next frame "Why..!?" Then in the next "W H Y ! ? ? " and then finally "oh, that's why."
See, this is funny, isn't it? Yes it is! Because you have experienced this! And probably recently! Don't lie to me! I know you have. I don't care how good you are at writing "self documenting code," that is absolutely what will happen if you don't put comments in and keep them up to date! Only the "oh, that's why" part will come after hours or days or weeks of going down a wrong path! Ugh! Just shoot me instead.
Please don't be gas-lit by the fadsters. It has been, is, and ever will be (as long as humans are writing code, and probably even when AI is doing it) an obvious, self-evident reality that one important measure of code quality is how helpful, brief, readily understood, up to date and discriminating (between what's necessary and what isn't) the comments are.
thanks for making some competition, after unity shit the bed, godot became the only competitor for C# IMO and i have a slew of issues with it, especially in 3D
Watching this made me feel a little better about myself as a software engineer 😂
Bro! "Time just passes" :DDD so wise! Made my day, thanks xD
Hey cherno Do you knoe rust and if you do can you make the playlist for it???
Nothing have to be perfect at beginning(even if everything else is already somewhat perfect), it will be perfect as time goes... I won't spend time trying implement something "perfectly", because then i would end up spending a lot of time making a mess..
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
This is most often a result of you not having complete knowledge of what you are working on. Bugs and issues will be encountered and you will need to try multiple things usually through trial and error until you get something functional.
When it's something I have complete knowledge over, I can predict often down to the minute how long it will take. This is typically the result of familiarity and experience doing the same thing over and over again.
you started developing a vocalfry like a starbucks barista lmao
I take whatever time I optimistically think it will take, and multiply by 6.
A man who became a great engineer at his 20s said!
Estimation accuracy comes with experience
That's Hofstadter's law, look it up.
True
Bro the video was just uploaded few seconds ago, how tf you agreed to the entire video lmfaooo
My late uncle wrote a book on software estimation(it's the Stutzke book, if you are wondering). All his work was in defense contracting, mostly in Ada, and they had all kinds of formal models to try to tame the issue. He really tried for a comprehensive survey of the field and took so long on it that he only finished once he developed terminal cancer, which was grim at the time but feels darkly humorous now 😂
My practice now for personal projects is to not really estimate, but to assume that I'm just continually studying my code. I will periodically copy it by hand into a subject journal, mark it up in different colors, then turn that into revisions. This eventually converges on "write something that generates code" because the process of copying manually and marking up creates a shorthand syntax. Fortunately my compiler writing skills are up to doing that, and there's no team holding me back.
The `mipWidth * mipHeight * sizeof(float) * 4 * 6` seems like it would calculate the data size for the six faces of a 32-bit HDR RGBA cube map.
Very true
What font and font color that you're using for your source code? (how you do those italic words... )
The only true software development estimate is after completing the task the first time, how long it would take to immediately do it again a second time?
TheCherno:"Everything takes longer than it seems"
Me: *Checks to see how long this video is assuming it will be like 3-10 minutes long, then finding out its 22 minutes long.
I see what you did there :)
Relatable. :)
Think of a time and multiples by 3
In my first week as a new Developer, after a new project kick off meeting where I'd thrown in a couple of rough time estimates for certain parts of the code, the main business analyst came to me privately and simply asked if I was "a x2 developer, or a x3 developer", which just made me realise her experience till then was of devs wildly underestimating. From that day I've always multiplied my inital guesses by 2.5, and pretty much usually deliver well on time. I guess that measn I'm a x2 😆
I am kind of a new guy here. Can someone tell me, please, what is the reason Cherno creates the Hazel engine? To educate himself more, to make a great project because he loves it, or to create competitor to existing engines?
I usually multiply the estimate by pi.
Hi brother, I wanted to ask a very simple question. How much C++ should I know to get a job with C++, I have gone through your playlist of learning C++ and learned many concepts, but I have not completed the whole playlist yet. So can I start your opengl series? Please reply.
Thanks in advance. 😅
0:13 13 seconds in the video and already agree.
re: what if the file is locked - While it remains locked, sleep a bit, up to some total time limit, then if it's still locked, throw or at least log an an informative error. There's no pause if the file isn't locked. But ideally anything waiting on files or any other kind of io should be async, right?
Best advice for time estimates, don't...
My SO just read your name as "The Chemo" as in chemo therapy. I don't know why but I fond that so funny
10:15 Create a File Handle
Speaking from the experience: better double it! 😅
You can hope that estimation is right, but you can't rely on that.
And then paint is updated to have layers so you cant work the way you used to work. So many things...
Like the new format.
PS: Your audio is out of sync by about 100ms.
As you get older for whatever reason coding becomes dreaded. Like idk bro. It's like sometimes I rather gouge out my eyes or something. Lmaooo. I can't describe the feeling. Lol.
I found it very weird the first time I started to get into project management that other more senior managers would just essentially made everything 1.5x times whatever the developer said it would take, now having seen the wisdom of that I think it is sometimes conservative.
and that's after the developer doubled their estimate
wait until you hear about black hole event horizons :D
Sir, as someone who loves ue5 and p4. This seems like it wouldn’t be the easiest to work with, if files are locked by p4
Programming in a nutshell: This video title.
You where behind The Lapsis Minecraft Series, Right?
I think this new idea is so great also to keep us in touch with you more.
Video only looked like 20 minutes, but then it took an hour and a half.
Should've taken the youtube playback speed off of 0.25x
What you actually develope in C++?
Hi cherno
This wat you get for being stuck in the matrix
Why store integers as binary? What if the target platform is a big endian machine? Or maybe it uses 4 bytes time stamps?! That's not a portable design at all!!
You let others work on Hazel as well? (Software engineer here would be cool to contribute)
The time to kick the as s of both Unity and Godot is now, Cherno. Unity is phasing out because it's not trusted by developers and Godot is just not as good as Unity in terms of 3D performance, in particular. Now it's time for Hazel to shine as "the new Unity".
time dilation!
Commenting LOL sums up my dev experience
This is the kinda stuff imposter syndrome is made off...
THE point that seniors in any company fail to understand. When coding bugs and development always takes time, or we release in a state and take the flak.
Planning fallacy
When I hear people say code comments are stupid, I think that those people either don't build software, or the software they build has no advanced features....or they themselves are stupid.
Class, function and variable names brings you quite far. At my job we have 4 million lines of code in c++ and some comments are from 1996 but the associated function is already changed by 10 devs in the meantime, so it's dangerous to trust the often non updated comments.
A cup of coffee and a cigarette, type one line of code for a day.
starting and stopping is the same thing. dont count drop time. 40 days trial time is a long time. interestingly windows does that for the file explorer folders for both jpg/png images and obj models. its a cashe thing. wasted work is work in vain. whole meat not even code management. you are your own worst problem. literally. what you think is best is not the best. trust me bro ;) even more work. more tools.
well hair is only a long thin cube triangle spline in 3d. a simple forest scene with landscape, environment map and copy trees, maybe a river, maybe with some animating elements, both texture and mesh animations. Some stones, maybe photo-realistic sample scene. better than unreal engine open world default scene.
of course you can do a point light with a cube map, similar to a projected spot light, with normal raster or ray traced raster
I believe we need to fundamentally change how we go about programming, there's just only so much we humans can remember, and hundreds upon hundreds of files full of code is just too much to build open over and over again. Our IDEs help us with intellisense, and syntax checking, etc, but they are still just a "level" above using notepad. There's got to be an evolution of tools. Perhaps a programming environment with AI at its core, an ai which not only understands the 3rd party libraries and system you work in, but also understands your code/engine as you create it. And AI which doesn't forget what functions do, or the gotchas, etc.
Maybe AI isn't the answer, but something has to change. We can't just keep building systems on systems and code on code and think we're going to move forward at the same pace.
Or you know, we could make things simpler, so we don't need to remember so much code; though personally I don't have any problem remember exactly what a few thousands line of code does, and which bugs, just not who made it, that's what git blame is for
How about thousands of hundreds?@@RasmusFrederiksen169
My approach is to design the whole programme before I start coding, do a full draught of the programme in pseudo-code, then use that as an instruction manual for the coding. Is that weird?
@@Christian___I don't think so, I guess it depends on the size and complexity of your program. I would think creating game engine would be such a long road, full of so many unknowns, that it would be hard to plan it all out beforehand.
@@Christian___ to add, it also depends on how well you already know the problem domain and the underlying tech used. A lot of the time you simply don't know what you don't know.
re: double it.
HAHAhaa! Sorry, but it's not double, I'm afraid. You're not there yet. It's more like pentuple. Hehe. No, but seriously, when they come to me with something that seems hours long, I start with weeks, and then pressure myself down to days. Because there is not just coding! There is clarifying requirements, researching, coding, testing, debugging (including profiling when there are performance issues), refactoring as a result of debugging (including optimization when necessary), testing and debugging as a result of that refactoring, refactoring other things that rise to the surface that absolutely must be refactored immediately or there will be terrible pain very soon, and testing and debugging that refactoring, and documenting and maintaining all that. All while other things also require attention. Yes. You see? Pentuple. (Listen to the voice of experience, my friend! ;)
"But it's not even worth doing if we have to pentuple!" Sshh! Don't speak the quiet part aloud! This is true of all of life. None of it is worth it. Yet we do it anyway, don't we? We lie to ourselves about how much pain and suffering is involved so that we'll go through that pain and suffering. Because.. actually it is worth it. Not necessarily because of the direct and obvious product, although hopefully that is certainly worth something. But what really makes it all worth it is more like.. all the side effects.
I cannot agree more: everything takes longer than you expect, even after you adjust your estimates.
hope U can produce shorter vedio,because I don't have enough time
Do not reinvent the wheel
first
FUCK
FIRST (i was second)