The problem with this is that while it is easy to see that the success of large corporations with practices we disagree with creates the problem, it is harder to see how us stopping our support helps fix them.
I boycotted Amazon for the better part of a decade over the one-click patent. Result: they lost some amount of money they didn't notice, I lost out on all the convenience and options. They changed nothing I was boycotting about.
I boycotted Blizzard over the bnetd response for 5-10 years. Result: They lost out on me buying Warcraft 3. I lost out on playing WC3, on the related social activities, on being part of DOTA being born, etc. They changed nothing I was boycotting about.
I revisited the boycott on blizzard after the Hong Kong mess, but this time I said I'd time box it if nothing seemed to be changing.
Is this cynicism? My unwillingness top accept some minor inconveniences to be part of a group trying to prevent human abuse? Should I care that my efforts are unsuccessful if they are nonetheless the right thing to do?
Maybe I shouldn't care about sacrificing but failing, but I do. And not just because I don't want the inconvenience, but because I want the problems to be fixed. Stopping the spread of soul-crushing (and in the case of warehouses at least, body-crushing) labor is GOOD, and way more important than promoting technological equality. I want success at this!
If I'm making life harder and doing nothing to actually stop that, I want to shift my sacrifices to a more successful area.
I just have no idea how. Right now my options are: Suffer a little without helping those that suffer a lot, or don't suffer while still not helping those that suffer a lot.
I normally hate boilerplate apps. CRA is an exception. It doesnt pre create any content of significance. ( basically a hello world page, although it has a demo image file to rip out)
It does create a build process, but not content. This frees me to focus on my code. Were I to struggle with getting the build to work when that isnt my goal, I'd likely half ass it, make basic errors, and struggle to reinvent the wheel. (Actually, I know this because I do periodically do this just to make sure I understand what CRA does for me. Each time I find months of changes and tweaks I have to learn that I definitely suck at keeping up on even when I have a project that doesnt use a boilerplate)
CRA isnt like other boilerplate apps - either I dont get your point or you choose a poor example to hang your point off of.
I was a Perl dev a long time ago, and I think it made me a stronger coder. I still miss it, and I've not coded Perl for real in a decade.
You're correct about "over-the-top cleverness and arcane constructs" being a problem, but it's also about using code as communication. We code in _languages_, and on one extreme is coding newpaper style - lowest common linguistic denominator. On a good day this is a common, understandable language, and on a bad day it is trying to communicate with stilted baby talk. On the other extreme is dense linguistic cleverness. On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.
As coders we like to talk about using the right tool for the job, but in code we so often assume that the most stilted repetative pattern is always best. It often is - like newspapers, we can't (or shouldn't) assume our audience is well-versed in our material. But we have other constraints as well. I often argue in favor of _skimmability_ over _readability_ of code. That means that the attention/focus of the eye is important. Stilted languages with minimal syntax give you almost no control over that. More fluid languages like Perl give you a lot more flexibility. Learning to use that flexibility to increase clarity...for MOST people, not just for yourself...is a skill that most of us have only limited practice at, and none of us have mastered.
But it's a good idea to work at it, and when done well you communicate MORE with LESS, and it's something people notice because it's not buried in the midst of visual noise.
Can you elaborate a bit about Context? I've been curious but wrapping multiple context layers to get multiple values feels awkward and wrapping an object to get CD around that feels like it screws over React rerendering logic.
Sure, but how many managers are actually trained to do what they do? There's this strange expectation that everyone somehow knows how to be a good manager, when in truth, most of us know (some of) what a manager is supposed to DO, but have only what we've personally experienced to guide us on HOW to do it. And what we've seen is only a sliver of the process - we've likely only seen the managing of others in public, and the managing of ourselves in private.
Ee can, at best, know from experience how to manage someone that is just like ourselves, and have an idea of what to say in public to people not like ourselves, but not what to say to them in private. And that's the best case, assuming we've had good managers (and thus have good examples to draw from). More likely, we've seen tolerable managers, plus plenty of bad ones.
To your point, how do we even recognize good management when we've seen it? How do we know what to emulate and what to avoid? We're the parents that say "well my parents beat me and I turned out just fine, so....".
Management is a skill (or collection of skills) It's not a skillset that most jobs actually train, nor is it one that they do a good job of recognizing. Most of the jobs people have growing up (and beyond) reward managers that push for short-term gains over such things like "morale" or "communication" - these are the managers that are "successful" for the vast majority of experience. Just look at how many places have techies shift into management as a career development path, but don't do anything to train them or say that people are managed any differently than code.
There are plenty of reasons for people to be biased against the person (their manager) that tells them what they don't want to hear (such as "take on this extra work" or "your time off request is denied" or "don't implement your idea"), there's also plenty of reasons to expect that most managers legitimately ARE poor managers.
I've also had several fights with google over my refinements.
If I search for 2 words, odds are stupidly high that most of the results will NOT include one of my two words. Thanks Google, for deciding I didn't really mean to type that.
I follow up with added quotes, etc to enforce what I actually typed, so there will be a lot of Google-induced churn.
Google has focused so highly on the peak that more and more searches - certainly the majority of mine - have been relegated to the long tail.
When I was younger, I was a free speech absolutist. I believed in rationality and that if you couldn't defend/oppose ideas then your position had no strength. Censorship was a sign of weakness. Even clearly "good" censorship (say, banning child porn) has problematic boundaries.
Now...I'm far less confident. I still believe in rationality, but I also see clear weaknesses in human's ability to process. Rationality emerges over time, not in the moment. Speech isn't just ideas, it's emotion. It creates social pressure, fears, threats. And humans are social creatures. Even this forum is chock-ful of signaling patterns and inclusion. These aren't personal failures, but human facts - to be without these would be to dissolve the functions that make us form communities - to remove the items that make us NOT be "defectors" (to signal).
We have to trust others, or we'll spend all our time verifying all the information we get and never accomplish anything. But this introduces the ability for others to exploit this. Speech has never been inherently good nor bad, and thus "free speech" is also neither inherently good nor bad. It is just a force multiplier for whatever you try to do. And "good" speech can't be solely dedicated to battling "bad" speech if it wants to achieve any change, while bad speech achieves its goals just by existing, or even by demanding the attention of those giving "good" speech. An inherent imbalance.
In the big picture, this all shakes out over time. The good speech investigates and explores ideas. Bad speech is beaten. Speech in the middle helps ensure that the "good" speech really is good, and periodic bouts of bad speech help the system enforce the boundaries that move everything in a healthy-for-society direction. But to zoom out to that level is to ignore all the suffering such a system entails. "You can't have a society that is afraid of hurting feelings!" free speech advocates will cry out...correctly. Some amount of suffering is unavoidable. Pick any arbitrary line between restricted speech and unrestricted speech and it's easy to see that people will suffer as a result. But that does not mean that we should automatically accept that unrestricted speech is the answer. That we should be blind to all the suffering that IS happening because we fear the suffering that MIGHT happen.
Or perhaps unrestricted speech IS the answer...but a lot more of us need to be calling out for the societal responsibilities. Free speech is a powerful tool, and like any tool should be used wisely. If we aren't calling people out for using it poorly, but are calling out people for any attempt to restrict it, we're empowering only one side of the equation. But that gets into a circular argument, because if you replace government restrictions with social ones, you have the same result - restricted speech.
I don't know where I stand on this. The only thing I see clearly is that the number of people that seem to be seriously examining the issue is vanishingly small relative to the population.
> In 2014 they were all fired. Their strategy for testing Windows is now three fold: - Devs are expected to test their own code now
I was at a company that did the same (at roughly the same time) - this was a terrible mistake. But it's very hard to discuss, because any dev complaining sounds like they want to avoid testing.
Dear manager that I hope reads this:
QAs, at least the ones under discussion, aren't just mindless pressers-of-buttons. They have a skillset and domain knowledge just like (but distinct from) devs. A dev should absolutely test their own code...but they will do so with their domain knowledge which will be by definition more limited than someone for whom such knowledge is a key part of the job. Devs should test so that only problems worthy of the QA skillset make it to the QAs.
Asking devs to do QA work is asking them to build skills that are not their strength, and that will come at the cost of their strengths. It is asking them to build skills they probably don't enjoy, and that will come at the cost of their job satisfaction. Having devs do QA work is as bad as devs that test nothing and leave it all for the QAs - it's an inefficient and ineffective use of resources and time.
There is nothing wrong with encouraging Devs to deliver higher quality code to the QA/Test engs. There IS something wrong with thinking higher quality code from devs mean you don't need a QA/Test Eng.
This advice is good, but never addresses the issues of:
- cost
- impact to work
- fear of retaliation (Oh, that's illegal? Show me how that will be dealt with in ways that don't negatively impact my job/family/bank account)
I've done primarily FE for the last several years and the argument I make with my BE peers is that our BE-focused industry focuses on coding for extension, while a well-run FE codes for _replaceability_. Because, for reasons that are NOT limited to a regular rotation of libraries and frameworks, our code will be replaced frequently. Our requirements change so frequently that no amount of extensibility will manage the paradigm shifts.
That's not a BE vs FE issue anymore - Many of these growth-oriented companies and startups are making dramatic changes in tech/approach/offerings and other basic requirements. Being able to pivot quickly is beneficial. Allowing a team to try out something and work out the kinks (while still producing output that can be used in production) before everyone else considers adopting it is really beneficial.
So in the sense of dealing with that reality, in avoiding being the company running on Java 8 or jquery 1 or heavily commited to their SOAP infrastructure or deeply coupled with a UI interface that everyone rolls their eyes at - yes, you can call these cases "successful".
If those issues aren't your biggest issues, if you have a stable collection of offerings and are interested in solving scalability, focusing on extensibility, etc. If you want to have a rigid set of UI standards and have confidence that those are being universally applied...then no, they aren't "successful".
Appropriate tools for the appropriate task. In this case, it's easy to see the result as the failures it contains and not consider the failures it has avoided.
That said, those of us that DO miss some level of meat simulacra (great phrase!) will appreciate this. I lost the taste for actual red meat over 20 years ago, but the texture is still something that has few parallels. Between the hardcore beef aficionados wanting nothing to do with "fake meat" and the hardcore vegetarians/vegans happy to consume veggies I find bland or noxious (As a vegetarian that strongly dislikes bell peppers, I can say the struggle is real) I've had limited options no matter where I turn.
Both Impossible and Beyond burgers have been teasing me for years, but have offered nothing for home. This doesn't get us there, but the more fast food places that carry them, the closer it becomes to being a part of normal.
Not everyone looking to have a repo today and joining a team tomorrow where it will pay off for Github is a student. Being able to pay doesn't mean the same as willing to do so, particularly if they've not used github yet and have no idea if it will be worthwhile.
I boycotted Amazon for the better part of a decade over the one-click patent. Result: they lost some amount of money they didn't notice, I lost out on all the convenience and options. They changed nothing I was boycotting about.
I boycotted Blizzard over the bnetd response for 5-10 years. Result: They lost out on me buying Warcraft 3. I lost out on playing WC3, on the related social activities, on being part of DOTA being born, etc. They changed nothing I was boycotting about.
I revisited the boycott on blizzard after the Hong Kong mess, but this time I said I'd time box it if nothing seemed to be changing.
Is this cynicism? My unwillingness top accept some minor inconveniences to be part of a group trying to prevent human abuse? Should I care that my efforts are unsuccessful if they are nonetheless the right thing to do?
Maybe I shouldn't care about sacrificing but failing, but I do. And not just because I don't want the inconvenience, but because I want the problems to be fixed. Stopping the spread of soul-crushing (and in the case of warehouses at least, body-crushing) labor is GOOD, and way more important than promoting technological equality. I want success at this!
If I'm making life harder and doing nothing to actually stop that, I want to shift my sacrifices to a more successful area.
I just have no idea how. Right now my options are: Suffer a little without helping those that suffer a lot, or don't suffer while still not helping those that suffer a lot.