4 ms·

I like to say programming is about knowing which rabbit holes to plunge down and which to step over. There's too much to know to go depth-first down every rabbi

I like to say programming is about knowing which rabbit holes to plunge down and which to step over. There's too much to know to go depth-first down every rabbit hole. Go breadth first and accept gaps in your knowledge - everyone has them. If something never comes up and never causes an issue you need to look into, and the project gets done, it doesn't matter. There's always an improvement that could have been made, but done is better than perfect because perfect never gets done. But the projects never getting done or even started - speaking for myself, that is corrosive to my motivation. I've written a lot of Rust. I've read less than half of the Rust book. Your competence in Rust is a function of how many lines of Rust you've written; getting to the point you can start working with it is more important than completing the book. Jon Gjengset's videos were really critical for me there, seeing how he worked in Rust made it possible for me to develop a workflow. (I broke down what I learned in more detail at one point [1].) Rust is an example I've honed in on because you mentioned it and I related to it, but this is broadly applicable. Dare I say, more broadly than just programming, even. (Also, note that I'm a giant hypocrite who shaves yaks and struggles with perfectionism constantly. I learned Rust 5 years ago to start a project, and I've written 0 lines of code for it. If I sound critical, that's my self criticism leaking through.) [1] https://news.ycombinator.com/item?id=38020654 https://news.ycombinator.com/item?id=38020654

vanjajaja1 1y ago
> I like to say programming is about knowing which rabbit holes to plunge down and which to step over. I like this a lot. I told someone once I avoid documentation like the plague and it just didn't have the same poetic ring as this line. Sometimes you need to dive in, other times you need to hobble together something to step over
PixelForg 1y ago
Thank you for your comment, especially for this > I've written a lot of Rust. I've read less than half of the Rust book. Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part) I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to get comfortable with having gaps and just start writing code and not be afraid of writing non-idiomatic rust code, atleast for now.
- maxbond 1y ago
  That's awesome, best of luck to you.
- ChrisMarshallNY 1y ago
  I've -literally- been writing Swift, every day, seven days a week, 52.4 weeks a year, since June 2, 2014 (the day it was announced), yet, I still have huge gaps in my knowledge of the language. I speak it without an accent, but not at Ph.D level. As to home projects, that's pretty much all I do, these days, ever since I "retired"*, in 2017. I'm quite good at what I do, and generally achieve every goal that I set, but, since I'm forced to work alone, the scope needs to be kept humble. I used to work as part of a worldwide team, doing some pretty interesting stuff, on a much larger scale. But what's important to me, is that I do a good job on whatever I do. Everything I write, I ship, support, and document, even if it isn't that impressive. The bringing a project to completion, is a big part of the joy that I get from the work. * Was basically forced into it
  - fragmede 1y ago
    Unrelated question since you've got the Swift experience: How would you recommend a modern day Mac utility get sold? Is grabbing some hardware ID of a device and then charging money for a license keys somehow still the way to go for some small utility (eg window management app like Rectangle) if you want to sell to users outside of the Mac app store?
    - ChrisMarshallNY 1y ago
      With Mac, you have choices (as opposed to iOS). There’s licensing libraries that you can use. These can do things like hardware keys. The App Store is very secure, but Apple gets their vig…
- speleding 1y ago
  Another approach that may help you, that worked for me. I was not familiar with rust so I wrote an initial proof of concept in another language (Go in my case). Then I asked Claude AI to translate it to Rust. It compiled on the first try, the only bugs being problems in the source file I gave it. Then I iterated a bunch of times by saying "please make this more rustacean style". I only tend to use AI for assistance, but for me at least it's easier to get started this way than to start with an empty source file.
jerf 1y ago
I think another important view is to consider how much you've already covered. As a young developer, I recommend spreading a bit wide. Try many technologies. Play with a new language every year. Focus on things you haven't done before, like, don't go from Python to Ruby, go from Python to C# or C++ or something. But as you get older you want to shift from exploration to exploitation. It is hard to make progress on anything, both professionally and personally, if it first comes with another couple of person-weeks of learning something new, let alone person-months. Even though I find learning new things easier than ever because of the breadth of things I have covered, I find myself having to be ever more skeptical of what I will invest in in that way, because unlike a fresh developer with no skills who has little better to do than learn their toolset, I have skills that can be exploited to good effect. As a mature developer, I need to trade off not so much "what might this be useful for in the future versus the effort of learning now" but "what could I be doing right now with the skills I have rather than learning something new". Particularly when the "something new" is a variant of a skill I've already picked up. It'd be great if I never again had to learn a devops deployment system. I've already had to learn three. Unfortunately I doubt I'm going to get away with that. It'd be great if I didn't have to learn another scripting language to do something, but I doubt I'll get away with that either. Your mileage will absolutely vary but it'll be something. I know there's a memeset of the "old fogey who doesn't want to learn", but I really do see the learning costs now as the opportunity cost of using that time to exploit the ones I already have, rather than just grumbling about learning in general. At the moment the things I can't escape even if I try have been plenty to keep my learning skills well-honed. So bear in mind that as you round out your skills, as you cover "scripting" and "static language" and "database" and "HTML" and "devops deploy" and "shell scripting" and "functional programming" and all the other categories you may pick up over time, it is natural and desirable to pivot to exploitation being more of your time than learning. After all... what is all this learning for, if not to exploit the skills to do something, not just learn the next skill, then the next, then the next?

