This was an excellent read. Thank you for sharing the articles.
631 karma · joined December 22, 2020
My first mistake was underestimating how much math one needs to know. Spoiler: it's all math - mostly linear algebra. That's why any graphics / physics / gamedev book has at least one math chapter. You do need it for everything - from coloring something to making things move on the screen.
My second mistake was not making games. One would think that it would be an obvious thing to do, but it's so easy to underestimate the amount of time it takes to understand graphics programming (in retrospect, just the size and weight of the "Computer Graphics - Principles and Practice" book should have been a gigantic red flag). I ended up writing game engine code instead of game code. Being able to draw triangles on the screen is just not as satisfying for me as making cars chase each other and it also doesn't move the needle on getting a game out the door. In practice this translates to maybe reading "Programming Game AI" instead of "Real-Time Rendering" (given limited spare hours) or actually finishing "Nature of Code" instead of reading "Game Engine Architecture".
Arguably my biggest mistake was being stubborn, but not stubborn enough to persevere through all the crap. Early on I didn't want to use an engine because I generally like to understand things from first principles and I didn't understand how deep the rabbit hole went. It turns out that the first principles in game graphics are closer to a collection of progressively more horrible hacks on how to achieve realism in real time without ray tracing, because that's too slow, and how to patch all the side effects of that reality (don't drop a book on implementing shadows on your feet). People with PhDs describe these techniques in scientific looking papers, which then get discussed at large conferences, referenced in books, etc and normalized. Want to learn a new technique? Read the (dense) paper. Other people decide then to take the best hacks, accelerate them in hardware and expose them as APIs. Decades of optimizations and hacks built on top of each other pushed the entry bar higher and higher, to the point where the amount of complexity one needs to wrap their head around is just not realistic for a beginner, unless they are stubborn enough and diligent enough to persevere through all of it. I should have paid that $100 to use the Torque engine, instead of buying the OpenGL Reference Manual, OpenGL Superbible and the OpenGL Shading Manual.
Lastly I fell into the trap of buying the books, but not working on games, aka "all the gear but no f*cking idea". My shelf is filled with highly regarded books that I read and some I gave up on (because they were over my head). I released 0 games. That said it's a good way to discover gems like "The Ray Tracing Challenge" book. Learning new things is fun and addictive.
I came to the realization that I would have really benefited from having a mentor, a well defined and structured curriculum, and being a bit more humble about my own ability to jump into this field, but, most importantly, I should have just made games - crappy looking, never-going-to-make-money, but fun games. That's why learned to code in the first place, after all.
These days I am using Godot and am finding it easy to use, especially after spending all this time fiddling in the graphics world. However, having children greatly reduced the amount of time I can dedicate to this hobby.
It was rather painful and cathartic to type this out.
P.S. I tell myself I'll find time to read "Physically Based Rendering" (another book that would make a whole in the floor if dropped), "Realtime Collision Detection" (more fun math!) and the newest edition of "Real Time Rendering" (its website is a nice resource to find other graphics books to purchase and never read).
Could you recommend any books on this topic? Thanks!
In the case of downloading a copy of the game you own, I don't have a moral issue with that.
However, I don't think that generalizes to any digital good. I'd say it is morally wrong to make copies of a digital good where an additional instance gets you some benefits. For example, downloading an additional digital ticket to a limited virtual event, thereby gaining access for free, or any instance where the original creator loses a sale and someone gets to enjoy or profit from said copy of the digital good.
You're free to fork the code, remove all the AWS code and build your own community around it without ever caring about Amazon.
For what it's worth, as a former Amazonian who wanted to release games, the games clause did prevent me from attempting to create a commercial game, but it didn't stop me from working on games for fun.
Of all the problems in your story, the employee shouting is the least 'wrong'. You've got a woman who won't wear a mask, yourself who sneaked in without a mask, and that's just in that moment of time, but somehow the employee who has to deal with that behavior all day every day is the bad person because they lost their cool.
It's one of those 'everyone sucks here' stories.
Having interviewed people myself, I think that's an overly broad question to ask in an interview and if the candidate starts answering it as asked, then you're not going to get a lot of signal from it.
Otherwise I thought the problems asked weren't that difficult, one was even directly taken from Cracking the Coding Interview - if only I had read that chapter ahead of the interview...
You can either change your program to fit existing tools, or you can build smarter tools. I prefer the latter.
> code itself is a presentation layer
Not for the tool it isn't
edit: I think we can all agree that ideally we fix this in the language itself by adding optional named parameters
People will attempt to blur the lines between adjacent categories to argue their point, but you're going from the first straight to the last, skipping over everything in the middle. That's what I call 'a stretch'.
Imagine you having always bought tasty tomatoes from your local farm, and someone steps in to show you studies that determined that the generally tomatoes in the US are tasteless.
I'm also not arguing that tasty tomatoes are taking shelf space away from other fruit.
I see getting hired as the last stage in the pipeline, with the first stages being your family, then your education and then employment.
The more things go wrong in the first stages, the less likely it is for one to succeed at getting to the top of the next stage.
If people from underprivileged families can only afford to go to the 50% best school in the state, then to the 75% best college, then by the time they enter the job search page, they won't be at the top of the list (again, on average).
I'll use myself as an example: I had the privilege of coding for entire weekends when I was young, while my peers had to work the land. This gave me a distinct advantage early on, which I capitalized on, so at an interview with a company I am more likely to get hired than if those same peers had hypothetically applied, again because it wouldn't make sense for a company to pass on the best candidate when they are all competing for talent, regardless of race, gender, height or other ways of splitting people into groups.
I think everyone agrees that the current situation when it comes to diversity in the workplace is not acceptable, and we should definitely fix it, but in my opinion, if companies are competing fairly for talent, then that part of the pipeline doesn't really need fixing. We can instead use it as a test to see if the attempts at fixing the earlier stages result in better numbers.
P.S. This a difficult subject and I don't intend to offend anyone. Despite my relative privilege above, compared to my peers in the US, I still grew up in a poor and underprivileged family and am behind my current peers both financially and socially, so it's a topic that hits home for me.
Given a list of chapters in a video course, and a list of user bookmarks, write a function that groups the bookmarks by chapter. Chapters and bookmarks are defined as millisecond offsets from 0 (the start of the video file).
I'd specify the data structures for junior devs and let the more senior people work those out.
Your average developer that gets hired can solve and unit test the solution in less than 35 minutes. Those who don't might be having an off day, or I didn't do a good job at explaining the problem and details, or they didn't ask the right questions or who knows. The point is, a thousand things can go wrong, but the problem itself isn't that difficult. A few loops and a hashmap gets you an acceptable solution.
This and the other problems in the interview question databases at FAANGs are typical of what's in the Cracking the Coding Interview book. Whether someone's ability to solve these types of problems quickly is indicative of their skill level is a hot topic of debate, but if one wants to join these companies, then hacking the process by learning to solve algorithm and data structure problems is acceptable and not a particularly complex process. It's high overhead for the candidate, but at the very least it proves that they can learn, and learning the custom tools and code quickly is about half the skillet required to be successful at a FAANG.
HR typically wants their diversity numbers up badly so if you're gay, a woman, and/or black they are already incredibly inclined to hire you, as long as you pass the interviews.
It's not a walk in the park, but you have this going for you and it's a big advantage imo.
I suspect that hiring and training cross platform developers, then having them own a feature across all platforms will significantly increase speed of delivery of that feature. These are typically called feature teams and they are most effective when there are backend developers on the team as well.
The trade-off is that now the new feature teams are not communicating between each other and coordinating on the common code between them, which starts affecting productivity.
In the end, regardless of how the new VP of engineering likes to split the teams and get praised for solving the current problem by introducing another one down the road, the trade off for increased size is loss of productivity due to synchronization overhead between the people involved.
At the end of the day, we largely trust canonical or the distros maintainers to not do anything malicious, even by accident.
I see Libre cloud as a similar situation, though with more avenues for larger-scale abuse. Hopefully, just like with other things FOSS, the community will validate that everything is fine and the risk is minimal.
For example, the city in this article is currently submerged under water. What was the world like right before? How about right after?
Think of it like a visual reconstruction of all of human history. It would be fascinating.
(I'm guessing off-planet, but that can come later).