440 karma · joined March 8, 2012
I am the cofounder of Pollitify, https://www.pollitify.com/ a social network for progressive activists and the Polly software suite, a set of tools for progressive organizations.
Looking to do mutual aid in America related to food assistance / SNAP ? Sign up for a Pollitify Grant: https://www.pollitify.com/grants
1. Write a blog post about it. I'm an old school blogger and my best learning tool is to immediately start writing about it. I'll do this even before I've used the thing in question. Another writer here talks about producing versus consuming and that's the magic -- this shifts you immediately into being a producer. Most things you try and learn aren't that hard when you start actively engaging with the topic by writing about them.
2. Write test coverage. If it is a software technology then I'll start to use it by writing out the tests needed to use it. I find tests always make software technologies much more understandable because, inherently, they force you to think very atomically.
3. If I really, really want to understand something in depth then I'll create a side project about it or that requires it. Just for example I'm currently doing this as a way to force myself to build better web apps. I've chosen HotWrite and Turbo as enabling technologies and now I've got the core of a neat little app that avoids full screen redraws, uses CSS I actually understand and so on.
PS - This is the best timeline tool I've ever used. I used it to chart out my career history and it was damn useful.
https://www.preceden.com/timelines/869343-scott-johnson-care...
And don't even get me started on ranting about podcasts that don't clearly label their feed.
One of my side projects even got venture funding (and not in 2021 when things were overheated -- back in 2003).
Yes Ruby has ruined me.
curl https://cooking.nytimes.com/recipes/1023587-brunswick-stew
-or-
https://gist.github.com/fuzzygroup/9496c22cb3c429ae3cf3aea19...
* Pair program to teach people you work with that there is another way; they may simply not know any better. * Make any code you touch better; new / old it doesn't make any difference. Do it right. * Important: NEVER, EVER COMPROMISE ON THIS!!! Seriously you skip one time and it can all be downhill after that (sayeth the voice of regretted experience).
All I do is edit text. My editor isn't an IDE. It doesn't run tests, etc. It is just an editor. I have no idea why it does what it does but it does it.
And I get what you are saying about nvim / neovide but it feels reasonable to me that __45__ years into the WIMP interface (assuming 1977 as a point when Xerox Parc had things running well) that we should be able to:
* Have a nice UI * That edits text without crashing
I completely agree on tools you are forced to use. Truth.
* The language you use defines how you attack the problem. If you use Snobol then you can only think of the world as strings. If you use an APL derived language then you think in terms of arrays. * If the language's core attributes really suit the problem then you get something fundamentally different. We see this with Erlang which achieves safety but (finally) acknowledging that stuff crashes so build support for recovery into the language.
As someone who used to commercially sell a text editor derived product, memory management is just plain hard.
I've been in TextMate about as long. And I love the product to death. I just want it to stop eating itself. And I really, really wish Allan would treat it seriously. He built a beautiful thing and then seemingly gave up. Right now the publicly checked in code on Github can't be compiled (errors in Rave).
Given that I use Ruby and MarkDown only (maybe some yaml), I can't see the syntax highlighting being the issue since TextMate internally is so much Ruby.
VI is also my adjunct.
I try Sublime every few years and it never feels right.
VS Code - Oy. JavaScript is NOT a proper way to write an editor.
Not an IDE fan.
Eclipse. Not Mac like.
BBEdit -- interesting; I'll add it to the list.