HN user

Transfinity

320 karma
Posts2
Comments49
View on HN

I think interest rates have a lot to do with that mindset. If you view a Jr engineer as a long term investment (in 18 months you get an SDE 2 who knows your business), that's much easier to justify when borrowing money is close to free.

LLMs get endlessly confused: they assume the code they wrote actually works; when test fail, they are left guessing as to whether to fix the code or the tests; and when it gets frustrating, they just delete the whole lot and start over.

I feel personally described by this statement. At least on a bad day, or if I'm phoning it in. Not sure if that says anything about AI - maybe just that the whole "mental models" part is quite hard.

There's no incentive for an engineer to do that. Saying yes and delivering crap gets you a bonus, hard truths get you shuffled around or made redundant. There's no real consequence for delivering crap, so that's what happens.

Contrast this with other engineering fields, where the engineer is truly responsible for the decisions they make. My civil engineer friends face losing their licenses, fines or jail time if they are found professionally negligent. The same is true of other high stakes professions - think doctors, lawyers, even accountants. It's probably not appropriate for most software engineering roles, but for safety critical systems it doesn't seem far-fetched to me.

I don't usually write in fiction, but with nonfiction and especially technical writing (like O'Reilly books) I find taking notes helpful, and the book itself is the most convenient place up do so. I'll underline important words or phrases, ask questions, raise concerns, recall definitions from earlier.

I find doing this helps keep me honest about whether I'm understanding what I'm reading or just glossing through it, and it helps pace my engagement. If I can't come up with one question or comment per page, I've probably lost focus.

Hi! I'm that person! Senior engineer, decade of experience. I've used debuggers in the past, both for running code and looking at core dumps, but I really don't find them to be cost effective for the vast majority of problems. Just write a print statement! So when I switched from C to python and go a couple jobs ago, I never bothered learning how to use the debuggers for those languages. I don't miss them.

I agree. IMO, Java-style OOP conflates 2 different concepts, polymorphism and inheritance.

Polymorphism (including dynamic dispatch and duck typing) is a game changer, in that it encourages simple, stable interfaces, enables testing, encourages encapsulation, etc. It's a key technique for building big projects.

Inheritance is a tool for reducing the amount of code written by a human, among many others (things like code generation and composition) I haven't seen it unlock other important conceptual domains the way polymorphism does.

Unfortunately many undergraduate curriculums get overly excited about inheritance when teaching OOP. I guess animal-cat-dog is an easy example (though totally unrealistic), but the problems polymorphism solves don't often show up in classroom-sized projects.

I saw a similar effect teaching at a coding school for adults: one of our strongest predictors for success was whether or not the student had someone close to them who was in tech. Having someone outside the system to practice lingo, talk about culture, or give an opinion on what topics matter makes a huge difference. I see no reason why grade school math would be different - I know my parents made a huge difference for me, not by "pushing", but by just being there to talk.

I will occasionally file bug reports or even submit fixes to open source projects as part of doing my job. As an engineer, one of my responsibilities is to maintain the commons - without it I would be much less productive. On the other hand I have a lot of autonomy in my work, a chill boss and a team that doesn't need to crunch. If someone I report to got grumpy I would stop, and I definitely don't do this on my own time.

The “silent majority” was used by President Richard Nixon during his presidency and his campaign against the Vietnam war.

Excuse me? The "silent majority" was the set of Americans who were for the war, not (loudly) protesting against it. Nixon was all for continuing the war.

That depends heavily on the shape of your data, what your workload looks like, what sort of consistency guarantees you need, etc. I recommend Designing Data Intensive Applications for getting a handle on this - it's the book I suggest to SDE IIs who are hungry for the jump to senior. Not a quick read, but well written, and there's not really a shortcut to deep understanding other than deep study.

I write software at a fintech, and the CFPB regulations are super important for protecting the customer. They also give important guidance on how the customer needs to be taken care of, which is important for a company that wants to do the right thing but doesn't have expertise in customer service.

I've seen variations in published cookbooks too! Maybe not this much, but easily in the 150-250 range. It's a real problem, not just a Google one.

Semi professional musician here. Repetition goes way beyond what the author mentions:

- Most music is highly repetitive, often recycling 2 or 3 short segments (chorus, verse) with minor variations to fill out a whole song. Coltrane is known for his avant-garde composition, and even he repeats (often on a much smaller scale than a pop tune).

- The work of being a musician is repetitive. Learning (memorizing) songs takes reps! Then you've got to keep them fresh, teach them to new band members, etc. You probably have a limited book, and you know what the crowd pleasers are. Unless you're big enough to have a following cutting a song you're sick of isn't a problem, but filling out a set might be. Between rehearsal, gigs and practicing at home I probably play through most of my band's book at least twice a week.

