koz_

> Power naps started working for me nicely once I removed the stressful requirement of actually having to sleep.

This is a lesson I keep having to relearn, that rest without sleep is still beneficial. And of course there's always a reward for 'failing' to fall asleep - then I get to do something interesting!

Lately I've had some success in making a game of cultivating enjoyable, productive thoughts while I lie there unable to fall asleep, rather than indulging in the usual anxious worry / regret cycle.

Love this. How much suffering have I inflicted on myself from the sheer refusal to accept that forces other than my own will play a part in determining my destiny?

> 'In the beginner's mind, there are many possibilities, in the expert's mind there are few'

This is a great quote. Once one knows how to do something the "right" way it becomes very difficult to do it any other way. That said, perhaps true expertise isn't about knowing the correct solution to a given problem, and is rather about realising that problems themselves can be changed in order to permit different, more desirable solutions.

I think one of the most common ways in which programmers fail is by immediately accepting a problem as a given and jumping into the solution space. So often we will come up with a perfect solution to a stated problem, when a slightly different problem has a 10x cheaper / safer / faster solution.

I remember getting a new lease on life with Factorio when I gave myself permission to start again as much as I wanted. Before that I would overcommit to every base, thinking that the "real game" only began after you get past the bootstrap phase, but in fact there is a lot of joy in just putting marks on the page.

Also, having things be small enough to fit in your head, as things tend to be at the beginning, is a boon for learning. I thought the early game was pointless, but in fact working with small factories made me realise that there were foundational practices that I had yet to learn which helped me to level up significantly at the game.

This definitely applies to programming as well. It's not uncommon to see people happily churning out mountains of highly redundant and repetitive code, or zealously pursuing far-reaching nit-picky refactors of dubious benefit and I think it's simply because the act of writing code and running tests and watching them go green is fun.

By that logic one shouldn't ever criticise let's say, Google (a separate entity), because in theory one could get a job there, work their way up to be CEO and then change how the company works. In fact, why ever criticise anything or express any opinion when instead you could be 'doing something about it'?

I think it's okay for people to express their opinion on the internet, and it's not a moral failing that they are doing that instead of, as you suggest elsewhere, running for office, getting elected, writing a bill and finding allies.

I used to suffer from regret a lot and I'm not entirely sure how I got over it. It could be just that I'm older and have had more opportunities to see that no matter how many of my dreams I achieve there is always room for perfectionism and regret to wedge their way in and dominate my thinking.

One's life isn't supposed to look a particular way, and international recognition and fame isn't a prerequisite for living a fulfilled and meaningful life. Fulfilment and meaning come not from making all the right choices every second of the day, but rather from just spending more of one's time following one's joy (and expanding the set of things that one finds joy in).

If gaming used to bring you joy but now programming does, then great, do programming. It will take you places and you don't have to worry about where, exactly. Just a high level directive like "this seems like it will be more productive than that, in general" is sufficient direction.

Smart people are just as given as anybody to the idea that happiness is about controlling outcomes, hence they are no happier. The desire to control outcomes is correlated with unhappiness because that very desire is predicated on the belief that happiness is a small target - if one would be happy with any outcome then there'd be no need to control which one eventuates. Put another way: happy people aren't the ones who win every game of chess, happy people just like playing chess.

Another aspect of this is that smart people - people good at solving well-defined problems - tend to see well-defined problems everywhere, tend to try and reduce things to well-defined problems, so that they can apply their unique gifts. This manifests as an apparent discomfort with ambiguity, which poses a problem, because comfort with, or at least an openness to, ambiguity is a prerequisite for happiness. The analytical mind is quick to label things and categorise them, including whether they are good or bad, but I find that happiness is more about refraining from applying such labels to things.

It's like with dealing with an incident. The unhappy say "the website is down, this is terrible", whereas the happy merely say "the website is down".

I don't know, is it more precise to say words like "encapsulated", "testable", "mockable" and "reusable"? Aren't these all essentially the same thing? Suppose you have a class that is technically testable, because you can control all of its inputs, but it has ten thousand methods. Is it really testable if it's so poorly encapsulated?

