141–150 of 221 posts
Earlier quoted context omitted.
>I do not and will not use LLMs, in any form, for any purpose.
As an educator there is nothing wrong with that.
And you can understand the principles governing something without knowing all the concrete particulars of an instantiation. In fact, you rarely do.
Earlier quoted context omitted.
> But I think I still didn't register that these concerns were real at that time. It was easy to believe that I wouldn't be working on anything that impactful. This did change once I started work. The case study i mentioned (it may not have been bhopal, but it was definitely based on something that happened in india) stands out for me because it really hit home about the impact and seriousness of some decisions we co…
I was thinking about it differently. I understood the potential harm on paper, but I think I was still pretty immature. I thought I would be willing to put aside morals (eg working for companies like Palantir) to work on interesting cutting edge things. But when I started working and found myself doing equally cutting edge research, but genuinely for the public benefit, I realized I definitely wouldn't be comfortable…
There's something so off-putting about academics giving industry advice when they haven't spent a day working as an engineer at a company. > Care deeply about your craft. Refactor code until it is clear and elegant. Write good documentation for other humans to read. Have the courage to go slowly, especially when everyone else is telling you that you need to go fast and cut corners. Outside of the bit on avoiding cutt…
What gets me is the craft point. I've shipped more useful software in the last year than probably the previous five combined, and most of that is because I stopped treating code as the artifact and started treating the product as the artifact. The craft moved up a layer. > until it is clear and elegant New grads who spend weeks refactoring code are going to get lapped by new grads who ship something and iterate. Ther…
Those people are going to be the absolute most dangerous possible thing you can do to a company.
Maybe some day we can just totally give up the technicals to the machine, but I strongly doubt it. Every single model is both brilliant, but also a fool, no matter how frontier it is.
Yes, the feedback loops are faster. But you need to assess what's actually technically happening. Someone does. Maybe you offload the actual thinking up the chain, delegate taste understanding and judgement to only people up the chain, and make them all go mad dealing with endless slopcoding they are being hit with. But just as bad, that junior engineer is robbing themself too. Maybe they get away with not looking, but they sure aren't going to learn a lot.
I'm missing the link but there was a great submission maybe a month ago about two hypothetical grad students, I think in astronomy, where one failed and flailed and did things largely the old fashioned way, and the other used AI to get it done. The advisor couldn't really tell who was doing what. But at the end, one student had learned & gained wisdom, and the other had served as a glorified relay between the AI and the advisor and learned little. Same work output, but different human outcomes.
Junior engineers are really not that cheap. Relative to your capabilities you are not a bargain. You take a ton of valuable time from other people. If a company is hiring you, they either are truly fools lacking basic understanding, or they are in on the bargain that they want you to be getting better, are testing to see if you can become more useful. Sure it's great to show up and have impressive output, but you need to actually be learning and growing. You need to be participating in the feedback loop actively. Or you will be lapped by people who care & think like engineers.
> Be intentional about deciding your own moral and ethical boundaries up front. Don't settle for the lie of compromising your principles "just for now" until you can find something better. my uk mechanical engineering bachelors degree had a required module on the ethics of engineering which has always stuck in the back of my mind. i think we went over the bhopal disaster as a case study one week, although it was abou…
The only time ethics in engineering was ever mentioned to me was in a class on applied number theory (cryptography), taught by a professor who had previously worked for the EFF. He went off-topic to tell us that many problems, like how to hit a target with a missile, may fascinate and compel us as engineers, but we shouldn't let that distract us into building instruments of death.
That course was an elective, and it was entirely possible to complete my degree without hearing a single mention of ethics.
There are many reasons I look back on my academic experience with disdain, but this one stands out to me.
Earlier quoted context omitted.
I remain hopeful that some day someone will train an LLM which is tolerable to people who take this stance (which I respect, much like I respect food vegetarians despite not being one myself). I've been tracking models trained entirely on out-of-copyright data, for example. I've not yet seen one of those which appears generally useful and didn't chuck in a scrape of the web or get fine-tuned on examples generated by…
I don't get why it's so hard for you and others in this comment section to understand why people hate AI so much because it's not just the theft and environmental destruction. A college professor, especially one at a liberal arts school, is obviously not going to like something that enables you to outsource your thinking and steals your agency. I think that's a perfectly valid viewpoint; maybe talk to someone without…
I don't need computer science professors to like LLMs, but I still want them to be able to poke at them with a stick without feeling like they are violating their principles regarding energy usage and unlicensed training data.
Earlier quoted context omitted.
As an educator there is nothing wrong with that.
Education is distinct from industry. The point of education is understanding and knowledge. The point of industry is practical effect and production. The aims are not the same. And you can understand the principles governing something without knowing all the concrete particulars of an instantiation. In fact, you rarely do.
I also believe learning the basics is essential before reviewing someone else's work. Whether that work is done by a human or machine.
There's something so off-putting about academics giving industry advice when they haven't spent a day working as an engineer at a company. > Care deeply about your craft. Refactor code until it is clear and elegant. Write good documentation for other humans to read. Have the courage to go slowly, especially when everyone else is telling you that you need to go fast and cut corners. Outside of the bit on avoiding cutt…
I generally agree with what he stated. We should clearly define our moral and technical redlines. Lines we will never cross because they will be tested every day.
There's something so off-putting about academics giving industry advice when they haven't spent a day working as an engineer at a company. > Care deeply about your craft. Refactor code until it is clear and elegant. Write good documentation for other humans to read. Have the courage to go slowly, especially when everyone else is telling you that you need to go fast and cut corners. Outside of the bit on avoiding cutt…
> Who is going to read your carefully crafted documentation lol? Everyone that uses or works in your codebase. Look at how people use LLMs these days. People frequently use it on new codebases to get up to speed on the code. Frankly because it's a lot faster than grepping, profiling, and all the digging we'd normally do (though those still have benefits and you're still going to do them. Hell, the LLMs even do them).…
thinking about it a little more, i would personally prefer to use the term momentum rather than velocity or just plain speed -- we accrue more mass by adding code, features, etc. and shifting direction/increasing speed are both harder with greater mass.
I really love the encouragement. Honestly it resonates a lot with me. It shows that the craft itself is still beautiful, you just need to find the right people to mingle with. But the real world and money blended in creates a weird corrupt mix, just like everything. Not to mention there is a real risk for people who are already has their feet in the industry but not yet senior enough to survive or to control, for exa…
It's important to distinguish between the practical and the theoretical. The flippant answers of "idealists" refuse to engage with the messy domain of facts, because it is aesthetically offensive or challenges their comfort or their nostalgia. The steam engine wasn't inevitable either, but people did choose it. How many today in this forum grumble about the loss of a world when the steam engine replaced old ways of working? The next generation won't have these sorts of hangups, just as we don't have them about steam engines. Or, if you like, how many pine for the days of assembly programming?
When something proves to be too useful industrially to opt out of, then it will be adopted. People will choose it. If you want to be Amish, go for it, but most people don't.
Earlier quoted context omitted.
What gets me is the craft point. I've shipped more useful software in the last year than probably the previous five combined, and most of that is because I stopped treating code as the artifact and started treating the product as the artifact. The craft moved up a layer. > until it is clear and elegant New grads who spend weeks refactoring code are going to get lapped by new grads who ship something and iterate. Ther…
There's a lot of ways to ship things & iterate without having any idea what you are building or doing technically, without building any tastes for how things work. Those people are going to be the absolute most dangerous possible thing you can do to a company. Maybe some day we can just totally give up the technicals to the machine, but I strongly doubt it. Every single model is both brilliant, but also a fool, no ma…
I hear you, but here's the thing: the companies don't give a shit about software quality any farther than it takes to keep you coming back as a customer. And it's actually been like this for a long time. They're going to hire people who can ship who-cares-how-buggy software as fast as possible. It's better for the bottom line.
And that pains my soul and pains me as a consumer (because we already had to put up with too much crap software before genAI started producing it in reams), but there's very limited money in the kind of quality you're talking about.
I hear stories from people interviewing now--the interviewers react negatively if you tell them you're working on keeping your programming skills fresh. They just want to know how many agents you can run at a time and how many lines of code you can generate per day.
Personally, I think someone skilled in software development working with genAI is going to be more productive than someone not skilled working with genAI, but I don't think that's even being selected for now.
Grim days.
The one thing that gives me hope is that every time we ask our graduates who are now in the field (and all work with AI) if we should drop classic CS education and only do AI, they all emphatically reply in the negative. Yes, we need some AI education in there, but they want the foundation, too.