Software devs in general seem to have a hard time with balance. No comments or too many comments. Not enough abstraction or too much, overly rigid or loose coding standards, overoptimizing or underoptimizing. To be fair it is difficult to get there.
Software devs in general seem to have a hard time with balance. No comments or too many comments. Not enough abstraction or too much, overly rigid or loose coding standards, overoptimizing or underoptimizing. To be fair it is difficult to get there.
You can read without using your inner voice if you practice. It supposedly lets you read a lot faster, though I have my doubts about how well you retain the information. One way to do it is to think “lalalala” while reading something!
Interesting, yeah. I inherited a Blazor project though and have nothing positive to say about it really. Some of it is probably implementation, but it’s a shining example of how much better it is to choose the right tool for the job, rather than reinventing the wheel. For a while I was joking about setting the whole project “ablazor” until we finally decided to go back to a React/C# ASP.NET stack. If you’re thinking of using Blazor still, though, I think two fun things to look into are “linting issues with Blazor” and “Blazor slow”. I’ve heard people praise it, but they tend to be those who consider themselves backend devs that occasionally get stuck making frontends.
Depending on the software, you still get to think about garbage collection!
For a long time I tried, but one day I just decided to focus on the hobbies I care the most about. I dumped a lot of time into software for my career, then kept up with bass guitar practice and dirt biking. All the other hobbies are things I might pick up if I have a surplus of time, but I’ve accepted that I’ll never go that deep into them.