NAHWheatCracker

Perhaps that can work, but I'm skeptical whenever the solution is "another manager".

Sick, I couldn't figure it out when I needed it so I just manually created a 20 line script to cd into each directory and go build.

I agree with you completely that you need trust.

> Our job is to highlight the tradeoffs they’re making so they can make informed decisions.

This is an oft-stated thing that I oft-disagree with. It states that engineers ought to be subordinate to PMs, which shouldn't always be the case.

If you have shit engineers and great PMs, the best outcome is likely to shift decision making to PMs. If you have great engineers and shit PMs, decision making should shift towards engineers.

If they are both equivalently shit or great, it should be a balance. I believe this is the most likely scenario. I believe that balance is thrown out the window if engineers "highlight the tradeoffs" while the actual decision making is lies with the PMs.

How to actually achieve balance is extremely idiomatic to the team and organization. It's hard to get people to have adult, non-confrontational discussions about this sort of thing, however. Too many people will treat it as a negotiation.

My experience with go build ./... is that it compiles everything but it doesn't make the binaries.

> When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built.

From https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependenc...

A bit annoying when you want to build a bunch of executables, but it's not something I need often and it's easy to script.

All of the teams I've been on have used one list. I've never seen a PM prioritize the technical work. I still think it's a good idea for it to be one list, but it's not sufficient.

For teams that don't have a good PM, you also need a tech champion. Failing that, engineers need to inflate estimates and do tech work under other stories. Then everything becomes less predictable and teams never develop trust.

AMD+TSMC revenue was almost $100 billion in 2023. Intel was $54 billion.

They shouldn't have 20k more people with half the revenue.

You would have been paid $17.7074 in dividends, according to https://seekingalpha.com/symbol/INTC/dividends/history.

If you bought one shared near the end of 1998, you would have paid around $30. That share would be worth around $22 now. So, you would have gained around $9 not accounting for reinvestment of dividends.

Not a good return on investment, in comparison, but you picked 1998 in the middle of the dot com boom. If you picked the end of 1995, you'd have paid $7 and have around $40 today, which isn't too much worse of a return than the S&P 500.

This isn't to say Intel hasn't been poorly managed, by the way.

It's just about tradeoffs in system design, nothing as specific as K8s.

I think the author just wanted to write a glib little blog post.

I honestly feel like that would be a good thing. It would push people towards alternatives and create competition.

If Gmail had a $5/10/20 per month fee, I would probably migrate to a more privacy/security focused provider.

I wouldn't pay much for YouTube, but video hosting is relatively easy and YouTube has degenerated so much that I'd like to watch content elsewhere.

I would pay for Kagi and ChatGPT each twice before I would pay the same amount for Google Search.

Good luck charging for Chrome and any of their developers tools.

I know there's a million services by Google and I would probably demean most of them and I'm not near the typical consumer. However, if the typical consumer at least had to consider whether to pay, there would be so much breathing room in many industries. Something as large as Google trying to explicitly monetize all those services could also tremendously change consumer attitudes towards being willing to pay for things thus making more businesses viable that do less of the shitty stuff that Google does. For a bit, there would be some bad will as people notice extra bills. It sucks that those extra fees would disproportionately affect the poor. The most likely case would be something like Google Prime with a monthly $15 or yearly $140, which I don't think is a gross value proposition for an individual of even low means.

Sadly true.

In the time spent gathering believable information to present, you could probably address a reasonable number of small tech debt items.

Large tech debt items probably can't be resolved without some major business-impacting issues. At which point, you might rather not be around.

Regarding bullshitting numbers, I think it's especially a losing game when you are presenting numbers to more experienced professional bullshitters.

I think this is all good advice when you're working with a PM who is making some reasonable forms of semi-objective decision making.

None of this is helpful when your PM has no business strategy to align with, prioritizes based on what's going to make them look good, and sheds responsibility to the developers when things aren't going well.

