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
He put his name and career on it. That takes courage in my opinion.
101–110 of 221 posts
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
He put his name and career on it. That takes courage in my opinion.
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…
So maybe there’s something wrong with how we organise work?
> 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…
"I do not and will not use LLMs, in any form, for any purpose." The academic navel gazing is strong with this one.
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…
edit, I see, a new slang:
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 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.
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
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?
Not everything is about making money anyways.
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?
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…
> * 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.