jaw

https://brokensandals.net/

I use a sort of intermediate approach for my personal site. It's just stored as html files in a git repo, and I do write the html by hand for pages that I want to put extra love into (e.g. an annual year-in-review post to share with family and friends). You wrote something in your original "Writing my own damn HTML" post that captures a big part of why this appeals to me: "I see my website as a sort of self-expression project - kind of like a zen garden..."

But handcrafting html is inconvenient to do frequently, so for more ordinary posts I write in markdown and use some custom scripts and pandoc to generate html. For me this approach is more fun than using a static site generator and less annoying (because I spend less time figuring out why an upgrade randomly broke something, or how to make the SSG do things I already know how to do manually). But the only reason it hasn't devolved into a full hand-rolled SSG is that I don't need/want much consistency across pages: there's no shared nav bar and I don't try to keep the styling or layout of older pages in line with newer pages.

For me personally, the effort of 'polishing' a post makes it drastically more valuable to myself in the end: I think harder about the material; I notice problems with my thinking that I would have glossed over otherwise; I explain things in ways that will be more useful/legible to me-five-years-from-now.

Committing myself to publish posts is, in part, sort of a motivational hack to get me to do the polishing. The possibility that someone else _might_ read it and judge me for it pushes me to put much more effort in than I would if I kept it private. (I wrote a short blog post on this: https://brokensandals.net/personal/reviews-as-notes/)

I probably wouldn't see this as a sufficient reason for blogging if I believed that _literally_ nobody would _ever_ read the stuff I post. But it is a significant benefit that's available even if I only have a very tiny and sporadic audience.

I do this too—every post has a footer telling people they can email me with feedback, along with a mailto link. I maybe see one piece of spam every few months because of it. And once in a while I get feedback that I really enjoy. As the top-level comment mentioned, there are advantages to 1-on-1 communication.

As a fellow fan of effective altruism, I really don't want people to think of it as the group that shows up whenever someone is asking for help and says "Don't help them! You should be helping these other people instead!"

Empathy is crucial for motivating people to give to any cause, and it's a crucial part of why I'm involved in EA. If someone's first/main exposure to EA is along the lines of "you should ignore this cause which touched your heart, because numbers", it's not going to resonate. I want people to be excited about the good they could accomplish by donating to EA-aligned charities, not feel like I'm trying to press some distasteful obligation onto them.

Also, it's not a zero-sum game in practice. People can be inspired to increase the total amount they give (so giving more to effective charities doesn't necessarily mean giving less to other charities they care about).

I have a blog, but I mostly assume people _don't_ care what I'm doing or thinking. Some of my posts have probably never been read by anybody. I still personally find it worthwhile for a few reasons:

- The mere possibility that someone will see it pushes me to put more thought and effort into what I write. Sometimes this reveals weaknesses in my ideas that I would have glossed over if I were just writing private notes for myself; sometimes it leads me to actually change my opinions. It also means the blog posts are easier for me to understand / get value out of than notes are if I come back and reread them years later.

- It creates opportunities for people to connect with me which can pay off at unexpected times. Occasionally people have reached out to me to say a post helped them or resonated with them, or to give a thoughtful reply or ask a question. Those sorts of interactions are really satisfying even if they're rare. (One time, I was interviewing for a dev job and the interviewer asked a question about a post I'd written on the philosophy of John Rawls, and how it could connect to software engineering. I found that absolutely delightful.)

- It's just nice to have an outlet when I feel like writing about something.

At several points in my life I've been so discontent that I felt I had no choice but to try something that felt (at least to me at the time) drastic and risky. This has included:

- pursuing romantic interests that I knew could get complicated

- reaching out for emotional support in ways that made me feel embarrassed and vulnerable

- confessing suicidal thoughts to my doctor

- quitting my job and taking >1 year off work

- moving across the country with no job lined up and no long-term plan