- Being a musician is very physical, which means you're drilling exercises in your daily routine. As a brass player, I run more or less the same set of warmups, range builders and flexibility exercises every day. Drummers do rudiments. String players have their own shtick.

As far as listening to music, I don't typically put something on repeat unless I'm trying to transcribe it. But I'll listen to a song, and there's a chance it'll play on repeat in my head all day (or all week!). Steely Dan and LCD Soundsystem are particular earworms for me. It wasn't until college I realized this isn't true for many people.

The types of error made by the model in the article are exactly the sort of error that I (senior engineer / decade of experience) would make if asked to describe how something works and I didn't want to spend too much time on the details. The difference is, I can usually give a decent estimate of how sure I am of something, and know how to zero in on the truth when it's important.

Maybe a confidence level for a given explanation, along with some sort of "here's where you can go to learn more" would be useful? No idea if language models would be good at that kind of meta reasoning.

But there's no way to train the transformer-based high-probability-next-word AIs to be superhumanly good at fooling you into doing something, on the grounds of lack of training data

The conversations of all those human scammers would be prefect training data for this. You even know exactly what conversations led to payouts. Assuming you can get all your data in one place, of course.

Perhaps "break up your book into chapters" is a better metaphor for microservices. Breaking a chapter into paragraphs makes me think more of OO design or functional decomposition.

Maybe. 15% sounds about right to me. Back in 1990 computers were expensive, bulky devices, required specialized knowledge to operate (Apple's ad copy notwithstanding), and had limited use outside of a few specific domains.

Rust is fantastic for some problems, poor for others. If your alternative is C++, or you're doing something where you need to compile high performance code to wasm, go for it. If your alternative is Java and you're writing high level backend services, it might not be worth the cost, especially given the difficulty of finding / training experienced Rust programmers.

I've heard that DLC has made this less of a problem in recent years. Since there's a stable, predictable revenue stream and delivery channel for new content, iit's much easier to justify keeping devs, designers and artists on full time. Presumably this varies by studio / publisher / genre, but my impression is it's much better than it was.

The author mentions in the post, and I think I agree, that Liskov substitution is the most "principle-like" of the principles in that it's pretty much always applicable. If the child object can't be substituted for he parent object, then you haven't really extended it, you've just made another unrelated class that happens to share some code. Inheritance is probably the wrong pattern here, and if you call what you've done inheritance you're going to confuse the person who next touches this code.

At a million tonnes of mass driven out of the Earth's gravity well per second, this would take 189,000,000 years.

I love how this takes an incomprehensibly large number (mass of the earth) and decomposes it into 3 exceptionally large but kind of comprehensible numbers (million tones / second, 30 million seconds / year, 189 million years). The earth is _big_.

Not technically forced since it's not mandatory that update, but not updating is not a viable strategy for most users. If you want new OS features or security patches, or apps that rely on those features, or if you buy a new device, then you don't have an option. Eventually everyone will have this update.

So the article is "correct", but not really in a useful way.

OTOH, this is more a natural side effect of how software development works than any malicious intent on Apple's part. Letting users opt into specific OS patches would be a maintaince / security nightmare.

And, like in art, the formulation matters, and more often than not the best formulation is the original (because its closer to their source, the thinker who came up with those ideas).

This is sometimes true, but I think it depends on who you're reading. The skill of philosophizing, and of carrying on a discourse with other philosophers, is very different from the skill of bringing a novice up to speed. Not everyone who's great at one is great at the other. There's also value in what the grandparent post mentioned about establishing historical and biographical context before jumping into primary sources. It helps you understand what you're reading and what the community thinks is important about it.

That said, I definitely agree that primary sources are valuable to read, and to appreciate as works of art in their own right. Yes Wikipedia can give you the big ideas, but it's just not the same. But hitting Wikipedia first can give you context to get more out of the primary.

The concept of "state of the art" exists for engineering not art

I don't understand this. Yes philosophy is not a linear progression of ideas, but the iterative process of people building on one another's ideas is definitely present, as it is in music or mathematics or poetry. Philosophy responds to current events, to art, to science, and to itself.

To put it another way, it's totally valid to ask "what was up with philosophy in X decade". You can look at the ideas that were floating around, how they interacted with each other, how they built on the past and led to future ideas. As I see it, that's the "state of the art". It's more a question of "what were top minds in the field working on", or maybe "what ideas were most influential", than anything else, but that's true if you ask that question of technology too.

Smartphones or cars change messaging methods and habbits, not philosophy.

Philosophy (or philosophers) respond to what's around them. The conversation around whether the brain is a computer, for example, is very different today (and probably more interesting to most people) than it would have been 200 years ago.

This feels fair to me. The news agencies spend time and money to research, verify and publish the news. If Google wants to use that content to sell ads, then they should pay for it.

I don't understand the negative comments here, and I'm not seeing an explanation for the disappointment. Maybe I've missed part of the story here?