231–240 of 249 posts
Earlier quoted context omitted.
Where are you making $200k+ with limited experience and do you need a senior partner? :-D
6 years is sufficient experience, and we're good, thanks!
Earlier quoted context omitted.
6 years is sufficient experience, and we're good, thanks!
It’s enough to do well, but certain we all grow for quite a while after that. The improvement typically springs from discipline at that point rather than calculative ability however.
I've seen interns that are better than some of my 15+ year colleagues.
I'm better than most of them myself, but I've also seen interns better than me -- better problem solving skills and attention to detail I suppose. Very inconsistent correlation in terms of time spent outside of filtering people. Of course, you used to have a knowledge advantage that would hold for a bit, but intelligent usage of GPT-4 removes even that.
I'm pretty sure the whole enterprise is a combination of being gifted intellectually, with maybe a sprinkle of actual effort and abilify to sustain your attention on supremely boring tasks -- but mostly just your innate gifts at work.
When I say "better than"... well, here's my opinion: In programming, someone more talented can be up to 10x more productive at each tier of competence, shall we say. My least productive (senior and junior) colleagues are 10-100x less productive than me. My most productive colleagues (senior and junior) are probably 10x more productive than me.
This is an interesting discussion to me because I used to believe the whole tiered conception of programming knowledge until I learned that this wasn't the case through experience.
It's all just problem solving, and you're either smarter or less smart and you can't change this with even 1000 years of study.
Earlier quoted context omitted.
It’s enough to do well, but certain we all grow for quite a while after that. The improvement typically springs from discipline at that point rather than calculative ability however.
I'm not entirely convinced. I've seen interns that are better than some of my 15+ year colleagues. I'm better than most of them myself, but I've also seen interns better than me -- better problem solving skills and attention to detail I suppose. Very inconsistent correlation in terms of time spent outside of filtering people. Of course, you used to have a knowledge advantage that would hold for a bit, but intelligent…
Knowing what rabbit holes not to go down is the true 10x. Not the faster typing part.
Earlier quoted context omitted.
I'm not entirely convinced. I've seen interns that are better than some of my 15+ year colleagues. I'm better than most of them myself, but I've also seen interns better than me -- better problem solving skills and attention to detail I suppose. Very inconsistent correlation in terms of time spent outside of filtering people. Of course, you used to have a knowledge advantage that would hold for a bit, but intelligent…
You’re comparing with others, however I meant compared with yourself. I look at my Uni code and see a quantum leap from that to now. Some of it is better tooling but a significant part is discipline and experience. Knowing what rabbit holes not to go down is the true 10x. Not the faster typing part.
That kid that blows you away will likely stagnate like all of us, he might pick up a few tricks, though.
Earlier quoted context omitted.
You’re comparing with others, however I meant compared with yourself. I look at my Uni code and see a quantum leap from that to now. Some of it is better tooling but a significant part is discipline and experience. Knowing what rabbit holes not to go down is the true 10x. Not the faster typing part.
In the job market, it's all about how you stack up to other people. That kid that blows you away will likely stagnate like all of us, he might pick up a few tricks, though.
Also, if one hasn’t read the historical literature such as Petzold’s Code, Mythical Man Month, High Output Management, McConnell *, etc they have a long way to go. No amount of bit-twiddling proficiency can make up for that. Unless you’re in the twiddling business. :-D
Earlier quoted context omitted.
In the job market, it's all about how you stack up to other people. That kid that blows you away will likely stagnate like all of us, he might pick up a few tricks, though.
I’ve never met a kid that blew me away, but would like to. Presumably they are shuttled off to an underground bunker somewhere. Also, if one hasn’t read the historical literature such as Petzold’s Code, Mythical Man Month, High Output Management, McConnell *, etc they have a long way to go. No amount of bit-twiddling proficiency can make up for that. Unless you’re in the twiddling business. :-D
Making things seems to do the trick there.
Earlier quoted context omitted.
I’ve never met a kid that blew me away, but would like to. Presumably they are shuttled off to an underground bunker somewhere. Also, if one hasn’t read the historical literature such as Petzold’s Code, Mythical Man Month, High Output Management, McConnell *, etc they have a long way to go. No amount of bit-twiddling proficiency can make up for that. Unless you’re in the twiddling business. :-D
I don't really think reading books is the way to go generally to improve at the job of making things, at least, not any of those books. Making things seems to do the trick there.
Earlier quoted context omitted.
I read about fifty books a year for a decade now. Only about four of them per year, are programming books. They are indeed to be read very differently. Here's how I read them, ymmv. - never in bed. never as audiobook. But sitting. At a table or desk. - no distractions. At most "focus music". - read a chapter through. Then read it again and do all excercises (on a computer without wifi) - make copious notes, highlight…
That's all good advice. You should definitely not read programming books like normal books. But I'll extend it somewhat: ~ Yes, always do all the exercises. It's important how you do them. No copypasting. Enter all the code examples in your text editor of choice and run them if possible. Experiment liberally and don't be afraid of errors; instead, adjust the program in response to the errors. Create a directory and s…
When you say "don't overwrite", di you mean to start from scratch every chapter? I can imagine this would work for me: repetition is key. But also to get frustratingly boring after a few chapters.
I'll just treat is as any trunk based git repo. Commit significant progress, several times per hour. Then rebase to "summarize" my learnings into a history. I'll commit them to a public repo and treat as if that annoying colleague is going to review. Not that anyone will ever read them. I probably won't myself. But the art of rebasing, amending and pulling apart helps me with what would have been the perfect eLearning history.
Earlier quoted context omitted.
As mentioned, I have ADHD. Which means I cannot handle distractions. So I try to uses processes and tools to manage distractions as much as possible for me. But I guess a neurotypical zoomer can code fine with a TV in the background, a podcast in one ear, insta and DMs ploinging into their notifications and slack nagging in the status bar. I cannot.
Do you keep some notes on the books you read? (I mean online notes here; but if you don’t keep them online, while maintaining the notes, the question is still valid. Maybe you have some system that works for you and you want to share.)
Also. Notes have always been a mess. I note a lot with pen and paper. Most even. I have piles of random paper. Pen drives with markdown. And large gaps.
If anything, adhd is terrible for consistency in this kind of stuff. Which is why I go full on plain text formats. Any binary, SQLite, cloud whatevs will rot within weeks after me loosing interst. Yet my diary.md and my bookkeeping.ledger, albeit gapped with years, still goes strong.
Earlier quoted context omitted.
Are you reading programming books the same way you would read a fiction book? If so, stop doing that. Programming or any technical learning is a hands on experience. Take notes and apply techniques, using pen-and-paper or the keyboard, as they are presented. If you really have to just "read" a technical book, IME a less-is-more approach works best. 5-10 minutes at a time, not even a chapter at once. Maybe a few parag…
I read about fifty books a year for a decade now. Only about four of them per year, are programming books. They are indeed to be read very differently. Here's how I read them, ymmv. - never in bed. never as audiobook. But sitting. At a table or desk. - no distractions. At most "focus music". - read a chapter through. Then read it again and do all excercises (on a computer without wifi) - make copious notes, highlight…
In bed, phone out of reach and reading one hour, sleeping half an hour was super efficient for me. You only process material while sleeping anyway.