I've never regretted any such decision; I think it's always had a major positive impact on my life. Because when I'm trapped in my routine the world can start to feel very small. To shatter that illusion and remind myself how wide the possibilities in life really are, it's often necessary to behave in some way that violates inhibitions I normally have.

So... taking a break from coding could be a great idea, especially if you can build up some savings first. It doesn't have to be forever (I took ~15 months off then got another software job). You don't have to plan the rest of your life - find a direction that looks promising for the next year or two, and adjust course again as needed after that.

you can't treat depression by hanging out with other depressed people

I disagree, a sense of shared suffering can be really helpful in building close and meaningful friendships. Connecting with another miserable person who understood what I was going through - and plotting with them about what each of us could do to try to change things - was one of the key things in getting me through one of the most depressed periods of my life.

Meetups in my area were also only tech-related.

No book clubs or discussion groups or political action or volunteer groups? Maybe you need to move; there should be a lot more than tech going on in any decent-sized city. Even if it's such a tech-focused area that lots of the attendees happen to work in tech, you'll see other facets of them at those events; people have passions outside of their careers.

It sounds like you've been able to consistently land dev jobs, produce working software (it's not your responsibility to ensure the thing you've been asked to build is commercially viable), and build a good reputation (you mention good feedback and promotions), plus you've made a ton of money (most people make way less money than software engineers, and the average software engineer has not gotten a lucrative stock windfall). I think you've been very successful :)

It's been a couple months and I have achieved nothing.

At my first software job it was said that a new hire typically wouldn't be a net positive for the team until they'd been there a year. You wouldn't necessarily have even been given a real task in the first two months, let alone gotten it shipped. Big companies have bureaucracy and gatekeeping (for good and bad reasons) and operate on timescales of months or years. By design, a new person can't unilaterally be productive. It's possible that investing the time to empower you to be productive just doesn't seem urgent to them right now - dealing with the fallout of a manager leaving may be much higher priority. You're on the payroll, they know you'll be around for them to utilize when they need you...

If I can't work in the tech industry it would completely upend my entire life.

Based on what you've said, this fear sounds very unlikely to come about. Even if this company is dysfunctional and you need to move on, you have a history of being able to get tech jobs, and it sounds like you've made a positive impression on many coworkers in the past, so I imagine they'd vouch for you. And there's a ton of demand for developers right now, and a wide variety of companies to choose from!

Reminds me of the tale in this podcast [1] where the guy's desire to avoid a difficult conversation spiraled into totally ghosting his employer for two weeks.

It's a really tough tendency to fight. One thing I think is helpful is to acknowledge failure as early as possible. If meeting the deadline would require me to work faster than normal or make some heroic last-minute effort, I've already failed, even if that deadline is still a long way out. Admitting that to myself and others now, so that expectations about the future can be adjusted, is a much smaller blow than admitting it weeks or months down the line. And it means I only have to feel a little flaky and underperformant, rather than super flaky and underperformant and also dishonest.

[1] https://80000hours.org/podcast/episodes/depression-anxiety-i...

I and many people I’ve met irl through book clubs etc use it; I find reading my friends’ reviews interesting and I’ve gotten good recommendations through it.

If you’re just looking at the top reviews for a book it’s more questionable; they tend toward the extremes: enraptured encomiums about how beautiful and important and bold the book is, or insult-laden rants where the book is a whipping post for the reviewer to show off what a biting sense of humor they have.

no one actually interacts with people selling you things like this

