Back in the ancient times of the early 2000's I had to deal with a massive, legacy java codebade.
I found a small free library called MaintainJ that used aspect-oriented programming as you used the app. It was great to make sense of how everything was pieced together: You coul fire it up, run through a single scenario (user log in, add to cart...) and generate a flow diagram of just that scenario.
The library still exists, http://www.maintainj.com but I haven't used it in +15 years, so no idea how it is today.
Depends, code that was not written with testing in mind can be very difficult to cover without some major refactoring.
Adding the first tests can be a slow and painful process.
Now, once you have those few tests? Yep! Add a few tests along the ones for the new functionality every time you touch a piece of code or pick the low hanging fruit every now and again and you can get to a useful test suite in no time.
I'm of the same opinion. I love getting feedback, better if it's constructive, but all kind of honest feedback is useful and welcome. And it doesn't always come from people with more experience, sometimes a greenhorn will see things that a greybeard like me doesn't.
But I've seen people giving negative responses to the best feedback. Hell, I've had people complaining for hours because someone else replaced their manual process that took an hour to do with a script (and copy&paste of the result) that took literally seconds to run.
Yeah, I've seen that as well. I believe it's mostly fear-driven, in a way of "if this gets automated, why would they need to keep me around". It's a terrible mindset for everybody involved. It really slows the team down, and it's a major issue for the person themselves. It's like impostor syndrome on steroids. Not only do they worry that they might be found out, they worry they might be replaced by a script.
I've never personally seen somebody getting fired because a script can do their job. I've seen them being freed from doing the same repetitive bullshit day after day though, and finally being able to actually tackle new challenges.
But unfortunately, that kind of mindset is not something you can change through rational arguments, at least in my experience.
Management and engineering are two different careers, so I wouldn't call it "upgrading".
Having the technical chops definitely helps as a manager. And knowing what the managers expect and be able to talk their language helps as an engineer. If you reach certain level its easy to jump between them. But they require a different set of skills and the work is different.
If you like it, there are a lot of rewards. If you don't, it can be soul-sucking.
Yep, my todo lists are all trees. Even when I'm writing a document, I first put the table of contents as a tree and then fill in the different sections :)
I have one exception, though. Mind-mapping.
I will use mind mapping tools for todos and notes. But for real mind mapping I use full blown graphs.
Not sure what to tell you... If I remember correctly, the last time I restarted Firefox was to update it, around the 5th of May (I have version 76.0). Generally speaking I don't restart it (or the laptop) except for that.
No addons other than uBlock Origin, TST and LastPass.
Have you ever used a complex database in a formal, by-the-book, third normal form?
The number of tables explodes, the number of joins become a pain and every single data change requires careful planning.
As for the "many database systems support materialized queries", I only know of a few that truly do: Oracle and DB2.
PostsgreSQL supports them, but you need to handle updating them yourself. SQL server kind of supports them, but are limited.
In other RDBMs you can work around that using triggers (or similar concepts), but that IMHO is definitely a bad practice and the times I've used that (usually because there was no other option) has only brought me grief.
Denormalization means you (by definition) have duplicate and redundant data in the tables. This certainly requires careful planning around updates to avoid data corruption.
> The number of tables explodes
This is IMHO a backwards way to understand normalization. Normalization tell you how many "logical relations" you have in the data - whether you like it or not. If you decide to squash multiple logical relations into the same physical table then you get redundant data (by definition). This might be a fine optimization, but it doesn't reduce the inherent complexity of the data model. It just saves some joins as the cost of more complex update logic.
I think there's a decent amount of hyperbole, but even taken at face value: Every single data change should require careful planning. Especially if it's a schema change, and not just a query.
You can do a lot with generated code, refactoring, etc. Data is much less agile, so I'm a lot more conservative when it comes to that end. Never mind that with decent naming, table comments etc. it's a good documentation in itself.
