I’d rather have SteamOS officially support more devices including desktop. Good on Valve for giving people options though.
I’d rather have SteamOS officially support more devices including desktop. Good on Valve for giving people options though.
Such great products. Now we get…image generation, inpainting and a conversational AI. All technically impressive, but those older products were actually functional and solved everyday problems.
Wow that is pretty damning. I hope Google is adding all this stuff in with the replacement of Assistant but it’s Google so I guess they won’t. I replaced Assistant with Gemini a while back but I only use it for super basic stuff like setting timers so I didn’t realise it was this bad.
They did the same shit with Google Now, rolled it into Assistant but it was nowhere near as useful imo. Now we get yet another downgrade switching Assistant with Gemini.
As I like to say, there’s nobody Google hates more than the people that love and use their products.
Great news! The more devices running SteamOS the better
It was a joke on the dual meaning of “user repository” which I didn’t think about that deeply but that would have been smart.
And the Arch User Repository is really handy when you need some more users.
Oh nice that sounds awesome! The only similar kinda thing I remember from back in the day was Microsoft Zone. Used to play a bit of Total Annihilation on there.
I don’t but it’s probably pretty region dependent. In Australia I used to play on Internode servers a lot.
Those were the days for sure. Dedicated servers were fantastic, you’d often run across the same people in the same server as well and get to know folks. A community, like you said.
Microsoft set themselves up the bomb
For the CCP arbitrary enforcement is less a risk and more a guarantee.
This looks pretty interesting! I haven’t used fedora before either so could be good to give it a go. I’ve had some issues with my Pop OS install so could be a good excuse to try something new.
I’m curious about why you think this. I’ve seen complex multi year efforts succeed and continue to evolve with agile principles in mind. What specific part of agile do you think would necessarily cause the issues you mentioned?
Fair enough, at my job the code working consistently is absolutely the number one priority at all times but I can imagine that there are some places where this is not true. If working software isn’t imporant then I agree agile is probably not the right choice
It’s worth pointing out though that having insufficient documentation is not a feature of agile. Sounds more like laziness or misplaced priorities to me as documentation is called out as being useful in the agile principles, just not as important as working software.
I don’t understand what you mean, why would coordinating across a large group be against the agile principles? It sounds like the main issue here is lack of communication and planning which are both important parts of any process including one based on agile.
Planning becomes more important for a larger project but if you hyper focus on sticking to the plan even if things change you can end up delivering something that is not useful for your customers, so I think the principles still make sense there.
Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.
Yes, and daily standups are not a requirement of agile in any way. The whole point is people over process and adapting to change rather than following a plan so if standups aren’t working you should stop doing them rather than following a rigid process!
Note that this is failure to deliver on time, not failure to deliver full stop.
I also think a lot of places claim to be agile, but don’t follow or understand the principles at all. Another commenter here is the perfect example of that where they say the opposite of what’s in the agile manifesto and claim that it’s a representation of what it says.
Maybe that’s a fundamental problem with agile. It’s just a set of loose principles rather than a concrete methodology being pushed for by a company and it has therefore been bastardised by consulting companies and scrum masters claiming to teach the checklist of practices that will make your company agile. Such a checklist does not exist, it’s just a set of ideas to keep in mind while you work out the detailed processes or lack thereof that work for you.
For anyone that wants to refresh their memory on the agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Just have to make it until after work and I can have a break
Just have to make it until the end of the week and I can rest for a couple of days
Just have to make it until the next holiday
Just have to make it
I would say as a new junior dev you are uniquely placed to help with this. Documentation tends to be written by people who know a lot about a thing and they try to imagine what might be useful for someone. Someone new coming in with a fresh perspective can help uncover assumed knowledge or missing leaps to make the documentation better. One of the common onboarding steps I’ve seen is to go back and update/improve the onboarding docs after you’ve just been onboarded for example.
I would say pick your battles though because documentation can be a never ending task and documents are almost always out of date shortly after they are written. Think about what would have saved you time or mental overhead if it was just written down and fix those first.
As far as organising and writing, every place is different and it can depend on the tools your org is using. In general I’d at least have links to relevant docs as close to where they might be needed as possible. Like how to set up and get up and running with a code base should probably be documented directly in the readme, or at least linked to if it’s overly complicated.
Hopefully that’s at least somewhat helpful. It’s definitely a problem basically everywhere I have worked though, you have to do what you can and not stress too much about it.