Any experience can alter your perception of reality, it doens't change reality. That doesn't mean it can't be a problem that needs to be addressed. It can also be a benefit and help people experience situations that would be dangerous to experience in real life so they get the skills to deal with them without being in danger. Think airline pilots practicing airplane failures in a simulator. The professional airplane simulators are so detailed, it really looks and feels like being in a plane.
Readit Newslasereyes136 commented on Video games can alter reality particle.scitech.org.au/t... · Posted by u/PaulHoule
lasereyes136 commented on Resigning as Asahi Linux project lead marcan.st/2025/02/resigni... · Posted by u/Shank
> Having in the person taking these meetings for a software vendor, it can get really toxic quickly [...] hearing them out was part of the job
Does it have to be a meeting? Although it's about sales calls, I'm reminded of https://keygen.sh/blog/no-calls/ (HN discussion: https://news.ycombinator.com/item?id=42725385 )
No, it doesn't have to be a meeting. It can be any method communication.
lasereyes136 commented on Resigning as Asahi Linux project lead marcan.st/2025/02/resigni... · Posted by u/Shank
This is every successful product, small, medium, large. I've never ever worked on a big corporate or small personal project and not experienced this.
The secret is to have a healthy system for taking in those requests, queueing them by priority, and saying, "you are 117 in the queue, you can make it faster by contributing or by explaining why its higher priority".
You can't let feature requests get to you, the moment you do your users become your opponent. None of those requests are entitled, the author has clearly already reached a point where they are antagonistic towards requests.
I agree that this is needed. It doesn't stop the person requesting the feature from asking for a meeting to explain why and just whining that they need it the whole time and saying they shouldn't have pay anything to get it addressed right now.
Having in the person taking these meetings for a software vendor, it can get really toxic quickly and I never had more than 1 meeting a quarter with really toxic people and they were at least paying for the product and maintenance so hearing them out was part of the job. It unfortunate to get to the point where you view customer requests as antagonistic, but I can see how it happens. Some people really feel entitled, and some have a job to do and limited resources or control to do it in.
lasereyes136 commented on Haunted Graveyards in Consulting datosh.github.io/post/hau... · Posted by u/datosh
Great article, I have I seen this situation too many times to count. It isn't just consultants that generate haunted graveyards. Any person will skills more advanced than their peers will do so. To make matters worse it isn't just the peers you have right now but the peers you will have in the future who you don't currently know and can't predict their skill level.
While the solutions you list can help, it will not solve the haunted graveyard problem, just ask all of the companies with Cobol programs in production.
lasereyes136 commented on Understanding how bureaucracy develops dhruvmethi.substack.com/p... · Posted by u/dhruvmethi
Yes, I meant something else, and of course I'm not advocating for hard to understand code. However, as the sibling comment suggests, what's obscure or hard is relative.
The problem with indiscriminate application of "code has to be easy to understand" is that it can be used to make pretty much anything, including most features of your language, off limits. After all, a junior developer may not be familiar with any given feature. Thus, we can establish no reasonable lower bound on allowed complexity using such a guideline.
Conversely, what’s too simple or too difficult is very specific to the person. Somebody who’s coming to a junior developer role from a data science background might have no problem reading 200 lines of SQL. Somebody with FP background might find data transformation pipelines simple to understand but class hierarchies difficult, and so on. So the "easy to understand for anyone" guideline proves less than useful for establishing an upper bound on allowed complexity as well.
Therefore, I find that it’s more useful to talk about a lower and upper bound of what’s required and acceptable. There are things we should reasonably expect a person working on the project to know or learn (such as most language features, basic framework features, how to manipulate data, how to debug etc.) regardless of seniority. On the other hand, we don’t want to have code that’s only understood by one or two people on the team, so perhaps we say that advanced metaprogramming or category theory concepts should be applied very sparingly.
Once that competency band is established, we can work to bring everyone into the band (by providing training and support) rather than trying to stretch the band downwards to suit everyone regardless of experience.
Reminds me of a dev team I once encountered where they stated they wanted to be expert C programmers and that they didn't understand pointers, so they avoided them.
I told them it was hard to become a C expert without understanding and using pointers and they didn't like that answer. https://daedtech.com/how-developers-stop-learning-rise-of-th...
lasereyes136 commented on Why Scrum is stressing you out rethinkingsoftware.substa... · Posted by u/aard
Interesting article and I have observed all of the situation described in it.
I would like to point out that when agile, and even Scrum to some degree, was introduced it was a way for people creating software to take back control of a runaway process that prevented team from doing their best work. It was a grassroots movement championed by people invested in finding better ways to create software that were less stressful and more successful.
Most of the issues in the article were coopted in Scrum to take control of software creating back from the teams. Whatever replaces Scrum, and agile, will need to learn from the mistakes and compromises of Scrum or it will suffer the same fate as Scrum and become a tool to force teams into a delivery model that gives managers and executives more control while reducing their accountability.
lasereyes136 commented on Why good developers should use bad computers youtube.com/watch?v=ilrTm... · Posted by u/Rinzler89
Makes sense for desktop software, less so for webapps and web services. I agree with the point that developers should profile their apps and for some apps having a bad computer is an implicit way of doing that. It doesn't mean it is a good strategy for everyone.
Since the festival shooting Vegas hotels have a policy of entering every room every 24 hours. If you skip housekeeping, they get suspicious and then they send security to check on you.
Some clever hackers figured out how to use the phone system to make them think housekeeping had been there[0], so now they do inspections when BlackHat/DefCon is in town because they don't trust their own tracking systems.
[0] One of the hotels had housekeeping dial *5 on the room phone when they entered the room to clean, and then *5 again when they left. So some hackers would put out their "do not clean" sign and then just dial *5 twice 10 minutes apart so no one would get suspicious.
They had that rule, every 24-hour room checks, for a few years after the Mandalay Bay mass shooting in 2017. Since Covid they removed that rule and don't do the room checks every 24 hours, unless, I guess, they really want to do it.
Room service counted as a room check so security only did it if you refused room service.
lasereyes136 commented on Are rainy days ahead for cloud computing? bbc.com/news/articles/cd1... · Posted by u/makaimc
Enterprise Linux was getting going for real in the late 1990s but in my view it was more 2005-ish that it became "mainstream" in these sphere. Sun Computer for example started to support Linux in 2006 and was a Hail Mary to try to save itself as SunOS was being eaten away by Linux.
Redhat Inc became part of the Nasdaq-100 in 2005.
I make this comparison as the question is whether OpenStack still has the potential to become a full go-to alternative in the way that clients consider closed cloud systems from AWS/GCP/Azure as substantial equivalents.
I see your point but disagree. Sun was the last holdout of the propriety Unix vendors to support Linux because they had underpriced the other Unix vendors like Linux was underpricing them. Sun's whole idea was to create cheap Unix workstations by using commodity parts and having a low-cost Operating System in SunOS and then Solaris.
Becoming a Nasdaq-100 company is a trailing indicator of going mainstream. By 2005 RedHat and Enterprise Linux had won, and Sun had about 5 years before Oracle purchased them.
OpenStack is great if you want to manage your own data center and some companies should do that. It is a cost/benefit analysis that some will make on the side of doing their own thing.
> if you’re working on more than 2 features
(Honest question because I've always worked in R&D...)
What counts as a feature when you're starting from scratch?
2 features here really mean 2 development tasks however a task is defined for your team. The idea is to have one to work on while the other is in the background (maybe being worked on by your subscience) and to take a new one once one is done, even if it isn't worked on immediately.
The main goal of work in progress limits to get work to done rather than starting new work (that doesn't get to done).
Ideally in Scrum your sprint commitment is a work in progress limit but in practice it isn't treated as such for reasons. Kanban can allow expedited issues to address an "emergency" issue but even that has a WIP of 1 so emergencies have to be prioritized.