thanks man.

started my first internship at big corpo. small team though ~10 people including interns. incredibly chill. given a straight forward proj, yet feel like i’ve been iterating and researching too slow.

kinda trying to trade speed for understanding. if a library promises to do x, ill use it for x and not look at how it works. though I shouldnt do this.

though, when faced with just not knowing how to do stuff I spin too fast in direction of searching for specific soln on copilot/stackoverflow instead of trying to understand the tools i have well.

feels like as a good engineer it should be i have these tools i know what it does and how and i can leverage to solve this problem. not i have this specific problem, time for me to search inter webs for the answer then spend time fixing the inter webs answer.

just hard to justify the tradeoff when working on projs that aren’t entirely relevant to my interests.

those are my thoughts rn. thanks for prompting me I admire how open you are to helping others!

being slow at both iterating and researching is ok – it’s almost expected, you’re just starting out dawg! you’ll need plenty of reps to develop your intuition and be able to just “feel” what to look at, what not to look at, what to try and not to try

re: speed vs understanding, I’d say it depends so much on your internship – if you ask your supervisor what is preferred (you can be very candid), and he says he does not mind you taking time to truly understand, that changes the game quite a bit. It’s always a fine balance to keep either way, because if you max out on understanding, you’ll enter endless rabbit holes.

re: libraries, it’s not the worst thing in the world to blackbox at first. Again, your sense of when to do that and the implied tradeoff will get better over time. But if the supervisor is OK with you taking more time, taking the time to slow down, going thru the method implementations, mapping out the library’s core code paths that you are likely to use, etc… can never be a bad idea. Same with the codebase you’re working in tbh – it’s a firehose of stuff and you gotta treat your brain like an LLM in need of data so you can backpropagate and adjust, that’ll just happen naturally.

re: good engineers need to have these tools, you’re right, but also, you’re starting out and knowledge/intuitions != the quality of the engineer, just how tenured he is. As long as you’re systematically trying to self-improve, and/or making sure to not always take the shortest path (without getting bogged down in infinite tangents) so you can explore and take in new data to update your priors, you’ll be getting better continuously

re: tradeoff + not relevant to interests, unfortunately it’s likely that at the beginning of your career you’ll be working on things that arent 100% a match to your interests. I think a good approach is to turn into a game – min-max the domain as hard as you can overtime, take pleasure in the grind, so that you are so comfortable you can afford to take detours that are closer to your interests (esp through relationships in your team, and being able to attach to things you would enjoy more – easier once you’ve min-maxed the initial, less interesting stuff)