say-vagnes

Uber is using their weight to get what they want, because they know we want them to continue offering service. This is actually quite a bit like having a raise negotiation at work. I don't see their goals as evil, either, simply at odds with the state.

Their shareholders likely suspect California will capitulate. Though it is hard to do research over whether their drivers actually want this, generally the information I see indicates they'd prefer to remain contractors. Yes, some of this is paid for by Uber. I imagine some of the content I read was also paid for by the opposition. But it seems like no matter how you cut it, the drivers generally want to remain contractors, and definitely do not want ~their livelihood~ an income source threatened either way in the midst of a pandemic.

> It’s baffling to me that American workers would cheer an acceleration of this trend that would place downward pressure on their wages.

I see shades of this in a lot of discourse - is it an alien idea to be for progress even if it means potentially more strife on your part?

Further, I'd say, not necessarily. People think that working from home is this grand new frontier, but cultures and subcultures have existed on the web for ages. It isn't going to be a wide open playing field. You're still going to have networks and self-selection into subgroups.

And finally, there's still a ton of money to be made by the few who are actually good at this. I hope everyone here is or has worked with someone of this type - where something they ship quickly actually leaves you speechless.

--

As to the rest of this article, it really doesn't resonate. A lot of the problems listed are problems even in the office. The long and short of it is that the world is changing, and so while we can cherry-pick examples of how companies are failing to adapt, rest assured there are organizations out there that are adapting.

I'd say - keep an open mind, and find ways to get what you need - the most important mental shift you can make right now is to be your own advocate, and be proactive.

I feel like GraphQL is the new NoSQL. Not just that it's mistakenly adopted, but also that it is quite valuable for the right use cases, but the public doesn't seem to understand what those are.

Do you really, _really_ need to support queries? 99/100, I'd guess no, and thus constraining people to a more defined interface and access pattern is simpler.

I finally bit the bullet and upgraded from a SE, compromising on the size of the phone. I already notice increased wrist stress and place more sideways weight than is optimal on my pinky (to hold the phone up but also be able to reach single-handed).

So, knowing how life works, we can guarantee that Apple will release a small form factor phone as part of their next offering ;)

A lot may have been simply my own inexpertise in Scala. But I remember it being much more of a fight, and subject to much more nuanced errors, to do anything interesting with generics or any more advanced typing. I would often stop, whereas at the same point in Typescript, I can just cast, and then see what actually happens at runtime. If I fail to be creative enough with my types, so long as I satisfy the type contract at some level, I can be wild wild west in the internals.

I do miss the for comprehensions, but have built an abstraction that does the same thing for my purposes. It isn't quite as good, due to the whole monad thing, and me fitting it to the average Javascript programmer who won't want to learn functional programming all at once. So at its core it is pretty much async/await with sugar.

I quite enjoy exploiting structural typing for unit testing purposes. Gone is the need to learn a mock framework and its DSL; just write plain ol' JS for the parts you are interested in, and tell the compiler to chill. ;) Long term, of course, you should probably just have doubles.

Hey, I've also made the trip from Scala to Typescript. We're talking ZIO and Shapeless wrangling. Twitter vs Scala futures. All that fun stuff (and I loved scala nonetheless).

Would love to know how your journey was. At first I was super hesitant, but now I am actually floored at the power Typescript has. The ability to tell the compiler to simply "trust me" has enabled me to build many abstractions I'd battle for hours to do in Scala.

It's not about most errors being due to type mismatch, as much as it is about being able to model your domain.

By having types, you open the door to formally describing the building blocks of your system. This lets you create very specific, well understood, pure pieces that then are composed together to bring about your desired functionality.

Why rely on documentation that a compiler cannot statically verify, as opposed to a type (annotation or otherwise) that can?

I think you're correct regarding your "most errors are caused by" comment, and no programming paradigm will ever get rid of these - you can always find a way to write bad code. And you are also correct that there are type zealots out there who create beautiful prisons they call abstractions. But at the end of the day, types are a tool, and while I'd highly recommend learning them, I also recognize some projects and teams will never make use of them.

Fair point, I suppose on balance their outcome was indeed successful. Thanks for pointing that out :)

> A person or group calling itself "The Breeders" took responsibility for the bioterrorist attack,[4] as financial retaliation for the environmental damage caused by the state's Malathion aerial spraying;

> It was instead ordered that, rather than 1-2 aerial sprayings of the infected communities, more than a dozen sprayings would be necessary over a period of months.[18] In addition, Malathion was no longer used alone, but mixed in a 4:1 ratio with Nu-Lure0 bait to attract insects to the area.[19]

I know, I know, hindsight bias. But it is hard to imagine that an increase in the infestation would not result in an increase of the treatment for said infestation.

Take note, future protestors. Outcomes are the only thing that matters.

Well put. I am amazed at the replies to your comment.

My thoughts are, it's all about accountability. Good development and, more broadly, learning, rely on effective feedback loops. "Did it work? Y/N and why?" repeated over and over.

When you blur accountability in an effort to be empathetic, it messes with this loop. You've changed the definition of "it" to not be fully what was in your control, and then as a result don't have a clear action you can take to do better next time. This, to me, is how you wind up with 10 1 year experiences.

To summarize, even if a bug is only 10% your fault, be accountable for it, because that's a clear signal towards something you can improve. Accountability doesn't mean falling on some sword, you can also own improving the things that lead you to make this mistake. The difference is, you're taking action to improve things, versus distributing blame (which I find often leads to "what can you do" type mentalities, leaving all the broken things there for the next unlucky person)

