1
point
godot
Joined 2,317 karma
Hi, I'm not related to the Godot game engine. I picked this username before Godot engine was as popular as it is now (or at least I hadn't heard of it in early 2015. Sorry!). The name is a reference to the Phoenix Wright character prosecutor Godot, which is a favorite character of mine.
- > Could it be bigger? Sure. But at some point — maybe even before 1,000 people — the vibe breaks. The intimacy evaporates. You stop recognizing names. People talk less because it’s harder to know who’s listening. Growth would make it worse, not better. > > Some things work precisely because they’re small.
I'd argue this is true for social networks like Facebook actually. There was a magical period in Facebook between 2005 to 2010 or so where it was mostly college friends, high school friends, some work friends, and we all actually shared what we thought on our posts, shared links to interesting stuff, etc.
When all the relatives started being added to your network the vibe became decidedly different, and then acquaintances, people who aren't close, etc. and everyone has that one experience where one time they post something and someone who isn't close get offended, whether it's political or not, and they gradually share less and less.
- Little fun tidbit: I happen to use the WinXP wallpaper on my Macbook (just for fun nostalgia, and because I like it), so when I open this up on my browser the background blends: https://github.com/user-attachments/assets/70a66a71-3f6a-485...
- I don't have "the right answer" for you but I would just chime in that in the current job market, your best bet is your existing/previous network. Reach out to folks you previously worked with in past companies, especially those in tech leadership positions. With more and more AI applicants trust is weighed more than ever and existing relationships is a major leverage point now.
I don't know if this "should" be how it is but this is the reality based on what I observe now. Hopefully you have some relationships you can reach out to.
- One thing that not enough people realize is that the gap between haves and have-nots widen in almost everything when technology advances, and I don't mean just wealth (that is one too), but also knowledge (LLM/AI widens knowledge gap between the curious and not-curious by a lot), and in this case socialization -- the availability of technology (in both organizing activities like your example and in AI loneliness like the article) widens the socialize and not-socialize people.
In the old days, not-socialize people tend to be forced to socialize anyway; but techonology enables them to not-socialize 99% of time now. Likewise, socialize people needed to put in more effort to socialize in the old days, but now it's easier than ever.
When more people realize this, the discourse should shift from "technology creates this trend" to "technology widens the gap between X and not-X".
- 15 points
- I've been using Cursor pretty extensively in the past few months and I use it to code pretty hard problems sometimes, and a while ago when the options were between claude 3.5 sonnet vs gemini 2.5 pro, there was such a significant difference in quality that claude 3.5 often straight up failed -- the code it wrote woudln't work, even after retrying over and over again, and gemini 2.5 pro often was able to solve it correctly. In a particular project I even had to almost exclusively use gemini 2.5 pro to continue to make any progress despite having to wait out the thinking process every time (gemini was generally slower to begin with, and then the thinking process often took 30-90 seconds).
- I think the general public (and by that I mean including software engineers too) overestimate the likelihood of a huge screw-up leading to being fired like they do in the movies, if the screw-up is neither (1) malicious/intentional in nature, nor (2) demonstrates that you're grossly incompetent for the job.
Most huge screw-ups happen to well-intentioned, knowledgeable software engineers, who simply made an honest mistake.
The correct way to handle it, on the company/management's perspective, is not to fire the person who made the mistake, but to allow them to correct it (perhaps with help from others). And that is indeed what happens in most cases. There are certainly poorly managed companies who would fire someone in these scenarios, but they should be less common than otherwise.
I'm not going to name any names: in the late 00s/early 10s I worked in one of the highest-profile, high-growth tech startups of its era, and I've personally made a blunder that corrupted literally millions of user records in the database. This incident was known internally as one of the most disastrous technical things that happened in the company's history, among a few others. The nature of the product was one of very quickly updating data, and updates were critically important (e.g. is affected by user spends) and hence restoring from DB backups of even the night before was unfeasible. There was irreparable damage where a whole team of us had to spend the next few weeks painstakingly hand-fixing data for users, and coming up with algorithms/code to fix these things as users use the product as they go. As you expect in this anecdote, I did not get fired, I was part of the team that worked tirelessly following this incident to fix user data, and I continued to have a good, growing career in my remaining time in this company (the next few years).
- I'd be curious to follow along and read more. My experience is that everyone's body is quite different and what causes chronic issues with everyone can be quite different. That's not to say his observations and solutions won't be useful to others, but it's another good anecdote to understand and things worth trying for others having similar issues.
I myself for example have had headache and migraine issues for more than 25 years. I understand deeply an incredible amount about what causes my migraines, how they feel, how I help with it, and so on. I understand migraines more than anyone else I ever know in my life because I observe, pay attention, study, and try different things so much. I understand it more than most doctors I talk to. But I also know that everyone's migraines are a little different and not everyone gets triggered by the same things (though there's a lot of overlaps) and my solutions may not help for everyone. I'd totally write something like this for migraines if I had the time (I don't :( ).
- I think most people underestimate how much of their immune system depends on their sleep. Sleep quality, amount (hours) of sleep, time in bed, all of it -- they matter.
In stressful periods, it's likely not stress crushing the immune system, it's the indirect relationship that stress causes bad quality sleep and low amount of sleep, that in turn crushes the immune system.
If, even if under stress, you manage to work out a system/habit that allows you to get proper sleep, you'd likely be ok.
- Would anyone still use a desktop-only (no mobile) messenger where you have to run/turn on intentionally (not always-on like most mobile-first messengers nowadays), lists online/offline friends the way AIM/ICQ did, and you can only send messages with online friends?
I get that most leisure computing has moved off of desktop to mobile in modern days, but there's definitely enough of us nerds who're on a computer a lot (even if just for work, if nothing else). It can't be any less than in the late 1990s when ICQ was popular.
- I realize I must be in the minority of software engineers/tech circles, I do not keep a "personal knowledge management" base.
I do have a personal Notion, but the things I keep in it are like list of restaurants we want to try and haven't yet, list of travel destinations we want to go at some point, the trash collection schedule, things like that. Basically references/bookmarks.
I don't keep reading lists, knowledge I learned, or anything like that in an archive. I rely completely on my own memory in my brain for those. (I also don't open up tabs with intentions of "I'll read this later". Either I read it and close it, or don't. If it feels semi-interesting but long, I just skim it, then close it.)
If anything interesting comes up, I talk about it, typically in a group chat (I have about half a dozen group chats with various friend groups or ex-coworkers groups that are active). If a discussion took place about something, I will likely remember it. If I remember some key points, if something comes up in the future about it, I will remember enough to look it up, whether by Google or by LLM. *
I've lived this way for decades professionally and never found myself missing a piece of knowledge in any context that I wish I had. In other words I don't find a use to keep a personal knowledge base.
For those reading this, maybe it helps you think about whether you need one like this as well. Perhaps like the article author here, you might feel more relieved not having one.
* I also want to note that I operate this way at work / in meetings as well. I find that if I try to take notes during meetings, I can't pay attention fully, and can't digest the information being discussed. It works much better if I don't take any notes at all, pay attention in the meeting, and if there's anything important from the meeting, I try to write it down afterwards (typically in a Slack message) from memory. 99% of the time it works fine and once in a long while I might miss something (but someone else who reads my Slack message would fill out what I missed).
- If you're already doing local ffmpeg stuff (i.e. pretty involved with code and scripting already) you're only a couple of steps more away from just downloading the openai-whisper models (or even the faster-whisper models which runs about two times faster). Since this looks like personal usage and not building production quality code, you can use AI (e.g. Cursor) to write a script to run the whisper model inference in seconds.
Then there is no cost at all to run any length of audio. (since cost seems to be the primary factor of this article)
On my m1 mac laptop it takes me about 30 seconds to run it on a 3-minute audio file. I'm guessing for a 40 minute talk it takes about 5-10 minutes to run.
- > Right now, preparing for these interviews is really gatekept – either you need friends in big tech willing to help you practice, or you have to pay hundreds of dollars for one-on-one sessions.
So I'm probably not your target audience (I haven't had to interview for a software eng job for at least 7-8 years), but from my past experiences in these interviews from that time, system design is typically the most sensible part of the interview process and it really does just test if you have experience solving those problems, or if you're less senior, if you can think at least through the problems logically. There are even pretty good system design interview books written out there. What do you think is gatekept about this?
Leetcode took off as a trend because it wasn't easy for company interviewers to come up with good coding questions, partly because the daily work of most software engineers in most companies simply don't involve much tricky programming. System design is the opposite, most software engineers have to work on system design in their daily work and most companies can simply ask system questions very related to their companies' problems.
Looking at it from this lens, I'm not sure what a leetcode for system design adds in value, that a system design interview book doesn't already give.
- I realized that the smallest background remover ML models (u2netp.onnx) is only 4.5mb and inference can be run in browser JS pretty quickly (a couple seconds), so I built a client-only web app for people to do this quickly without using one of the upload-then-process tools out there (which is most of them from what I can tell). It works decently well for pictures where the object and background are relatively distinct. It's a small model so it definitely struggles with the more complicated cases. It's just intended to be for the easy use cases.
- 2 points
- I googled for "image resizer" and every single one of the top results (imageresizer, Adobe, simpleimageresizer, promo.com, etc.) have to upload the image(s) to their server and it does server processing. The upload itself takes a minute and the export/download process often takes longer. On top of that sometimes there are too many knobs and ads. Most of the time when I need to resize one or a bunch of images I already have a target dimension in mind and want to just do it all quickly.
I wrote scripts to do this before but I figured why not build a web tool that's super fast. With HTML5 canvas there's no real reason to do server upload to do resizing other than to get people to sign up or something. This client-only tool should be way faster than the common alternatives.
- 5 points
- I think in their case, offline is as in you don't need to set up a pubsub server and the client doesn't have to talk to a server for the specific pubsub functionality, not as in "use this for offline web pages/html files locally" (it may or may not work for that, I have no idea, didn't look).
- I like it a lot, and I see from the source you're coding in vanilla js, which is awesome. It's underrated how much of an interactive web app you can build without using any libraries or frameworks nowadays.
I actually also really like the idea of building simple/local web apps in a single HTML page. A while ago my child and I visited a science museum and played with a simple stop motion animator. I decided to make a web app just like it and built it as a single HTML page, copied it to her laptop and she can use it without internet. I built it using React and a bundler though, because I'm too lazy to write vanilla js. It just bundles into a single HTML file. Maybe I'll post a Show HN some time.
- I do agree with this article; I just think there is a time and place for each type of engineer.
There are companies where 10x engineers make sense, and there are companies where normal engineers are better to have.
One good example is the Commandos, Infantry and Police article from 2004 Coding Horror. (you can look it up, not going to link) Typically the commandos are the 10x engineers. Having them on early in a startup is tremendously helpful. As a company grows to stages where you want infantry and police, having commandos / 10x engineers might hurt more than they help. Of course this isn't always true but this is more likely true than not, in most cases.
We as humans, and particularly in America, like to quantize people and use a single variable to rate how good people are. In reality different people are good at different situations. It's not always the best option to hire for the 10x engineers.
- I feel languages and cultures also gradually change over time and over a couple of decades it can be fairly different when you've been disconnected from it.
I was born in Hong Kong and lived there for 13 years, moved to the US and I'm now 40+. I was back in HK last year and although didn't have problems understanding people in Cantonese for the most part, there were situations like calling a restaurant (to make a reservation) where I absolutely could not understand the waitstaff's Cantonese. After 30 years I still consider myself more fluent in Cantonese than English but language and culture had evolved in HK so much that the way younger people talk, especially on the phone where it's harder to hear, is almost completely foreign to me at this point.
- The scenario is a task needs to be done. Whether it's for business, personal, whatever. It's a task. It needs to be done somehow. It can be done by a human, or by AI.
We are calculating the cost of doing this task. I don't know how else we can be more clear.
Honestly I'm very unconvinced by this article author's sense of need to calculate the energy cost of the LLM as an argument against it. But if we're using it as an argument, it's only fair to compare how else the task can be completed (i.e. by the human) and what it would cost. What is there to not understand about this comparison?
- The energy usage concern is also funny in that it doesn't try to compare the energy usage of a human doing the same task (if one were to not use LLM to do the task). If we assume it's true that asking ChatGPT a question costs 3 bottles of water, you should take into account how long that question takes to answer by a human doing the research. If it takes you a couple of hours, you need to include the food and drink intake it takes to power yourself for a couple of hours. If it's anything like beef or almonds it takes way more than 3 bottles of water.
For devs who currently think this way, I suggest thinking about it more deeply from the perspective of a developer: Let's say you want to start a company/startup from a passionate idea you had. What do you think happens when you build it? In reality, do you truly expect "build it and they will come"? What happens when you bought a domain, put up your product on the web, or the app store? I can tell you what will happen: there will be zero people signing up to use it. Posting it on a Show HN or Product Hunt is an illusion of ease to publicize a product. A PH launch is a carefully planned and curated process involving hours and hours of marketing work to prepare for. A Show HN post will go unnoticed with no clicks 99.9% of the time.
And if you just work in a bigger company, as a non-founder, and say "this isn't my problem, I just build stuff for a job", what do you think the founders did to build their company so there are users who sign up and pay?