mmatants

Yeah this kind of stuff makes my blood boil. One can shame and belt their kid into compliance, and it might even get them (barely, only if they're lucky) all the way through university but holy shit the lifelong damage of self loathing and burnout and broken relationships it creates is im-fucking-measurable.

Taking a neurological imbalance and turning it into a morality thing is abuse. Even if unintentional. This is real. Parents look for simple answers like "give em the strap" but how is that less reductive than "give em the pill"?

To add a data point, I used to do Pomodoro timing (25+5 min) but now switched to 15 min timer with a loose 2-5 min break. It's still hard to actually pull out of hyper-focus/anxious perseveration sometimes, but the shorter timer period seems to match my task cadence better. And the non-timed break just vibes better because it doesn't feel like punishment then.

Reminded me of one of my favourite text-art/PETSCII adjacent creators I follow - Mrmo - who creates satisfying retro stuff like this custom font/tileset: https://mrmotarius.itch.io/mrmotext

Suburbs are not the only place to raise kids though. Probably not the best place for it either.

One clever hack I've seen is Yield Prolog (https://yieldprolog.sourceforge.net/) which basically translates the querying/backtracking execution model into mainstream language syntax - such as JS, Python or C# - using the `yield` keyword and loops. Supports things like variable unification, too.

I also want to mention the Lichee Pi Nano, though it is much smaller and targeting a different use case: https://www.cnx-software.com/2018/08/17/licheepi-nano-cheap-.... Made an embedded distro Buildroot config for that one some time ago (https://github.com/unframework/licheepi-nano-buildroot).

I'd say for 95% of data fetches https://github.com/slorber/react-async-hook works really well without needing generator syntax or explicit promise cancellation boilerplate. I'm not the author but a satisfied user.

At least for parsing PDF into table I had decent success with Tabula.

The fact that choosing to use Uber represents a certain amount of trust in the driver (basic background check, identity information, etc), makes it more than lead generator or transparent broker.

Law as an industry is pretty dysfunctional. Plenty of data governance issues, losing track of documents, etc. A lot is at stake there, for sure, but that's actually the thing that process helps with - reliability and safety. And law is very resistant to incorporating that.

I had some success with https://www.beeminder.com/ in my short time of using it so far. Essentially, it moves items from "important + not urgent" quadrant to "not important + urgent" one: by dinging your card $X dollars if you don't comply.

However, I also had to shift my mindset towards trying to progress via small inconsequential chunks, rather than trying to "fix everything". E.g. the idea is to just show up to the gym - not exercise - but if latter happens, then sure, why not (and it usually does). I think it helps snap out of the failure avoidance mode.

Apparently, Peter Naur (the N in BNF) wrote this up nicely back in 1985 in "Programming as Theory Building": http://pages.cs.wisc.edu/~remzi/Naur.pdf

This is a really neat looking project (and the GH readme references the original HN discussion). For folks who are generally into TTY UIs and dashboards, I also want to point out the Blessed terminal rendering lib and its ecosystem (which even includes a React bridge!):

  - https://github.com/chjj/blessed
  - https://github.com/yaronn/blessed-contrib
  - https://github.com/Yomguithereal/react-blessed

(edited for syntax and also to clarify I am not affiliated with the above, just a fan)

Rules like DRY or keeping line counts low are based on surface metrics and definitely lead people to over-fit the model based on incomplete information.

Underlying principle of maintainable code is "simply" that it is a concise and flexible expression of knowledge. The "simply" part is in quotation marks because, of course, it takes a good amount of self-awareness and meta-consideration to understand why some ways to express knowledge are better than others. There is also a limit to how "perfect" it can get, because it really depends on the audience too.

This is also why it's OK to let it slide sometimes and move on to more interesting topics - there are diminishing returns on splitting hairs, once broad strokes of good encapsulation and basic readability are applied.

This is an impressively thorough walkthrough.

I think one of the biggest saps of motivation in that situation is that even successes are meaningless. Because one instinctively doubts the whole thing then (even a broken clock is right twice a day, but it still doesn't make one feel great).

Re #2: - patio11 recently fired off a few tweets about doing away with comments on his blog: https://twitter.com/patio11/status/813895918692876289

Can't say I would disagree. A lot of folks these days just seem to append an HN/Reddit link to posts that get discussions on those sites. There's the blog as an expression of author's personality, and then there's the discussion space as an area with a life of its own.

I became so much happier when I realized how much my education-minded parents and my environment gave me a leg up (even in the economically declining Eastern Europe of the time). Helped me chill out a lot and feel less pressure (and hence have much more actual productivity).

Starting advantage does not mean you are not working hard now. Just means that you should do good things with that advantage. Make it shine!

Most performance problems with websites/webapps out there are just due to sheer nastiness of the shovelware that they embed. No need to have fine-tuned debugging and profiling when the main fix is "don't accidentally run this jQuery selector 1000 times on every click". Very low hanging fruit.

People need to be reminded of obvious things. In this case especially because there is active pressure to collect things - from your typical BigBoxCo flyers, sales, TV doorcrashers, buy-one-get-one events, etc. I know too many people who are simply drowning in junk, so if it takes a half-cultish trend to get them to unload - then so be it.

Every approach has ups and downs, but my fundamental gripe with ORM as it exists is that it does not match business data model very well.

Here is a shameless link to something I wrote on that topic; it complements the above article: http://unframework.com/orm-vs-key-value/

One thing to remember, too, is that the original Facebook was quite different from what we have today. It focused on personal profiles, and had features of almost like a dating site. A huge use case was organizing parties (I know that because that's what we did as a group of students). Newsfeed as a timewaster is a feature that evolved only later. Messages were clunky and a non-thing.

Any product that has persisted is actually a series of products sharing same name, but each targeting a different demographic - oftentimes even actually same set of people but at different life stages. And as sibling comments point out, it is all about just trying and trying (and also, it would seem, having super convenient access to millions of people to try things on).

It makes sense to have centrality of vision for how code should be laid out. This is software architecture (as skill and role, not title though!). And as people have a limited focus span, it makes sense to segment - by business topic, by API, etc. But of course fiefdoms emerge.

In some ways, it might then almost be better to not have that person contribute to same codebase: to avoid ego pissing contests and to keep the opposing pressures in balance. The pressures being: delivering features on time on one hand, and keeping things clean and orderly on the other hand. Often, if the architect codes then they can't see their own mistakes, but have 20/20 vision of others' grubby flaws, and hence gain subconscious animosity towards external contributions.

That being said, an architect who does not code is even worse! This is where we get ivory tower Architect-as-title, and even less gets done. I wonder what the optimal middle ground is.

It feels like the early language wins were due to the languages themselves introducing new concepts, not just syntax changes. Allowing higher-level reasoning.

Then, past a certain point, most of the new concepts started coming in via frameworks and libraries (although of course things like functional programming and interesting typing approaches are still language-driven tools).

Thus, these days, I would look at libraries and frameworks as sources of new productivity unlocks. E.g. in the Web world, jQuery saved millions of work-hours and qualitatively unlocked some new things. Then Angular (and eventually React) started realizing huge savings from declarative UI definitions. My preference for one next innovation in this area is a higher-level framework for user input modeling (a huge source of bugs these days).

I'm sure that you are not getting a lot of upvotes for that comment, but you hit the nail on the head regarding programming being the translation layer between entropy of the real world and automated efficiency of computers. That is a very valuable service, but there are implications as to how this profession evolves long-term.

My most fulfilling and interesting career stories were about listening to people and reading their needs between the lines, un-kinking silly workflow knots, finding non-tech solutions to seemingly technical problems. Not constructing pristine castles of code (that ended up not even being used, ultimately).

This is also why I have tried very hard to define my identity around my general values and mission as a human being rather a specific career choice I serendipitously rolled into when I was 15. It has been very gratifying and liberating as a change of worldview.

I think the gist of the first point is that there is a lot of communication that needs to happen. Talking is not the point; understanding others and making yourself understood is the point. And for most situations, currently, that just happens to involve a lot of talking.

I really like the philosophy you describe. It pains me to see folks disenfranchised from the concept of real teamwork. Isn't the whole point to be working with each other? Even if the person is signing my paycheque, they are still another human tackling the same general problem as I am.

Easier said than done, because of course there are bad managers out there. But even in difficult situations it can sometimes help to try "manage up" - again, the value-building and the mission is bigger than any one person.

What really helps me stay engaged in conversations with strangers is directing my genuine interest in their "story".

What drew you to get into computer science? How did you end up enjoying accounting? Why did you choose NYC over Tokyo?

When someone asks me what degree I took, the answer is two words: Computer Science. If they ask me why - now there's a real conversation.

Often, also, it may help to tug even further at that story thread - what background brought it around? What did the parents do? What was the formative experience that created the story?

Working independently definitely does not save one from BS and playing by the rules. However, I think the main distinction is that it feels less "personal".

In a poorly-run hierarchy, having a manager means playing along for someone else more powerful, playing along with their personal politic, etc. That can be very distracting and exhausting, because for less-adequate managers it involves a lot of mental effort. And, importantly, it feels very person-centred rather than craft- or value-centred.

Contrast that with freelance work: yes, clients can be very difficult to deal with, and in fact may require more "high touch" interaction. However, at that stage it is just a social contract, customer service, explicitly outlined interaction. And the relationship is transactional from the outset, there is a clear value focus. Plus, one could theoretically fire their client and move on (although that is not always realistic).

As another comparison, let's look at a trades job in a highly unionized company: it can actually be quite liberating, because promotion and career track are again detached from specific personal impressions and set to a highly regulated and enforced schedule. People feel empowered, because it is a shield of sorts (albeit one that comes with costs as well).

I for one actually prefer to put a different type on the variable than the implementation. I.e. in the given case, I would actually use:

`List<String> a = new ArrayList<String>();`

I know that for some things it is convenient, but I appreciate the reminder to treat interface and implementation as distinct concepts.