lasereyes136 (u/lasereyes136)

lasereyes136 commented on Resigning as Asahi Linux project lead marcan.st/2025/02/resigni... · Posted by u/Shank

drivers99 · 7 months ago

> 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 )

lasereyes136 · 7 months ago

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

prododev · 7 months ago

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.

lasereyes136 · 7 months ago

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

lasereyes136 · 9 months ago

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

SupremumLimit · a year ago

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.

lasereyes136 · a year ago

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

lasereyes136 · a year ago

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

lasereyes136 · a year ago

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.

lasereyes136 commented on Room inspections at Resorts World confuse, annoy DEF CON attendees reviewjournal.com/busines... · Posted by u/jarsin

jedberg · a year ago

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.

lasereyes136 · a year ago

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

subtextminer · a year ago

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.

lasereyes136 · a year ago

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.

lasereyes136 commented on Your Company's Problem is Hiding in Plain Sight - High Work-In-Progress (WIP) mdalmijn.com/p/your-compa... · Posted by u/thunderbong

acuozzo · a year ago

> 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?

lasereyes136 · a year ago

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.

lasereyes136 commented on TDD is Not Hill Climbing (except where it is) tidyfirst.substack.com/p/... · Posted by u/KentBeck

sureglymop · a year ago

What I never understood about TDD is: why would one have to write the test first?

Now, I get that maybe the reason is human psyche and that one may not have the same discipline to write the test after the code. But, stripping that away, more logically asking, why does the test need to exist first?

I get that if you have a test, you have an exact "plan" of what your code needs to do/return and you then work on it until the test passes.. But isn't that the case already in any strongly typed language? You constrain the set of values your function can return to only the set of all valid values by defining a type (which is that set). (Okay I may have answered my own question, as we do define the expected type first).

I think that at the end of the day it comes down to finding a balance between complete formal validation of correctness and productivity/usability i.e. actually getting something done. TDD strikes me as a practice that slows you down a fair amount yet still doesn't offer anything close to complete formal validation, so it doesn't seem that attractive to me. But I still also wonder what alternatives are out there.

lasereyes136 · a year ago

TDD is a design technique you can apply to low level or tactical coding design. Strongly typed isn't the same as a knowing and testing your inputs and outputs based on a plan or design of methods or functions. Sure, strongly typed can make that easier but it isn't guarantee it.

Testing after the fact usually means your tests a designed based on the code and not on what the code should do. Sometimes their little difference between the two, sometimes there is a large difference.

In my experience writing tests first is a slow down to speed up technique where the code is easier to write and maintain because it is tested and has built in regression testing.