It makes me wonder, if you're working with a PM who would even consider the information in the article, would you have to gather it for them?

The PMs who I've work with that conscientious as such already have some grasp of the problem. They see slow delivery of features, bug reports, and listen to the engineering team moaning. They get out of the way on stuff they aren't qualified to decide on. They just make sure that tech debt work stays within a reasonable scope and time budget.

The glasses seem fine, but the process did make me feel like measuring my own PD would have been easier. I've done it before for Oculus prescription lenses.

Warby Parker measured the distance between my pupils by having me upload a picture of my face while holding a credit card. I had to upload 3 pictures because I was too close or at a bad angle twice. I'm not sure if they had an algorithm or if they actually had people looking at the photos.

My experience isn't that estimates are impossible or unreliable, even with somewhat novel work. Most of the problems come from a lack of respect and understanding for the estimates and for who is making the estimates.

Back in 2019, I estimated a project to move a product to the cloud so that we could scale it out and make it more reliable. The business was projecting big growth, the existing system required daily baby sitting, and there were features that just didn't work because of poor software engineering. At the time, I barely had any cloud experience, hadn't used Python/R/Docker for very long, and didn't understand the product or business in depth. And yet, I was the most knowledgeable person on the team.

I estimated the project would take me 2 years. The project manager didn't like that. Behind closed doors they talked to my manager who told them 6 months was fine. They didn't talk to me about the team, the scope, the approach, nothing. The project got the green light and I was given 2 fresh grads - one who was awesome and one who wasn't.

Cut to a year later and we're spot-on my estimate, half way. We've delivered the major features and stabilized the product. It scales perfectly and is far below operational budget. Yet people are angry because it was sold as a 6 month project to middle management. The product was worth $10s of millions annually to the company. They're fretting over a couple $100k that they would have spent anyway.

But they didn't respect me or understand why it was 2 years. They could have talked to me about alternative approaches (maybe a lift and shift but I was strongly opposed). They could have asked me what sort of team could have done it faster (4 senior, motivated, knowledgeable, responsible engineers).

I read House of Leaves last year and it was interesting. It was a good story and I enjoyed following footnotes to footnotes and tracing them back and turning the book and figuring out the hidden message.

I have S. I'm waiting to read it since there isn't a whole lot of ergodic stuff. I'm excited.

I should have bought The Unfortunates when it was available on Amazon, but it hasn't been available for some time. $50 for a used copy on Ebay seems a bit much.

Infinite Jest was basically ergodic with all the end notes flipping back and forth, plus the vocabulary.

Something Happened also requires a bit of traversal with long and sometimes nested parentheticals. I remember coming to an closing parentheses one day when I had read the opening parenthesis the previous day. I spent 10 minutes scanning backwards to find the matching parentheses to figure out the beginning of the sentence was that the parenthetical was in.

I'd argue that trying to be most trustworthy to untrustworthy people is often a way to get screwed even harder. On that project, since I was the most productive people who showed regular progress meant that the project manager rode me to get more stuff done rather than fixing the broken parts of the team. I was forced to pick up dropped balls constantly.

Identifying the untrustworthy people is super easy and doesn't help. It takes a only a few weeks to see that someone isn't putting the effort in. If you're on a project with that person, you're often stuck with it with no recourse if the organization and managers aren't willing to do something.

The article doesn't seem to address the main reason I learn not to trust some people: They aren't trustworthy.

At my last job I was on a project with two other developers, two data scientists, and a project manager. At the outset of the project I mostly trusted people to do their jobs. I'd only worked closely with one of the developers, but I'd had enough incidental contact to have a good opinion of everyone else. We divided the work up and made a decent plan early on. Then things fell apart.

One of the developers had a single 3-point spike story open for the whole quarter. He made one boilerplate PR and left no comments in any other PR. He regularly missed meetings and didn't add to any discussions. He talked a big game and never delivered.

