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.
I think Target isn't the right comparison here - the skills required for this project are worth much more than minimum wage bagging groceries. If you assume something like $50 an hour (on the low end for a skilled electrician), you get to the $6800 number in the parent post pretty quickly.
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.
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.