Hard disagree. The amen break, the music it is a part of, the technology and evolution in sound that it heavily influenced; is a welcome discussion focus on a weekend for many on HN.
203 karma · joined November 18, 2014
Oh my goodness yes. I started playing on January and followed the Hanon instructions with the sheets. I have been trying to release tension, especially around my flying pinky… and realized that this way of playing Hanon was making it worse. I am in the process of fixing this now, and am enjoying less tension.
Some things are just part of the responsibility of being a grown up. Home maintenance, driver for children, doing taxes, etc. These are your baseline priorities that you don't get to choose.
Some of these sound like they occupy a rotating priority slot. House and car purchases do take a big commitment and require prioritization (especially if you build) but they are temporarily a priority. It is usually your choice to make these a priority, and they are rare.
Keeping a smaller priority list means saying 'no' to more things too, like being 'tech support geek for wifi and computer issues' or vehicle maintenance. These priorities are fully under your control.
I have 20+ yrs experience as a polygot developing products from IDE integration, cybersecurity, economics, project planning, market analysis and more.
I know applications can get lost easily in the shuffle these days, with high volume of candidates applying. Is there any way to get a specific resume noticed?
But when it's not being upgrade, it's fantastic. Many thanks to Red Hat.
> I believe that it is a mistake to believe that merely working harder will earn that respect.
<bingo>
You must be a principal level developer -- it is a role driven with the highest degree of cynicism and empathy, which you comment is gushing with.
Exactly! This can be very difficult to quantify; as this kind of debt is undetectable by standard gates (linter, static analysis, etc.). Instead, it is more nefarious... introducing coupling, where none was needed, or long-winded tests; that test very little, and make the code hard to refactor. I don't have a measure for this beyond my intuition of working with code for decades.
What makes it all worse, is when the features are 'delivered' and marked as 'complete' by these folks, they are difficult to take back! Especially if their delivery was identified as a key objective to a quarter.
One was doing absolutely nothing at all for months on end.
One was doing negative work - every line of code made things worse, every document was unintelligible, and they would approve every PR from other devs the second it was opened.
Suffice it to say, the dev that did nothing at all was the most productive of the two.
It is important to understand the foundation from which all these decisions originate.
Did you mean 'the' instead of 'they'? Did you do this on porpoise?
If you want jsonapi, you probably really want graphql...
Laying off 23% of staff is _literally_ how he will make the stock go up enough to get a good % of his compensation, if not 100%.