There's a whole successful social network (Goodreads) built on people's desire to talk about books, frequently in the form of effusive praise. I think being able to trace the product to a single individual (e.g. a book's author) helps make it particularly appealing to leave that sort of feedback: we know it feels great to hear that someone values a thing you've created, and we like the idea of giving that pleasure to the creators of things we like.

I've used this service for a few years and really appreciate it. Mostly I use their app, which works perfectly fine, but it's nice to be able to download the DRM-free files so I know I'm not locked in.

Articulating your flaws isn't the same as fixing them.

If you just tell people what your love language is, but don't learn to show love in their love language, they still won't feel cared for. You may even be reinforcing the message that you don't care enough to adapt to them.

If you tell people to call you out on being late, but are still routinely late, it will feel like an empty apology.

We all have flaws and have to deal with each others'; for all I know this person is a fantastic manager. But I'm skeptical that this kind of document is a good way to start a working relationship. It's very personal to the author but impersonal to the recipient, giving the impression that all responsibility lies on the recipient to deal with the author's issues. I know the document tries to emphasize that that's not the case, but until you have a real relationship with the person you don't know which parts of that to trust. (Most people see themselves as being open to honest feedback, but that doesn't mean they actually are.)

I recently stopped using a static site generator for my personal site [1] in favor of just manually maintaining a bunch of HTML files, for similar reasons. The last straw for me was a nonpassive change to the site generator mysteriously breaking the homepage. Themes are frustrating as well since they either constrain you or force you to spend time figuring out how to shoehorn what you want into the theme. I only post occasionally, and keeping all the pages consistent with each other isn't as important to me as being able to post a page that looks however I want it to with minimal hassle.

[1] https://brokensandals.net/

Right. Aside from 'files' and 'bytes', the metrics are just the result of running shell commands specified in a config file. In this case it's `jq '.items | length' $PARCEL_PATH`, i.e., parse the file and print the length of the attribute named "items".

Obviously, that won't catch all potential problems in the file, but it's a low-effort way to catch some.

Scrolling through thumbnails is better than nothing, sure.

"Better than nothing" is pretty much what I'm going for here. Almost all my personal data stored in cloud services falls into this "corner case": I only have indirect access to the source, it's important enough to me that I want to do some level of checking, but it's not important enough to spend the huge amounts of time it would take to inspect every individual datum.

I keep multiple versions as well, and also use third-party backup software on all these files. These techniques are meant to be part of something analogous to a 'defense in depth' against errors in the backup process, not thorough or foolproof.

Not only do you have to validate a file looks like a .jpg/.json/.zip file, you also need to validate that it looks semantically correct (ie. the file format is valid but a chunk of it is missing).

But you don't have to do that perfectly to get value out of it; for example:

- If the .json file parses as json, then at least you probably didn't truncate the download mid-stream.

- If it also contains a particular attribute, then you probably didn't save a structured error response instead of the actual data, or save something from a radically-nonpassively-changed endpoint that might no longer be adequate.

- If it also has roughly the number of elements you expect, you probably didn't miss entire pages of the response.

I replied to a similar point about hashing here - https://news.ycombinator.com/item?id=23032633

You're correct that the methods I described are a far cry from actually guaranteeing that the backup has no errors. In the same way that a unit test doesn't prove code is error-free, but _can_ justify increased confidence in the code, I'm interested in techniques that can justify increased confidence in my backups. Particularly in cases where I don't have direct access to the original data, and where exhaustively checking the data manually is too time-consuming to be worth it.

I'm mostly trying to address cases where there is no original file that I fully trust. If I'm exporting my data from some web app/service, I can't get a hash of the data as it is in the actual source of truth on their servers, and there's multiple points at which an error could be introduced before the completed export file lands on my machine.

It's a good point that hashing is a better method when you have access to the original files.

Focus has been an issue for me too. I think it helps to view yourself as having a limited number of focus 'slots', but to view each focus as just a medium-term commitment (a few months or years). So e.g. you're not choosing an instrument _instead_ of drawing, you're just choosing to learn the instrument _first_.

Setting specific goals for each month, which I track on Trello, has helped me a lot. It encourages me to make concrete progress and not tackle too many things at once, but reduces FOMO since I know I can always go a totally different direction the next month if I want.

(I blogged a little about focus: https://brokensandals.net/three-books-on-focus/)

Location: Seattle, WA

Remote: Yes (preferred)

Willing to relocate: No

Technologies: Java, Ruby, Rails (8+ years); JS, React; would be happy to learn more Rust, Go, or whatever for the right project

Résumé/CV: https://brokensandals.net/code/#professional-experience

Email: jacobaw@gmail.com

I'm usually drawn to backend work, but can pitch in on front-end stuff when necessary. I have about 9 years experience developing in a corporate environment and 10 years before that of coding for fun.

Location: Seattle, WA

Remote: Yes (preferred)

Willing to relocate: No

Technologies: Java, Ruby, Rails (8+ years); JS, React; would be happy to learn more Rust, Go, or whatever for the right project

Résumé/CV: https://brokensandals.net/code/#professional-experience

Email: jacobaw@gmail.com

I'm usually drawn to backend work, but can pitch in on front-end stuff when necessary. I have about 9 years experience developing in a corporate environment and 10 years before that of coding for fun.

I'm not sure the concept of "truth" is reducible. Any argument about the question "what does truth mean?" implicitly requires that participants can already make some sense of the idea that some answers would be true and others would be false. Also, it seems like you're implying that unverifiable claims are meaningless - but isn't that an unverifiable claim?

Putting that aside, some things are unverifiable yet have concrete ramifications for people's lives. Some examples:

- If "earth will be swallowed by a black hole in ten seconds" is true, I'll never be able to verify it, even though it will have the concrete effect of ending my life.

- I can't verify _or_ falsify that other humans have conscious experiences, but I believe they do. If that belief happens to be false, the world is vastly different than if it is true.

- _Nobody_ could 100% verify that a given physical law applies everywhere at all times. But if it does, some people's lives will be different than if it did not. The fact that everyone in the cosmos has experiences consistent with the law being true, and nobody ever has an experience inconsistent with the law, are part of what make the law true. But that fact can't be verified by anyone.

(A hypothetical omniscient person could verify all these things, but omniscience just means "knowing all true things", so redefining truth in terms of what an omniscient person could verify would be circular.)

I think that's a potentially misleading way of summarizing it. Facts are true beliefs; not all beliefs are true. The trilemma only implies that there's no way for me to step outside of my own head and know, beyond the possibility of error, that my beliefs are true. But they may still be true. (That applies recursively to the trilemma itself!)

So if you dig far enough, how accurate our beliefs are is partly reliant on factors beyond our control: if our minds happen to be wired with bad axioms we may be unable to avoid inaccurate conclusions.

Released! https://github.com/brokensandals/blunt-instrument#blunt-inst...

I'm fascinated by the idea of first-class support for preconditions/postconditions and class invariants. Has anyone worked on a large code base (whether in Eiffel or not) that made extensive use of those constructs?

Obviously it's common to put argument validity checks at the start of functions, and to check invariants at some critical points. But I'm curious how the existence of specially designated slots on every method/class for checking arbitrary invariants affects developer behavior and productivity.

taking your argument to the extreme, we all probably should've stuck with PHP, since everyone understood it and, well, was it really worth the switching cost?

There are multiple paths for honing a new technology, without dumping it on a large group of developers while it's in its experimental stages:

- Use it for a series of side-projects

- Use it in a startup or startup-like team in which all the developers are bought into it, and happy to work through the obstacles

- Use it at an organization that's both able and willing to devote a large amount of resources to making it work (e.g. devoting a full-time team to its development & support & related training)

Once the kinks have been sufficiently worked out in one of those contexts, and a solid ecosystem with good documentation exists, then there's a much better chance that the benefits will be worth the switching costs for the average project.

Yep, works now :)

Interesting! This way of structuring & evaluating a program seems analogous to how spreadsheets work, but with a hierarchical instead of a tabular data model. I could see it being helpful to new programmers for building intuition about how code works.

And translating a program's execution into sound and being able to hear changes sounds really fun.