5 ms·
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
by cdfalcon 5mo ago
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 cutting corners, this advice seems like a straight path towards unemployment in a few years. The implication is that "your craft" is writing and polishing code, a skill which seems to be increasingly antiquated in favor of higher level system design. Who is going to read your carefully crafted documentation lol? The agents who replace you?
If a tree falls in the forest...
- danny_codes 5mo agoPerhaps your vantage point from industry is in fact myopic. We all have our own biases.
- cdfalcon 5mo agoCompletely fair - but at least my PoV comes from having actually worked as a SWE, you know? I feel like the best understanding this fellow can have is purely secondhand from watching the success / failures of his students. I also think I get doubly upset from advice like this because it’s given and marketed to impressionable young students. Even agreeing with all the moral points he’s made, I truly think this advice would set up a new grad for failure and have them focusing on the wrong skills for this market. The bit about ignoring trends feels too head in the sand for my liking :/
- danny_codes 5mo agoFads come and go in industry. This version of LLMs will come and go as well, as will the coding languages and paradigms we used before (and, presuming you want your code to actually run, still do with some decent frequency). Will LLMs in their current ergonomics have staying power? Perhaps. Nobody can predict the future. But I don’t think it’s a given in the least
- ActivePattern 5mo agoAutomatic coding systems have way too much economic value to be considered a "fad". I don't think you need to be Nostradamus to predict that we're never going back to manual coding. Sure, the systems will evolve and improve, but they're certainly not going anywhere.
- slabity 5mo ago> Automatic coding systems have way too much economic value to be considered a "fad". Which is why they very carefully worded it more as 'LLMs in their current form', twice.
- CamperBob2 5mo agoYes, if you stake out an argument carefully enough, you can make its perimeter infinite and its area zero.
- deleted 5mo ago[deleted]
- DJBunnies 5mo agoHow do you know they didn't? My college professor was formerly at NASA, where this stuff is important. I recognize not everyone's work is [as] important, but we should still strive for excellence (and safety.)
- cdfalcon 5mo agoOne check of their LinkedIn.
- gipp 5mo agoBuddy... The whole point of the post is that he wants his students to question whether "succeeding in this market" is really the right choice.
- lukan 5mo agoThe right choice is rather to strive for perfect - and be unemployed? To me it was actually not clear what his point was. "Above all, be motivated by love instead of fear." Sounds great. But not that practical.
- fooqux 5mo agoWhy isn't it practical? In my life, I've encountered many SWEs that have changed careers. I've met them in national parks working as rangers. In real estate, grocery store butchers, and yak ranchers. Yet I've never once encountered a SWE that was once doing something non-technical and decided to switch. Purely anecdotal, I know. But still, I prefer to think that all those people discovered this practical advice and are far happier for it. I've never met one that regretted their decision.
- lukan 5mo agoOh, I would consider becoming a park ranger as well, but as a european, I also did not had to go deep in dept, to become a SWE. And a professor should take that into account and give practical advice. In the real world, solving haskell challenes (of which the prof is fan of) is unfortunately not that useful. People have real needs for working software to solve their real pain points. Not to worship code quality. Some projects need obviously better code quality (airplanes, medical equipment..) - but not all of them. And if you want to have sacred code when coding a crude throw away app .. you won't get enough money for that. And positions for academics are limited.
- dijksterhuis 5mo agoi was writing a bit of a lengthy reply, but yeah this is the whole point really. making that money, getting that job title, being at that company, working on that project -- are these success? or is success simply doing the best job possible when writing code?
- microtherion 5mo agoWhen I started studying CS, the "industry" thought students should be taught COBOL, and maybe some PL/I and Fortran, because obviously that was what the market wanted.
- archagon 5mo agoI worked at a FAANG in a senior role for around 6 years and I completely agree with the article. (I left before LLM/agent use became widespread, but I would have flamed out anyway if it was forced upon me.)
- xantronix 5mo agoIt's scary just how quickly the past has been buried: Decades of accumulated insight on best practices, all discarded in service of the new electric Christ.
- CamperBob2 5mo agoThe blacksmith's lament.
- xtracto 5mo agoThis hit very close home. I'm a 44 year old developer, with Software Engineering Bachellors and CompSci MPhil and PhD. All my life I spearheaded "best practices" and code quality (from Fred Brooks, Joel Sposky, Martin Fowler, etc...). But since LLMs arrived... things have become crazy. The layer of "obscurity" that permeates code writing seems to make a lot of those "standards" moot or just not really pragmatically possible to follow.
- lo_zamoyski 5mo agoThat'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 the wild. Like, sure, in the ivory tower, you can confine yourself to nicely bounded problems and tidy little toy POCs. You can survive doing those things, because the selective pressures allow for it. I love those things, personally. They help me understand the nature of the thing. And in an academic settings, you can refine and refactor the hell out of those things to your heart's content (not that there is necessarily an objective end point to refactoring; code organization is subject to goals and constraints which can shift around). But the reality of software in a commercial setting is not the tidy one you can expect in an academic setting. 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? Whether you should refactor something is not just a question of whether it suits your conceptual tastes or even whether it is more maintainable. Unlike algorithms and principles and even techniques, software is not eternal. It is ephemeral. It's shelf-life is bounded. It is a piece of a larger business process. You're not refining some theory or some grasp of a Platonic ideal. You're mostly just putting into place plumbing to get something done. Whether you should refactor something, when you should refactor something, is a matter of prudential judgement, which is to say, of practical reason. So, in light of that, there are actually quite absurd things to say given the difference between the privilege of academia and the gritty reality of industrial and commercial software development. If we were to force our professor into the world of industry, he would quickly lose his job or he would quickly learn that some of his strange idealism is silly and detached from the reality that his students will face.
- godelski 5mo ago> 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
- csmantle 5mo agoThe industry's goal is to ship fast and profitably. A learner's goal isn't.
- cdfalcon 5mo agoOh that’s such a high horse position lol - I try and learn as much as possible every day by shipping fast and profitably. Learning to be successful in industry is a completely valid (and common) goal.
- throwaway81348 5mo ago>I do not and will not use LLMs, in any form, for any purpose.
- flockonus 5mo agoHow this will age: >I do not and will not use the internet, in any form, for any purpose.
- 1attice 5mo ago[dead]
- andyfilms1 5mo agoOh no! Anyway
- sambapa 5mo agoI mean... Right now it sounds pretty good?
- 2ndorderthought 5mo agoAs an educator there is nothing wrong with that.
- lo_zamoyski 5mo agoEducation 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.
- 2ndorderthought 5mo agoI know what you are saying. But, almost every major issue I've run into with various teams writing software in production required knowledge of all those particulars to fix. I also believe learning the basics is essential before reviewing someone else's work. Whether that work is done by a human or machine.
- thundergolfer 5mo agoCompletely agree that it's off-putting. The author indeed has only ever worked in academia per his LinkedIn. But disagree that this is a path to unemployment. At work we go very fast and yet I think fast is compatible with each of those points, just not in all situations. Marc Brooker, distinguished eng at AWS, gives much more useful advice for industry, as you'd expect given his almost 30 years in industry. https://brooker.co.za/blog/2026/03/25/ic-junior.html https://brooker.co.za/blog/2026/03/25/ic-junior.html
- rowanG077 5mo agoFrom that guys LinkedIn he was in academia and then at AWS. I guess it's better than the professor but hardly someone who knows the ins and outs of the industry. For that you need someone who has had a multitude of jobs at various different types of organizations.
- uhhhd 5mo agoThis. Exactly this. You'll be unemployed. He'll still have tenure.
- sosodev 5mo agoI sense that the frustration you feel is that professors are able to make choices based on their values, but the average person is not. That is broadly speaking, of course. I think it is a great shame that we live in a modern world where we do we must to survive regardless of how it makes us feel. I suspect it is the root of much suffering.
- ryandrake 5mo agoSeriously. This thread is so depressing. It's like the entire software industry has given up and just accepted "increase speed forever at any cost" as some kind of iron law of software employment. Is nobody even pushing back anymore? Even offering token resistance? The 'bros have truly won. Our only imperative now is "Can we crush it in the market?"
- g-b-r 5mo agoThe parent comment (cdfalcon) has 41 votes right now, it's disgusting
- CamperBob2 5mo agoHow do you know how many votes another user's comment has?
- g-b-r 5mo agoIt was his only comment ever (and no submissions)
- deleted 5mo ago[deleted]
- foltik 5mo agoWild how many people take “care about your craft” as a condescending personal insult. Maybe it’s hard to hear once the job’s beaten it out of you. And it’s about to get a lot worse.
- saadn92 5mo agoWhat 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. There's just a faster feedback loop now.
- 2ndorderthought 5mo agoThis person is an educator. You should absolutely learn how to code by deep practice. You can easily learn how to use the slop machine in I don't know a week or something if the job demands it.
- minihoster 5mo agoSo now we're downvoting the idea that people should have a strong understanding of how to code? We're cooked. A week does seem about right for getting to 90% of optimal AI agent use if you earnestly explore its boundaries.
- smolgumball 5mo agoAbsolutely wild to see this take downvoted. While it's abundantly clear that Hacker News has long since become a mouthpiece for the AI investment machine, I really hadn't felt the loss of strong engineering ethos until recently.
- mwigdahl 5mo agoI didn’t downvote, but if I were to it would be due to the dismissive phrase “slop machine” rather than the message, which I agree with.
- hhjinks 5mo agoThe slop machine is stupidly easy to use. Recently switched jobs and got to use Claude Code for the first time. Literally just talk to it. There's nothing to learn.
- loveparade 5mo agoDoesn't matter who reads it. The point is that you will probably never learn to do "high level system design" well if you do not have enough experience writing and refactoring code yourself. It's like you wanting to become the chef of a kitchen and giving instructions without having ever prepped food. There is indeed something useful about trying to write elegant code. Not because others read it. But because that's how you learn about the engineering tradeoffs and abstraction that exist everywhere.
- newobj 5mo agoThe engineer who only does high level system design and never codes has existed for decades and is often the most useless and derided engineer in the org.
- nopinsight 5mo agoFrom 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” software developer.
- lukan 5mo agoI 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 https://news.ycombinator.com/item?id=47928885
- 2ndorderthought 5mo agoProbably another viral marketing campaign to further pressure those meta employees to have their in office flatulence levels monitored with probes as they are pressured to vibe code more features faster.
- jszymborski 5mo agoWhy do you think this is industry advice? I can't find anything here that indicates that it's the case? Maybe they just feel this is the right thing to do.
- kube-system 5mo agoThe stated audience is his students who are "imminently going out into the world (e.g. "The software industry" he is referring to) or continuing your studies."
- godelski 5mo ago> 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). But how much of that could have been avoided had people just taken a few seconds to document their code? No one is saying sit down and document the whole thing but "add a few comments when you add new functions" or "update comments in places you touch". If it costs you more than a minute of your time you're probably doing it wrong. I'm tired of these arguments. People are turning molehills into mountains. It's so incredibly myopic. We waste so much fucking time on things because we're trying to move fast. But no one seems to understand the difference between speed and velocity. It never mattered how fast you go, it has always been about velocity. Going fast in the wrong direction is harming you, not helping. If you don't have the time to know if you're headed in the right direction or not then you're probably not. > Outside of the bit on avoiding cutting corners But what your gripe is with is cutting corners. Not documenting? That's cutting corners. Not refactoring? That's cutting corners. Not spending time understanding the code at multiple scopes? That's cutting corners. Those are all corners cut that end up wasting tons of man hours. Sure, they save you a few precious seconds or minutes now, but at the cost of hours or days in the future. Here's the thing, if you don't take those shortcuts, then none of those tasks are hard. Even refactoring. But as soon as you start taking those shortcuts they start compounding. Then a year down the line your company is writing a blog post about how your code is 500x faster now that it's written in rust (or whatever the cool kids use). If it's 500x faster that's not because a language change, it's because tech debt. And like all debt it accumulates little by little and it's the compounding interest that really kills you. Sorry, I'm tired of cleaning up everybody's messes. Go ahead, move fast and break things. It's a great way to learn (I do it too!), but don't make others clean up your mess. Stop buying into this bullshit of needing to move so fast. It's the same anti-pattern scammers use to get you to make poor decisions. Stop scamming yourselves
- dijksterhuis 5mo agothis resonated for me, quite hard actually. there's the famous quote which has always stuck with me on this stuff slow is smooth, smooth is fast. 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.
- stackghost 5mo agoThis has been my experience with academia also. I have an MBA (gasp!) and the best profs were the ones who had real world experience. Despite the common rhetoric you see in HN comments about how MBA programs only teach graduates how to cut costs by enshittifying, I actually found it a great education that made me a better engineer. Anyway, The best profs were the ones who'd worked in industry. One guy who taught finance worked on Wall Street and was fond of distinguishing between how the textbook taught a particular technique or fact, and how practitioners actually do it in real life. Got taught startup valuation by a guy who'd been a VC, competitive strategy by a guy who was a strategy consultant for companies you'd actually heard of, etc. The worst profs were the ones like the guy who taught operations. He'd never worked a real job. Went straight from being a student to being a TA to a postdoc to a "research prof", whatever that means. All his examples and case studies were useless or overly simplistic to the point of being useless. The fact that TFAuthor is concerned with polishing one's craft shows they're completely divorced from what actually happens outside the ivory tower. Typing code into a buffer has never been the hard part.
- cramsession 5mo agoHilariously his site doesn't even have HTTPS. Seems like corner cutting to me!
- avaer 5mo agoWhenever I hear this kind of argument, I basically let the person know their argument is fine as long as 1) they are going to pay me competitive money to "go slowly", "polish my code", or whatever, or 2) they are actively working on getting me UBI Otherwise I just shake my head.
- linguae 5mo agoI do sympathize with the viewpoint that many academics are not in a position to give good advice about industry since many of them either never worked in industry or had limited exposure via internships. Additionally, the values of academia are sometimes different from industry. Academia, at least in its purest form, is about advancing and disseminating knowledge, while industry is about serving customers through providing products and services. With that said, I discovered that I’m an academic at heart after nine years in industry, though I left right before agentic coding took off. I got tired of “moving fast and breaking things,” of prioritizing shipping things and “the bottom line” over everything else. With that said, agentic coding, in my opinion, only amplifies long-standing trends, that shipping matters more than craftsmanship. Even without LLMs, software engineering has long had a “git ‘er done!” attitude. To be fair, market effects matter greatly in software businesses. Quality matters insofar as avoiding completely unusable software, but many software companies succeed without building carefully-crafted software. Even Apple, which has a reputation for being perfectionistic, doesn’t make perfect software. Academia has its own problems (publish-or-perish, low pay compared to other occupations that require heavy investments in education, politics, etc.), but it seems to allow more breathing room for computer scientists to focus on the craft of programming without as much pressure to ship (publish-or-perish aside).
- torrance 5mo agoI 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?
- nikcub 5mo ago> 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 https://www.forester-notes.org/index/index.xml
- kube-system 5mo agoI 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.
- JKCalhoun 5mo agoSounds to me like someone who enjoys programming as an intellectual pursuit, as a craft, as an art. I suspect there are more than a few students in the CS program that also feel that way. Clearly they're the intended recipient. If programming is all about making the most money then by all means disregard everything he says.
- kube-system 5mo agoI think it is fine advice for someone doing computer science in academics. It is just bad advice for students going into industry.
- uhhhd 5mo agoIt can be both. People ride horses for leisure; no one commutes on them.
- jmspring 5mo ago[flagged]
- g-b-r 5mo agoAnd it's actually his only comment ever
- remywang 5mo agoHe is not giving advice to the industry, he is giving advice to aspiring programmers and computer scientists. He has no experience in industry, but has produced lots of high quality software and research.
- rawgabbit 5mo agoThe author stated your concerns at the beginning of his post. He prefaced his post saying what the industry wants is the antithesis of what he believes in. 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.
- kqp 5mo agoIt’s not industry advice, it’s life advice. Believe it or not, there exists a world outside what’s trending in the tech industry, and the outside world is also much bigger, much more important, and considered by many more to be the point of both education and life. You were gifted a breath of fresh air, and thought only “well this does a terrible job of smelling like my room”.
- Apylon777 5mo agohttps://en.wikipedia.org/wiki/Ad_hominem#Circumstantial https://en.wikipedia.org/wiki/Ad_hominem#Circumstantial