Hacker News new | ask | show | jobs
by jrowen 37 days ago
I found the whole article to be a bit heavy on anti-academia. And I went to industry after undergrad.

It's a false dichotomy between the "thinkism" bogeyman (actually reading books and papers and putting work into theoretical design is just bad now? Have they tried building anything in the physical world? Checked in with nuclear physics, ever?) and hands-on experience. Both are important. It should be about balance, not trashing an incredibly valuable set of tools because others exist...

3 comments

I am team academia more than hands-on experience. And I have 5 years of experience. To me, it felt like most SWE things could eventually be solved by what I learned at school.

Not everything I did I learned at school, such as navigating codebases with more than a million lines of code. But most things? Yea.

With that said, I am curious how people say that they learned much more through experience, what did you specifically learn?

A lot of technical skills sure. Algorithmic analysis sure (although in practice it’s a lot less formal and more intuition + rote knowledge.

But taste about the best ways to structure a codebase? How to balance speed vs quality and when to do that? What does good vs bad observability look like? How to handle services going down in production and run post mortems? How to handle ambiguity both at a leadership and technical level to chart a path forward for a team? Even reading about these things from blog posts and things is nothing like actually experiencing these things first hand and certainly not taught. It requires accurate and constant self reflection and retrospective to guide an exploration process and if that self reflection tool is askew you can end up learning weird lessons and habits that are difficult to correct (and we all have them somewhere).

I’m team learning and was team academia early on, but the real value in academia is in teaching you how to think and to give you some minimal useful knowledge to about that capability. But it often struggles to even that because it’s still following an assembly line model of teaching whereas learning is relational.

Source: nearly 20 years as a SWE from a well regarded university.

Every company structures a codebase differently. So it’s best to be open. I have worked at many places where speed vs quality didn’t come up. Also it depends on the constraints. A HFT company is much more worried about getting cache hits whereas a big tech company seems more concerned about a big n. Good vs bad observability: well you better know your statistics well, otherwise you lull yourself into a false sense of security. Not my strongest area tbh. I haven’t worked at a company where post mortems are needed.

Ambiguity: there is a lot of ambiguity at uni as well. So you should have had the practice, especially working in groups of students.

> It requires accurate and constant self reflection

Skills I sharpened at university by studying psychology. Do you know how big the mind fuck was to grok the reproducibility crisis while being a 3rd year student in that program (5th year student overall)? I had to re-examine my whole degree.

I also had courses where self-reflection was a weekly part of the course. And I took that seriously.

> whereas learning is relational

I consider it a mode.

Try mathacademy.com it will teach you the “shut up and calculate” version of math really well, and there is nothing relational about (since it’s an app).

I also had courses that were about computer and network security in C and assembly. In it, I self-taught vim, assembly, C and git. The self-teaching was partially the point.

One thing I have learned from university is that what many people see as good practices is more akin to a culture rather than an actual good practice, because the actual empirical work in figuring out what works hasn’t been done. And I find what you say to strongly fit a particular culture of software engineering. But there are many forms. For example, in the Smalltalk/Pharo community it is recommended to extend the base classes to your liking. Whereas in other languages they look at you with horror. Back in the day (2012) Airdrop was what people used and didn’t want to use git, and these people have programmed for decades (I disagree with that one personally, just showing the culture).

Could you tell us what you learned at school that is useful for your SWE career? Im sure there is a lot of us that learned 0 at school and learned everything ourselves as kids on the internet
The problem with "learned everything ourselves" is that you might have niche interests and you miss things. Things I learned that probably I wouldn't have by done by myself: computer architecture (memory, buses, cpu-s, instruction set), and related VHDL/Verilog; how complex is synchronization (implementing from scratch synchronization libraries); different programming paradigms (functional languages); compilers & operating systems (kernel modules, etc.); various types of maths (dsp); algorithm complexity analysis.

Some I ended up using more during my career than others, but knowing more definitely reduced my tendency to think "ah, that should be easy".

Benefits of learning online yourself is that you're self motivated and you get access to the best resources (better than the teacher you are forced to listen to)
But what is the teacher teaching from? Generally they are working off seminal and highly-regarded texts that the autodidact set would tell you to read anyway.

I will grant you that the current form of the education system, especially in light of how easy it is to engage with the primary resources nowadays, is massively inefficient and needs an overhaul to provide more individualized learning. Something like Alpha School is promising in this regard. But don't throw the baby out with the bathwater. Even if a kid today learns entirely "on their own" with an AI teacher...neither them nor the AI accumulated that knowledge, and we still need that infrastructure of people contributing to advancing and refining the shared knowledge base.

Again I think this is a false dichotomy. Learning "everything ourselves" does not mean going out literally by yourself and rediscovering everything from first principles. Whether you learned it from a dreaded teacher or from a manual or reference or tutorial or a more senior engineer, you're leaning heavily on the accumulated body of knowledge and "thinkism" that produced that.

You will learn some things through trial and error entirely on your own of course, but you will also take a lot of time independently re-learning things that are well known. Which isn't necessarily a bad thing. I'm a huge DIYer. Sometimes you have to try and see for yourself. But I do acknowledge that I could have learned a lot faster about, e.g., carpentry, as an apprentice, than I did mucking about in my backyard with youtube videos. I think the concept of "balance" is more important than taking sides on this matter. They're both incredibly useful tools to be used in conjunction. Read the manual. Then go muck around. Then read the manual again and go, "oh now I get what they were talking about."

I think what I'm learning from this is that a lot of the "entirely self-taught" folks don't realize how much they've benefited from "thinkism" and standing on the shoulders of giants.

Edit: feel free to summarize this with an LLM it will be a ginormous comment.

That's a fair question and I'll do my best to answer this. It'll come in an edit. I think it's fair to say: not all courses were created equal in this regard but I'll do it course by course. I studied a bachelor information science but I tweaked my program so close to computer science that I almost daresay it's computer science (if I had 3 courses different, it was). I studied a bachelor in psychology. A two year master in computer science and a one year master called game studies (officially a specialization of information studies, but in practice it wasn't and it really was game studies as a whole field that we studied).

I'll try to do it in order per study program too.

AI-kaleidoscope: general overview of AI algo's. It's a shame we didn't know how to program or that we knew the usefulness of BFS or DFS but we learned it here. Not a useful course due to scaffolding issues (teach programming first).

Business mathematics: partial derivatives, etc.

Problem solving: useless course (teach programming first).

Privacy and security: we didn't learn much about security. We learned a thing or two about privacy. Should've been a TED talk, not a course.

Graph theory: graph visualization (and when not to do it, helped me out as a data analyst later), mathematical proofs, social networks (helped me to actually network a bit), graph algo's (made leetcode easier), not being scared of math notation. This was a really math heavy course as it was taught by someone that studied math in undergrad and grad and then switched to CS as his PhD (and by the time he taught it he was a full professor). He did not skip on the math which was wild since I was under the impression that I did a "business informatics" bachelor so I didn't need to have advanced math as a high school prerequisite. But I definitely needed that here so this course was hard.

Web technology: this was a bit too early but it was a good overview of web programming at the time. I remember being explained what the DOM was and I remember thinking "wtf is the point?" That was because they explained it way too theoretically and simply should've opened firebug or something to really show it.

Language of Logic and Methods of Reasoning: propositional logic and predicate logic. Practically speaking: after this course if statements are not a problem. This was true for me at least.

Pervasive computing: fun course but could've been a TED talk about how tech is used in interesting ways.

Introduction to programming: basic programming stuff in Java. I learned that Java is a terrible language to start programming in. I recommend JavaScript for app/web-oriented people and Python for "just pick a language" people. Nevertheless, while it was a terrible start, it did teach what it needed to teach which was a basic understanding, and skill, in programming.

Empirical methods: the better name is statistics 1. We learned about statistics and we had to program in R. Since our actual programming ability was quite weak it was a double course. It was the second language ever that I had to take seriously and it taught me a lot of programming stuff and statistics stuff at the same time. It helped that I had friends studying psychology at the time as that degree has a lot of stats in it, so I knew the lingo. Almost everyone else was hopelessly lost.

Programming project: no lectures, just one big programming assignment. After this it was expected that the student could write readable code. I failed this course the first time by a hair. And when I came back to it the second year I realized that I failed because my code was unreadable. So I refactored the whole thing and learned how to write much more readable code. We created the game engine for an Othello game. The graphics library was provided by the TA's. So we also learned to program with a library that was way beyond our heads at the time. And that also implicitly teaches you to trust certain abstractions.

Interactive multimedia project: we learned XIMPEL a hypermedia framework, kind of useless. But through XIMPEL we also learned about storyboarding, creating scenes and general video editing. This teacher was super hands off and allowed students to be creative. So I also learned to create simple PHP websites and learned my way around bash a bit. Then I decided to create an upload script where I used PHP to call the ftp command on bash. I thought it was impossible but it wasn't and had to rethink about what web applications could really do. None of these things were formal course requirements but this teacher encouraged this type of explorations so I do credit it to him that "I learned it in school". It's part of these efforts that he also gave me an amazingly high grade as my XIMPEL story graph was a bit meh but my creativity and extra explorations where a 10 out of 10 effort. So he gave me a 9 out of 10 in total. Also deepened my HTML/CSS knowledge.

-----

I'll write the rest later in another comment this is about the first year and I studied 9 of them. As you can see, I was just learning the basics here. But there are a few patterns:

* Some teachers allowed us to work on real stuff if the student chose to (e.g. Interactive Multimedia) and that got way more serious later on as I created an iPhone app for a client when the teacher taught Multimedia Authoring in the master.

* Some courses were quite useless or could've been condensed to a TED talk.

* Some courses taught something useful or semi-useful but it's not up to industry standard. But as you'll see, this will lead up to a level where - while not quite industry standard - makes the gap between industry standard and whatever I did small enough to just make the jump easily by simply applying what I thought was common sense.

Interesting ! What is the name of the schools you attended, if that's not too private ?

In France at "prepa" (2 year intensive courses to prepare for exams for big eng uni) I learned the theory behind computer science (for example how to modelize a regex machine with graph / automata / matrices). That was useful theory to me, but that's just a drop in the ocean of uselessness

One thing I think a lot of people don't internalize is that academia and industry have fundamentally different goals. When I went into industry, I had the thought, like many others, that "my degree didn't prepare me at all for working with a production database, and I'm never gonna implement a Turing machine, wtf?" I think it was a major disservice to academia when college became seen as the path to a good job, because it was never meant to be that.

Academia is about pure learning about the world in a very deep and philosophical sense. It's about underpinnings and history and giving you the abstract tools to reason about things. Academics are often aggressively against learning practical things to solve a specific business problem. Which is what industry is all about. I think it's easy to take a degree program for granted, but it's difficult to understand how your brain would be different had you not done it (assuming one did apply themself and attempt to get its value. If you just cursed it the whole time yeah it probably was a waste.)

Another thought is that, I might be more likely to apply the term "ocean of uselessness" to a lot of what goes on in industry than to what academics are striving for.

People like having a job and a paycheck and accomplishing units of utility. But kludging together some libraries and maintaining another CRUD app isn't all that important or interesting in the grand scheme of things. The Von Neumann architecture and asymptotic analysis are, though.

Vrije Universiteit Amserdam
I find that many people can learn a lot by doing but then at some point hit a wall and really struggle to recognize that another kind of learning needs to take place to understand a deeper concept.
I've had a research-heavy career in computer science. A central problem with the academic research is it commonly ignores real-world constraints. Or less commonly, it imagines constraints that don't exist. As someone who went deep in a few domains, academic literature is usually disappointing[0] once you've read and understand the entirety of it.

The valuable thing about hands-on experience is that the real world doesn't let you ignore constraints. You get that feedback quickly if you are paying attention. This in turn allows you to build a more accurate mental model of the true nature of the problem you are solving and where the hidden limitations and leverage points are. A lot of academic literature tacitly works from a set of assumptions that don't map to any real-world environment.

Once you have that hands-on mental model, the flaws and limitations of much of what is in the academic literature becomes obvious from first principles. Most of the insights might be academically interesting in a theoretical sense but they often aren't reducible to useful practice in real systems. Non-academic careers require implementations that actually work well.

[0] The computer science literature from the 1970s and earlier is much better in this regard than what came later. Many early papers were written by people that clearly had concrete experience in the trenches with the problems they were writing about. Those papers are both more readable and more applicable. This awareness of constraints is lacking from a lot of modern computer science papers.

I think it just goes back to what your goals are. I don't know for sure but I imagine the research you're describing as disappointing was never meant to be directly applicable to a real world problem. It's meant to explore and push the boundaries of our understanding in an idealized and theoretical sense. Over time the research that turned out to be important gets codified into textbooks and undergraduate courses and software packages, but if you're at the bleeding edge yeah it's gonna be tough to make sense of the landscape and apply it to your needs, but that's why people that can do it get the big bucks.

I mentioned nuclear physics because it's a wonderful union of theory and practice. The experimenters need theories to test, and the theorists need their ideas tested.

Contemporary AI is massively driven by research. There are a handful of influential papers from the past few years that have gone right into practice. Industry players have famously invested in their own academic divisions.

To give a concrete example, spatial indexing algorithms badly break cache replacement algorithms for intrinsic theory reasons. This has been known since at least the 1980s.

We have a literature full of spatial indexing algorithms that can't work in any real system because they assume cache replacement algorithms. This problem isn't even mentioned in modern academic papers. That is extremely low-value research. That's like doing physics research under the assumption that the fundamental laws of physics don't apply. It might be an intellectually interesting exercise but it isn't useful.

It isn't all like this. The spatial indexing literature is actively bad to an unusual extent. If you look at e.g. academic graph analytic algorithm research, where I also worked, it is mostly just decades behind the non-academic state-of-the-art. The literature won't mislead you but it also won't tell you where the frontier is.

I'm not really trying to white knight for academia. I know there is a lot of low-quality stuff (part of that is just reality, most of the work done in academia or industry won't stand the test of time). But I do kind of have to assume that if this field of work is continuing there is a reason and they haven't just been spinning wheels for 40 years because they missed something simple and obvious.

This article[0] says "Data changes are usually much less frequent than queries, so incurring an initial cost of processing data into an index is a fair price to pay for instant searches afterwards."

Is that what you're referring to with cache replacement? There's no way to quickly update the index?

Wikipedia says "The R-tree was proposed by Antonin Guttman in 1984 and has found significant use in both theoretical and applied contexts."

I'm gathering that there are applications which are ok with that limitation? Generally there is communication and awareness between industry and academia, if everyone really needs cache replacement for it to be useful, why have they not attempted to account for it? What is the cause of the total disconnect you describe?

[0] https://blog.mapbox.com/a-dive-into-spatial-search-algorithm...

Theoretical design is pretty worthless until you try it out. Until then it’s just an idea or hunch you have. You hope that your experience and intelligence will tip the scales in your favor but that’s all it is. And often your design still has flaws anyway because there’s bound to be unknowns. So then your hoping some kernels of ideas still hang on after encounter with the world and that the ideas are directionally resistant that you can keep the design going forward.

Design is useful as a tool to sketch out a plan but it can definitely become thinkism if you always hand off your design to someone else to action.

Also, the author is talking specifically about research type problems where there’s a lot of unknowns and the problem space is not well trodden and understood.

Also, I don’t know when the last time you built anything is, but talking with mechanical engineers and construction engineers, it’s all the same. You have your designs and then you open up a building to do repairs or start construction and some surprise presents you that you weren’t expecting. That’s what the research phase is for where they learn all they can about the problem space before they start designing (in this discussion ignoring all the years of trial and error that built a base of experience already) and even still in practice problems arise.

You have your designs and then you open up a building to do repairs or start construction and some surprise presents you that you weren’t expecting.

And yet, the field of architecture is still highly valuable. Without those designs, there would be a lot more problems. Try building something complex without a design. You're going to waste a lot of time and materials. My point there was that it's not like the digital world where mistakes and trial and error and rethinking things can sometimes cost almost nothing.

Theoretical design is pretty worthless until you try it out. Until then it’s just an idea or hunch you have....ignoring all the years of trial and error that built a base of experience already

Lots of (smart) people have tried lots of things, there is a ton to learn from that, you're calling it worthless and taking it as an assumption at the same time.