[maxbond]

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

[PixelForg]

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.

[ChrisMarshallNY]

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]

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]

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…

[sanderjd]

By the way, I fear I'm harping on "AI tools can be really useful" here, but I really find that learning new things is my favorite way to use these tools.

You said that you don't want to use them to generate code and just be a reviewer. I definitely feel that! But you can instead use them like a tutor helping you learn to the code yourself. "I'm trying to do xyz in Rust, can you show me a few techniques for that?" Then you can conversationally ask more questions about what's going on. Maybe eventually you can go read relevant sections in the book, but with the concepts better motivated.

I do this all the time when learning new things. It's not a canonical source of information, but it can be a useful guide.

[speleding]

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.

[sanderjd]

Yes! No tool has ever helped me more with the blank page problem.

[dijksterhuis]

> 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.

i was in the same boat. i’d probably gone through the first half of the rust book and made actual hand written notes several times over the last 5 years. started rustlings. started “100 exercises in rust” (can’t remember actual title). never finished them. never felt like i was going to be “ready” to handle rust.

6-9 months ago i had the time to start learning a new language. was between rust or go. decided on rust. avoided it for a month. recently released my first library crate (with another on the way).

my tips/experience

- don’t worry about the borrow checker to start, just be aware it’s a thing. clone() everything if you need to. i had to just get comfortable writing rust code first. “i wrote some rust” was the goal each day. just working on getting it to compile somehow was all that mattered. confidence building is a thing.

- i started with simple CLI binary doing stuff like “package the files in these directories as a release/dev build setup”. basically copy paste /symlink files with clap. simple but useful [0]

- start with an ide that hooks into the compiler and shows you errors. ideally one like theia or rust rover which shows you the documentation of the error when you hover over it. i’ve now switched to nano and compiling manually after like 7 months. i see fewer errors these days and usually i expect some of them.

- keep it simple. don’t worry about being idiomatic. it will come as you read other people’s libraries and code over time. i’m still not there yet.

- if you are really struggling with the compiler just wont let me do this one bloody thing why won’t you let me do it it’s so simple in language X —> you are either fighting against the type system or the borrow checker. pause. take a moment. figure out which. it’s time to figure out what you’re not understanding. accept that you might have to completely change the approach of what you were doing. it’s okay, it’s part of learning.

- i would read all the outputs of `cargo clippy` and change each one by hand. i don’t use `cargo clippy —fix` ever. repetition helps me learn. doing enough boring repetition forced me to remember basic stuff that makes my code more idiomatic. i cannot emphasise how useful this was to make my code more idiomatic up front.

- commit your changes. then use `cargo fmt` and read through the diffs. again, helps to work out what rust code is supposed to look like while writing it (eventually without needing to use `cargo fmt`). i cheated with formatting compared to clippy (see above). it’s just formatting, you can probably rely on cargo fmt and be lazy tbh.

- you don’t have to start your rust journey with hardcore systems/hardware level coding. i felt like i was cheating / doing it wrong because i wasn’t doing that. but a lot of crates are nothing to do with systems level stuff. just because it’s a systems programming language doesn’t mean you have to be that hardcore to start with. see 2nd bullet point.

- generics might be my favourite thing about rust. realising how they work and how to apply them blew my mind. once i had that ‘mind blown’ moment with something — i was hooked. i don’t wanna go back to python now!

[0]: i need to change perms. apparently i set code viewing to private somehow? wtff. https://gitlab.com/dijksterhuis-arma3/vn-mf-builder

[PixelForg]

Thank you so much for your comment! You've addressed a lot of issues I was having, each point is gold, I have no more excuses, I can simply start writing the code.

[maxbond]

That's awesome, best of luck to you.

[vanjajaja1]

> 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

[jerf]

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?