Goal-oriented work, creativity and motivation definitely have a difficult relationship.
In programming, I learn the most things simply by experimenting at home on my own. I'm thinking about switching jobs, so I wanted to learn some new frameworks and concepts to help with that, and I decided to make my personal projects a bit more "professional". Use continuous integration, focus more on web stuff, build and automatically deploy containers and so on.
Big mistake. I don't want to spend my leisure time fighting with tools, debugging build processes that break all the time, make sense of docker's tagging system and so on. I don't mind programming all day, because I love programming, but I do mind working all day.
So I let it go. I'll come up with my own tools. They won't be great, but I'll have fun making them. And then it'll feel nice using them. And then I'll work on whatever excites me.
Once in a while someone will ask me "how do you know all these things?" and my answer has always been "I don't know that much, I just randomly got interested in this particular topic and decided to play around with it". Over the years/decades, that adds up!
This is exactly why the more I think about it, the more I just want to git-push-heroku-goodbye and be done with it.
I don't care about setting and maintaining AWS instances, docker containers and jenkins.
The older I get, the more I realize how precious my time is and now I have very little patience for anyone or anything that wastes it.
This is also why I've basically cut off all social medias from my life (except HN occasionally), have always preferred working from home to avoid wasting time in traffic, have cut off people who I don't enjoy spending time with and spend more time with my family instead.
> I don't want to spend my leisure time fighting with tools, debugging build processes that break all the time, make sense of docker's tagging system
Now that CV-driven development is the standard, we are forced to learn new bloated "devops" tools and services every year.
This type of knowledge expires very quickly.
Also these tools and services do not develop communities: business users drop last-year tools like hot potatoes when a new cheaper or shit^ny one comes along.
This hype-fueled corporate-driven culture is not going to end well.
Hah sounds like you described me perfectly. But I do have to say, ever since I'm programming full-time I seem not to be able to just code for fun anymore.
I used to program all day long.. and I guess I still do, but now it's for work, and after 8h of work I'm just done, you know? The "stuff I want to look at" list is growing longer and longer and there's no hope of me ever catching up.
(I can't imagine how it is for people with kids. How do you get anything done in your private life at all?)
Hm, it’s different for me. Since at work I don’t really do the Continuous Integration/Delivery stuff (or anything with “real infrastructure”), I find it very enjoyable to fiddle with it at home. There’s no pressure to accomplish anything and I can just leave it alone for months or even years before coming back to it.
There’s a nice side-effect, too: The CI definition documents how to compile the project. I recently dug out an old LaTeX “project” and there was nothing, no Makefile or anything. Had to look up everything again to get it to run (with XeLaTeX and Biber).
I love your "it adds up" comment. I will steal this. It is very true for me as well.
Several years ago, I started using make extensively. Not to compile, but to automate. Make understands failing and dependencies. Also, bash and zsh have wonderful completions.
I used to write a bash or python script to do this. They often turned into their own projects and were painful to document.
A great make example (thanks Aaron) is on YT: Using Terraform, Packer, and Ansible Together": https://youtu.be/pkEezNSFWtA. Aaron automated it all with make.
Ya, I know... Make was created in 1976 to compile Fortran. It's old school. I love it.
I use it to test my kubernetes CSI driver on 5 versions of k3s with a single make call. That call is the tip of a dependency tree. The leaves end up being a line or three of bash running Ansible, Go, Helm, etc, but could be anything.
Documentation is simple because the make dependencies are so easy to follow. They are much of the documentation. The docs are correct because we execute them.
There are three forms of cognitive workload: Intrinsic, External and Germane.
Intrinsic is things you just *know*. How to write a class in java, how to write a query in SQL, ...
External is stuff you only need occasionally, and need to look up every time: How to deploy to X, how to set up CI/CD, ...
Germane is context knowledge. Usually referred to as business knowledge.
You want to keep external cognitive load a minimal as possible. You can really dig deployment and stuff, and then this becomes your intrinsic cognitive workload and coding becomes more or less external, but for somebody who just likes to code, it's best to once do a deep dive to deployment logics, write a scaffold and stick with an automated version forever.
> Once in a while someone will ask me "how do you know all these things?" and my answer has always been "I don't know that much, I just randomly got interested in this particular topic and decided to play around with it". Over the years/decades, that adds up!
"Don't become a well-rounded person. Well-rounded people are smooth and dull. Become a throughly spiky person"
There is a sweet spot somewhere between the extreme of not using pre-built tools and drowning in them.
I've been following a similar path: automation and testing give me certainty and peace of mind when I'm working on bigger teams, so they should also improve my personal projects, right?
Well, the difference is that my personal projects are used only by me in limited ways, and I also don't have to worry that someone will break the build when I'm not looking. So the extra work making things super safe would not pay off that much.
Except when I feel I'm losing grip on what I'm doing, either from having to cover many use cases, not being experienced, unstable dependencies, or risk of data loss. That's when I set up CI pipelines for my personal projects.
> I'll come up with my own tools. They won't be great, but...
They WILL be great. They'll do exactly what YOU need them to do, and nothing else.
Software at present is a disaster, partly because we're just piling on complexity all the time, thinking only of the benefits and never of the huge downsides ("fighting with tools").
The mold “operates” in roughly two modes: exploring and exploiting. It explores to find the food and then it exploits the best paths to the food to consume it.
I feel our minds work in a similar way, we explore when learning new stuff and then we exploit when using what we learned to accomplish something.
Probably most of the work that majority of people do is mostly exploiting previously learned stuff, with some limited exploration sprinkled into it every now and then.
I'm struggling with this. Manager managing more and more people. Old school on premmy turned AWS and Kubernetes while I was already manager a few years ago, making it hard to learn first principles of k8s and Docker.
Now here I sit, Sunday, staring at a terminal window to force myself to set up a ruby on rails app on Docker so I can shove it into a EKS setup I will set up with Terraform.
Could I do this at work? Yes. Except No. In the hours of 'free time' between meetings and other work, I feel too mentally foggy to play and learn new things.
I had the opposite happen. I had been building servers for my (largely Django-based) projects using long txt files from old digital ocean tutorials I had customized.[1]
I fought docker and all of that but had some time last year between gigs and spent a few weeks examining the state of things and experimenting. The most influential of works were recent guides by Michael Herman. [2]
In the process I learned to set up not fully reproducible server setups but branch and commit message-specific CI/CD workflows using Github Actions.
It turns out it is like most things, hard and complicated until you know and have living samples and then it seems relatively straightforward and efficient.
GA is still fairly young and there is still opportunity to create and share flourishes of art in devops there.
Is this really a matter of tooling versus programming, or is it a matter of wanting to create rather than wanting to re-use the work of others?
Even purely in code, you always (EDIT: usually) have the choice of implementing a solution yourself or finding the work of someone else, packaged into a library, which solves the problem for you.
Implementing the solution yourself may be the most satisfying way to scratch that instantaneous creative itch. But does it create the end result which you can be most proud of or satisfied with?
I can't agree more! I make the same argument, but much less eloquently than you did "I just randomly got interested in this particular topic and decided to play aorund with it".
Using the same motivation: "let's play with things and see what I can figure out", I created a video [1] where I figure out what I need to do to create a silly version of the cat command that prints text out upside-down.
I did it for a bunch of reasons: figuring out how to replace system commands, learning a bit more about Unicode, trying out our C extension for VS Code, learning the process for building YouTube video (which was a very deep rabbit hole) ... all to produce a single video. It was fun, scratched an itch that I've had for a while that I'll continue to work on.
For me, true programming joy comes from not having to look at docs. To be able to just write code for long periods of time, without running into something weird happening with a library or tool is the "zen" feeling that I hear lots of others talk about.
At work, and in this domain:
> I wanted to learn some new frameworks and concepts to help with that, and I decided to make my personal projects a bit more "professional". Use continuous integration, focus more on web stuff, build and automatically deploy containers and so on.
It's all docs. It's all "This thing was supposed to happen but ____ didn't do what I expected". Fighting with tools and configuration and triggers and stuff like that is the opposite of zen.
> Big mistake. I don't want to spend my leisure time fighting with tools, debugging build processes that break all the time, make sense of docker's tagging system and so on. I don't mind programming all day, because I love programming, but I do mind working all day.
Yeah, I've basically moved on from anything that isn't Caprover + Portainer. Fuck the rest.
Quit normalizing work in your free time for this field. There is no other field that has such a brash concept that we all should work for free to do this. We have a skill. If an employer needs a highly specialized version of it, they better pay to train you to learn it.
"The diagrams and the whole business that I got the Nobel Prize for came from that piddling around with the wobbling plate."
This shows the extreme importance of blue sky thinking and allowing people to follow their whims sometimes rather than not starting something unless it fits into existing research goals and funding. This breakthrough all lead from an observation that had no apparent use beyond fulfilling a whim and to have fun with it.
I try to live my life by the ludic principle of 'playing'. It's honestly been the lifeblood that's fueled me, kept me sane at work and allowed me to do OK in my career. All of my best ideas at work and in things like making music came from this spirit I'm convinced.
I learned my trade by playing. I suspect that many other people on HN also did. Now I do something very different, and that also came from playing, as did many of the skills that made it possible.
I still write code, but it's entirely for fun. It's a completely different experience from closing tickets in an office.
I do many other things that aren't very cost-effective, just because they're fun. They might not pay the rent, but they keep me sane enough to do the things that do. For Mr. Feynman it was playing the bongos.
Do things that don't matter. Aside from the doors it can unlock, it's just damn fun.
Well, apart from being playful you also need to be a person who can figure out the equation for water funnel effortlessly as a high school kid. The rest of us can benefit from forcing oneself to intellectual effort
If you pay a man a salary for doing research, he and you will want to have something
to point to at the end of the year to show that the money has not been wasted.
In
promising work of the highest class, however, results do not come in this regular
fashion, in fact years may pass without any tangible result being obtained, and the
position of the paid worker would be very embarrassing and he would naturally take to
work on a lower, or at any rate a different plane where he could be sure of getting
year by year tangible results which would justify his salary.
The position is this:
You want one kind of research, but, if you pay a man to do it, it will drive him to
research of a different kind. The only thing to do is to pay him for doing something
else and give him enough leisure to do research for the love of it.
-- Attributed to J. J. Thompson by Lord Rayleigh, c. 1940
The meta-principle is that in complex domains there is no straight line, well worn, "plannable" path to greatness.
Kenneth Stanley calls it "The Myth of the objective" and has spent the last several years trying to formalize this idea (within AI as well) and get it more traction.
Applying a real world observation toward something not related is called cross-domain technological transfer.
I did the same with fishing at a lazy brook in 1983.
I observed how the river get all bendy shape of the letter “S”, how the banks are shallow on inside curves, recalled a geostat photos over decades and finally noticed how these increasingly curvy S finally touch the other curve to a point of making a new waterway path, leaving behind a stagnant bend to dry up.
Network modeling, and the many architectural variants of TCP flows came soon afterward, notably delay-tolerant TCP variant called Space Communication Protocol Specification (SCPS).
TCP-SACK was instrumental precursor toward its delay-tolerant design.
I read (listened to, technically) this book a few weeks ago because I've always been inspired by the idea of Feynman and didn't know much about him. Honestly, I actually like him less after having read it.
As I guess I should have expected, because its subtitle is "Adventures of a Curious Character", it's unfortunately for me filled with many more random personal anecdotes, often involving naked women, prostitutes, gambling, or topless bars. There are some rather more scientific and aspirational anecdotes like the one linked here, and certainly it's beneficial to learn about a man as a whole and not deify him as a scientific god. However I cracked it open hoping to read about nothing but neat ideas he had and what drove him, not read about some rather shameless guy's strange happenings.
I guess I wouldn't say I recommend against reading it, but I wouldn't get your hopes up before doing so like I did.
One thing to remember about this book that is easy to miss is that it's not a memoir or autobiography in the usual sense. You may have seen this book, and its sequel, What Do You Care What Other People Think?, described as being "by Richard Feynman and Ralph Leighton" or "edited by Ralph Leighton" or "as told to Ralph Leighton". It turns out that it was not written as a book, but his friend Ralph Leighton (son of the physicist Robert B. Leighton) took several hours of (recorded) conversations with Feynman talking to him, and selected parts of them to go into the book.
So although the book is sold as "by Richard Feynman" (which is true in some sense: it's in the first person, published when he was still alive, and he really did say everything that's in the book), it would be more accurate to call it a book by Ralph Leighton, and an appropriate title may be "Things my friend Richard Feynman told me about himself that I thought were fun". (This also explains the subtitle "Adventures of a Curious Character"—this is not Feynman calling himself that, but Leighton describing his friend that way.)
Now consider that (1) Ralph Leighton was not a physicist but Feynman's "close friend and drumming partner", and (2) Feynman was a natural conversationalist, automatically adapting his style depending on whom he was speaking to, whether it was a friend, or undergraduate physics students, or he was talking about computers to a New Age crowd at Esalen (https://www.youtube.com/watch?v=EKWGGDXe5MA), and you have this result. The friendly conversational style increases the appeal of the book and gives some insight into the speaker, but the technical detail of Feynman's core work, which was very important to him, gets diluted.
(One of my professors disliked the book for giving the impression that you get a Nobel Prize just living a life of having fun and playing around, while in fact Feynman was known to work very hard, at all hours of day and night. He liked to re-derive by himself anything he learned till he was satisfied he understood it, and that took prodigious amounts of pen-and-paper calculation. This may partly be Feynman projecting an aura of effortless brilliance, but I think it's more likely a combination of the fact that hard work doesn't seem hard if you enjoy it enough, and that going in detail about how hard you worked does not make for very good conversation.)
It is true that many memoirs are written this same way (dictating to someone else), but I think this book shows the effects more than most: including the selection of topics, as you observed.
(BTW the audio material that went into the books is available too, as "The Feynman Tapes", and listening to it may give a different impression than listening to an audiobook of someone else reading the text of a book itself transcribed from audio: https://kongar-olondar.bandcamp.com/ )
All the stories had neat ideas, demonstrated his personality and showed what drove him. Of course it wasn't laid out directly in a boring technical book that no one is going to read.
Also, what's up with people ignoring the fine line between crazy and genius, and thinking all these genius are supposed to be completely normal people?
I don't think Feynman was that different in this masculine or promiscuous respect from many of that era's greats... Schrödinger, von Neumann, Einstein, to name a few.
Feynman at least writes extensively about his deceased wife.
I imagine you would not enjoy reading history too much as the 21st C Western first world attitudes on these topics are pretty unique compared to any other time.
There is some pretty bad sexism in the book (because that era was sexist, I guess), but I think your comment goes too far the other way and treats sex as taboo. What's wrong with naked women, prostitutes, gambling and topless bars?
If you’re looking for a deeper look beyond the anecdotes, I’d recommend James Gleick’s Genius: The Life and Science of Richard Feynman. It covers much more of the ideas he had and what drove him.
This is one of my favourite anecdotes from that book. In recent decades, we've learned how important intrinsic motivation is, and this is a great example of it.
My father was a massive fan of Richard Feynman and also happened to be extremely cynical about formal education. He believed that if you wanted to learn something, you had to take the initiative and learn it for yourself, rather than waiting for the education system to suck the enthusiasm for the subject out of you. It was only after Dad died that I picked up his copy of Surely You're Joking Feynman and learned where he got a lot of his ideas from.
I think you need both. Formal education is great for "basic skills". Most people won't invent calculus on their own. Most of us learn reading and writing in a formal way. But equally, formal education is only half of what is needed to be good in a field of work. Then there comes the experimentation, the practise. All the knowledge that can't really be taught by a book. Sometimes a good teacher or mentor can help on that side, but real excellence comes through your own tinkering.
The anecdote of Feynman shows this actually well. He gained a lot of knowledge and inspiration for other problems solutions by working out the motion of the plate. But he did so by using the calculus and tools of theoretical mechanics. Those were what enabled him to do the theoretical description which then yielded the insights.
> I had nothing to do, so I start to figure out the motion of the rotating plate. I discover that when the angle is very slight, the medallion rotates twice as fast as the wobble rate - two to one [Note: Feynman mis-remembers here---the factor of 2 is the other way].
To me it's even more inspirational that Feynman misremembered basic things about physics he understood better than almost anyone. He achieved so much, and yet fundamentally was human and imperfect. Any curious smart mind can achieve something great.
A while back I realized that I don't care about my career anymore: Promotions, politics, etc. I'm just going to work on what I enjoy. So far I'm a lot happier this way.
> When I was in high school, I'd see water running out of a faucet growing narrower, and wonder if I could figure out what determines that curve. I found it was rather easy to do.
Out of curiosity, does anyone know the solution to this problem? I wouldn’t even know how to approach it. (I’m an undergraduate physics major; I know nothing about fluid dynamics, but from Feynmann’s description I suspect that isn’t necessary…)
A couple of comments here focus on the ability to play -- which is important -- and on blue sky thinking, etc. All very important, true!
But what really strikes me is how this situation Feynman was in is a perfect example of Deep Work. He could expore whatever his mind needed to explore, and do it for as long and in whatever way he needed.
I'm pretty sure this is an often overlooked success factor for his Nobel win.
I makes me think about how I approach really difficult problems. I use a strategy that I call: "obsess and let go" that has worked wonders for me.
Essentially it has two parts:
- obsession: look at the problem intently, poke it, prod it, think about experiments, talk to other people until you're completely blocked and making absolutely no progress.
- letting go: forget about it, go do something else, exercise, take a vacation, paint, attack a different problem, go to a bar, whatever makes you let go (truly let go).
Eventually, as if by magic, at some unknowable time later (could be days or years), while doing something else the beginning of solution pops into consciousness, like a thread that needs to be pulled and as if by magic the whole problem untangles.
I have no clue why this works (I assume the subconscious part of the brain never really lets go after a good obsessive phase), but it does work more often than not.
The hard part is dealing with outside expectations.
Similar to “You have to keep a dozen of your favorite problems constantly present in your mind, although by and large, they will lay in a dormant state. Every time you hear read a new trick or a new result, test it against each of your 12 problems to see whether it helps. Every once in a while there will be a hit and people will say “How did he do it. He must be a genius.” - Richard Feynman
Interesting how Feynman can be inspiring people long after his death.
He sounds as if he likes to talk about himself rather too much, so I wouldn't be surprised if there was a fair amount of exaggeration in his prose.
That said, if I made a list of dead people I'd like to spend a day with if I could, he'd sure be on it (as an aside, who [else] would you add to such a list?).
And he could be serious, too: despite being an outspoken atheist, he deeply loved his wife to the extent that he wrote a letter to her after she had passed away.
> And before I knew it (it was a very short time) I was ``playing'' - working, really - with the same old problem that I loved so much, that I had stopped working on when I went to Los Alamos: my thesis-type problems; all those old-fashioned, wonderful things.
Given the circumstances of the time, post-war, and his circumstances, the loss of his wife and stress of the Manhattan project, I might argue a guess that he was grieving.
So it's not just that he found playfulness with physics, it's that he was ready to find it.
What I'm trying to say is don't force it if you're grieving or suffering from some traumatic event. Feynman could play with physics again because he was ready to do so.
The last sentence "There was no importance to what I was doing, but ultimately there was. The diagrams and the whole business that I got the Nobel Prize for came from that piddling around with the wobbling plate." reminds me of Steve Jobs' speech at Stanford - "Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backward 10 years later."
Intrinsic motivation does lead you to better places. Programming was such a breeze before, I enjoyed it. But now, as I start to build a portfolio, anxiety creeps up. "Should it be like this or this? Man, this doesn't feel right." I admit my way of thinking is flawed, which I'm also working on. But it really is different when your goal is to enjoy the process than to please prospective employers.
Love that sort of infectious enthusiasm. I guess the question for me is how to balance that sort of explorational play with actually trying to accomplish something, like starting a start-up. The lure of playing with something constantly challenges the need to focus on finishing something that in the moment seems less interesting.
[+] [-] Netcob|4 years ago|reply
In programming, I learn the most things simply by experimenting at home on my own. I'm thinking about switching jobs, so I wanted to learn some new frameworks and concepts to help with that, and I decided to make my personal projects a bit more "professional". Use continuous integration, focus more on web stuff, build and automatically deploy containers and so on.
Big mistake. I don't want to spend my leisure time fighting with tools, debugging build processes that break all the time, make sense of docker's tagging system and so on. I don't mind programming all day, because I love programming, but I do mind working all day.
So I let it go. I'll come up with my own tools. They won't be great, but I'll have fun making them. And then it'll feel nice using them. And then I'll work on whatever excites me.
Once in a while someone will ask me "how do you know all these things?" and my answer has always been "I don't know that much, I just randomly got interested in this particular topic and decided to play around with it". Over the years/decades, that adds up!
[+] [-] swat535|4 years ago|reply
I don't care about setting and maintaining AWS instances, docker containers and jenkins.
The older I get, the more I realize how precious my time is and now I have very little patience for anyone or anything that wastes it.
This is also why I've basically cut off all social medias from my life (except HN occasionally), have always preferred working from home to avoid wasting time in traffic, have cut off people who I don't enjoy spending time with and spend more time with my family instead.
[+] [-] goodpoint|4 years ago|reply
Now that CV-driven development is the standard, we are forced to learn new bloated "devops" tools and services every year.
This type of knowledge expires very quickly.
Also these tools and services do not develop communities: business users drop last-year tools like hot potatoes when a new cheaper or shit^ny one comes along.
This hype-fueled corporate-driven culture is not going to end well.
[+] [-] schindlabua|4 years ago|reply
I used to program all day long.. and I guess I still do, but now it's for work, and after 8h of work I'm just done, you know? The "stuff I want to look at" list is growing longer and longer and there's no hope of me ever catching up.
(I can't imagine how it is for people with kids. How do you get anything done in your private life at all?)
[+] [-] fuzzy2|4 years ago|reply
There’s a nice side-effect, too: The CI definition documents how to compile the project. I recently dug out an old LaTeX “project” and there was nothing, no Makefile or anything. Had to look up everything again to get it to run (with XeLaTeX and Biber).
[+] [-] sqqqqrly|4 years ago|reply
Several years ago, I started using make extensively. Not to compile, but to automate. Make understands failing and dependencies. Also, bash and zsh have wonderful completions.
I used to write a bash or python script to do this. They often turned into their own projects and were painful to document.
A great make example (thanks Aaron) is on YT: Using Terraform, Packer, and Ansible Together": https://youtu.be/pkEezNSFWtA. Aaron automated it all with make.
Ya, I know... Make was created in 1976 to compile Fortran. It's old school. I love it.
I use it to test my kubernetes CSI driver on 5 versions of k3s with a single make call. That call is the tip of a dependency tree. The leaves end up being a line or three of bash running Ansible, Go, Helm, etc, but could be anything.
Documentation is simple because the make dependencies are so easy to follow. They are much of the documentation. The docs are correct because we execute them.
[+] [-] teraku|4 years ago|reply
There are three forms of cognitive workload: Intrinsic, External and Germane.
Intrinsic is things you just *know*. How to write a class in java, how to write a query in SQL, ...
External is stuff you only need occasionally, and need to look up every time: How to deploy to X, how to set up CI/CD, ...
Germane is context knowledge. Usually referred to as business knowledge.
You want to keep external cognitive load a minimal as possible. You can really dig deployment and stuff, and then this becomes your intrinsic cognitive workload and coding becomes more or less external, but for somebody who just likes to code, it's best to once do a deep dive to deployment logics, write a scaffold and stick with an automated version forever.
[+] [-] Balgair|4 years ago|reply
"Don't become a well-rounded person. Well-rounded people are smooth and dull. Become a throughly spiky person"
-Bruce Sterling
[+] [-] rhn_mk1|4 years ago|reply
I've been following a similar path: automation and testing give me certainty and peace of mind when I'm working on bigger teams, so they should also improve my personal projects, right?
Well, the difference is that my personal projects are used only by me in limited ways, and I also don't have to worry that someone will break the build when I'm not looking. So the extra work making things super safe would not pay off that much.
Except when I feel I'm losing grip on what I'm doing, either from having to cover many use cases, not being experienced, unstable dependencies, or risk of data loss. That's when I set up CI pipelines for my personal projects.
[+] [-] temporama1|4 years ago|reply
They WILL be great. They'll do exactly what YOU need them to do, and nothing else.
Software at present is a disaster, partly because we're just piling on complexity all the time, thinking only of the benefits and never of the huge downsides ("fighting with tools").
[+] [-] ta1234567890|4 years ago|reply
The mold “operates” in roughly two modes: exploring and exploiting. It explores to find the food and then it exploits the best paths to the food to consume it.
I feel our minds work in a similar way, we explore when learning new stuff and then we exploit when using what we learned to accomplish something.
Probably most of the work that majority of people do is mostly exploiting previously learned stuff, with some limited exploration sprinkled into it every now and then.
[+] [-] mancerayder|4 years ago|reply
Now here I sit, Sunday, staring at a terminal window to force myself to set up a ruby on rails app on Docker so I can shove it into a EKS setup I will set up with Terraform.
Could I do this at work? Yes. Except No. In the hours of 'free time' between meetings and other work, I feel too mentally foggy to play and learn new things.
Please.Help.Me.
I think I just need a vacation.
[+] [-] bredren|4 years ago|reply
I fought docker and all of that but had some time last year between gigs and spent a few weeks examining the state of things and experimenting. The most influential of works were recent guides by Michael Herman. [2]
In the process I learned to set up not fully reproducible server setups but branch and commit message-specific CI/CD workflows using Github Actions.
It turns out it is like most things, hard and complicated until you know and have living samples and then it seems relatively straightforward and efficient.
GA is still fairly young and there is still opportunity to create and share flourishes of art in devops there.
[1] https://www.digitalocean.com/community/tutorials/how-to-set-...
[2] https://testdriven.io/blog/deploying-django-to-digitalocean-...
[+] [-] shawnz|4 years ago|reply
Even purely in code, you always (EDIT: usually) have the choice of implementing a solution yourself or finding the work of someone else, packaged into a library, which solves the problem for you.
Implementing the solution yourself may be the most satisfying way to scratch that instantaneous creative itch. But does it create the end result which you can be most proud of or satisfied with?
[+] [-] localhost|4 years ago|reply
Using the same motivation: "let's play with things and see what I can figure out", I created a video [1] where I figure out what I need to do to create a silly version of the cat command that prints text out upside-down.
I did it for a bunch of reasons: figuring out how to replace system commands, learning a bit more about Unicode, trying out our C extension for VS Code, learning the process for building YouTube video (which was a very deep rabbit hole) ... all to produce a single video. It was fun, scratched an itch that I've had for a while that I'll continue to work on.
[1] https://www.youtube.com/watch?v=OJ2ivP2llFs
[+] [-] void_mint|4 years ago|reply
At work, and in this domain:
> I wanted to learn some new frameworks and concepts to help with that, and I decided to make my personal projects a bit more "professional". Use continuous integration, focus more on web stuff, build and automatically deploy containers and so on.
It's all docs. It's all "This thing was supposed to happen but ____ didn't do what I expected". Fighting with tools and configuration and triggers and stuff like that is the opposite of zen.
[+] [-] WrtCdEvrydy|4 years ago|reply
Yeah, I've basically moved on from anything that isn't Caprover + Portainer. Fuck the rest.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] utxaa|4 years ago|reply
[+] [-] MeinBlutIstBlau|4 years ago|reply
[+] [-] jmfldn|4 years ago|reply
This shows the extreme importance of blue sky thinking and allowing people to follow their whims sometimes rather than not starting something unless it fits into existing research goals and funding. This breakthrough all lead from an observation that had no apparent use beyond fulfilling a whim and to have fun with it.
I try to live my life by the ludic principle of 'playing'. It's honestly been the lifeblood that's fueled me, kept me sane at work and allowed me to do OK in my career. All of my best ideas at work and in things like making music came from this spirit I'm convinced.
[+] [-] nicbou|4 years ago|reply
I still write code, but it's entirely for fun. It's a completely different experience from closing tickets in an office.
I do many other things that aren't very cost-effective, just because they're fun. They might not pay the rent, but they keep me sane enough to do the things that do. For Mr. Feynman it was playing the bongos.
Do things that don't matter. Aside from the doors it can unlock, it's just damn fun.
[+] [-] mmcnl|4 years ago|reply
[+] [-] oytis|4 years ago|reply
[+] [-] hprotagonist|4 years ago|reply
In promising work of the highest class, however, results do not come in this regular fashion, in fact years may pass without any tangible result being obtained, and the position of the paid worker would be very embarrassing and he would naturally take to work on a lower, or at any rate a different plane where he could be sure of getting year by year tangible results which would justify his salary.
The position is this: You want one kind of research, but, if you pay a man to do it, it will drive him to research of a different kind. The only thing to do is to pay him for doing something else and give him enough leisure to do research for the love of it.
-- Attributed to J. J. Thompson by Lord Rayleigh, c. 1940
[+] [-] bvsrinivasan|4 years ago|reply
Kenneth Stanley calls it "The Myth of the objective" and has spent the last several years trying to formalize this idea (within AI as well) and get it more traction.
Book -- https://www.goodreads.com/book/show/25670869-why-greatness-c...
Talk -- https://youtu.be/dXQPL9GooyI
[+] [-] egberts1|4 years ago|reply
I did the same with fishing at a lazy brook in 1983.
I observed how the river get all bendy shape of the letter “S”, how the banks are shallow on inside curves, recalled a geostat photos over decades and finally noticed how these increasingly curvy S finally touch the other curve to a point of making a new waterway path, leaving behind a stagnant bend to dry up.
Network modeling, and the many architectural variants of TCP flows came soon afterward, notably delay-tolerant TCP variant called Space Communication Protocol Specification (SCPS).
TCP-SACK was instrumental precursor toward its delay-tolerant design.
[+] [-] bserge|4 years ago|reply
[+] [-] jacobmischka|4 years ago|reply
As I guess I should have expected, because its subtitle is "Adventures of a Curious Character", it's unfortunately for me filled with many more random personal anecdotes, often involving naked women, prostitutes, gambling, or topless bars. There are some rather more scientific and aspirational anecdotes like the one linked here, and certainly it's beneficial to learn about a man as a whole and not deify him as a scientific god. However I cracked it open hoping to read about nothing but neat ideas he had and what drove him, not read about some rather shameless guy's strange happenings.
I guess I wouldn't say I recommend against reading it, but I wouldn't get your hopes up before doing so like I did.
[+] [-] svat|4 years ago|reply
So although the book is sold as "by Richard Feynman" (which is true in some sense: it's in the first person, published when he was still alive, and he really did say everything that's in the book), it would be more accurate to call it a book by Ralph Leighton, and an appropriate title may be "Things my friend Richard Feynman told me about himself that I thought were fun". (This also explains the subtitle "Adventures of a Curious Character"—this is not Feynman calling himself that, but Leighton describing his friend that way.)
Now consider that (1) Ralph Leighton was not a physicist but Feynman's "close friend and drumming partner", and (2) Feynman was a natural conversationalist, automatically adapting his style depending on whom he was speaking to, whether it was a friend, or undergraduate physics students, or he was talking about computers to a New Age crowd at Esalen (https://www.youtube.com/watch?v=EKWGGDXe5MA), and you have this result. The friendly conversational style increases the appeal of the book and gives some insight into the speaker, but the technical detail of Feynman's core work, which was very important to him, gets diluted.
(One of my professors disliked the book for giving the impression that you get a Nobel Prize just living a life of having fun and playing around, while in fact Feynman was known to work very hard, at all hours of day and night. He liked to re-derive by himself anything he learned till he was satisfied he understood it, and that took prodigious amounts of pen-and-paper calculation. This may partly be Feynman projecting an aura of effortless brilliance, but I think it's more likely a combination of the fact that hard work doesn't seem hard if you enjoy it enough, and that going in detail about how hard you worked does not make for very good conversation.)
It is true that many memoirs are written this same way (dictating to someone else), but I think this book shows the effects more than most: including the selection of topics, as you observed.
(BTW the audio material that went into the books is available too, as "The Feynman Tapes", and listening to it may give a different impression than listening to an audiobook of someone else reading the text of a book itself transcribed from audio: https://kongar-olondar.bandcamp.com/ )
[+] [-] P0l83q4p1Hw3Ul|4 years ago|reply
All the stories had neat ideas, demonstrated his personality and showed what drove him. Of course it wasn't laid out directly in a boring technical book that no one is going to read.
Also, what's up with people ignoring the fine line between crazy and genius, and thinking all these genius are supposed to be completely normal people?
[+] [-] practicalpants|4 years ago|reply
Feynman at least writes extensively about his deceased wife.
I imagine you would not enjoy reading history too much as the 21st C Western first world attitudes on these topics are pretty unique compared to any other time.
[+] [-] StavrosK|4 years ago|reply
[+] [-] otras|4 years ago|reply
[+] [-] chris_j|4 years ago|reply
My father was a massive fan of Richard Feynman and also happened to be extremely cynical about formal education. He believed that if you wanted to learn something, you had to take the initiative and learn it for yourself, rather than waiting for the education system to suck the enthusiasm for the subject out of you. It was only after Dad died that I picked up his copy of Surely You're Joking Feynman and learned where he got a lot of his ideas from.
[+] [-] _ph_|4 years ago|reply
The anecdote of Feynman shows this actually well. He gained a lot of knowledge and inspiration for other problems solutions by working out the motion of the plate. But he did so by using the calculus and tools of theoretical mechanics. Those were what enabled him to do the theoretical description which then yielded the insights.
[+] [-] 55555|4 years ago|reply
To me it's even more inspirational that Feynman misremembered basic things about physics he understood better than almost anyone. He achieved so much, and yet fundamentally was human and imperfect. Any curious smart mind can achieve something great.
[+] [-] LordHumungous|4 years ago|reply
[+] [-] bradrn|4 years ago|reply
Out of curiosity, does anyone know the solution to this problem? I wouldn’t even know how to approach it. (I’m an undergraduate physics major; I know nothing about fluid dynamics, but from Feynmann’s description I suspect that isn’t necessary…)
[+] [-] dang|4 years ago|reply
Feynman: I am burned out and I'll never accomplish anything - https://news.ycombinator.com/item?id=10585890 - Nov 2015 (22 comments)
Feynman: I am burned out and I'll never accomplish anything - https://news.ycombinator.com/item?id=3874875 - April 2012 (66 comments)
Feynman's wobbling plate: how to recover from burnout - https://news.ycombinator.com/item?id=2291773 - March 2011 (22 comments)
[+] [-] hungryforcodes|4 years ago|reply
But what really strikes me is how this situation Feynman was in is a perfect example of Deep Work. He could expore whatever his mind needed to explore, and do it for as long and in whatever way he needed.
I'm pretty sure this is an often overlooked success factor for his Nobel win.
[+] [-] juancn|4 years ago|reply
Essentially it has two parts:
- obsession: look at the problem intently, poke it, prod it, think about experiments, talk to other people until you're completely blocked and making absolutely no progress.
- letting go: forget about it, go do something else, exercise, take a vacation, paint, attack a different problem, go to a bar, whatever makes you let go (truly let go).
Eventually, as if by magic, at some unknowable time later (could be days or years), while doing something else the beginning of solution pops into consciousness, like a thread that needs to be pulled and as if by magic the whole problem untangles.
I have no clue why this works (I assume the subconscious part of the brain never really lets go after a good obsessive phase), but it does work more often than not.
The hard part is dealing with outside expectations.
[+] [-] robocat|4 years ago|reply
[+] [-] zeeshanqureshi|4 years ago|reply
John Cleese's book[1] and lecture[2] on creativity also have some thoughts on this.
[1] https://www.goodreads.com/book/show/50719532-creativity
[2] https://www.youtube.com/watch?v=Pb5oIIPO62g
[+] [-] jll29|4 years ago|reply
He sounds as if he likes to talk about himself rather too much, so I wouldn't be surprised if there was a fair amount of exaggeration in his prose.
That said, if I made a list of dead people I'd like to spend a day with if I could, he'd sure be on it (as an aside, who [else] would you add to such a list?).
And he could be serious, too: despite being an outspoken atheist, he deeply loved his wife to the extent that he wrote a letter to her after she had passed away.
[+] [-] decasteve|4 years ago|reply
Given the circumstances of the time, post-war, and his circumstances, the loss of his wife and stress of the Manhattan project, I might argue a guess that he was grieving.
So it's not just that he found playfulness with physics, it's that he was ready to find it.
What I'm trying to say is don't force it if you're grieving or suffering from some traumatic event. Feynman could play with physics again because he was ready to do so.
[+] [-] kkylin|4 years ago|reply
https://mitpress-request.mit.edu/sites/default/files/titles/...
and the quantum analog:
https://en.wikipedia.org/wiki/Spin%E2%80%93orbit_interaction
[+] [-] ibic|4 years ago|reply
[+] [-] alskdj21|4 years ago|reply
[+] [-] shannifin|4 years ago|reply