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.
Sadly the extended out of state family seems to like FB, and I try to follow science/math twitter.
As you get older, something in you clicks, that you realize that time spent being angry, or combative, reduces the time you have for enjoying things (family, life, etc.).
Your time on earth is a zero sum game. Maximize its utility, maximize your enjoyment, minimize your negativity (e.g. outrage of the day on social media). Your life will be better.
Even better (imo) is going beyond the maximization maxim and realise the “beauty” of the analog, a world you directly see, hear, touch. Just existing without a specific goal, which is indeed similar as a vacation / holiday. However people seem to reserve the “no goal” mindset only on vacation, but you could also integrate it into your life.
Hear hear! I wish one day the dev community will understand that its never about the tools and more about the delivery. The customer does not give a monkey if the backend is node, go or PHP. You do not impress anyone by using React, redux, amber, angular ... etc. All people care about is a solution to a problem they have.
However, from my experience, this is not a popular opinion among developers.
It's not popular because it's not realistic in most environments. In many cases it's advantageous to use those things you listed because that's what the market can provide talent-wise. I'd rather deal with learning new tech that's well documented than some custom lib that "just works" but no one understands because the architect left years ago. My whole career has been about consistent education, so that doesn't intimidate me. Working on undocumented architectures that I have to make substantial changes to (and not knowing all of the side effects) is what intimidates me.
Turnover is a reality that can't be ignored. New people come in and now have to figure out something that reads like a stream of conscience. It isn't well documented, doesn't follow the latest best practices and doesn't support modern paradigms and uses outdated frameworks/libs, but works great.
The apps I build always take into consideration the talent pool my employer intends to pull from. The reality is that they (usually) can't hire general "technologists" that are proficient at all layers of the stack. If the project is something that only you will ever work on, then you can do whatever you want and this whole conversation is moot.
it's advantageous to use those things you listed because that's what the market can provide talent-wise
More silliness. Pay developers enough so that they'll stick around. If they stick around, then you don't need to hire for talent in a particular framework or language. You can hire for intelligence, creativity, passion, drive, whatever... and invest in training people when they get there.
Jumping from framework to framework and language to language as the talent pool does is incredibly wasteful.
> Pay developers enough so that they'll stick around
It's amazing FANG companies have any turnover based on that logic. Turnover happens for a variety of reasons... like global pandemics... you can't make a blanket statement like that and expect to be taken seriously.
I believe you have agreed with me in your points especially regarding talent and turnover. The shiny tech today will be a legacy 6 months later or a year if you’re lucky. Then the talent pool will change and you can’t attract the devs who religiously follow new trends. You’ll end up hiring people to deal with your {legacy} system or as you pointed out .. substantial changing it.
React/Redux/Angular all have staying power so I don't understand your point. I don't know what you mean by "shiny" tech. Other than specific libs that go unmaintained, most popular tech has some staying power.
That’s not a universal truth. Java was shiny once upon a time. Rails was shiny once, even C was shiny once. This stuff is still being used (not legacy). I’m sure when rails first showed up, people were calling it a fad.
In JS land there’s a ton of churn though for sure if that’s what you were thinking about. Not all of it though.
Being used does not mean it is not legacy. Do you consider a system running in Java 6 up to date? But if it is stable, serving customers requirements then there is no need to replace it.
The point I am making is, using the current {shiny} tools might not be the correct answer (it could be though depending on the use case). Just use whatever gets the job done faster and then iterate. Some developers will start solutionising based on technology instead of focusing what is the purpose of the system and how it will help users. AKA: CV driven development :)
Which is why I open my conversational interviews with, "There's an emergency, sales promised a customer a to-do list app yesterday. It's getting shipped out and forgotten, you're doing it on your own, only thing that matters is it's done fast. What do you use?". And then of course I spring the, "Okay, now it's becoming a flagship product. How do you onboard co-workers? How do you pivot to ongoing maintenance? What problems do you anticipate scaling it out?". But it's always important to have a tool in your toolbox to hack something together in an afternoon, even if it's just to prove a point.
As a candidate that would be a hell of a red flag, particularly as an opener. After answering I would definitely follow up with "are situations like those an expected part of my day-to-day?" and minutely examine your response. Even if the rest of the interview went swimmingly that opener would give me pause after the fact.
That question translates to me as "your sister teams/leadership/communication infrastructure are completely incompetent/lacking and you're on the spot to pull an 18 hour shift to clean up their mess. What do you do?"
Sure occasional unforeseen emergencies/breakdowns in communication are expected even at the best of companies, but I'd replace it with a hypothetical that makes the company sound fundamentally competent. Perhaps something like "The company has promised the customer a To-Do List App, however automated testing failed to catch a mission-critical edge-case. This comes to light the day before it's supposed to be delivered. The flaw is so fundamental that the app will have to be re-written. Everyone else is handling other parts of the delivery, so you're on the spot to do it on your own. The only thing that matters is that it's done fast. What do you use?"
I'd make a note of that response and count it in your favour. But if you get sidetracked enough that you never end up answering the question, that's also not a good sign.
IMO your counterexample is wildly implausible, and is likely to sidetrack the candidate. "Is nothing salvageable? What was the flaw? What automated testing? Do I have to use that testing in my alternative fix? How does that reflect on the rest of my tech stack choice?"
True, just came up with it off the top of my head. I suppose it is possible to be too detailed in such questions. Point being it at least makes it sound like the company was doing the right things and got hit out of left field, vs stepping in a pile of their own making and making you responsible for fixing it.
Perhaps a more innocent miscommunication like the customer failed to clearly communicate requirements, and it was just discovered in an email conversation that they were expecting and as-of-yet un-implemented To-Do List App in the current release, which is shipping tomorrow/this week/etc. I've experienced situations like that before, not sure how applicable it is to your business.
Perhaps a better way to phrase it would be along the lines of, "You propose a to-do list app at a team meeting, and you want to demonstrate that it's a feasible product. However, you have a limited time box to ship it in. What do you reach for?" It lacks a bit of the urgency of the original question, but still comes with time constraints.
My original example is born of a decade of cynicism, and you're right that it could reflect poorly on the company. Thank you for the feedback, though in fact I'm happily unemployed right now.
Fair point. I'd say it's sensible for the candidate to assume that context added to any hypothetical is there to inform their answer. Why add the context if it's not meant to inform? At that point it becomes fluff at best and misleading at worst.
It would make no sense for an interviewer to provide meaningless context unless they were deliberately attempting to distract from the the question, or are otherwise simply incompetent/unfocused. I don't see how gas-lighting candidates would be a productive mode of interview, particularly given that each party only has the interview from which to judge each others' character. Even if the candidate were to successfully discern the gas-lighting, all it would do is prevent trust from being formed. At that point every interaction would be subject to question.
So with the assumption that gas-lighting is not the intent and that the hiring party is competent, the question is how is the context meant to inform the response?
Given that the interviewer is gauging the candidate's ability to perform a job, it is sensible to assume that realistic-sounding context applied to a question is meant to see how the candidate would perform in what the interviewer deems a "realistic" scenario.
If the scenario is unrealistic but meant to impart other information, then it should be obvious or stated as such, so that the candidate can attempt to parse to the correct information from the scenario to inform their response.
If the point is merely to motivate the candidate to answer the question by placing themselves in a narrative, I'd argue they should be motivated enough by the fact that they're in a job interview, without the need for unrealistic scenarios. If they aren't then they clearly aren't taking the position seriously or likely have other issues that would impact their job performance even if hired.
Take the hypothetical removed from context: "You have make a deployable to-do list app as quickly as possible, speed and basic functionality are the only priorities. What tools do you use?..." That format accomplishes the same goal of revealing the candidate's knowledge of what a quick/dirty workflow looks like. The followup questions mentioned "what problems to you anticipate when scaling the solution? How would you on-board coworkers? How would you shift from rapid development to ongoing maintenance? etc" would then flesh out the candidate's knowledge equally as well.
> Even if the candidate were to successfully discern the gas-lighting, all it would do is prevent trust from being formed. At that point every interaction would be subject to question.
That would give me a bad impression as a candidate.
It's like you're aware of the issue (sales doesn't give two shits about the capacity of the engineering team) but you want someone that is good at wasting a lot of time efficiently instead of improving communication with the sales team.
And then as a hiring manager I get the impression that this candidate doesn't understand hypotheticals, which is a big red flag. Happily, we will come to mutual agreement on whether you proceed.
As a candidate I by definition know practically nothing about your company and how it operates internally save for maybe some glassdoor reviews, and you're supposed to be judging how I would perform as a part of said company, same way I'm judging whether the position is worth my time or not.
If all your hypotheticals revolve around cleaning up the mess of flagrantly incompetent coworkers/leadership I'm going to get the impression that that's what I'm expected to do all the time. You could get the same information with different hypotheticals, so there's no point in making your company sound like a horrible place to work.
Happily, we would come to a mutual decision that I should produce profits for someone else. It sounds like you're one of those managers who wants supplicants, not applicants. Good luck with that.
I wouldn't hire someone without telling them plenty about where they will work. You don't have to guess what the workplace is like by decoding my questions. You are certainly welcome to, but the obvious danger is that you will get something wrong. A mature person would just ask, and that's the type of person I would want to hire.
It sounds like you're one of those managers who wants supplicants, not applicants.
Absolutely not. I want human beings with whom I can have a good relationship with, based in communication. I definitely don't want to hire a robot who is making important assumptions based on questionable (and totally wrong) heuristics, and Not bothering to ask simple questions.
So yeah, someone applying a weird algorithm to the questions I'm asking them isn't going to be a good fit.
Isn’t the development community sort of there? I mean, most things are still run on PHP, and honestly, I recently saw an open source “forms for the public sector” thing build in Drupal, and now I’m wondering if we’ll ever need another custom programmed form for our web facing applications.
Yet if I go back to my non-management dev friends and talk about this, they are all like “eeeew, what about X and Y” and I’m just like, but neither the citizens or my IT operations staff gives two shits about any of that.
I’m not going to say what is right technically, because I’m not qualified to do that, but I do know what will happen as it’s my decision, and we’ll be slowly moving all our customs forms to a PHP CMS system and we’re just going to shoot the docket container it comes in directly out into our internal Azure cloud with public access through our national identity system (NemID). My developers aren’t going to be out of work either, but instead of making the same form with small differences 9000 times, they will be building Drupal modules with actual challenges.
> Yet if I go back to my non-management dev friends and talk about this, they are all like "eeeew, what about X and Y" and I'm just like, but neither the citizens or my IT operations staff gives two shits about any of that.
That's exactly what I meant. I remember arguing with a colleague who over-engineered a simple ORM table by having 3 classes. One was just an empty class, the other was an empty interface, and the third was the actual class. When I asked why did you make it this way? He said: "What if we decided to use Mongo later?
Technically he was right but practically, he was wrong! I saw this overthinking and over-engineering pattern across many in-house dev teams. But this is just my experience, and I'm not judging what is right and wrong from devs point of view. Every decision has its context, but I saw how these complications affecting the delivery and customer experience badly.
For some reason the first time I do something I always over engineer it... it took me a lot of self growth to take feedback like yours seriously and not get defensive of my “what-if” thought patterns.
I’ve gotten into the habit of just pumping out a naïve solution without worrying about anything and then throwing it away and re-building more thoughtfully because now I have full sense of the scope and some immediate edge-cases. As long as the thing is small enough to do that.
Yup, I agree it's likely not a popular opinion. In my experience, developers love developing frameworks and tools, even when it isn't necessary.
I mean, it's just fun. Developers are biased to do things that make work interesting, even if it's superfluous. We think that coming up with a better framework or tool will save time in the future. I think that often it's just a wash or a net negative since you now have to maintain this tool AND when you first start on creating it, you are sort of naive about what it needs to support, so you open yourself up to a lot of hurt later when clients of your tool come up with more requirements than you envisioned.
I completely overbuilt a recent side project and ended up scraping the whole thing because it wastes too much time to maintain it. As much as I love building new projects, having children at home reminds me that time is my only true resource and it's better spent with the kiddos (at least at this stage of my life).
Asking because I feel this way a lot too -- is this the kind of thing that was avoidable (IE if you built it on Rails/Django + Heroku would that have cut down the maintenance), or was there intrinsic complexity to the project that made it unavoidable?
More and more, I want to build things that are in the former category if I build them at all outside of work.
In my particular case, I opened the CI/CD can of worms using Docker (which obviously has great use cases). My use case could have fit into a Rails/Django + Heroku model that would have saved me a bunch of time. I thought by investing in the infra early it would save me time later, however later will likely never come. So basically I spent more time debugging issues due to adding infrastructure complexity than developing the actual project.
TLDR; Wasn't a total loss as I did learn some, however I would have rather spend more time on developing the actual product (or in retrospect more time with my family).
This tech is great when someone working full time at your company sets up all the scaffolding and you just code your microservice with magic happening around it. Not so great when devs trying to spice up their resume start implementing these ideas to their own personal projects during their free time. I've spent so many hours fighting Basel, gRCP, API gateways, tracing etc etc, just because it's nice at work. But took too much time to replicate something own my own, and it is of course, fragile.
Depends on what you're building. Rails/django/heroku are web app accelerators. If you are building a web app, then yea they make it super easy and take away a lot of having to think about complex systems, but if you're building anything else not really
Are you sure about that? You get a ton from a batteries included framework, but it doesn't prevent from successfully building a complex system, nor does it preclude you from having to reason through the powerful footguns.
The way I'd describe it is that /most/ codebases can fit into what you'd call a "web app" including most codebases that include complex systems -- there are, of course, significant exceptions.
I still use Heroku for almost all my personal projects. I stopped for a while, but they now allow you to dockerize your projects and push them to their registry. They also allow you to have multiple apps with access to shared resources. Those two changes have made it much more flexible than it was back in the early days.
You never realize how much configuration of AWS is like pulling teeth until you stop.
I'm going through literally what you mentioned last. I had a very simply API built on lambdas for a side project, that worked perfectly fine till last month. But now, every minor change I make to that code results in some error or the other that I can't figure out for the life of me. It has been so bad that I had to quit the project altogether.
Ditto, recently moved from AWS to render.com
It's like a cheaper Heroku, it's been stable so far.
I do use GitHub actions to run a small pipeline on projects but its a far cry from Jenkins.
I recently switched all of my personal projects from being self hosted on a linode with a complex nginx setup to just using Netlify... never going back.
> 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.
Sometimes I wonder if modern corporate culture has adopted soviet style newspeak.
Why are we immigrating to the new thing? For the same reasons as we migrated to the old thing. Why is the new thing better? Because it’s just so much better.
If you can convince the higher ups that migrating tooling provides business value, you can do something that requires zero insight or creativity for a few months and at the end of it be promoted for organizing a successful migration despite delivering zero measurable business value. The effects of the migration are gonna be second and higher order effects that are impossible to separate from the rest of the business so you can just claim the tooling was the leverage that let the people doing first order work succeed. Being a tool astronaut lets you claim a portion of everyone else in your orgs success without ever taking a professional risk, since your odds of being called out for an ineffectual change are near zero, since there’s no first order signals.
I’m not saying modern tooling is useless; I don’t use ed, cc, and make for my development. But there’s a huge difference between a zero to one tooling effort and an N to N+1 tooling effort. The first one requires figuring out all the implicit/implied/manual parts of the process. The second one is often just turning one set of configuration languages into another.
Holy cow. This! Exactly this! It happened in big corp., I am working at right now. As an engineer, I just watched it happen. When I tried to explain to other engineers, most didn't get it. Only a few got the trajectory we were put in by higher ups for credits they were aiming to get. But those few were onboard or powerless as me.
We just observed it happen. As the engineers, we did our job best we could regardless. Things broke, we fixed. Somethings rolled back, and even for those they claimed credit & celebrated for re-inventing the wheel.
People on HN are always deriding the “tech hedonic treadmill”, but I find it interesting that this meme seems to have reached maturity in 2015, and the list of things they point to as “the new trendy thing this year” has been the same ever since: Some combo of Node.js, React, webpack, Docker and Kubernetes.
I think this meme was still fairly true then: Node was at risk of splitting into Node.js and IO.js, React was still new-ish and people were (rightfully) panicking over the drastic changes coming in Angular v2, Docker was still new-ish and there were arguments over whether Docker Swarm or Kubernetes was the future. But nowadays Node has stabilized, React and webpack have been comfortably dominant for years, Docker’s model of containers won out a long time ago and Kubernetes is there if you need it, but is mostly useful for people building a PaaS.
If people don’t want to learn these things, then fine, but I do wish the overall mood here would update to reflect the fact that we are now living in a much more stable time than when these memes were created.
New hypothesis: People like to move on to the next thing once they have mastered the current thing, so in a weird co-evolution, those tools-of-the-year evolved to not be masterable and thus people haven't been able to move on yet.
Also, you shall shortly be smited for not having included Rust in that list. :)
> we are now living in a much more stable time than when these memes were created
Quite the opposite. The cambrian explosion of tools and SaaS is getting faster and the average useful lifetime of anything released today is getting shorter.
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?)
Dad of two - we basically don't, if I'm honest. I've had to give up on an immense number of things and while lots of people tell you "having kids is expensive" very few will tell you that the most expensive part is the opportunity cost. I have so many things I want to do and it hurts, almost physically, to watch other people doing them because they could hack on stuff after work while I had to deal with making sure a 3 year old wiped their butt OK or get yelled at because they actually wanted a _different_ spoon.
Now, it turns out my career was lacklustre, so no great loss, and I'm sure having older kids is different than mine (1 and 3) but right now I get make 40-60 minutes a day to do what I want. Not much time for a side gig. I'm writing this right now with my kid watching a cartoon next to me when I originally wanted to work on some UI stuff for a side project, because I'm exhausted. Speaking of the above, she's scratching her butt so maybe we need to discuss the importance of thorough wiping.
FWIW - in my experience, if their demands upset you, it’s not going to go well (you’ll get more demands and feel more exhausted); if you laugh at the ridiculousness of the situation, remind them to ask nicely, and still help them with what they need/want, you’ll be much less stressed, you’ll be teaching them that being unpleasant doesn’t bother you and doesn’t help but does have the natural consequences of slowing down what they want, and you’ll be teaching them a better way of being; at least with my own kids, they picked up on it pretty quickly, and they started being much more fun to hang out with.
True, and oddly given my comment, I adore them and love being their dad. But they destroyed my old life so I've had to build a new one around them. The pandemic hasn't helped.
The first few years of kids were infuriating and terrifying. I built my career by constantly exploring and learning after hours. Kids made that impossible, and that made me frustrated (because there’s SO MUCH I want to do besides diapers) and scared (because how can I maintain my career without learning).
It’s somewhat better now. I’m seeing them grow and can believe that this stage of life won’t last forever. I’ve managed to keep up with work by increasing efficiency during core hours, though I still look forward to getting back on the wagon with side projects when I can.
Here are a few beliefs that have helped me build & maintain a positive mind set:
- An engaged parent is priceless to a child. They desperately need you and you are irreplaceable. There is huge value in showing up for them, it’s just very different from your prior experience.
- COVID is terrible and we’re all struggling to get by. You must ruthlessly prioritize where you spend mental, physical, fiscal and chronological resources. Nobody expects you to maintain the same pace as before; we are all suffering through this together.
- Family and Profession both benefit from strengthening your mind, body and habits. Level up your time management game to improve exercise and diet. When the kids get easier, you’ll have more capacity for professional endeavors than before.
Having your own time to try out whatever you like is immensely helpful for a developer, thats why at the companies I work for I campaign (successfully for now) to have “learning days”. You do whatever coding / learning you want, but you are obligated to share your discoveries with your colleagues. Companies benefit with more motivated, engaged and loyal employees, and you get to progress as a dev.
Sometimes managed to convince people to do this once a week, sometimes once a month, or somewhere in between. For example now I’m doing it once a fortnight.
Everyone recognizes that learning is an integral part of the profession, so I think companies should really accommodate that, rather than expect people to carve out personal time for it.
As a father of two I can relate with some of the answers here, but I'd like to add an alternative viewpoint here just to give young dads some glimmer of hope.
For the first and a half or so we've had a difficult life with the first kid. To be honest, there is just no way around it. Especially your first kid. The SEAL-level sleep deprivation and complete lack of "me time" really takes it toll. I'm also not the type of dad to let mom handle everything. She also has a career and, to be honest, a better one too. So I was regularly up at 2AM, 4AM and 6AM. Then a workday. :) (If you have young parents around you, please try to be compassionate.)
But for some reason I'm more effective now than I ever was. I can remember "not having enough energy" to complete some project for as long as I am alive - even when I was alone. It is clear to me this had very little to do with my actual life and more with my attitude. My life is more complex and demanding than it used to be but somehow I still managed to lose 60lbs, learned to read Latin, took guitar lessons and started a business. Every single one of these items never would have left my todo list without my family. They have endowed me with a keen sense of priority which made planning my life quite easy to be honest.
I know those achievements I listed are not that hard, but for me they are significant. I've found most things in life don't require your eternal soul as a sacrifice, they just take (usually a lot of) time and so you need to be strategic about your goals. Take it slow, don't burn yourself out, but also don't stray from left to right unnecessarily. Keep your eyes on the ball. Don't shift from "write a compiler", "read latin", "write toy OS", "build cpu from nand-gates" to "learn german" and back to "learn to draw realistically" in a month. Focus. A dirty word, I know, but a powerful one.
Because as children age you're able to reclaim some of your life back. At least, if you don't fall into the trap of them living a packed schedule themselves.
I've got three, the eldest is now old enough to babysit the rest if needed. With a consistent bedtime and family nearby to care for them on occasion, my wife and I do get some spare time. We mostly choose to spend that together but we can pursue our own hobbies also.
As a parent of two kids who are both past that age, I feel like your perspective on this is all wrong. You’ve given 70+ years to someone else. And you haven’t lost those years at all, since presumably you also have a meaningful day job (and if not, that’s not your child’s fault).
It sounds like you and your partner should work on splitting the load more. You don’t need both parents to look after the kid constantly, you can often take turns. Kids can also watch TV and all kinds of stuff. They also have earlier bedtimes, giving you even more free time.
> since presumably you also have a meaningful day job (and if not, that’s not your child’s fault).
Turns out that you need 3x the money when you need to feed 3x the people, so no, my job is not as meaningful as it could be and while you can't say it is my child's fault, that certainly caused my family status.
I don't know how old you are and for how long you've been programming but your experience mimics my progression.
I started playing with some kind of programming when I was about 9-10, BASIC on a MSX and later HTML that opened up me for web development on ASP 3.0 and PHP at the time.
It was a very big hobby when I was young and turned into a career when I was pretty young, about 16. It stayed as a hobby for another 9-10 years but I got to the point where thinking about programming outside of my paid time was exhausting...
It helped me tremendously, I would never have a career if I wasn't extremely curious about programming for 15-20 years of my life, I just got to the same stage as you did.
There is an evergrowing and endless list of things I want to learn and experience, staying on top of the latest tech on my own free time is just too costly nowadays. I still do it, when I need it for work and during work hours, and all the accumulated experience helps me to figure out things way faster so I don't need to use my free time to catch up. Increasingly rarely I get that curiosity again, to use my free time to study something work-related. When I do it nowadays it's for much larger and abstract concepts such as organisation culture and change, team spirit and building trust and effective communication.
I noticed that the past 5 years of my career has been much more about the human and social aspect of work rather than technical ones. And I didn't try to become a manager, tech lead or product owner, it has just attracted me as I think I always got attracted to gaps of efficiency at work. It seems that seeing this human aspect of work brought me closer to more human aspects of life (arts, music, sociology) and a bit away from controlling the machine I learned when I was a kid.
This resonates with me too. Instead of spending 2 weeks shaving off 100ms in a request I’ll spend two weeks shaving off 3-4 days worth of time for a request from the marketing or sales team by figuring out a better process for them to request changes on the management side.
An aside for future or present dad's (and all Parents.) There is so much joy and learning that happens with raising kids, that I think the secret is not fight it, but enjoy it. Almost sounds cliché, but embrace the experience. From the very beginning to when they are adults, to experience a window into your own life, a window into the world. These windows allow you to explore your surroundings and relationships with a different eye, with more understanding.
The best way to get into that zone, is to forget your own desires for a bit, forget your schedule. Just live in the moment of the kid (s). After you relax a bit, and surrender to their schedule, then all of a sudden you find opportunities for your time in between. But with passion and effectiveness. As mentioned below in a comment, you can be more focused, I believe because you are more relaxed. If you fight all the time to make 'your' schedule fit, you become frustrated. As you let go, you find a schedule that works, and with enthusiasm for that time to create and build. Cherish the moment with the kids, everything from diaper changing to eating, because they are a reflective window on your own soul, and a fresh mirror to the insanity if the world around you.
How do you let go of the things you want to do? I like to think that my side project is something only I could do, that the world needs but doesnt know it yet... so the thought of giving it up sends chills through me.
You seem to have a really nice outlook on things so I'd really appreciate any hints on how to reconcile this and get to where you are! (I dont have any kids yet)
For the vast, vast, majority of us, nothing that we do individually is important. Sure we work and provide some value to somebody somewhere, but if we didn't exist or didn't do that job, the world wouldn't be any worse off.
If you think otherwise, it's probably your ego lying to you.
And even still for those “others” - nothing individually they do is that important, it’s how the team they’ve assembled operates when the leader isn’t around... and as much as a belief system can anchor people into habits and behaviors, it’s still the deputies or vps of a cause that must maintain consistency in purpose...
That’s a long winded way of saying, no ones individual contributions are that important... it’s only through the concert of others that any person reaches those heights.
You can still do side projects when you’ve got kids. You just have to treat your priorities seriously, which usually means having to give up most of the netflix/social-media time. You also have to realize that in a two parent household, you don’t usually need both parents looking after the kids, and it’s better for both of you if you take turns (for your sanity AND for your free time).
It can, but it really depends on the personalities of you and your partner. It works best if your partner also has some independent work they need to get done (or enjoy doing, ex a hobby).
In talking with fellow parents of young children the biggest variable seems to be whether there is a stay-at-home parent, live-in relative, or nanny who can help with the recurring labor required to run a household like cleaning, cooking, shopping, bills, repairs, yard work, taxes, etc. Otherwise that work piles up until after the kids go to sleep and on weekends.
You can sacrifice sleep, but that's not sustainable for everyone.
My partner and I block out a couple hours each week for the other to wrangle the kids so we can work on our various hobbies/projects. I've found that when I work on my computer-based hobbies I usually end up frittering away half the time reading online news whereas outdoor construction, yard, and bike projects don't seem to suffer from that so they end up making more progress.
Hopefully in ~5 yrs I can actually do some of these things with the kids and it'll get a little easier.
I do have small children, and, for like many others, I get to do my things when everyone are asleep. You seem to have interest (which means you have energy), but the problem seems to be finishing. I have the same issue.
I am maintaining a list of them in a notebook, and am trying to limit the number of them to not more than 8-10 at the same time. And I can only start a new one if I finish an old one.
Everything in that list is a task with a clear Definition Of Done, so I know when I can cross them out. Realistically, each of them would take from 4 hours to a week (assuming full-time). Over the years, many things got done. Slower than I'd like, surely, but I think a SaaS business will come out of those TODOs in a few years.
This way, things are moving forward (since I must complete something), but I am allowing myself freedom to switch effortlessly. That motivates to do *something* when the hour comes. :)
I don’t mean to stick my nose in, but seeing as we are on HN: I keep hearing the market is pretty good for capital lately, have you explored raising a round to accelerate dropping the 9-5?
Speaking as a person with kids, I get into many things but with exceptions of very simple/small stuff, mostly nothing gets done and there are lots of stuff in various stages of incompleteness. It also depends on your level of procrastinating. Doing all these things also has an effect on sleep because I only get time once everyone has gone to bed.
I found that the kids running to you and jumping up and down and demanding your attention is an extremely quick way to reset. After an hour or so you completely forgot about work.
When things are kinda slow and aimless at work, that's when I really start to do some projects at home again. But to be honest, it all comes and goes.
But yeah, right now I'm both single and in lockdown, and if it was any other way I wouldn't spend a week just programming some sort of custom build/deployment agent.
With kids? One of my colleagues once told me that once you have them, you'll suddenly be out of time you didn't even know you had in the first place.
Ever since I started a "real" job in programming a few years ago, I've had such a hard time doing anything programming-related on the side. Which is such a shame since I have so many ideas. That's why I've been thinking of switching to a different field of work, even if it pays less. Ideally something where I don't really use computers at all. Not sure what that could be though.
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).
It also really depends on what you find cool, there are different ways to look at things. For example if I think of pipelines as these execution graphs that run on their own and make sure your artifacts end up in the right place, then its really fun. CI systems that visualize this make it even more interesting.
A little combination of the right personal interests and perspective goes a long way towards building up resilience to deal with the ugly bits.
I had this interesting experience back in university. We were doing some simple web service project in pairs, and it consisted of a program and some devops stuff. My partner in that project turned out to have skills that exactly complemented my own - he had trouble with the algorithmic stuff that I thought was trivial, yet he easily stitched all the services together by editing some configuration files before I even understood what any of them were for.
I would caution against trusting your build process definition to hold up to time. It's definitely better than nothing.
Even within the last few years of my job, we've had numerous disruptions to our automated builds due to everything from repo changes to version bumps in our fundamental deploy tools. I've got a self-assigned action to take just tomorrow due to how a change in how secrets management has now disrupted our performance testing process available to devs. Anecdotally, it seems more and more that as newer build tools move forward, they rarely seem to prioritize compatibility with existing methods (I'm looking at you, k8s, and your API versioning; "where feasible" turned out to be a loose definition).
It may not run to completion in the future, that’s true. However, if it’s something as simple as a shell script or a shell command list, it’s at least relatively transparent.
Unlike, say, tasks on Azure DevOps. Not a fan of those.
> There’s a nice side-effect, too: The CI definition documents how to compile the project.
Okay, sure, but that's not an argument for CI. That's an argument for a Makefile.
In fact, I find myself going back to Makefiles all the time not in spite of all these specialized build tools, but because of them. Even if the steps are straight-forward for someone who's familiar with the tools, just having a Makefile there in the repository root will be helpful documentation to help someone new (or myself in 2 years) get started with how to build the stuff. For example, for LaTeX, it could be something like:
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.
I tried that, and at first it almost worked. But that scaffolding just kept breaking. TeamCity doesn't want to execute my unit tests since I've upgraded to .Net 5.0, I still don't get how that docker "latest" tag works, my Ubuntu-TeamCity-Agent refuses to acknowledge it's running in Linux and that it has access to docker. After a while I realized I was wasting precious free time.
But I agree about the cognitive load. I have ADHD so in order to qualify as "high functioning" I need to continuously improve my coping strategies when it comes to keeping that load low. I write everything down. My thought process is anchored in long text files with hundreds of indented lists. My programming style is super verbose and perhaps a bit enterprisey, but each class does one thing and I always spend extra effort making sure the things I can re-use work well enough that it's safe to forget how they work.
Oddly enough, my reserves are much bigger when it comes to programming. I remember having trouble with some linear algebra homework - it involved a lot of matrix calculations, and my results just didn't make sense, and I couldn't focus long enough. So I programmed it instead, and it worked immediately and solved my homework. I think it was about change of basis, which actually got me side-tracked because I realized the same code could be used for a simple 3D renderer. And that's what got me into computer graphics. What was the topic again?
I also programming my linear algebra homework assignments, and then nearly failed the class. Didn't really learn it until I had to use it for more interesting combinatorics.
> 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.
Every third party tool (or library dependency, by the way) is something that will have to be well understood, maintained and fixed when broken. Which is why I try to avoid them for the most part in my personal and work projects.
When someone at work says "Hey, lets just use Xyz package I found online! It does just what we want!" you need to ask: Who fixes it when it causes a problem that stops us from shipping? Who does the security audit? What data does it collect, and to where does it send that data? What will adding it do to our software's performance? Who decides when to update it to the next version and verifies compatibility? Is its license compatible with our workflow/software?
All of a sudden, people are less excited about that great doodad they found on StackOverflow! I'm always troubled by the cavalier attitude about relying on external tools and library dependencies. Yolo just pull it in! In some cases it might be the right decision, but not always. And, avoiding third party stuff is not always just blind NIH mentality: There are costs to depending on someone else for your project.
I strongly agree that bringing in new dependencies is not a small consideration. But at the same time, third-party dependencies will always be necessary and by carefully choosing those that are best suited for the job, you might be able to get a net reduction in complexity.
Old, established third-party dependencies are not necessarily better for the job than new, trendy dependencies. Their entrenched nature can be an advantage and also a limitation. And when you roll it yourself, then that is of course the newest and least established solution of all.
If you rolled your own, you invest your time to learn about the problem domain. If you use third party libs, you invest your time to learn about its interface/behavior. That is usually much more ephemeral knowledge. It is good tradeoff if the library does some heavy lifting, but that is not always true.
> 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").
Everyone who develops a tool did it because they thought their tool would be great, and do exactly what they needed better than everything else that existed previously.
Everyone has slightly different needs, so that is exactly what creates the complexity disaster you are talking about. I think that being more willing to re-use the existing work of past developers actually works to reduce this problem.
That's true, and personally I'd much rather fight with my own code since I usually 100% understand what it does.
In a team of course it would be different - unless I perfectly document my own code, my colleagues would be better off with something they can actually google.
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?
> Even purely in code, you always 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.
In my experience, this isn't remotely true, especially if you're constrained to use a particular language and don't want to pay the overhead of wrapping another language
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.
You can't really make a learning system that doesn't play.
Physical play is how we train, develop and calibrate our bodies; mental play does the same for our minds.
If we one day build AGI that doesn't skip and dance and draw and make up silly stories for the fun of it, that will surprise me a lot more than the other way around.
It wouldn't need to skip and dance, though. Mental play is just randomly trying to piece together different information and see the results (physical play is simpler, a subset of mental play, basically continuous calibration).
It's like having 12 puzzle sets and just taking pieces from each, trying to fit them with others and seeing the results. Sometimes something interesting shows up.
Our brains do it constantly, all the time, 24/7. Most often the results are garbage and discarded, but sometimes something interesting/useful comes out, so it's tagged as such and stored for further processing.
The data used for such play is everything we have stored in memory, recalled either randomly or, more often, based on current circumstances/needs/wants.
An AGI would only play with what it has. And what it has available would be up to the creators.
If it's built to imitate a human, it will have to be loaded with the same data as a human. And I mean all of it, everything from birth to current age or death (that varies a lot by individual, by the way).
Basically, you'd have to recreate a whole human life's experience for this hypothetical AGI. Otherwise it won't be even close to a human.
But such an advanced AI would most likely be built for specific purposes, which would save a lot of resources. It can play all it wants with that limited data, improve it and create new stuff. But it won't be able to do things like applying information from bird flight to car building, because it will simply not have that data.
> If we one day build AGI that doesn't skip and dance and draw and make up silly stories for the fun of it, that will surprise me a lot more than the other way around.
I agree, it would be sad if AI wasn't able to play with human culture. Culture is crystallized intelligence.
I've been thinking about this recently and realized that my brain is capable of drawing an incorrect conclusion about the "mattering-ness" of something based on limited data, typically a feeling arising from personal values.
The thing is, everything we do does matter, and it's one of the reasons why the Bible instructs us to "walk by faith, not by sight". On the cosmic scale of things, we don't have all the information to truly calculate whether something does (or does not) matter. In that regard, choosing to live as if what we do always matters seems like the preferred and life-giving approach.
I wonder how much is made by very simple emotions:
- playing
- competition
- noble obligations (helping someone else)
I keep looking at adult life in dismay because what people consider work would barely amount to 20 minutes of soccer when we were kids. We used to run wild for hours, hurt ourselves, attempt everything that could work and we kept asking for more. Can we plug that back into daily adult jobs ?
I really wish there was a PE class for adult, where you stretch, run around the track, then play some random sport for about an hour. One day it's cops and robbers, another it's grass hockey, and nobody knows in advance.
You could argue that having fun is the end goal of things. Why do we do things that we consider important? Why is it important? Somewhere down the line everything we do should enable someone having fun. If not, then why bother?
True. I think most people can benefit from a bit of this at least. Ie. Speaking of software engineering, at work our 10% time is for us to do as we please. A lot of good things come from that. Maybe 50% time would be too much for most though. Google's 20% is probably the maximum I'd opt for if I were a CEO.
For me setting 10% aside as "do as you please" feels like a restriction on creativity as well. It's hard to "plan" creativity. I think culture and trust is much more important than setting a number.
I agree about culture and trust, both crucial in this regard. I think something like 10% time can play a part too, it at least gives people the feeling they can do what they want for a fixed period of time.
These percentages are purely aspirational. Managing software developers' time down to the single digit percentages is impossible. In reality if you're doing something in your 20% (or whatever) that turns out to be valuable, and in particular you make your management see that it's valuable, your 20% will become 80%, and if not, then your 20% will be whatever you manage to make it.
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
That just can't happen, though. Part of tenure is having experience and being able to draw from that. It isn't just job experience, either: Life experience counts and can give your different ways to think outside of the box.
The best example I can give is art related: Documentaries and other non-art learning puts a variety of concepts and ideas in your brain, making it easier to think of creative concepts for artwork.
The process takes time, though, more time than can be reasonably stuffed into getting a degree.
The uni system couldn't afford to give tenured professors freedom to follow their fancy without the "underclass" working hard to make it possible in the first place — graduate students and untenured staff do the high-volume work needed to make profits: churning out tens of thousands of undergrads per year, paid for by fed-backed loans, and definitely not all of them taught by Feynman-type professors.
I don't know if that's true, that's just my model of how American university works.
Sure. I just wonder if there is some sort of middle ground? Does it have to be zero sum here between tenured and non-tenured in this regard? I'm not sure what the answer is but other setups are possible unless you consider this one optimal (perhaps some do!).
> 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.
Wait, is this caused merely by the water being accelerated by gravity?
I bet most people would be able to figure out the equations for that if they got interested.
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.
Reminds me of Suchman's "Plans and Situated Actions" --- an anthropological study of plans and planning, which also has a lot of implications for AI. Resonances to that famous Eisenhower quote "Plans are nothing, planning is everything"
Thank you! This was a very interesting watch. I've also started reading the book.
For some reason, this reminds me of the debate between Peter Thiel and David Graeber on the topic "Where did the future go?" where Graeber points out the lost potential of people as one major reason.
In all probability, Youtube's algorithm will already suggest this to anyone who watches the talk, but there is a (very) long, ML Street Talk interview on this idea here https://youtu.be/lhYGXYeMq_E
Stanley addresses some strong and subtle criticisms here but I actually preferred the book the most. The book is a bit repetitive but has some very good ideas in the appendix.
Just finished the talk. Plan on reading the book. This is one of the most interesting concepts I've come across in recent memory. Really appreciate you sharing.
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 people expect them to be normal. But we hold these people up as our heroes. People aspire to be more like their heroes. So it comes as a shock when they learn their hero was a notorious philanderer, or terrible father, or chronically depressed, or self-aggrandizing.
Personally, I’m unsettled by how often the kids of our heroes seem to wind up unsuccessful, unhappy and poorly adjusted.
I’ve kind of lost interest in the unstable genius. I want to learn about the also-rans who made quiet but notable contributions while remaining happy & raising equally happy kids.
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.
I do enjoy reading history, and I'm not even turned off by knowing that he did and enjoyed those things. I just got tired of listening about it for what seemed like about half of the book when I was expecting a memoir of a Nobel prize winning scientist.
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?
Please see my other comment; I don't think there's anything wrong with them necessarily, I just didn't particularly enjoy reading about them and his behavior just seemed sleezy a lot of the time.
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.
Although I didn't approve of some of the things he did, his book (Surely You're Joking, Mr. Feynman!) made me want to branch out more, to approach the world with renewed curiosity. His book is a good reminder that there is more to life than your resume.
I often find myself taking random detours like he did with the ants or the bongos.
His ant experiments blew my mind. The only experiment I did with ants was rubbing my finger on their trail and then watching them wander around blindly for a minute or so.
That's a better way of phrasing what I intended in my last sentence, go into it with an open mind. I was expecting differently, so I didn't enjoy it as much as I would have had I known ahead of time that it would be largely tangential to his scientific life.
IIRC Feynman both had a reputation for putting a lot of effort into crafting a persona, and later said he had been less than honest in the sexist stories. So perhaps they reflect a somewhat different mix of sins.
I don't know, I don't disapprove of any of those things morally or anything, but it just got old eventually. As an example, somewhere in the later parts of the book he talks about a period where he starts painting, and very shortly afterward he starts trying to convince women to let him paint them nude, including a student at the institution where he was a professor.
Again, I don't think there's anything wrong with nudity, or anything inherently sexual about nudity in art, or even anything morally wrong with the desire to see naked women. But by that point after some of his other stories I started to see him as a somewhat creepy dude and it just came off to me like, oh of course, shortly after taking up this interesting art form you'd go straight to using it as a reason to see naked women, typical Feynman.
I don't think there's necessarily anything wrong with anything he did in any of his stories, all of the parties were consenting in them all, it just left an unpleasant taste in my mouth.
Thanks for expanding. I had forgotten about the painting anecdote.
As others have pointed out, a lot men in that era seemed similar in a way. I'd been assuming that going through all the changes that happened in the 60s as a middle aged man must have had a certain effect on them. Seeing expressions of sexuality go from being something very private, something to be ashamed of, to being something that the younger generation is much more open about.
For example, I remember reading Asimov when I was a kid. His earlier books were all very buttoned up, with highly intellectual and in depth discussions of galactic politics or robots. Then his later books are full of sex. I gather that Asimov in his later years gained a reputation for being somewhat creepy too.
Dude was smart, but definitely a sexist. He didn't believe that women would be as capable of doing physics and engaged in some really awful behaviors that were weird even at the time (having meetings at a strip club? asking to paint students in the nude? really?).
The lockpicking stuff in "Surely..." is a really fun chapter but also makes it clear that Feynman does not actually care that much about inconveniencing others. It was a fun intellectual exercise but actually harmed other people, which is pretty shitty behavior.
It is just a little hard to read a book when assholish behavior just shows up with such frequency. Feynman was a genius, a great storyteller, and a lot of the content in his books is fabulous. But some of the material sours it.
> He didn't believe that women would be as capable of doing physics
Interesting, from having read about his sister[1] I really got the impression that this limiting belief was something he bucked heavily, despite having been explicitly taught women were incapable of science by their mother and grandmother:
> Joan was an inquisitive child, and she exhibited an interest in understanding the natural world from an early age. However, her mother and grandmother both dissuaded her from pursuing science, since they believed that women's brains were not physically capable of understanding complex scientific concepts in the way that men's brains could. Despite this, her brother Richard always encouraged her to be curious about the universe. It was he who originally introduced young Joan to auroras when, one night, he coaxed her out of bed to witness the northern lights flickering above an empty golf course near their home
Most people who hold bigoted beliefs permit exceptions. Feynman is on written record saying things like being surprised that a particular person was able to do physics, given that they were a woman. It would not surprise me even a little that there were some women that Feynman believed to be intellectual exceptions while also holding nasty beliefs about women in general.
Even if all of this is excused as a product of the man's time (I don't believe that all of it can be), it still adds a disappointing aura to the otherwise fascinating stories he tells.
I love listen to audio books, but you're absolutely right, the narrator is sometimes more important than the narrative.
Some gifted narrators probably could read out operating instructions of kichen machines and it would be entertaining.
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.
Wise words. I'm sure most of us would never have learned all the of the basics of mathematics on our own. Though I do remember Feynman claiming in the book that he'd come up with certain trigonometric concepts on his own and then had to un-learn the names that he'd created for them and learn to call them sin, cos etc. That was pretty mind-blowing.
I suppose the question for me is: how do you find the right balance between formal learning and the self-directed learning, experimentation and practice?
In different terms, we’ve all heard If I have seen far, it is only because I stood on the shoulders of giants.
Those who came before give you a leg up so you can work on the next problem. There aren’t enough years in a life to develop particle physics by yourself, completely from scratch.
> 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…)
I imagined it has to do with how the water coming out of a faucet is affected by gravity, and gains velocity. If you imagine two cross section slices, one near the faucet, and the other near the sink, the bottom slice is going faster than the top due to gravity. Another insight is that the amount of water (flow rate) passing through these slices remain constant. To keep the flow rate the same, it has to be narrower. If you let the water fall far enough, it would hit terminal velocity and it would not narrower any further.
I looked it up and found it was called the continuity equation.
> If you let the water fall far enough, it would hit terminal velocity
Does it ever hit terminal velocity? There is no air in front of it, just more fast falling water.
It's well known that water gains velocity until it vaporizes. I assume it vaporizes because some small flow turbulence gets strong enough to atomize it once it reaches enough speed.
The water will break apart into raindrops which fall at terminal velocity. Depending on relative humidity, they evaporate as they go, making them cool and get smaller, which lowers the weight/surface area ratio, and they get slightly slower.
Surely it depends on the diameter of the water column. For diameters much less than a rain drop, surface tension will dominate, and perhaps no column is produced (unless initially at high velocity, like water cutting?). For larger diameters air pressure will keep the column in shape at initiation. For very large diameters I am fairly sure the column would very easily exceed the terminal velocity of a rain drop. That would be a fun experiment to do from the top of a tall building!
Most of our intuition is with columns that have turbulent flow and standing waves (e.g. taps), which affect how quickly the column disperses.
I like this way of looking at the problem, I wouldn't have thought of this! I think this relies implicitly, too, on incompressibility of the fluid, no? As well as surface tension? Otherwise, we might imagine the fluid having less density at the bottom, while occupying a circular cross-section of the same area.
It does rely on incompressibility, but, to this order, does not include surface tension.
The water faucet puzzle that interested me as a student was after the water had reached the sink and begun to spread out radially from the stream. Have you noticed that there is a circular boundary where the layer of water suddenly changes depth?
The water is accelerating downward due to gravity...but the amount/s flowing out of the faucet is equal to the amount/s any distance below it...so the stream has to get thinner as it gets "faster".
Surface tension plays a role. Water wants to reduce its surface area because forces between molecules at the surface pull them together. So a droplet of water will want to form a sphere.
A column of water will first form into a cylinder and then break up into spherical droplets. It’s called the Plateau–Rayleigh instability.
The only role surface tension plays in the Feynman problem is to ensure that the cross section of the stream is a circle. The rest you can work out based on classical mechanics and the fact that the amount of water is conserved.
You actually get exactly the same "thinning" behavior if somehow the stream is square shaped or anything else in cross-section.
Air pressure probably dominates over surface tension.
Imagine a water column large enough that surface tension is very weak, say a tap with an outlet 1 metre in diameter.
At the exit of the tap the pressure of the water is at air pressure ( = 1 bar: any less and the water would be pushed back into the tap).
As the column speeds up, the pressure inside the column "wants" to decrease, however the air pressure outside forces the column to be narrower to maintain 1 bar of pressure.
Also the forces within the column depend on the hydrogen bonds between the water molecules, which will "pull" the column together. Effects at the actual surface will have little overall influence (the term surface tension seems misleading to me).
Disclaimer: I have only done undergrad physics, and although I do try to think things through, I am regularly surprised at how wrong I am about basic physics!
> Also the forces within the column depend on the hydrogen bonds between the water molecules, which will "pull" the column together. Effects at the actual surface will have little overall influence (the term surface tension seems misleading to me).
Water is a polar molecule with positive and negative charges corresponding to the hydrogen and oxygen atoms. This makes it a very ‘sticky’ molecule and so water coalesces into droplets and reaches an equilibrium internally. It’s the forces between molecules at the surface that are not at equilibrium, they experience a net attraction which causes the pressure in the droplet to increase — the Laplace pressure. The smaller the droplet the higher the Laplace pressure, lots of interesting stuff to read about there for you.
Now, consider the water tap, a very small flow rate of water will form a droplet which increases in size held in place by adhesion to the metal of the tap. Surface tension and the wet ability of the metal determines the shape of the droplet until it’s weight due to gravity overcomes the surface tension forces and it falls. The ambient pressure has no effect, the pressure of the water supply and the air are pretty much balanced, the pressure in the droplet is slightly higher due to the surface tension.
Increase the flow rate a bit and you will get a thin laminar column of water. Here the thinning effect due to acceleration is observed. However, the column quickly breaks up as per the Plateau-Rayleigh instability; the water is pulled into a chain of droplets. The air pressure is invariant so you can continue to ignore it. You can even work in a vacuum.
Increase the flow rate and the diameter increases due to the greater supply pressure needed to drive the flow. The supply can have zero velocity but higher pressure. Now you get a longer stream of laminar flow before the breakup occurs.
Increase the flow rate further and you start to see turbulent flow.
"For the water droplets of 1 micron and 4 mm, the capillary pressures are of the order of 10e5 Pa and 10² Pa, respectively (σ=0.072 N/m for water)."[∆]
Atmospheric pressure is approximately 10e5 Pa at ground level. Capillary pressure is another name for Laplace pressure from a quick Google.
So as your water column increases diameter, air pressure matters more and.
For my example of 1m diameter, I would expect Laplace pressure and surface tension to be negligible. And the rayleigh instability will still occur at a small column diameter, when the fluid is going very fast.
I guess there are two thought experiments:
1. what happens when you use a liquid with an extremely low surface tension in air? (Or maybe even a column of heavy gas like uranium hexafluoride thick enough that diffusion doesn't dominate?).
2. How could you model a system to avoid the dynamic effects of air circulation (donut flow as occurs with a helicopter) and the dynamic effects of having water laden air where the column starts to break up. Does a thick downwards jet of water at speed (over the terminal velocity of rain) still show narrowing? Or do other surface interface effects cause problems? What happens to a thick downwards jet that is over the speed of sound?
Edit: The water exiting the tap is at approximately 1bar, I need to be clearer about pressure differentials rather than absolute pressure...
Edit: what I was trying to point out was that "surface tension" is misleading, and that air friction and gravity are not the only other major forces acting on a stream of water from a tap.
Edit: Also thinking of a dam with holes down the side more than 10m. I am guessing air pressure matters the most when the water is at low velocity exiting a wide nozzle, when the water is accelerating the most due to gravity relative to its velocity.
The Laplace pressure is in addition to the static pressure. Working in gauge pressure you can ignore the air pressure and the pressure within the droplet.
Don’t confuse gauge and absolute pressure.
A 1m column of water is going to be a turbulent waterfall.
Remove surface tension and the liquid will form more complex shapes as it is less constrained to form a sphere. Instead of forming a droplet the stream will simply fall and break up as other influences dominate.
I love HN. Start with feynman fooling around, and end with wikipedia explaining how close a man has to stand from a wall to minimize splashback while urinating.
It’s not. It’s just conservation of volume. Imagine a thing disk of water just as it comes out of the faucet (pi r^2 v*dt) as it falls, the speed increases so the same volume of what is now thinner and longer (r decreases to account for the increase in v).
I think it's a power of -1/4: velocity of a falling object is proportional to square root of height, and the stream diameter is inverse proportional to square root of velocity.
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.
Very true. I guess in my original comment I meant to imply this in talking about blue sky thinking and following through on it. For me this is work which is original, out of leftfield, probably intrinsically motivated and which you have the time to follow through on deeply for a sustained period of time.
I definitely agree on this being a factor in his, and likely several other, Nobel wins
Actually Feynman did an opposite of Deep Work for that case, he literally worked in strip-club on purpose.
By today standard it's like working with reddit open, gamepad on your lap and pornhub on second laptop.
If I had to make a fancy explanation I'd say "turn your work to a lifestyle so you naturally do it while entertaining".
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.
Most of the stuff I have learned well were a combination of them fitting into the need for automation and sufficient time/lack of pressure/deadlines. I personally find deadlines suffocating but sadly that is how most things are.
There is power in the startup/business world also in doing things that aren’t immediately sensible or predictable. Read Rory Sutherland’s ”Alchemy” for learning more.
> Physics disgusts me a little bit now, but I used to enjoy doing physics. Why did I enjoy it? I used to play with it.
When I was at uni other grad students often referred to us studying physics as “Spielkinder”, play children. No one could say to what end they really wanted to study physics for. Mostly it was just fun understanding how things worked. It was a lot of fun.
The downside of this was that when I was finished I really didn’t know a lot about the real world.
I think this roughly boils down to information theory and the exploration / exploitation tradeoff. Play is fun because it’s information-rich. It’s personally rewarding because exploration opens new doors.
Exploitation is boring because it mostly discovers nothing new. It’s information-poor, and its reward is mostly fixed, and doesn’t open any new doors.
This is a good example of how you can escape from procrastination too.
And I think also a reason why so many side projects go unfinished.
It’s also an interesting phenomenon i realized whereby when you are working full time you long for time to work full time on a clever idea you have. But when you have time to work on this idea full time you don’t want to do it. But then the feeling returns when you again don’t have time to work on it.
I realized that working on something for fun can help you segue back into what you should be working on.
But it seems it only works as long as you don’t have grand plans for it becoming a business or a great industry-changing discovery. You must maintain that it’s only for fun. To see what can be done.
>> It’s also an interesting phenomenon i realized whereby when you are working full time you long for time to work full time on a clever idea you have. But when you have time to work on this idea full time you don’t want to do it. But then the feeling returns when you again don’t have time to work on it.
--I totally get this feel(of procrastination on things) in all of my endeavors.
I will try to work only for fun to get on with it. Is there any element that might sustain fun for the very end or any other secret sauce to it?
This reminds me of my first year out of college in 198x at my first job when I really really enjoyed learning and playing and growing. Fast forward 20 years into my career I was burned out and forced higher and higher up, to the point where every misunderstanding or new idea was a chance for me to stumble and be overcome by interdepartmental competition. Constant joy turned into constant fear in just two decades.
I love those moments when you're warming up, getting into the work, you may hit that first snag or obstacle, but you reflexively enter play mode.
Now you're practicing creatively, now you're finding out new features of your tools and packages and data. You're hacking in a new script, you're trying new ideas. You find the answer,bring it back in, integrate it. You click run, and it just works!! Yess!!
Not all passions, pursuits and energy return Nobel Prizes. Something to be mindful of when reading too far into this. Still, I learn things that are interesting to me and sometimes I get lucky and people want to pay me and other times a new technology comes out and I wasted a few good years. Since I’m making my decisions on what to learn, it doesn’t seem like wasted time, but rather a shit ton of fun.
To an extent, this is my attitude towards programming. At the very base, my motivation is genuine interest in the project and tinkering with it.
Even when I build useful apps, straying has done more good than harm. By doing this for no reason at than fun curiosity, I've broken builds... But more importantly learned how to fix and document those scenarios.
I love reading this when I was in university. I remember thinking to myself, may I be burned out enough one day that I can play with Mathematics and not have to worry about how to pay rent or support my family.
I found an article which points out some negative things Feynman's did that i was not aware of. It is an interesting take by a woman who was essentially driven away from her natural direction in science by bad behavior of men in academia, and i sympathize with it. I really liked the original article posted here, though, and respect the way Feynman looked at the world.
I've been thinking about this a lot since I first heard this story about Feynman. I've been in this industry now for 25 years and there have been three times when I wanted to quit. During the first two, in the back of my mind I still knew I wasn't going to and shouldn't. I'm working in an industry doing what I wanted to do since I was ten years old.
The third came this time last year. I had lost a parent (not to due to COVID), my business had failed (also not due to COVID), and then COVID hit so my prospects seemed low for employment. I found a contract with someone who turned out to be easily one of the most unethical people I had ever worked with.
Little of this had to do with technology but, compounded, I found myself in such a deep state of burnout that the thought of picking up my computer made me sick. I genuinely didn't want to work in technology anymore once that contract had ended. I was trying to decide whether I wanted to go back to school for something else or try to get on at Costco. The problem with going back to school is, I couldn't really pinpoint anything I wanted to study so I had all but made my mind up that when things opened back up I was going to put my application in at Costco. Hard work for lower pay but I have more respect for Costco than I do for a lot of companies in my industry. At least Costco solves a real problem and is beloved by their customers. They're not pretending to be innocent to fomenting sedition while making a buck off of abusing peoples privacy.
Fast-forward to around December and I had found employment back in tech. This company provides a quality service that directly benefits real people. I had quite earnestly tried to avoid it, though. It will go down as the oddest interview I've ever had because I was basically trying to talk them out of hiring me but to their great credit, they did anyway. Due to the nature of the job, I have a lot of leeway in deciding how to solve problems since I'm responsible for all of the code. I needed a simple log server for the various scripts that were running. I looked at all the Open Source options and found they offered way more than I needed so I decided to write my own. Almost all of the code I work with is PHP so I started writing it in that.
One Friday night after work I thought, "Hm, I wonder how hard it would be to port this to Clojure?" I had a little experience with Clojure from a contract I worked on a year prior while trying to bring some much needed cash into my business at the time. I could see the power and beauty in it but, still, coming from languages that descended from C, the syntax was foreign enough that it was tough going at first. I suspect that contract ended because they didn't think I was picking it up fast enough for their needs. I don't blame them.
Anyway, I found that I had actually picked up enough Clojure during that contract that my fingers started flying across the keyboard porting my log server. It was... so - much - fun! I was playing with programming again! I was exploring and learning and, importantly, being productive and solving a real problem.
Now, let's not kid ourselves, this log server isn't some sexy blockchain-containerized-whatever. It isn't a product that is ever going to be sold for millions of dollars. It isn't going to change the world or disrupt any industries. It is very simple and pretty much only helps me and one other person at the company. You know what? That's really great to me.
I've learned a lot over the years about burnout but they were really reinforced in a big way last year. It's important to step away from the computer and you need to do so frequently. We get weekends and vacations for a reason. Use them! Get outside when you can. Get some exercise in whatever ways you enjoy most. Eat good, healthy food with people you enjoy being around. (social distancing notwithstanding) Have a hobby that is not related to your job. I love technology and playing with it can be fun like a hobby but the fact is that it's not because my livelihood depends on it.
So far, 4-5 months later, that log server written in Clojure is still cranking away dutifully. I get a little smile each day when I check the latest logs to see if anything needs my attention.
You get a couple of lines in, and it’s painfully familiar, since it’s sadly so incredibly similar to my waning love of programming...
It’s wildly destructive for society to have these completely devoid of ethics, fascist-style assholes with capital/power, that can dictate what what more useful people than can spend their time thinking about, yet no-one even thinks it’s a problem.
Although to be fair it’s just a sub-problem of how humanity has forced itself into self-destructive patterns, by ignoring reality and following fanatical ideologies about “unrestricted capitalism” and “the free market” as if that is some sort of divine power...
Imagine spending your short life developing ads for Google or Facebook. It would have been objective better for all of humanity if all these naive assholes people had become alcoholic bums living on the street... that would at least have curbed their ability to fuck with the rest of humanity.
Primarily to redistribute capital from clueless geriatrics that can’t separate Ivanhoe from an iPhone...
The bigger problem is of course how we as a society legitimizes destroying young people’s future, just to fund exorbitant pensions for clueless old people who still think 1968 was a “leftist” moment, instead of actually being the starting point of the fanatically far-right fantasy world we live in today. (The next step is of course to dismantle this fantasy world)
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!