HN user

phuff

639 karma

Email me any time: phuff.hn@gmail.com

Posts1
Comments171
View on HN
Show HN: 18 Words 14 days ago

I wondered about this because I used a keyboard to do it. But then I thought maybe krick used mobile and there's no onscreen keyboard. But then I realized that krick said mouse skills and so is probably on a desktop. I think maybe just some graphical indicator that you can type would be helpful for first time users.

I don't think this rule is universal.

Counterpoint: Most workplaces would be best served by a team of developers who help up level each other without causing morale issues when knowledge gaps, which everyone has, inevitably show up.

This type of environment is the best for software development organizations specifically because most software development shops that have more than one person working on a codebase or system or set of systems have already reached the point where no single person can keep the whole thing in their head at once.

Maybe that person really worked in an environment where they didn't have to think about pointer arithmetic. Reframing closing knowledge gaps as a beneficial and necessary part of a healthy development system makes it so when somebody doesn't know something and needs help they are willing to get it quickly. And that they will talk about knowledge gaps openly so they can be filled with the collective pool of the organization .

Shutting that down even by just "narc-ing" on the person just makes it that much harder when others need to know something they don't to get a job done, slowing down the system over time.

[C]onsumers, on the other hand, are mostly looking to waste time, which is why attention- harvesting advertising is the only software business model that works at scale for consumer services.

I came here to talk about this, like some other commenters did, too :) I think that this _is_ a predominant view amongst most of Silicon Valley but I think it's kind of a local maxima view... Easy to agree with, easy to see that it's a functional idea, but... people... (i.e. consumers) do lots more than just waste time on their phones even though I bet that's a huge amount of what people are doing across the US right now.

I guess the thing that _is_ true about this nugget is the "at scale" part. It's hard to find things _at scale_ that people would pay for on a phone. So the phone sort of falls back into this easy to monetize thing via advertising. But I think people (qua consumers) probably can clearly be a sustainable market for way more than attention harvesting (or dopamine fracking!) but it requires a lot more effort to think of things that you can build a market out of there. So people sort of lazy-back into attention harvesting via ads.

I think that this is an attack on the understanding of the LLM _potentially_ but it doesn't seem like it's likely to standup to legal scrutiny?

