I've dealt with very little politics, credit stealing, and jealousy as a % of my time since joining the workforce. They definitely exist, but to say they're so bad that they prevent you from learning is laughable.

I still find opportunities to grow and learn on a weekly basis. I don't work at one of the worlds top research divisions, but that's never stopped me from improving/developing myself.

You can learn in both academia and industry, but you learn completely different things. In industry, you typically learn more about business and current "trends" in technology, whereas in school you improve your fundamentals and have the opportunity to learn more hard skills, like machine learning, programming languages, etc.

I'd argue there is a lot more opportunity to learn in school than industry though, if only because you can go at your own rate in school so if you wanted to learn about current technology in school you could easily do so on your own. Still, I think a lot of it really boils down to having responsibilities that you are getting paid for vs not being paid but having the freedom to do what you want.

I certainly have learned a lot since leaving school, but the majority of it has not been due to being in industry but learned on my own time.

Most engineering jobs require a lot of horizontal learning: develop enough knowledge of a topic to do something useful for the company then move on. While academic learning revolves around developing depth in a particular subject.

If you'd like to learn enough about a topic to contribute something truly new to the field, 99.9% of engineering jobs will not satisfy you.

So-called "programming" jobs can be science, engineering, a trade, or a completely different job masquerading as "programming."

Science is what tends to happen in research divisions and academia. These jobs revolve around the invention of novel algorithms, research into theory, and so on, sometimes without even having a practical application in mind. The work product is often papers, but is also sometimes new languages or proofs of concept.

Software engineering jobs tend to be what you see in "senior developer" positions in industry. They're about applying known concepts (i.e., existing languages, implementations of approaches from the literature, and so on) to build a defined system in sometimes-novel ways. The work output is usually a product or service that you have some degree of responsibility for.

Software as a trade is what most junior programmers and general employees at larger companies do. This is the application of very specific learned skills to implement pre-solved problems (i.e., a ticket to "make X work like Y using Z method"). The final product is closed tickets / implemented features.

And still another large group of "programming" jobs are actually more about knowing the problem than the solution. These are really jobs about using programming to do something else. Process and product optimization as well as a lot of engineering support jobs fall into this category. The work product is an improved process or system that happens to use a computer.

You can learn in any of these jobs. In the science job, you learn the fundamentals and then think of advancements to the field. In the engineering job, you study the fundamentals to apply them to solving a problem. In the trade job, you build the biggest possible toolbox of code to apply to each solution you're given to implement. And in the non-programming job you learn a whole new field and then apply code to it.

All of these jobs can be lucrative, fulfilling, educational, and fun, but you need to know which one you're getting into ahead of time. "Programming" and "industry setting" are awfully vague and useless terms.

I trade my "pure learning" opportunities to be able to still grow and develop while earning an income that empowers me to live my life as I desire. I get to solve real world problems and challenges, rather than open ended ones.

I'm not trying to take anything from academics, but the most useful result will always come from a combination of academia and business. Neither would exist without the other, and there's and endless amount to learn from either side.

The difference is between maximizing tenure-track job prospects vs learning. Surprisingly those two goals can sometimes be at odds and that is usually what you hear about on HN. People that were trying to maximize for both learning and future job prospects inadvertently running up against academic bureaucracy. If you have a clear goal then you'll have a much easier time.

I'd love to hear you defend that statement.

All you did was give a justification that academia is a place that learning happens. In fact all that is needed to prove you incorrect is ONE counterexample.

Ummm.... Academics spend a lot of time in non-learning activities. As do students. Learning is a state of mind. You can learn wherever you are if you want.

Based on personal experience, I gave up the idea of a Phd when I saw how much time the professors spent begging for grants. And I've learned the most within the first 6 months of a new position. (This is also why jobs that offer a lot of variety are nice)

[0] https://www.insidehighered.com/news/2014/04/09/research-show...

Tell me what exactly are you going to learn by being under business pressures and goal posts.

Learning is a lot like exercise in that regard (not surprisingly for similar physiological reasons). Just as walking to and from your cubical to the bus is "exercise", and you do derive a cardie-vascular benefit from it, deconstructing a broken application deployment process and recreating it without the obvious defects is "learning."

Can you elaborate? I am an undergrad and this sounds incredibly interesting. What are those skills? How do you pick up them?

I can talk about each of the (few) areas I mentioned in detail, but I think I'd be leading you astray. The real question is: what are you interested in specializing in? Let's say it's field x. What will it take for you to become so well versed in x that a company will hire you to work on hard problems involving x? X can be anything - programming languages, graphics, kernel, distributed systems. And x doesn't just have to be something "hard in CS" - it can be any number of UI/UX/HCI related fields that are popping up these days.

In terms of how you pick them up: figure out what your interests are and either find a professor at school that's into this and work with him/her, or start hacking on this stuff and getting your hands wet in your spare time. I'm a new grad myself, and I can say for a fact that the ~5% of my peers who are working on truly hard problems in industry are exactly those peers who worked on hard problems in their spare time at school.

I have a growing interest in distributing systems but I am also very interested in programming language theory. I know that I want to become a software engineer but I also like to dabble with research papers.

This summer I'll join the Infrastructure team of a mid-sized startup in Waterloo, I think that's a good start but I would like to know more about your experience. What do you found the most effective way to turn an "interest" into a subject you are expert in (read able to create new and non-trivial things). I want to get my hands dirty but I am also a bit clueless as to where to start!

I have just started college but I feel that I need to figure out a (even very rough/broad) strategy to structure my learning. Waterloo is a great school but the meaty CS electives are reserved for 3rd/4th year student and I feel that I can work by myself until I reach this academic level.

Distributed systems is a very broad field, do you think that I should start by the fundamentals and then pick-up a niche area to grow in or would you rather have a broad approach, experience different things and specialize after graduation?

It would be really cool if you could shoot me an email: aaron_at_rely_dot_io Thank you :))