Modern Work Journal

Bram Adams -
💡
This is a daily standup post of the work put into maintaining bramadams.dev. Ex nihilo nihil fit.

Newsletter (Sundays)

  • no updates

Software (Saturdays)

  • ill say it again – record programming work sessions with obs. there are so many minor elements to the programming experience that cant be screenshot:
    • how long you spend thinking about some functions vs others
    • how many times you ran a terminal command
    • how much time your programs take to compile and run
    • that answer to your question you found from that code forum at that random url
    • how much you goofed off on the internet since you were by your browser
    • what day did you work on this bug or that bug
    • provable effort outside of git commits
    • fun to watch, especially if paired with music from spotify or apple music or youtube or something
    • easier to stay in flow state longer

the modern work journal is permissive local screen recording

ARBITRAGE
im all in on arbitrage
Bram AdamsBram Adams

Books (5/month)

💡
links are affiliate! if you pick up a copy, i get a little kickback!

Seibel: Do you think programmers are overenamored of new things? New languages, new tools, new whatever? Fitzpatrick: They might be. I don't know if that's desperation in hoping the new thing doesn't suck, like the new programming language does what we all want. But users are the same way. Users always like to get the one with the higher version number even if it sucks more.

Seibel: What do you think is the biggest change in the way you think about programming compared to back then? Crockford: There was a period of maybe a decade where efficiency was really, really important. I guess it was in the early microprocessor era when memory was still really small and the CPUs were still really slow. We'd get down into assembly language in order to do things like games and music to make it fit and to make it fast. Eventually we got over that, so today we're writing big applications in JavaScript that run in a browser. It's such a profoundly inefficient environment compared to the stuff that we used to do, but Moore's Law sort of made it all OK.

Seibel: Do you find that you have to teach people how to do code readings? I can imagine it'd be hard to find the right balance of being critical enough to be worthwhile without making the code's author feel personally attacked. Crockford: Yeah, it requires a lot of trust on the part of the team members so there have to be clear rules as to what's in bounds and what's not. If you had a dysfunctional team, you don't want to be doing this, because they'll tear themselves apart. And if you have a dysfunctional team and you're not aware of it, this will reveal it pretty quickly. There's a lot that you can learn, a lot that's revealed by this process. It feels unnatural at first, although once you get into the rhythm of it, it feels extremely natural.