Agreed on SpaceX and partly on Tesla. What is his “tremendous positive impact” with Twitter and Boring? Not trying to argue, just curious if there’s something I don’t see.
I like Musk's reincarnation of twitter. I didn't care much for the "sanitized for my protection" earlier version. I wish I could buy some stock in X, though I understand keeping it private to keep the scourge of activist investors out of it.
Hmm but Wine doesn't work on recent versions of macOS or Apple Silicon anyway, right? But hopefully the Apple Game Porting Toolkit makes it easier for Mac users to play games...
I think that’s not right — there’s even a commercial product (code weavers crossover) which is exactly this — wine for Apple silicon which can run amd64 windows games on apple silicon).
> electrified, so that your daily commute is efficient and environmentally friendly.
Moving an off-road vehicle of over two tons to transport (usually) one person to work seems neither efficient nor environmentally friendly. The vehicle being electric doesn’t change that, as the electricity has to be generated somewhere.
I do nominally agree with you. But I'm also pretty sure I can't convince my coworker or my sister-in-law to switch off of their Jeep.
But switching them to a Jeep Wrangler 4xe is much easier. They seem more amendable to that idea, because they want an offroading vehicle so much. I do think its a bit of a "cosplay" situation because they only do offroading one or two times per year, but ... yeah.
Anyway, getting +5 MPG and electrifying the overall drive of a Jeep will save a ton of fuel. If I can't convince them to drive efficiently with a Corolla, I'm still happy to convince them to get a more environmentally friendly decision here.
Use common sense, and organize your team in a way that works.
Students tend to learn to do that in university group projects. Then they join the industry and we tell them "you need to gather everyday at the same time for what we call a 'stand-up', where we talk to each other". Guess what? The students were communicating without having to make formal stand-ups, and it worked.
I’d say that it depends on who you ask when it comes to what’s „common sense“ and what’s „a way that works“.
What I have seen working is:
- Have somebody who is responsible for understanding the customer from a business perspective and be able to explain that to developers in the form of prioritized development items.
- Try to build something that works to confirm your assumptions and manage risk, ideally on a short-ish cycle of a few weeks. Always keep a working product. In some projects this is not (immediately) possible - in that case, it’s probably better to run a traditional waterfall-project, with the tradeoffs that come with it.
- Get together regularly to talk about less immediate topics and improve the work process.
- Plan and make forecasts using actual data from the past, not wishful thinking.
And that is basically Scrum. For me this is common sense, I wouldn’t know why you would do it in another way.
How it’s implemented in practice differs and it seems a lot of places don’t implement it very well. So far I haven’t heard many good suggestions from the developers suffering under these implementations on how to make it better though, hence my question.
The devil is in the details. The problem is the cargo cult that goes with Agile. You can take any example that works and say "this is Agile!". But in practice, what happens with Agile is that some people come with their book that they treat like a bible, and try to apply it without question.
I have had teams where we were communicating really well, but still we had a 40min standup everyday where we would basically say "as you already know, <blah>". Still we were doing standups, because the bible says we should. We could have used that time for a coffee with the team instead.
I have had teams where people were working on very different things, so nobody would listen to the others during the standup, and during the planning, it was 10 times a 1-on-1 with the team lead because nobody really cared about the tasks of the others. Everyone but the team lead was losing their time. But the team lead found it useful (obviously).
I’d expect from someone making 300kUSD a year to come up with their own ideas instead of spinning their wheels. Reading the article and some of the comments here, that seems to be an unpopular opinion, at least in tech.
It can be pretty stifling on giant teams to make any actual change.
Sure it sounds romantic to sit down with a cup of coffee and write some amazing code that makes things better. The reality is writing documents, hunting down code owners and stakeholders, organizing meetings and running into tons of adversity just so you can attempt something very risky as it is impossible to have full context on everything.
Consider that companies like these can afford to pay $300k USD precisely to just spin their wheels, because they simply don't want them going elsewhere where they might compete...
Sounds to me like they aren't paying enough for talent if they can afford to leave it unused. Very similar to landlords being able to afford leaving a property empty rather than lowering the rent.
One doesn't get paid $300k/year to fuck around and choose what you work on yourself. Very often you will get punished for making management decisions above your pay grade at this level.
As a manager in big tech, it’s fantastic when folks come up with their own ideas. But the hard part is not just coming up with the idea: you have to evangelize it horizontally and vertically, and be open to the possibility that there are valid reasons not to do your idea. Helping folks sell their idea or convincing them it might be a hard sell is part of my job.
The whole point of Scrum, in my opinion, is to create a working increment in the sprint. That’s the mechanism for managing risk.
Finishing tickets for writing specs don’t achieve that. Unfortunately, it’s a common practice though.
Yeah, having running software forces you to prove a certain level of correctness and lets people test against it.
You can call a spec done arbitrarily and it's much harder to test that spec against any number of edge cases; and harder to visibly inspect "do these two specs get along" than "did this API call to this other place succeed?" "It doesn't compile" or "it throws an error" or "it doesn't do what it should" are all much more concrete and force you to confront "we might not understand the problem as well as we thought."
