Or I am just the type that would mess up an equation and spend the next 3 hours trying to figure out why something is rendered upside down or worse, with just subtly incorrect lighting and colors.
Anything math-y that doesn't fail loudly requires a different type of debugging skill that the typical programmer doesn't have.
I mean 5 hours is pretty much a days work realistically so if you look at it that way it seems pretty reasonable to me. Project 1 is basically a "you'll take a day to do this" project 3 is basically a week's work, etc.
If it comes with some instructions and hints it would line up with my estimates pretty closely, that said I've done a bit of this sort of work before so I might have less unknown unknowns in my estimate.
Yes, me too. Although I'd hypothesize you would like to explore tangential parts of the lessons rather than heads down follow without mental digestion.
"Time estimates are in person hours based on averages from 140 college students. Projects longer than 6 hours could be done by pairs or small teams, or by an individual over multiple weeks. Some projects also must be run for significant unattended time to produce results."
I’ve been recommended the book “The Raytracer Challange” [0] which let’s you implement a raytracer in the language of your choice by only giving you the expected results and test cases in a TDD fashion. Super creative way of learning!
I approached this wondering if it would be somewhat like 'Make a Lisp' or similar [0], that as a competent programmer you could start within minutes of starting to read the instructions.
It doesn't seem like that. I think this is because
* it has comprehensive background for newbies (e.g. the idea of setting breakpoints in a debugger)
* it is the accompaniment for a separate book
* it has some serious background assumptions (e.g. you know calculus)
* graphics programming is much, much harder than making a lisp.
Or I am just the type that would mess up an equation and spend the next 3 hours trying to figure out why something is rendered upside down or worse, with just subtly incorrect lighting and colors.
Anything math-y that doesn't fail loudly requires a different type of debugging skill that the typical programmer doesn't have.