cloudego

I’m not sure why you’re so upset by this. Electron is installed on our machines and deserves to be scrutinized.

The author presents the info clearly and even includes videos demonstrating the “technique,” so it doesn’t seem “low effort” and click-baity to me.

I’m not sure I can support your view that this is unworthy of attention or fix because of in-memory patching, etc. If I told my customers Not to worry about my product because there are much scarier ways they can get hacked elsewhere, they would still ask why I didn’t put my best effort into closing a known loop.

> That’s... how it should work.

I think the absence of this theory in reality is proof that it is not a successful business practice for software development. If you believe that this model accurately translates to software then I challenge you to start your own software shop.

I wish this was not random.

I work as a lead developer at an enterprise that uses JIRA. This is a question very close to my heart.

JIRA is feature dense, but everyone hates it. The interface is complex and the learning curve is silly. We waste valuable hours fighting the tool. It was not made for software developers. It was a trouble ticket tool that treats software projects as if they were high priority catastrophes.

Trello is too malleable. Long story short, the question became, "Why don't we use sticky notes?" Sticky notes didn't work because we have 1 remote employee and a fistful of executives that demand involvement in tracking sprint progress (lolololo) but they are unwilling to sacrifice 10 minutes for standups or a trip downstairs to see the board.

At the end of the day, we spend time arguing about how to reduce friction for the development team and ignoring their needs because we already purchased JIRA licenses. If I started my own company, we would request features and track progress in the issue tracker of the source control product our devs chose. If project managers, scrum masters, execs, and other parties have a need for another project management tool they're welcome to use whatever integrates with the issue tracker.

The entire point of practicing agile development is to produce better software faster. Move decision making closer to the problem. Therefore, I don't understand why we can't manage our developers closer to the codebase. Every time they come up for air to the project management tool for someone else's benefit is a context switch that costs us. You wouldn't hire a mechanic to fix your car and tell him that he had to bring all of his tools to your garage to work.

If your clients or internal customers are using your issue tracker, they are actively showing you which features or bugs are impacting them the most. My experience is that JIRA, Trello or anything similar encourages you to create an interpretation layer for your customer's emotional responses. If you teach them to interact with your internal projects as if they were contributing to an open source project, you get a first person account of their priorities, and you may yourself with less empty stares around the room during product reviews.