u/dev-voln

Have you finally tried it?

I have this question too, but I don't want to waste time reinstalling my OS in case it doesn't work.

Have you tested it? How much is it slower?

I don't understand why I should recompile everything when a user resizes the window and why I should have multiple versions of the pipeline for each texture size I render to.

Great job!

By the way, I'm developing my own ShaderToy analog that stores users' snippets in their GitHub account as Gists. It is going to have a quite minimalistic GUI but with a lot of features. All passes, textures, meshes, and all connections between them are declaratively defined by the user in a JSON-like JS subset. One editor is for JS and the other for all GLSL code.

I didn't suggest this convince anyone in an interview. My objection was only about "CSS is so trivial". I totally agree that it shouldn't be mixed with primary skills. A resume should clearly show which skills are primary.

So, CSS either should have been omitted if the job didn't require it. or mentioned separately as a secondary skill.

Of course, CSS is totally different from C++. But it's not trivial.

"Your methods should be well named and easy to understand"

Of course, this thing is primary.
However, when you achieved it and still have the choice between the number of units (functions, etc) and their size, try to keep a balance between them. You should consider that our short-term working memory holds 5-7 elements or so and long-term working memory holds 100-200 elements. So, holding more than 7 nesting levels in short-term memory might be a problem. You will need time to "upload" it into your long-term memory. Also, the more functions you have, the less easy it becomes to give them good names that easily differentiate them from each other.
There is no recipe for everything. Analyze your own experience in your projects from the point of the human brain limitations.

I don't agree that CSS is trivial. In every project where I have to use it, I run into issues when positioning drives me crazy. Sometimes I think that JS and even C++ are much easier.

Only you can know it. Doing a random task that someone gave you just to maintain your knowledge won't lead you anywhere. You learn better when you choose yourself what you what to learn and what methods you want to use. Ask yourself why you enjoy node.js and what you want to do with it. Set a goal and start your pet project. Try to work on it every day and make it your habit.

At some point, you will probably run into a problem with your motivation. Long breaks may lead to losing your drive and require some time to get back to your project and start enjoying it again. So, if you feel lazy, check your motivation. Ask yourself if you still want to achieve that goal and why. If it doesn't inspire you anymore, set another goal, and start another pet project.

I have been developing libraries for about 10 years as hobby projects and I always wanted to make them perfect. I was naive enough to believe that there were some ideal ratios, but when I asked about them online I could never get any specific answer. So my only option was to figure it out on my own by trying to apply different rules and trade-offs myself to my codebase.

Every time I picked a new rule I was excited as I believed that it would finally get my code closer to the ideal. But then I found drawbacks and got disappointed.

For example, I had hundreds of small classes (20-30 LoC) and when I decided to put each one of them into a separate file following the rule "one class = one file", I got hundreds of files that I needed to put into a deep directory structure to be able to navigate through them. But then it became hard to remember where the file I was looking for was located. IDE's intellisense helped but not completely.

The right structure should be based on your project size and how well you or another programmer can remember it. If your project is not small it will need some organization because you can't hold it all in your memory. It requires good naming and clear understanding of the purpose of every separate unit in order to be able to think of them abstractly.

When your project gets really big you will eventually run into a limit of complexity your brain can cope with. Then you will probably need to split it into smaller independent parts that you can work separately with or delegate to other people.

To avoid running into this limit too early you have to decrease the number of entities your brain needs to operate at the same time. This means doing the following things:

1) Increase the expressiveness of your code, code reuse rate, and make good abstractions with good names and clear purposes.

2) Make them decoupled as much as possible so that you can think of them separately.

3) Your units (functions, classes, files, directories, etc) shouldn't be too big or too small. They should be balanced with everything else. When your project grows, that balance shifts. On average they should grow together. Small functions and files are good for small projects. Big functions and files are good for big projects since this limits the nesting depth. Think of your codebase as a balanced M-ary tree (or even a real biological tree in nature) where not only the depth grows but also the number of children per node.

Thank you u/alecco and foonathan for sharing this.

I'm developing a template-heavy generic library that has a lot of nested levels of templated code with moving and forwarding on each level. And every time I need to move or forward something I worry about its performance in MSVC in Debug mode.

Now I know that I can safely replace it with a macro and stop worrying. The macro for forwarding is even more readable than std::forward. Even though I don't like macros much and everyone says that they are evil, I prefer to consider each use case separately and not just blindly follow the rule of avoiding macros at all costs.

This is how our brain is wired: you either use it or lose it. The good news is that every time it gets easier and easier to understand and remember. This means that every time you can increase the interval between repetitions. This mechanism is described here: https://en.wikipedia.org/wiki/Forgetting_curve

So there is no magic way to keep something in memory. It requires work. You can try things like spaced repetition and taking notes. They are useful, however nothing will replace practice of applying your knowledge.

Thank you for sharing. I learned a lot of things about CDNs and HTTP/3 from this article. In particular, I didn't know that CDNs may be faster even without caching.

Vue developers have already created a great tool for this task - Vue CLI. I'm pretty sure they follow all the best practices.

I think that it is always a good idea just to start with a standard solution unless you already know that you want something different and specific. You can always modify and improve your project later. Especially if you already have experience with node.js and npm.