vanjajaja1 1y ago

> I like to say programming is about knowing which rabbit holes to plunge down and which to step over. I like this a lot. I told someone once I avoid documentation like the plague and it just didn't have the same poetic ring as this line. Sometimes you need to dive in, other times you need to hobble together something to step over

PixelForg 1y ago

Thank you for your comment, especially for this > I've written a lot of Rust. I've read less than half of the Rust book. Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part) I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to get comfortable with having gaps and just start writing code and not be afraid of writing non-idiomatic rust code, atleast for now.

maxbond 1y ago
That's awesome, best of luck to you.
ChrisMarshallNY 1y ago
I've -literally- been writing Swift, every day, seven days a week, 52.4 weeks a year, since June 2, 2014 (the day it was announced), yet, I still have huge gaps in my knowledge of the language. I speak it without an accent, but not at Ph.D level. As to home projects, that's pretty much all I do, these days, ever since I "retired"*, in 2017. I'm quite good at what I do, and generally achieve every goal that I set, but, since I'm forced to work alone, the scope needs to be kept humble. I used to work as part of a worldwide team, doing some pretty interesting stuff, on a much larger scale. But what's important to me, is that I do a good job on whatever I do. Everything I write, I ship, support, and document, even if it isn't that impressive. The bringing a project to completion, is a big part of the joy that I get from the work. * Was basically forced into it
- fragmede 1y ago
  Unrelated question since you've got the Swift experience: How would you recommend a modern day Mac utility get sold? Is grabbing some hardware ID of a device and then charging money for a license keys somehow still the way to go for some small utility (eg window management app like Rectangle) if you want to sell to users outside of the Mac app store?
  - ChrisMarshallNY 1y ago
    With Mac, you have choices (as opposed to iOS). There’s licensing libraries that you can use. These can do things like hardware keys. The App Store is very secure, but Apple gets their vig…
speleding 1y ago
Another approach that may help you, that worked for me. I was not familiar with rust so I wrote an initial proof of concept in another language (Go in my case). Then I asked Claude AI to translate it to Rust. It compiled on the first try, the only bugs being problems in the source file I gave it. Then I iterated a bunch of times by saying "please make this more rustacean style". I only tend to use AI for assistance, but for me at least it's easier to get started this way than to start with an empty source file.

jerf 1y ago

I think another important view is to consider how much you've already covered. As a young developer, I recommend spreading a bit wide. Try many technologies. Play with a new language every year. Focus on things you haven't done before, like, don't go from Python to Ruby, go from Python to C# or C++ or something. But as you get older you want to shift from exploration to exploitation. It is hard to make progress on anything, both professionally and personally, if it first comes with another couple of person-weeks of learning something new, let alone person-months. Even though I find learning new things easier than ever because of the breadth of things I have covered, I find myself having to be ever more skeptical of what I will invest in in that way, because unlike a fresh developer with no skills who has little better to do than learn their toolset, I have skills that can be exploited to good effect. As a mature developer, I need to trade off not so much "what might this be useful for in the future versus the effort of learning now" but "what could I be doing right now with the skills I have rather than learning something new". Particularly when the "something new" is a variant of a skill I've already picked up. It'd be great if I never again had to learn a devops deployment system. I've already had to learn three. Unfortunately I doubt I'm going to get away with that. It'd be great if I didn't have to learn another scripting language to do something, but I doubt I'll get away with that either. Your mileage will absolutely vary but it'll be something. I know there's a memeset of the "old fogey who doesn't want to learn", but I really do see the learning costs now as the opportunity cost of using that time to exploit the ones I already have, rather than just grumbling about learning in general. At the moment the things I can't escape even if I try have been plenty to keep my learning skills well-honed. So bear in mind that as you round out your skills, as you cover "scripting" and "static language" and "database" and "HTML" and "devops deploy" and "shell scripting" and "functional programming" and all the other categories you may pick up over time, it is natural and desirable to pivot to exploitation being more of your time than learning. After all... what is all this learning for, if not to exploit the skills to do something, not just learn the next skill, then the next, then the next?