Live data from Hacker News

To my students

ozark.hendrix.edu

101–110 of 221 posts

Re: To my students

#101
post #43

This took a lot of courage. Glad to see this is being shared. It's the best honest advice I have seen to date.

Courage is not the appropriate word

I think it fits. Look at the anonymous posts in here, the sheer volume of posts saying this person is failing their students, is a relic, a Luddite, etc.

He put his name and career on it. That takes courage in my opinion.

Re: To my students

#102

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 think you are making exactly his point. Practicing code as a craft, caring about how you do it, how well you do it, and what it’s ultimately used for is, as you correctly point out, not going to bring you profit or employment.

So maybe there’s something wrong with how we organise work?

Re: To my students

#103

> 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…

As others have said, my comp sci degree also had a required ethics course. But it’s also pretty silly to think that a single ethics course where people don’t pay attention is going to change the hearts and minds of students. No amount of discussion about therac is going to make someone question if they should really be working for palantir or raytheon

Re: To my students

#105

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…

From the author’s earlier essay: “A good way to describe myself is as a generative AI vegetarian. You can find a fuller explanation—and many, many links—at the above essay by Sean Boots, which I agree with almost 100%.” —- Given the capabilities of upcoming LLMs, I suspect that by mid-2027, most competent companies, outside specific niches, will not hire and might fire any non-senior “generative AI vegetarian” softwa…

I have actually no idea what you want to say with “generative AI vegetarian.” You mean people who refuse using LLM's?

edit, I see, a new slang:

https://news.ycombinator.com/item?id=47928885

Re: To my students

#106

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…

> If a tree falls in the forest...

I hope this is a pun on the content management system used to publish OP. It's forester[0], written in OCaml and parses TeX-like .tree files into semantic XML which uses browser XSLT to render the HTML.

View source on the page to get an idea.

Reminder of what the idealised web promise from decades ago was. Long gone. Very apt.

[0] https://www.forester-notes.org/index/index.xml

Re: To my students

#107

Earlier quoted context omitted.

Perhaps your vantage point from industry is in fact myopic. We all have our own biases.

That's a flippant reply. Programming is a practical skill, and its most common expression is industrial or commercial, not academic proofs of concept. The post addresses students who will enter industry; that's the focus of the professor's own post . And I sympathize with many points being made here. However, the point of refactoring code is somewhat odd and detached from the real life constraints of programming in t…

  > It's messy, subject to commercial pressures, to a hierarchy of values that doesn't place "refactoring" at the top of the list. And why would it?
Probably because it's a good way to be more profitable.

Code that's easier to understand is easier to: maintain, generate new features for, fix bugs, onboard new engineers, etc

Code that's well written: executes faster (saving computational costs), scales better, has higher uptimes/more robust, reduces bandwidth, and so on.

The thing is the business people will never understand this. Why would they? They're not programmers. They're not in the weeds. But that's what your job is as an engineer. To find all these invisible costs.

I'm pretty confident the industry is spending billions unnecessary. Hell, I'm sure Google alone is wasting over $100m/yr due to this.

Don't be penny wise and pound foolish. You're smarter than that. I know everyone here is smarter than that. So don't fall for the trap

Re: To my students

#108
post #32

Start three two-decade projects: programming language, operating system, and home lab. Build your own job-portable software libraries. Yes, you might need a lawyer. Start now.

Not sure how this is supposed to help earn money or be a path to financial independence. Can you elaborate?

By understanding computers and enjoying the field you are in you will be more skilled then someone who says "tests pass", "worked on my machine", "maybe it's a good idea to run agents on my companies live prod database". Anyone can learn to slop it up, including someone who is passionate about writing code as a hobby.

Not everything is about making money anyways.

Re: To my students

#109
post #10

You could write this from the perspective of a historical luddite [ https://en.wikipedia.org/wiki/Luddite ] and the points would be identical.

This is a tired, weak, and pathetic argument. Opposition to technology is very reasonable if that technology is doing more harm than good. In the case of present-day LLMs, the vast majority of the public finds them to be more harmful than beneficial. Why accept a decreasing quality of live instead of sensible regulation?

What would that sensible regulation look like?

Re: To my students

#110

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 agree, some of this is awful advice for a entry level engineer:

> * Cultivate your ability to think deeply. Do whatever it takes to carve out distraction-free bubbles for yourself in both space and time. This might mean saying no to technologies or patterns of working that others say are critical or inevitable.

An entry level engineer is going to be inundated with a lot of technology they've never heard of and a lot of power structures and group dynamics that are new to them. They're not even in a position to be making these judgements until they actually learn about how professional software development actually works.

> * 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.

That's great, but also, there are not many entry level roles where someone is going to be in a position to be making these kinds of decisions, other than avoiding a company altogether.

> * 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.

Yikes. A software engineering job is not a PhD program. If you are refactoring your code and someone is telling you to hurry up, you should probably wrap it up. You need to ship your code or you won't have a job.

Post reply on HN