I feel like good code is just decoupled code that lends itself to composition. Most writing about code is just about how to achieve that quality, not about identifying all these different and conflicting qualities and finding balance between them.

> “I like solution X. It decouples the error message presentation from the core logic. It’s easier to understand, because you don’t have to consider both at the same time. This separation also unlocks some testability, as we can mock either object whilst testing the other. It does come at the expense of requiring the parent object to inject the dependencies, but that’s a worthwhile tradeoff for the testability.”

Take this passage - is it saying anything other than "I identified two independently meaningful components here where you have one". What else can you do to clean up code other than separate things that don't have to go together?

Your comment describes my perspective almost to a T. I used to put a lot of stock in the idea of retiring early and then being free to do whatever I wanted, but what I want is to build interesting things as a team, i.e., exactly what I have always done.

I think many people are trapped by this dream of attaining financial freedom so they can escape work, but in a way that is a cynical take because it presumes that if you are getting paid to do something then it must be something bad that you wouldn't do otherwise.

Such a mindset is unfortunate because harbouring escapist fantasies is a really good way to undermine one's ability to find the joy in what they "have" to do. I spent over a decade not realising that I wasn't suffering from work, but from my hangups about work.

My advice to those who hate not only their job but any conceivable job, and who nonetheless have a job, is to get as good an understanding about why that is as possible. Reflect on it. Try moving around and changing your environment. Try different jobs. Try jobs that have one redeeming thing about them and seem awful in other ways.

The goal isn't to find the perfect job, i.e., the one that fits all your preconceived notions of what you want out of life, but rather to develop an understanding of what your assumptions are and where they come from. It is a useful mindset to be open-minded about what you really want and how you might get that.

I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front.

VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily), one that is familiar to all users, even those who might prefer a more idiosyncratic and keyboard-driven interface. This is analogous to how Java facilitates a certain style of OO programming that is familiar to the vast majority of programmers, even those that may prefer and see value in other, less popular / accessible modes of programming.

By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.

This is not to say that Emacs can't or shouldn't be made easier to use, just that I don't think its survival depends on it catching up to editors like VS Code which I perceive as being for a different purpose altogether. I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.

I'd love to be wrong about that, though, and one day get the best of both worlds.

I think what people mean when they say REPL-driven is to have a headless REPL that one never actually interacts with directly, but rather sends it snippets of code for evaluation directly from one's editor. Typing code into a shell prompt is excruciating by comparison.

I think this is a huge barrier of entry to languages like Clojure. The syntax and dynamic nature of the language really lend themselves to an extremely interactive and productive workflow, but that is a hard thing to communicate. It seems most people think that when Clojure programmers refer to the joy of the REPL they imagine writing code into Python or Ruby's REPLs (e.g. https://repl.it/languages/python3), but that is about as far from what is meant as is possible. I mean, who would enjoy programming in an environment that deleted your work every time you finished a line of code?

The author of the code is going to have to discover how these APIs work somehow, right? Why would the code end up worse if the author has access to a particular tool for interacting with these APIs? A shell and curl is a REPL for interacting with and exploring HTTP APIs but I don't think anybody would claim that the use of such tools makes code written to those APIs harder to follow.

In fact, one of the benefits of your REPL being integrated with one's editor, and being in the language of the system, is that the kinds of ad-hoc scripts you write when doing exploratory / debug coding which one would typically discard after use can often times simply be committed, either as utility functions or test cases. Far from pulling up the ladder on devs who come later, having a REPL makes it more likely for them to have access to the same tools used to build and understand the system in the first place.

Ah I see, thanks for setting me straight. I must have conflated someone's later reading of the poem with the author's original intent.

This is my favourite poem and was before I even knew how layered and knotty it is. In addition to its obvious interpretation it's also about readers and reading, how even if you are the mightiest ruler who has ever lived you still can't make people read you a certain way - the sculptor who "mocked" his features may have found the king's intentions absurd even as he was forced to sculpt his likeness.

It was an illustration by Shelley of the problems of a certain school of literary thought at the time which held that the author of a text is the ultimate arbiter of its meaning. That Shelley was able to make such an elegant counter-argument and encode it as one of the most lyrically and thematically beautiful poems of all time puts me in awe every time I think of it.

