I'm having the same problem.

Yesterday I noticed my laptop running very slowly, so I looked at my memory usage, and 'in use' was just under 30GB (there's 32GB available). I realised I hadn't restarted for a few days, probably since the start of the week. I had three instances of VS 2022 running, and they reported using about 4GB between them. So I shut down the three VS instances and it freed up nearly 10GB :wtf: I guess there are a lot of related programms processes running that wouldn't necessarily show up under VS on Task Manager. Anyway, I restarted the machine, then launched every application I previously had running, did a build on all three solutions I previously had open, and 'in use' was in low 20s. Seems like something is a bit leaky to me.

I have a Das Keyboard with brown Cherry MX switches. I love it. Really nice tactile feel to the switches - clicky, a bit on the noisy side, but not offensively so. The construction of the keyboard is just lovely.

It's all about the switches, really. Das Keyboard uses Cherry MX switches, of which there are different levels of clicky-ness. Das support a couple of varieties: - Blue: very clicky - Brown: less clicky (but still quite clicky) I have a Das Keybaord with brown Cherrys, and I love it. It does make a fair bit of noise though, so if you really want quiet, you might be better with different switches, e.g. Cherry red. This would mean a different keyboard to Das. Here's a good comparison of Cherry switches: Cherry MX Switches: A Complete Color Guide and Chart[^] There are other switch manufacturers of course, and some are just as good, or better in some cases - I've only really looked a Cherry.

This feels like one of the most useful things I've learned in years. Never again will I have to paste something into Notepad then copy it out again. Thank you!

Having been involved in a big ground-up rewrite (painful, everything takes longer than everybody thinks or is willing to stomach) I would tend to favour an incremental refactoring approach. So (if possible) put the new code in the same site as the old, and start replacing features one by one. I wouldn't envy the person who has to extract that SQL out of WebForms though!

Some of the new features I really like. Some I don't. The issue for me is not about what I may or may not like, but the ever-increasing complexity. People say 'just don't use the features if you don't like them'. This is fine if you mainly work on your own, but what if you work in a team? Or worse, lead one? You're likely to have a mix of people, some of whom want to explore all the new features, and some who are just learning. The latter group will really struggle because of the former - their learning curve will be much steeper, they will require more support, and they may even lose confidence and decide this isn't for them. There's a good article here[^] that explores this. TL;DR: langauge design is a balance between keeping up, and overloading with complexity. If you don't add new features, the language dies; but new features eventually make the langauge die from complexity. Personally, I understand the need to keep evolving the langauage, and really appreciate some of the additions, but I would prefer a slower, more measured evolution.

https://www.lucidchart.com[^] works well for me.

I couldn't agree more. We need to start a revolution in software development, called... er... Flexible! Where we shake off the shakles of Agile and Waterfall! Then watch sadly as the principles get co-opted by consultants and degrade into a soul-sucking form filling exercise.

Ah, understood. Sounds very frustrating. Many times I've been pressured to start the work, pressured to finish, then end up waiting months for sign off. :sigh: I hear so many stories of agile and how it seems to often create more problems than it solves. I suspect that if you have good people, committed and motivated, they can make a success of things regardless of process.

OK, if it's 2 1/2 hours to deliver a statement update, then you have my deepest sympathy :^)

In terms of 2 1/2 hours talking to business owners, I know everybody does agile differently, but my interpretation is that having devs interacting with business users is central to agile processes. From the 'Manifesto':

Quote:

Individuals and interactions over processes and tools

Quote:

Customer collaboration over contract negotiation

From the 'Principles':

Quote:

Business people and developers must work together daily throughout the project

Quote:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

My personal experience in development is that the worst problems come from a lack of understanding of requirements, and that the more you have people as conduits for requirements between the business and devs, the more likely misunderstandings will arise. So, as painful as 2 1/2 hours away from the lovely code may be, in my view it's time well spent. That's not to say that I don't think PMs are useful; I just don't think they should be a buffer between devs and the business.

Hey Mark. So sorry for your loss. Must have been a real shock to have that happen so unexpectedly. We also lost a dog over the weekend. We had the vet around to put our 14-year-old Working Cocker Spaniel, Cassie, to sleep. She's been sick for a while with chronic pancreatitis. I miss her so much. They're such a big part of our lives and leave a huge whole when they go. My thoughts and condolences are with you for the loss of your Louis.

Sounds like you could have gone to the same 'technical college' as I did :) As a hiring manager myself, I wouldn't be averse to taking on somebody in your position, but would need to see some evidence of your commitment. The easiest way to demonstrate that is by developing a working application that you can show off. For example, a browser-based application that does something vaguely useful, and demonstrates that you can create a UI that does stuff with a database. I wish you all the very best in your career change, and hope you find your way to something that elevates your soul instead of crushing it!

I've been using Entity Framework for about 10 years. Before that, I had 20 years experience in hand-coded SQL queries through stored procedures and views. So, I've used both approaches extensively. This is what I've found. Against: 1) It occasionally produces poor-performing queries, especially when they are big 2) It consistently produces queries that are very hard to understand For: 1) It saves a lot of time in the maintenance of stored procedures and views (or the ugliness of in-line SQL, if that's your thing) 2) You get compile-time checking. If I refactor my schema, my code breaks until I fix the problems. Does it matter in my job? Yes. Does it positively or negatively affect database design or performance? No affect on DB design - I design my database independently then hook EF up to that. It does have an affect on performance though in some cases. Generally, it's fine for simple CRUD operations, but where you have complex joins and grouping it can (but not necessarily will) produce slow queries. I'm generally pleasantly surprised by the perfomance. It produces crazy-looking queries with lots of sub-queries, but they seem to perform OK. I guess the EF designers know what SQL can handle. My approach is to use EF where EF is fine, then drop into views/stored procs where necessary. The difficulty here is with inexperienced team members who may never get the opportunity to learn to hand-code SQL, so will just rely on EF when they shouldn't. Also, some developers just don't like the idea of mixing strategries and would prefer all or nothing. Does its use ever cause you any headaches or make your job any easier? Yes and yes! The LINQ syntax can get very complex. Sometimes it's just quicker to write the SQL yourself. Occasionally queries need to be written in SQL for performance reasons. It all depends what you are doing really. If you are doing complex transactions on high volumes of data, then EF may not be the best choice for that. The time saver isn't so much not having to write T-SQL, but on the admin overhead of having to write views/sprocs seperately from the rest of my code. The compile-time checking is the real benefit for me though. In the past, a common problem I had was production bugs due to an obscure view or sproc that wasn't updated after a schema change. Now, I have a limited number of views and sprocs to check, and the rest is caught by the compiler. This is the single biggest advantage for me. It's reduced production bugs and

I'd like to see software development best practice being informed by science instead of the opinions of influential groups and individuals.

I agree about using Display Port. You'll almost certainly get better resolution with it than HDMI.

I often find it easier to bypass their search altogether and use a search engine. E.g. 1/16" FOOBARS site:amazon.com

I'm glad I'm not alone in that :)

And you may ask yourself: "Well, how did I get here?"