| If you find yourself doing only theory, do some practical work. It'll help with your theory.
| If you find yourself doing only practical, do some theory. It'll help with your practical work.
The two complement one another. Theory informs you of what is possible while the hands on informs you on what is feasible. They are different kinds of intuitions. Theory gets you thinking in high abstractions, understanding the building blocks and how things are put together. The practice forces you to deal with everything that slips through the cracks, teaching you how to do things efficiently and effectively.It's like making a building. You technically only need the construction skills to make a building. But the engineering designs make you able to build bigger and safer. The theory lets you find new novel designs and materials. You need all of this working together to build something great.
I've always found theory and practice to go hand in hand. Maybe because I came to CS from physics, but they have hard divisions there. I focused on experimental physics but I was known for strong math skills which allowed me to bridge these two sides. But the major reason I did it is because I couldn't see how they were different. So when I later heard Knuth, it really resonated with me.
But truthfully, I've struggled sometimes working with others, getting pulled in different directions. I left physics to become an engineer and all they saw me as was a theorist despite most of my work for them being practical (running simulations and then building physical devices and the necessary test infrastructure).
Now I'm about to defend my PhD in CS (ML) and the biggest struggle I've had is that it feels like any time I spend on theory is seen as wasted. I do so much less than before, but it's been the most helpful tool to my work. So I'm hoping others can help me understand this culture. We definitely see theory differently but I'm not sure why or how. Everything seems hyper focused on making products. To ship as fast as possible. No time to think about what we're making. For me, that slows me down! Just because lines of code aren't appearing on screen doesn't mean I'm not hard at work. A few hours or even a day of thought has saved me weeks worth of work. I'm not the quickest to first result[1] but the result is I can do more with less and quickly adapt to all the changes that happen as the project evolves. New experiments, measurements, features and such get integrated quickly because I expect this to happen. But still, considered slow, and I can't find out why.
So I'm wondering how others have dealt with this. I know I'm not alone here. I'm probably not going to change much because the end result works. But why is CS so focused on short term and how do I highlight longer term work when we're just measuring weekly updates. The strategy means more weeks with "not much to show" but other weeks that look like extreme productivity. But it's all the same. Because the truth is, the earlier work is just difficult or impossible to measure. I'm pretty sure this is why CS is the way it is, but I've got to say, I've got a lot of experience with measures and analysis and the fact is not everything is measurable. We only can use proxies and those easily become unaligned.
[0] I didn't copy paste it so it might be a little off but the message is right
[1] after proof of concept. Early on I try to be quick to fail. I'm talking about once that's going and we're doing more serious building.