-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Twitter and the Chief Twit
- Thread starter Mr H
- Start date
Jason71
Well-Known Member
True, but it does go to the heart of the matter.
In a democracy, unpalatable things/people/views/cultures to many aren’t necessarily wrong or invalid, especially if a different ’many’ hold that view. Let Trump hang by his own words, and be defeated by a more compelling argument in the opposite direction, not by censorship. Same for every politician, Left or Right. The rules of democracy, whether we like it or not, mean any 2 idiots can out vote a genius.
But Trump was using Twitter to incite violence, riots etc. In those extreme cases I think censorship is entirely valid. I'd go further and censor any of the climate-denying idiots. The planet is in such a perilous state now that we simply can't afford to have the fossil fuel lobbyists and far-right halfwits like Farage peddling their - to use a Trump term - fake news.
No, why would they? They were normal, decent people, not deranged, delusional idiots. This is the UK forum by the way.
ACarneiro
Active Member
Illegal things are already illegal.
Did you notice how you were already going down the slippery slope? Ban Trump! Oh, and climate deniers! Just one small step to also ban COVID sceptics! Oh, and flat earthers while we’re at it!
We need dissenting voices to have a rational discourse (Galileo was a dissenter and would have been banned from Twitter by your standards), and it seems to me that censorship is not a great way of achieving that.
Don't worry, I've been deleting any posts I don't agree with since it started
On a serious note, it is drifting away from TMC guidelines. It was left to run as the impact of the twitter purchase could have been/probably is material to Tesla. The inner workings of Twitter, the Trump debate, moderation and what it means etc aren't. (and yes, I put my hand up to adding to that, these things often start in a grey area and drift away from the topic, as interesting as the debate might be).
If we can't swing the discussion back to any material impact on Tesla then it will be time to close the thread.
From now on, off topic, political posts will be moved to the "Off topic - Political thread"
ACarneiro
Active Member
Ah HAH!!! J’accuse!!!Don't worry, I've been deleting any posts I don't agree with since it started
ACarneiro
Active Member
Actually I think it has remained very civil. Not a shouting match at all so far, which is quite remarkable
Jason71
Well-Known Member
ACarneiro
Active Member
Both equally contentious, I would say!We seem to have two threads running of a not dissimilar nature; this one includes the removal of censorship. The other is the removal of sensorship
To give people closure, but without wanting to give the mods a headache, I'll make one post about pairing and anyone that wants to discuss it further can DM me, and I shalln't discuss it here any further.
No, I'm not joking. Yes, it really does work*, and it really does lead to higher-quality code. The reasons are that programming is a thinking exercise and not a typing one, and two brains are better than one. It's better than code reviews (generally) because the feedback is faster - you can stop someone barking up the wrong tree much more quickly. It's better for team-building, as you all need to demonstrate vulnerability and develop social sensitivity. It reduces your 'bus factor' in that every line of code is seen and understood by two humans before getting into production. It propagates knowledge throughout teams more quickly, as they learn each other's tricks. It aligns a team more quickly, as all the arguments about how to do things is front-loaded. It reduces the amount of time spent skiving, because there's always someone else watching. It makes people more likely to show up to work on time, because you know that someone is waiting for you. It is inefficient when people are writing boilerplate code (in which case, you have bigger problems), when you have an antisocial team, or when there are large disparities in skill level that are not compensated for with emotional intelligence. It's much harder than coding solo, and much more mentally draining. Pairing should not be done 100% of the time on everything, and to do so would be considered an anti-pattern by most. It is not for everyone, and not everyone is suited to pairing.
Anyone flabbergasted by pairing should go look up mobbing, which is even more fun And yes, I've used that successfully, had customers pay us to help them mob, and seen it work really well in regulated financial enterprises (JPMC, Index Labs).
*ran a consultancy for six consistently profitable years that used pairing and mobbing almost exclusively, with customers paying up to £1,800/engineer/day for the service. Also surrounded myself with companies that paired and mobbed, and saw them work. By contrast I got customers who solo'd and did Git Flow asking us to help them figure out what their lead-time-to-production was terrible and why morale was so low.
No, I'm not joking. Yes, it really does work*, and it really does lead to higher-quality code. The reasons are that programming is a thinking exercise and not a typing one, and two brains are better than one. It's better than code reviews (generally) because the feedback is faster - you can stop someone barking up the wrong tree much more quickly. It's better for team-building, as you all need to demonstrate vulnerability and develop social sensitivity. It reduces your 'bus factor' in that every line of code is seen and understood by two humans before getting into production. It propagates knowledge throughout teams more quickly, as they learn each other's tricks. It aligns a team more quickly, as all the arguments about how to do things is front-loaded. It reduces the amount of time spent skiving, because there's always someone else watching. It makes people more likely to show up to work on time, because you know that someone is waiting for you. It is inefficient when people are writing boilerplate code (in which case, you have bigger problems), when you have an antisocial team, or when there are large disparities in skill level that are not compensated for with emotional intelligence. It's much harder than coding solo, and much more mentally draining. Pairing should not be done 100% of the time on everything, and to do so would be considered an anti-pattern by most. It is not for everyone, and not everyone is suited to pairing.
Anyone flabbergasted by pairing should go look up mobbing, which is even more fun
And yes, I've used that successfully, had customers pay us to help them mob, and seen it work really well in regulated financial enterprises (JPMC, Index Labs).*ran a consultancy for six consistently profitable years that used pairing and mobbing almost exclusively, with customers paying up to £1,800/engineer/day for the service. Also surrounded myself with companies that paired and mobbed, and saw them work. By contrast I got customers who solo'd and did Git Flow asking us to help them figure out what their lead-time-to-production was terrible and why morale was so low.
Befor I retired I had extensive exposure to Agile Methodologies and remain a total sceptic, in my experience the Quality and Testing was poor leading to lots of Live Issues and negative Customer Feedback. That was on a Banking App where logic would suggest that Quality should be King but it definitely wasn't, I am not a Fan !
EVer Hopeful
Active Member
ok, I'll not discuss it either, other than to say I remain unconvinced by anything you've said in favour of it
EVer Hopeful
Active Member
Let's be honest, Agile is just marketing designed to make money ... and not for the organisations that deploy it
If it was really a good way of designing and building something, then it would be everywhere. Take the building your IT department works in for instance:
Sprint number 1 is The Door - we have no idea yet where the parking lot is, or how many people will work in the building, or what kind of security we'll be using there, or even if it's staff only or for the general public too, whether there'll be a reception desk behind it, how much we can budget for it etc etc, but we want a door, so we make a "story" about someone walking through a door (it has to open and *maybe* close behind them).
So we build it, are happy with it, but later find out all those things we should have considered before because we built in in the wrong place, it was too small to meet building regs and we have to retrofit a security system. No problem though, we just brick it up and make another sprint ... and that's a GOOD thing because we "failed early"
Nobody would build a building like that and there's really not much difference between building a building and building an application