Seems like this is pretty clearly a case of fraudulent misrepresentation (https://www.law.cornell.edu/wex/fraudulent_misrepresentation) which kinda nullifies the contract, if I understand correctly:

  Fraudulent misrepresentation is a tort claim, typically arising in the field of contract law, that occurs when a defendant makes a intentional or reckless misrepresentation of fact or opinion with the intention to coerce a party into action or inaction on the basis of that misrepresentation.
  To determine whether fraudulent misrepresentation occurred, the court will look for six factors:
    A representation was made
    The representation was false 
    That when made, the defendant knew that the representation was false or that the defendant made the statement recklessly without knowledge of its truth
    That the fraudulent misrepresentation was made with the intention that the plaintiff rely on it
    That the plaintiff did rely on the fraudulent misrepresentation
    That the plaintiff suffered harm as a result of the fraudulent misrepresentation
  Like most claims under contract law, the standard remedy for fraudulent misrepresentation is damages.

This is a great bug report! I am not a kernel expert by any means even though I have read some about it... 10+ years ago. And I was able to follow along and see what was going on.

It does make me scared for what other dangers lurk since this was a really bad one and it was so little work to find.

Also of note: so many security issues lately have been done using AI. This report makes me think two things:

1. Expertise is still immensely valuable, the more niche, the more valuable.

2. There are lots of niches still where AI doesn't dominate...

I present an alternate etymology for homelab. Instead of "lab" as experimentation space, think of it as lab: place for doing work. Away back in the day we didn't have laptops to work on university CS classes.

So you had to go to the lab to find a computer beefy enough to do your work on.

It's not a home "lab for experimentation.".

It's a home "lab for getting work done."

ADHD (and many other psychological struggles) can be managed with practice and good habits and time. You seem to have a desire to change (evidenced by posting here) which is a great signal you are in a place to make changes in life. If you want, you can learn now how to make changes in your life to work with your ADHD and learn to manage it's effects, thereby being more successful than you would have been leaving it undiagnosed and poorly understood. This is a great position to be in! You know are in a position to learn the skills you need to manage the ADHD.

Additionally, you seem to have diagnosed yourself as having a skill deficit with interviewing. This is also a great position to be in. If you want to work on interviewing, which based on your message it sounds like is your weak skill, then invest time (and maybe money) in practicing that skill with the added understanding you have (and skills you are building) about your managing your ADHD.

One way to think about this is to treat interviewing as a separate skill set; there really are lots of online resources that teach you to interview these days. Practice interviewing as a separate skill set.

You can invest in this skill with money; leetcode and other sites really package this as a service. The benefit to you is not that they will grant you a job offer; it's that they will grant you the opportunity to practice in low stakes environments. There are also places online that are pairing people for interview practice.

You can also reach out to people you have worked with previously and say: I want to practice interviewing; would you spend 30 minutes with me doing a mock interview? People love to help each other.

At the same time continue to invest in managing and understanding your ADHD by working with professionals to develop those skills. Combine the two and some time and you can do this.

You'll get this. Hang in there! Feel free to email me if you would like to talk more.

You can see it in cost explorer if you break down by one of the spend types. Went and checked it: group by usage type and then filter for service: RDS and you can see your io usage broken out in plain baa cost explorer.

[dead] 3 years ago

Regardless of the interpretation of these maps, these do seem to show the power of a good tool built for the free market.

Here you have an app on everybody's phone that is such a useful tool that the government isn't even thinking to turn off in the middle of a war even when it's providing real time intelligence in the open about what is happening on the ground.

This seems like a great example of how openness in technology can overwhelm even one of the least Democratic governments through transparent infrastructure.

I bet when they were building Google maps back in the early/mid 2000s they never thought their tool would be used for real time tactical war reporting on civilian and troop movement.

I have been remote, working outside Silicon Valley for Silicon Valley companies for 16 years (4 companies). The difference in salary/cost-of-living was initially a greater part of my value prop to Silicon Valley companies than it is now.

I think over time (say the next 5-10 years) there will be upward pressure on remote salaries and eventually they will normalize to being approximately in the same range as the Silicon Valley ones because of economic pressure: everybody is still going to be competing for workers everywhere. The competition is simply going to get bigger as firms realize they can hire top talent from other places and they need to in order to find and keep the best people.

From the lens of the internet as means of disintermediation in society this makes sense. Using this framework to reason about the internet, we might think of different ways that the internet removes barriers to communication; recently there are several social phenomenon where the internet has removed geography as a barrier to communication enabling lots of different social changes. In this framework, salary and employment markets were just slowly going to eventually get geolocation disintermediated. The pandemic has just sped that up 5-10 years. Now instead of taking 10-20 more years it'll take 5-10.

I know this has been discussed and rediscussed but the notion of thinking about human organization blackboxes trading work with each other the same way we think about how distributed systems blackboxes trade work and communication with each other I think is a huge insight for helping software engineers understand the complexity of human organizations.

You want to avoid single points of failure, optimize bottlenecks, build in redundancy in similar ways etc. Etc. It's a great insight.

I got a Fiio M7 for Christmas or my birthday a year ago. It's amazing how awesome it is to have a device that's dedicated to music and does a great job at it. There are side loadable apps like Musicolet that also do a great job of providing all the music management you could want.

"This is the kind of magic that sometimes happens when an engineer gets to talk directly to the users to find out what they are doing"

I think this is also the kind of magic that happens when a business is operating well and it's employees have empathy for each other.

If Engineering and Product are well aligned it should be a matter of habit to be looking for and executing on regular projects like Olaf's new menu item or the auto fill of a new account form mentioned here.

As engineers and engineering management we can make sure there is room in our schedules for these kinds of small projects.

And if we develop well our relationships with our product managers we can make those conversations like the one about the form auto filler easier to happen: "this is three hours of work tomorrow that will save this team 10s of hours each week until we get the new system built, it's worth an afternoon one sprint for a developer".

But also what I think is best displayed in this report is empathy :). Organizations that show empathy for their users are ones that tend to be the best to work for because they actually care about people who are using their products and the people who are making their products. And in general, over time, I think empathy builds better customer and employment relationships which then builds better businesses.

I think there are a lot of strategies for dealing with the kinds of issues you're working with, but a lot of them involve building a good engineering culture and building a disciplined engineering practice that can adapt and find best scalability practices at that level.

We do billions of requests a day on one of the teams that I manage at work, and that team alone has sole operational and development responsibility for a large number of subsystems to be able to manage the complexity that a sustained QPS of that level requires. But those subsystems are in turn dependent on a whole suite of other subsystems which other teams own and maintain.

It requires a lot of coordination with a spirit of good-will and trust among the parties in order to be able to develop the organizational discipline and rigor needed to be able to handle those kinds of loads without things falling over terrible all the time and everybody pointing fingers at each other.

But! There are lots of great people out there who have spent a lot of time figuring out how to do these things properly and that have come up with general principals that can be applied in your specific circumstances (whatever they may be). And when executed properly I would argue that these principals can be used to mitigate the burnout you're talking about. It's possible to make it through those rough spots in an organization (that frequently, though not always, come from quick business scaling -- i.e. we grew from 1000 customers to 10,000 last year) etc.

If you're feeling this kind of feeling and the organization isn't taking steps to work on it, then there are things you can do as an IC to help, too. But this is all a much longer conversation :)

I got an Android DAP for Christmas last year and found that I really like musicolet: https://krosbits.in/musicolet/

It works really well. It has the playlisting/queueing metaphors that I prefer and it has a decent interface for finding things or even playing all of the albums from a specific artist.