I've found that this grind is conquerable. There are only so many ways to go before you start to see the fundamental patterns, and friction in picking up anything new becomes seriously minimal. It's like how some other comments are, talking about how most of programming is really just data access and some clever gluing of frameworks. Or like how there are already software patterns, especially in OP.

My point is, you start to glimpse these overarching patterns as you interact with different takes, and you learn what works and what doesn't, ultimately empowering you to intelligently make tradeoffs or designs of your own. The chaos of web development is, IMO, because it was a new frontier, and a lot of inexperienced leadership occurred. This was compounded by bootcamps churning out people experienced only in Framework X, causing poor re-implementations of nearly _everything else_ inside Framework X.

It sounds like you feel like you _have_ to keep up with these things - perhaps someone else on the team is constantly insisting on migration, but they don't have to go through and tediously migrate and test everything. I'd suspect this lack of autonomy is at the core of your dissatisfaction. You can, and should, say no to a lot of trends, and if you do pick up something new, you should be able to clearly articulate why it's valuable, and these values should be more than superficial.

Another thing worth noting is that the release you work on today is the "legacy, painful" code of tomorrow. But that's a good problem to have - it got the job done. It just happened to get it done in one way, when there are really N ways, and so obviously the numbers game will work against you eventually, even in the imaginary case where the implementation is perfect.

This actually convinced me that Yelp is probably unfairly being targeted. I had come into this thinking that they were in fact unethical.

However, this video very clearly shows a family who incorrectly blames the business owner for one of their members losing a job. Yelp fired them, as they should have.

Sometimes we need to remember that positive interactions make people happy, and negative ones make people sad. And that's what they'll remember about the interaction afterwards.

For a lot of people, these basics apply even to technical discussions. Criticizing their code makes them feel bad, and so you are a jerk. Meanwhile, you think you are criticizing their design to help them improve it. This is a mistake on the part of the person receiving criticism, but it's very rare to have a manager or mentor who can point this out to them, and help them dissociate their implementations from their self worth.

Couple into this other culture's aversions to even just saying "no", and we have a complex and challenging world to navigate. I'm constantly in search of the team where we don't have to do silly social dances to make sure everyone feels valued, and can just criticize and fix, since the members know they're valued by virtue of being part of the team to begin with.

But that is asking a lot of people - they have to have reflected on these issues. Since this is rare, and the larger a team gets, the more likely you'll have to deal with those who haven't dissociated yet. Makes for a great mentorship opportunity if you can find a way to have them "let you in".

Can you unpack exactly what made this comment go from 0 to 100? I didn't get any of that from the parent post.

This take can cause a pretty unproductive worldview. The trouble is, we've all met different people who fall into broad categories like "jack of all trades". A lot of morons will say this sort of thing. Sometimes it's because they think you think they are dumb, so they want to show you that they are good at other stuff so as to keep their ego happy.

However, generalists are a very useful component of a team. They tend to be able to have a higher level view of all the moving parts, and typically are great for, say, proposing integrations, or high level system design. Also, often specialists will solve a problem in their specialization, fit be damned. They need someone to derail them and say e.g. "this would be much, much easier if we leaned on MySQL to do this".

So, this feels like a baby and bathwater situation to me.

I'm sorry to read so deeply into your anecdote, but there's some interesting stuff to unpack.

> This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand

This describes nearly every company's MVP, so if you're thinking of a person in particular who had to cobble together some dynamic mess, chances are they have great regret for their design. But remember, tech debt is a luxury in these cases - often the alternative is no job or company, as the runway was exhausted, or investors were not impressed.

> A person believes they're the smartest, but not most knowledgeable, in the room.

I think there's no getting around this. In fact, TBH I hope my colleagues feel this way - I want them to advocate for things they think are better, and I don't want them to instead fall prey to their own insecurities.

It's actually kind of a little self-help bullshitty -- the "you can do anything" stuff -- but truly it's actually not awful advice. I guarantee there's someone you work with who has a better way of doing things, but isn't confident enough to endorse it.

Anyhow... thanks for the writing prompt? ;)

Good article. However, I'd like to talk about documentation and comments, as they were mentioned a lot.

I think the industry should rely on them less. The trouble is, nobody updates every comment, and documentation is even more out of date. They cannot be automatically verified either.

Getting worked up about it is just going to give you stress. Further, it is terribly subjective. Instead, advocate for the other good practices - variable names, clear separation of concerns, single responsibility, functional purity, etc.

I have this inkling, actually, that the more comments there are in a function, the worse it is. Even high level overview comments, like some outlining an algorithm, could instead be high-level code, composing the various pieces together.

It is very rare that a concept is actually nuanced in code. Instead, it is usually the implementation - and you can improve it.

That said, it's a ton of work, and we have to ship a product at the end of the day.

So here we are again, discussing tradeoffs in tech, and I think in these cases a comment block is an OK compromise. Just be cognizant that it IS a compromise.

Your copy & paste comment really resonated with my experiences. Our services are a cobbled together mess of pasted solutions from other services, and members of the team often say something is impossible because they can't find an example of the exact same problem being solved somewhere else in the code base.

Amazingly, they are just as aggressive as the competent people when it comes to pursuing promotions and responsibility, despite not being able to write a function in the main language of the company after working in it for multiple years.

I don't know how things got this absurd, but here we are.