> SQL schemas are basically the opposite of file layouts
Which is you disagreeing with what a judge has decided?
It seems hypocritical to shut-down someone arguing with one aspect of the case on that basis, only to end with your own disagreement with a judge's decision.
No, I think you're mistaken. That the case didn't turn on how marginal a security risk was isn't a matter of opinion. That a SQL schema isn't a file layout is (though: there's clearly a right answer to that: mine).
I want to believe that can work. There's a neat idealism to the final approver being responsible for any bug fixes. It's encourages knowledge sharing prevent knowledge silos; the approver needs to be well versed enough to fix bugs.
But the reality is that it also risks pushing away those who go out their way to conduct more reviews.
Every team I've been on has had a mix of developers, some of whom are responsive to doing code reviews and will pick them up and process them quickly. There are also those developers who drag their feet, only pick up reviews when they're the only one who can review that area of the codebase, and take their time.
The former developers are displaying the habits you'd like to encourage more widely, and yet they find themselves "punished" by getting even more reviews, as people learn to assign things to them when they want a PR handled effectively.
I fear that compounding that by layering on another obligation to the star team members would further push them out.
> Every team I've been on has had a mix of developers, some of whom are responsive to doing code reviews and will pick them up and process them quickly.
Rubber-stamping is not really "reviewing" though.
And leaving a comment "I don't have enough info to review this properly" is a valid review as well. It signals that somebody else needs to pick it up.
> I fear that compounding that by layering on another obligation to the star team members would further push them out.
I get it, but I don't see an alternative.
1. the company culture must value reviews as work, probably even more important than coding
2. the reviewers must be allowed to respond with "I don't feel comfortable reviewing this because I don't have enough context"
It looks like it's limited to 10 requests per minute, it's less of a hug and more of a gentle brush past.
It's documented as "Per IP", but I'm willing to bet either that documentation is wrong, or it's picking up the IP address of the reverse proxy or whatever else is in-front of the application server, rather than the originator IP.
People who make statements like that are the kind of people you dread will pick up your pull request. You just know you're going to go from maybe spending an hour cleaning up some suggestions to a 3-day philosophical battle to get them to a point where they deign to accept your PR.
Not at all. If the code is decent and shows effort I have no problem. If it's sloppy it shite code.
I really don't have time to care about what my peers think of me. It's work. I don't want to communicate with them outside work. Work is just another mind space that stays at work. I am strict when it comes to code, I expect the same.
I want working maintainable code to enable me to do my job. If people dread submitting a PR because they can't write code with effort, good. I like my ships built strong not weak.
If they fix their problem, good. Trust given, more than happy to salute however time and time they've proven to me they don't.
These developers have proven to me they won't. These are developers who are those who do not fix the issuing code and will just move on to the next problem hacking it to make it work.
If you've never worked with such, then lucky. If this sting for you, time to put more effort in to your work.
No, they really don't. They submit their code. I submit mine. If they have a problem with mine, I'll fix what they have issues with if they are reasonable, why wouldn't I?
Where I work in enterprise your peers change daily. With my role and importance to the company implementing hacky code puts me at risk and so I will of course push back. The people I knew last months may not even work in the company.
The view of I must be a horrible person comes from the Comment OP being angry at me for having a reasonable standards to an Enterprise standard of code. "It works im done. Next please"
If their code isn't up to scratch I will tell them and reject it. The issue I have is lazy developers who implement hacks and don't actually go and fix the code.
I am being made the bad person from someone's angry hospitality. All I was saying is that lazy developers are lazy developers and that I axe their work because it's sloppy and doesn't deserve to be on show.
I'm not to engage further as you're only ever going to repeat yourself in more obnoxious ways, but I will say that if you treat people in real life the way you comment here, you will only ever be tolerated at best. Never respected and never liked.
Even the people you consider peers will abhor that you think and speak like this about people.
I agree there's a teaching problem happening somewhere. I'm not sure I blame CS-education since I'd wager that most developers don't have a formal CS background.
I too regularly however come across people who believe some or all of the following:
- "Everything is ultimately just C"
- "All other languages just compile to C, so you should use it to be fast"
- "C is faster because it's closer to bare metal"
- "C is fast because it doesn't need to be interpreted unlike all other languages"
The special elevated position of C, being some kind of "ground truth" of computers is bizarre. It leads to all kinds of false-optimizations in practitioners in other languages out of some kind of misplaced confidence in the speed of C relative to all other languages.
The idea that C is "naturally faster" due to being some kind of representation of a computer that no other language could achieve is a hard myth to shake.
My layman understanding is that it's the other way around, C doesn't have a string type.
Since C doesn't have a string type, "quoted strings" are actually char[] but with '\0' as an extra last character.
People have therefore made warnings happen when defining a char[] which silently truncates the '\0', because that's a common source of bugs.
They've then had to develop a way of easily disabling that warning from being generated, because it's also common enough to want to avoid the warning.
All of this seems insane coming from a modern language.
But look at the complete disaster that was the Python 2 -> 3 migration, a large motivator for which was "fixing" strings from a non-unicode to unicode compatible type. A decade or more of lost productivity as people struggled to migrate.
There's no way to actually fix C. Just keep recommending that people don't use it.
Yep, agreed on all accounts; I'm an advocate for Rust for Linux for these reasons, among others.
My thinking was that the Linux kernel already uses a custom dialect of C with specific features that benefit their workflow; I'm surprised that one of those features wasn't a
char[] charset = b"abcdefghijklmnopqrstuvwxyz";
that would allow for intent to be signalled to the compiler.
> What surprises me is how much people on this site underestimate facebook.
It’s the classic disconnect between engineering and product management: When engineers don’t want a product and therefore conclude that nobody wants the product.
When I’ve brought up Facebook active user stats here in the past I got flooded with responses suggested Facebook was lying or manipulating their user counts to pump up the stock.
Yeah, I often see claims online that Facebook is dead, Facebook is just Boomers posting pictures of their grandkids, etc. Maybe it's a regional thing, because where I live, everyone's on Facebook. Most small businesses, organizations, and communities here use it as their primary (or only) online presence for promoting themselves and staying in contact with their customers/members. Marketplace has completely replaced the old newspaper classified ads. That's unfortunate since the search in Marketplace sucks, but it's happened.
My family uses its messenger for organizing things because everyone has it, even if some of us rarely use it except for that. If I wanted to draw attention to something locally, whether it was promoting a service or running for office, I'd be a fool not to use Facebook.
Part of the disconnect is that these days, a lot of the Facebook use is concentrated in places you don't necessarily see from the outside.
Like, fifteen years ago, if you happened upon the Facebook page of a random person, you'd usually see a handful of vacation pictures, a meme or three, some updates from their latest Clash of Cookie Farm Kitchen Dash session, and whatnot.
These days, all that stuff - if it's even still being posted - is likely siloed away to Friends-only posts. That random person might still be there, might still be logging in every day, but you don't see the Messenger group chats and the Marketplace offers/haggles.
Likewise for small businesses - a lot of the "look at this thing we're selling now, come check it out" posts now go to Instagram. They might still be auto-logging in, still responding to PMs on Facebook, still clicking a few news posts here and there, but that's just not visible on the outside, and creates the perception of Facebook the Ghost Town.
I'm confused about what exactly constitutes "slam door", because wikipedia says they were last in operation 2005, but there were definitely still the type of "open the window to open manually" type used on the Reading / Paddington line well after that. Is the difference that they had central-locking?
IIRC it largely depended on the age of the carriage. Some newer slam-door carriages had the door sensor and remotely operable lock, but most of the stock did not and was of an age already that they were due for replacement so retro-fitting wasn't cost-effective. That subset which did have the mechanisms in place may not have been counted in what was decommissioned in 2005 & prior. I'm pretty sure I used slam doors later than 2005 too.
> [...] what matters is what the judges decided
But then say
> SQL schemas are basically the opposite of file layouts
Which is you disagreeing with what a judge has decided?
It seems hypocritical to shut-down someone arguing with one aspect of the case on that basis, only to end with your own disagreement with a judge's decision.
reply