koz_
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.
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.
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.
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.
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.
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 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?
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.
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 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?
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.
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.
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.
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.
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.
That is to say, I don't think e.g. Trello would really care if their site was "slow to load" either.
`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.
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.
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.