One of the data scientists took six months to make an extremely simple model. He made the only PR for it on the last day of the quarter before he got switched to another project. He wouldn't answer any questions whatsoever about how the model worked. It was inefficient and not ready for use. I had to rewrite the model.

The project manager never wrote anything except titles in Jira tickets. He repeatedly didn't follow up on questions, even when we had a clear issue needing feedback from the customer, whom only he could talk to. He was completely oblivious to the lack of progress above, despite never seeing a demo from those people.

Luckily, the other developer and the other data scientist were capable and accomplished part of what was needed. The project was still a disaster because we had the software equipment of a car without wheels. I spent half a year begging my manager to move me to another project when I realized it was going this way.

I love to trust people. It's how I work. I tell you what I'm going to accomplish and I do it, every time. I expect the same from others. I don't care about performance as much as I care about doing what you say you will. There isn't a model to build trust with untrustworthy people.

I use https://github.com/Adamcake/Bolt to play on Linux with a Jagex account.

It's frustrating that Jagex won't support Linux directly, though.

Native English speaker here. "A" is the correct article before the word "walking".

BTW, I changed it so it's iterative, getting 12.5 MH/s.

Yea, I know. It makes me feel better this way, though.

I profiled my code and you're right that it was using a big chunk of CPU on generating the input. Approximately 40-50% of the CPU time was taken up by go's rand.IntN function.

I was able to optimize it so that I only call rand.Int63 twice per string generation, bringing the CPU time of that part down to 10-15%. I'm getting 11.3 MH/s now!

I added some instrumentation and it was doing around 3.3 million hashes per second. Mine isn't sequential, it's generating random strings. Changing from a 64 byte string to a 26 byte string with (14 character nonce) brought it up to around 6 MH/s.

Given the nonces you provided, I guess you're going sequential and you're hashing 2-3 times faster than me. I just got a 7 0 hash in 70 seconds and an 8 0 hash in 164 seconds. You're right and I was overestimating how long I waited around last night.

I guess either my computer or my code is really bad! I only got a mid-8 0s with multiple hours.

SHA256 doesn't generate characters, it generates bytes that are usually rendered in hex form, which gives you the "first character".

There isn't a known way to calculate just the first bytes of a SHA256 hash faster. Each step in SHA256 depends on the value of the previous step, so you have to calculate the whole thing through. SHA256 is meant for cryptography and would be considered vulnerable to attacks if a shortcut were known.

ChatGPT says a desktop CPU uses 105Wh for every hour of maxed computations. I think a hash with 8 leading zeros takes around an hour and every additional 0 takes 16x that. I'll ignore anything less than 8 0s and disregard how close the hashes are to gaining or losing a 0.

There's 13 8s, so that's 1365Wh. 5 9s is 8400Wh, 2 10s is 53760Wh, 3 11s is 1290240Wh.

Total that's ~1.35MWh, which might cost $100 to $180. Very weak estimate, though.

Anyone who stumbles into your SHAllenge ought to know that JS isn't going to be really competitive, so I think you're good. A warning might encourage them to delve a little deeper. I like that it makes it very accessible.

I assume anyone with knowledge about GPU hashing and the will would be able to steal the top spot very quickly. Assuming seletskiy isn't already that guy. I don't have a good grasp on the compute difference between 8-9 0s and 10 0s in a reasonable amount of time.

I ran the javascript miner for like an hour, then I asked ChatGPT to write some go code that worked perfect (minus an unused variable error).

The go program beat the javascript miner within seconds. Right now it's that easy to get into the top 10.

Oh thanks so much!

I didn't consider checking the old domain, I updated my bookmark at some point.

I played this app when it was on netlify and you posted it originally (https://news.ycombinator.com/item?id=38913220). I noticed a few weeks ago the redirection of the domain.

Now I see this today and I'm very disappointed.

I can't click on desktop. It doesn't scale nor does tapping work on my phone. Basically ruined the app for me. I can't imagine my brother-in-law who says he used this app every day will be happy.