Having read some of Dan Luu's other prose I think this is a bit unfair. The sort of meta analysis of writing always comes off a bit navel gazy I suppose, but I don't think you have put his post in context with some of the other things he's written. In those entries of his blog I always find the prose flows quite nicely.

`phone` and `talk` were two of my favorite things to do on the internet way back in the day. Almost better than IRC was starting up a chat with somebody on the local University VAX or Unix boxes that you had never met before.

This and the .plan/finger posts from a few days ago are playing to the nostalgia of a better time on the internet. :). Iirc you could also do fully animated .plan files on VAXes at the time.

Nextroll | Remote, various locations in the US | Senior + Staff Engineering, distributed systems, Erlang, Rust, etc. | Full-time

I'm hiring for several senior/staff engineering positions working on distributed systems in Erlang with some elixir, go, and exploratory rust sprinkled in here and there. If you're interested please feel free to send an email to the link in my bio.

I dunno -- if you work on software you get used to the fact that there's always something that could be better, something that could be fixed. Something that could have a smoother user experience. This is just part and parcel of the nature of the medium. Given that they likely didn't realize this was a high priority feature until the pile-on here, and given that they're likely to re-prioritize this item to the top of that long backlog... do they really owe compensation for just having a backlog?

I mean -- I kind of feel like if you're going to store your core business information in software, you're just going to have to deal with the fact that software has bugs. It's the nature of the beast. So, is it really something they owe compensation for?

Probably they owe a bugfix, that I grant you, but compensation? I mean I guess if there was an explicit contract for the feature that tied compensation to it I could see a good argument that they owe compensation. But do they owe compensation to the good people of Hacker News who are suddenly talking about DDOS-ing the feature? That seems like a much harder case to make.

Empathy. A lot of these suggestions here don't show it. Sure, Notion should fix this feature. If your backlog is completely free of features that are no brainers, raise your hand.

Anybody with your hand raised should be ashamed of yourself because I bet it's not true :)

Sure they should fix this -- but is this something they should be fined for? Or be DDOS-ed by Hacker News readers? Or GDPR reported for?

It's just not a great way to get help from up and coming businesses to force major financial pain on them and it's certainly not empathetic to what's likely a hard working, reasonable set of people on the other end of this service.

Hey I did this, too! I forgot until just now :)

https://github.com/phuff/epub_builder

I built it because I wanted to have something that made a daily brief news paper that was personalized and sent to my kindle. It makes an epub and uses kindlegen to convert it to a .mobi. There's a lot of fun epub formatting stuff you can do.

Here's the system that makes the daily newspaper, but it's been so long I'm not sure it's actually functional code outside of my production version:

https://github.com/phuff/steward

The first thing I think I would say is: Hang in there. Regardless of your situation there's going to be a way out of it with the facts on hand -- you have a lot of the skills you need to do "Senior Software Engineer" type roles, as well.

For example: one large professional skill you have is this: "I've been able to always have work on my desk because I'm always moving and talking with people in the industry" combined with this: "I've always managed to solve the problems in front of me but in a 'hacky way'."

Those to things together say to me: "This person is able to communicate with others in order to solve problems" which is really one of the key differentiators between a more "senior" software engineer and a more "junior" software engineer.

I have some questions: Are you still at the company? If so I think you have a great opportunity ahead of you to improve some of your software design/engineering/crafting skills while leveraging some of your strengths.

If not, I think you should consider another medium sized company and not worry about this most recent experience as being the end of your software career.

Next question: The code that was filled with hardcoded values, wrong structure, difficult to debug bugs... was that your code or the existing code? If it's your code, then you're in a great position (like others have said) because you've already identified problems and so that's your list of things to work on next.

What does "failed to accomplish it" mean in terms of the task? The thing about software, especially at a company that's not going to go down in flames because of a problem you've failed to solve is that... you can try again. You can keep taking swings at the task until you figure it out and eventually knock it out. So that doesn't seem bad.

"I'm thinking about looking for semi senior roles but I'm afraid it'll look weird..." As a hiring manager who's been interviewing people in this industry for more than 15 years it never looks weird. And if it looks weird and you have something to offer and the company can't see past whatever "weirdness" that's their loss -- you sound like a thoughtful, introspective employee who's got an impetus towards self improvement. That's gold.

You could transition to PM, you could "take a break" -- but I'd want to think carefully about the answers to the first few questions if I were you because it sounds to me like you are interested in software development and are interested in self improvement in software development and if so it sounds to me like you have a great opportunity in front of you.

If you are still feeling lost, and actually make it to my message, hit me up at the email in my profile -- I would be happy to talk about it further in more detail.

Most of the popular strategies for playing Diplomacy include telling people that the player is going to do one thing and then deliberately doing a different thing. Those strategies mean that essentially the player has to lie in order to be successful.

This means that essentially what we're doing with these kinds of AI experiments is headed into the: "How do I teach the computer how to lie" territory. And that seems bad for a whole host of ethical reasons.