Hacker Newsnew | past | comments | ask | show | jobs | submit | coderintherye's commentslogin

Related:

https://news.ycombinator.com/item?id=3248911 - Why Stack Exchange Isn’t in the Cloud (2011)

The original blog post is down but available here: http://web.archive.org/web/20120120201529/http://blog.server...


Worthy of a re-submit / retry, but also: posted 15h ago: https://news.ycombinator.com/item?id=44604696

Most large ships have large water storage vessels as well as make fresh water using pumps (while operating). They also usually have separate pumps to pump salt water for firefighting. But in the event the pumps are not running that's a problem such as what happened with https://en.wikipedia.org/wiki/USS_Bonhomme_Richard_(LHD-6)


> Chrome, the browser itself, hasn’t made any significant improvements to its user experience in years. (By comparison, Firefox has shipped more UI updates in the same 5 years, including ones like sidebar navigation for tabs

Firefox has to ship more to just catch up to where Chrome is. Whereas Chrome is extremely usable as it is today and they ship tons of minor improvements behind the scenes which make it that. I'd actually be more concerned if Chrome was shipping a bunch of "improvements" as they would be more likely to hurt the user experience than improve it above a certain cadence.


Will be interesting to see if these get pair up with Verifiable Credentials.

My real world use case for emblems would be to have an ability to place an emblem on a website that is verifiably provable as having been offered to the website by the emblem provider, for example a "Secured By Acme, Inc" emblem which Acme, Inc. only provides me use of the website is actually secured by their software.


>the real opportunity lies in understanding that you’re not bound by the conventions that have been passed down as “standard.”

While in agreement with the author, I think Moxie is missing here that if you want external funding you are in fact mostly bound by conventions, conventions that most VCs and investors expect you to follow. It's possible to go beyond the normal funding routes as well but it narrows the path considerably.

Perhaps though, VCs will change their mindset about this as the AI-driven company becomes vogue and strengthens the perception of small orgs doing big things.


It's worth noting that Moxie is the same Moxie of Signal.

He's also an anarchist. I don't think he's in it for the money. It's also worth noting that several multibillion dollar organizations use the underlying software too. I'm saying he's highly experienced and has created a successful business. Even without VC funding!

So there's a difference:

Is your intent to build a high quality product that will make money?

Is your intent to make high income by selling a product?

Personally, I'd argue it's the job of the engineer to focus on the product. The money is the domain of the business people. I'd also argue that the former option is better for society and we're in a bad situation if the latter situation is dominating. The contention between business people and engineers is healthy. It creates balance. Our job is to make the product the best it can be, their job is to sell it. If we don't do our job they're more than happy to sell garbage as long as people will buy it. And remember, VCs don't care about you or the company past their exit. That's not healthy for something if you really care about the product. But it's fine if you care more about the money.


>Don’t study the “common” things, but go all-in on the niche pockets. The common things are common enough that you’ll learn them through osmosis regardless of what your main activity is. But the niche things require active study, and ignoring the niches is how you remain a novice.

I'd add, work on the niche things that no one else wants to work on but need to be done. That's how I quickly advanced in my career, becoming knowledgeable about systems no one else wanted to touch.


I very much agree to get to work tackling the things no-one else enjoys, especially if you find you enjoy it.

I learned fairly early on that I enjoy debugging and fixing bugs far more than I enjoy greenfield development. This seems to be less common than yearning for fresh projects to work on, but it also makes me valuable to have on a team.

Debugging is an absolute joy, it's like a two-layer puzzle.

There's the immediate puzzle of "What's causing this errant behaviour", in which you mechanically dissect the code. You figure out the state the program needs to be in to trip the reported fault. This can be easy or difficult.

There's also a secondary puzzle of, "What was the programmer# who wrote this thinking?". This is the enjoyable part. The root cause isn't "Here on line 53, we were multiplying Foo by Bar when we should have been Scrobbling Foo". The root cause is that someone thought that's what needed to happen ( and with PRs, someone else signed it off ).

That secondary aspect is fascinating, because it can shine a light on misunderstandings about the product or the API. It'll also lead to reflection and introspection because occassionally you must stop to think, "What if they were right?".

Every bug in a program is a learning opportunity. It's an opporunity to expand the understanding of the system, an opportunity to fix procedures or approaches to writing code so it doesn't slip through next time.

One of the sad things about the march of AI, is that there's no longer any of that psychology or learning. The answer to, "Why was it written this way?" becomes, "Because the LLM said so".

# That programmer might be your past self, but as they say, "the past is a foreign country", and it can sometimes be harder to put yourself in your past mindset than someone elses.


100%, debugging is an absolute joy, especially with niche systems-level kinda of bugs that simply can not be debugged with simple printf's.

I had a friend once asking me to help debug a weird issue over discord. We went through some obvious things like are there any other threads running or is there something obviously wrong with the code. We didn't find anything so we went on to the best part -- trying to figure out the root cause from the panic. Checked the pointer values, wrote them down, checked where the TLS is, wrote that down to. At that point I forgot how Windows had TLS arranged, so I pulled up some docs, while the other guy fiddled around with the debugger. I found the TLS layout, and the debugger we used didn't have any kind of TLS debugging enabled, so we had to pull up PE spec to do some calculations on where the addresses could end up and sure enough the answer came -- we had a TLS corruption. Turns out he used a C bindings library that had a typo that overwrote the TLS and was messing with his variables.

Debugging is such a joy when it feels like Sherlock Holmes movies.

(*) For anyone who thinks might be misreading this, TLS means thread-local storage, not transport layer security. I'm sure I've had my share of wrong search results because of this too.


> niche systems-level kinda of bugs that simply can not be debugged with simple printf's

Funny, printfs are the only thing that works for me for debugging niche systems-level bugs :-)