That's interesting. I can imagine in cases like this it's not necessarily that the doctor doubts their own diagnosis, but rather the AI is essentially offering to relieve them of responsibility for it either way.

It's like in human hierarchies - it's often not the person who is more likely to make the best decision who gets to decide, it's the one who is going to bear the consequences of being wrong.

The thing is boring tech is often really just painful tech, where pain manifests in lots of different ways (error-prone repetition, painful manual testing, hard to read spaghetti code, etc). Programmers who are too insensitive to pain will continue to generate pain for themselves and others.

It's pretty clever advertising really. I don't imagine that having noticed an HTTP header would really give an applicant much of a boost in the interview process, but to some it probably feels like finding a ticket to Willy Wonka's factory and may motivate them to apply in the first place.

Reminds me of when my team at bigcorp noticed that you got given a badge on your personal page for being quick to respond to code reviews. Cut to suddenly every code review being immediately responded to with the comment "got it, will review soon".

That said, it really did change the team's behaviour. Code reviews became a priority instead of something left to batch up and do later. Whether that was a positive change or not it's hard to imagine an edict from management achieving the same result.

The creator of the course, Professor Laurie Santos also has a podcast on the same topic which is quite good: https://www.happinesslab.fm/

This allergy to reality is surely the biggest trap not just for startups but people in general. It's surprising but I feel like the norm is for people to care far more about feeling that everything's okay, rather than everything actually being okay.

That said, one problem I see with the anecdotes provided is that the problem solver is doing two things: discovering a problem and solving it. Conflating these two things is a great way to encourage pushback: every change comes with an associated risk, so the general rule is to say no (using whatever flimsy reason) if it's not well understood and agreed that the problem being addressed is a real problem worth solving.

It's not that Gmail has a dominant position and so doesn't need to care about its rating - Gmail is an app not a page and it's less important for apps to load quickly than pages. Apps tend to be long lived and so a slow startup time is tolerable, whereas one is constantly opening new pages.

That is to say, I don't think e.g. Trello would really care if their site was "slow to load" either.

This is an attempt by Google to influence the bloated websites out there, rather than a browser feature intended to attract users. It's probably mildly helpful as a user to know if a site is slow (as opposed to it just being slow for you), but it's a big incentive for a website owner to speed up their site if this badge of shame appears it for a majority of users.

Hooks are great! I can sympathise with those suffering from JS fatigue, but I don't think they are merely a prettier/different syntax for doing the same thing, they are a significant conceptual simplification. This:

`const { data, loading } = useFetch("/query", {page});`

is not only shorter than the corresponding slew of lifecycle method implementations that would be required in a class component, it's also much more direct and readable. Trying to recover the intent of code by reading the implementation of various imperative methods is painful and error-prone, whereas it's hard to imagine how the above could any more effectively communicate the intent - every single token is meaningful.

I think Google's interests are aligned with developer interests here. The main benefit to GCP that k8s success brings is that migration between clouds becomes easier (e.g. moving from EKS to GKE would presumably be easier than moving from Elastic Beanstalk to App Engine). Less lock-in benefits everyone except the current market leader.

I suspect the person who got fired wouldn't have self-identified as someone who finds it difficult to avoid saying sexually inappropriate things, either.

Meditation is a great way to train one's attention and focus.

A lot of ink is spilled describing what companies and bosses could do to enable programmers to get or stay in the zone, but all of that is immaterial compared to one's intrinsic ability to focus, which is a skill that can be developed.

Or worse than never going, you'll keep going, but you'll always just do whatever you feel like and never push yourself. Then years down the track you've made no progress, but poured countless hours into the habit.

It's probably not going to work if your strategy is to only do easy things, or only do really hard things. I suspect that the answer lies somewhere in the middle, as it often does, and as ever there is no way to summarise that as a simple and absolute rule, you just have to use your own judgement and self-knowledge to guide you.

People who seek these kind of easy answers are already in a quagmire. The most debilitating belief is the one that there's a perfect, general answer out there that you just have to find.