Also love debugging, it's puzzle, pattern matching, evidence gathering, poking around, experimenting, it's using tools, diving into documentation, learning more than whats required to write it and learning about humans and machines and why and how we make mistakes and forgiving these mistakes and fixing the errors. That feeling when spending lots of time to write just one line of code to close that one pesky bug.

Are all developers like this? Is there something I should look for when looking for a job that can help me get more of a career with more of this joy in it?


Debugging can be a joy when dealing with a single system. Not so much when dealing with things like microservices where every combination has a possible failure scenario related to that bug. And because of the deployment strategy, you can't easily test that combination in isolation. Also no tests for each service, only full integration tests that takes a while to run.

I know distributed systems can be a pain to reason about, but I think every node should be capable of being tested in isolation, at least to be able to partition errors (either the node, or the distributed nature of the system)


> And because of the deployment strategy, you can't easily test that combination in isolation. Also no tests for each service, only full integration tests that takes a while to run.

That doesn't sound like microservices at all, but a distributed monolith.

I'm so sorry!


> Are all developers like this?

No, there are different types of developers. Some are like this (and so are some sysadmins) but others have strengths in different areas.


This is also what I love about rebuilding some existing architecture that's not working for a business, its doing mostly the second part - the system is working but it - costs too much, is too slow, doesn't realize some goal, etc - and often times a big part of that problem is because the original intent of the author was not expressed properly.

Usually its not enough time and skills to solve the particular problem, but the most satisfying thing is building a new system that expresses the intent of the original author but at 2% of its original resource usage.


(author here) I've always found this advice a bit of a double edged sword. I absolutely agree that it'll develop your career, but I don't really want my day job to become 100% drudgery because I'm the only one who bothers to do it properly.

If the untouched system is just fiendishly complex this can be fun to figure out, but if the untouched system is pure pain to deal with, I think I'd rather risk unemployment.


Nice Twitter thread from Nov '24 analyzing the paper: https://x.com/Robert_Palgrave/status/1856273405965693430


> Nice Twitter thread

That's a paradox. Maybe it's just me but if you need more than 3 "posts" to say something, put it in a blog and link to it from Twitter. That was excruciating to try and get through (which I failed at doing.)


Thanks. On Twitter, Ethan Mollick seems to imply that Robert Palgrave might be the scientist that triggered the investigation.


Is there a way for not Twitter users to read these?


Yeah, replace x.com with xcancel.com or nitter.poast.org, e.g., https://xcancel.com/Robert_Palgrave/status/18562734059656934...


While poast works, I strongly feel most people on this site are not aligned with what poast represents. Graf has to spend a lot of time (and time = money) getting accounts set up to run nitter, and it would suck if the views of poast users wound up costing the internet a twitter mirror.

I strongly recommend people not investigate this unless they think 4chan is quaint. As in, if the reason you are not using X is because of the outrage at Elon and the "typical user" of X, then maybe use xcancel instead.


4chan is probably still 'better' than Xitter : not only it's open web, it's also not taken 'seriously'.

Twitter's issues long predate Musk : for instance Mastodon was created as a reaction to the 2012 APIpocalypse.


fwiw i believe strongly that there would not still be a nitter without graf's work on it.

in the space of working on cool shit, he's good people. see: moldbug and urbit, for a similar case.


oh, totally. I was hoping to avoid people going "i wonder what poast is", but Graf said they've been backlinked before and it's no big deal; but i can't remove my earlier comment.

So i guess i misread!



"A common trait of high-agency people is that they take accountability for achieving a goal, not just doing some work"

Very well-said. Be agentic.


Germans were the ones supplying Putin with the military technology components needed to fight his war: https://x.com/kamilkazani/status/1537133053889347584


Thinly disguised ad.


Exactly


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: