SHAM (the Self-Help and Actualization Movement) takes advantage by cleverly marketing the dualism of victimization and empowerment. Like a religion that defines people as inherently sinful so that they require forgiveness (provided exclusively by that religion), SHAM gurus insist that we are all victims of our demonic “inner children” who are produced by traumatic pasts that create negative “tapes” that replay over and over in our minds. Redemption comes through empowering yourself with new “life scripts,” supplied by the masters themselves, for prices that range from $500 one-day workshops to Robbins’s $5,995 “Date with Destiny” seminar.
[…] if you asked random people on the street if they’d like to be able to draw like Leonardo, you’d find most would say something like “Oh, I can’t draw.” This is more a statement of intention than fact; it means, I’m not going to try. Because the fact is, if you took a random person off the street and somehow got them to work as hard as they possibly could at drawing for the next twenty years, they’d get surprisingly far. But it would require a great moral effort; it would mean staring failure in the eye every day for years. And so to protect themselves people say “I can’t.
I have come to accept that I’m really not smart. I’m slow, forgetful, concepts never seem to stick, I have to force myself to not take things for granted.
Congratulations! You have just discovered that you have an asset! Forgetfulness, an awareness of one’s limitations and an understanding that learning can be challenging are all things that actual newbs are not aware of. You no longer suffer from hubris.
Your newfound recognition of your limitations is the foundation upon which you must build and shore up a structure for acquiring new knowledge, outlining plans which recognize your limitations and executing these plans in a predictable manner.
These problems are the same problems that most programmers (hell, most people) face. This is what the life-hacking movement is about. It is about understanding that we are all human, and that improvement in our lives requires recognition of our weaknesses.
If something is not working for you, what you should do is look for alternative methods to achieve your goal. If you do not absorb knowledge through reading books or theories, perhaps reading code would be better for you, or perhaps you are a social learner and need to talk to other programmers about what it is that they do.
Remember that every challenge is an opportunity. There are even people who have turned their quests for self improvement into niches and businesses in their own right. If you see something that doesn’t make sense to you, it may not make sense to other people. If you find a way to make a task easier, others might find it useful too.
I hit the point you’re at about 5 years ago. I’m beginning to feel competent and trust my ability to build things. There’s a lot more that i want to learn and become better at. It’s a long process, but many have tread the path before you, and many will follow in your steps.
This is one of the few comment threads on Hacker News worth reading. We’ve all had these moments in our career—where we feel stupid, slow and like this isn’t the career for us. If you’re feeling this way, read through it. If you aren’t, skim for reminders of why we do what we do and why we help other people in need.
I honestly don’t know what works for others. The act of writing, like any art, defies description. Some of the best advice I’ve seen regarding how to write essays is from Paul Graham. He says writing is thinking, and, insightfully, that writing forces you to think better. He wrote, “Just as inviting people over forces you to clean up your apartment, writing something that other people will read forces you to think well.”
My other suggestion (also, I think, stolen from Graham) is to concentrate on writing things with lasting value. I’m not sure I’ve been doing a good job of this at all lately — I think too much of what I write currently at DF is about stuff that’s only relevant right now. I’m certain that what helped me make a name for myself, what built the DF readership, were the long pieces I did in the first few years, most of which are still relevant, or at least still interesting.
There are a lot of people writing for the web today; but there aren’t that many at all who are trying to do great writing for the web.
Seeking advice is addicting and can become a proxy for action. […] Be suspicious of lists, advice, and lists of advice.
That comes from someone I highly respect and is a great suggestion for people who are stuck on self-help books and list posts. I’ve been hearing this pretty loud and clear for the past six months from a couple of people and yet, I’ve ignored it. Book purchase after book purchase, I’ve accumulated a library that would make anyone anxious.
What I’ve been recognizing lately is that all of these books are causing me to lose things that I hold very dearly: time, sanity and common sense. My wife suggested that maybe by reading all of the time, I’ve trained my brain to stop bothering with thought and simply go to the instructions it’s been taught. While I have no clue if that’s what’s actually happening, it certainly feels like what might be happening.
It’s with all that in mind that I resolved not to buy a book for the rest of the year. Even with this resolution, I still have too many books to read this year.
This resolution is also borne out of the desire to increase the depth with which I read. I want to truly know what a book says, instead of having a table-of-contents-depth-of-knowledge after reading a book. And having all of these books feels like a crushing weight: when I read, I read to finish the book as quickly as possible, not so I can enjoy and learn from it.
One part of me worries that this resolution will harm me in the long run, yet I got along just fine before I had all of these books and I’m sure I’ll be just fine after I get rid of some of them. Another part of me worries that this is wasteful, that since I have all of these books I should just read them. But, that attitude is what got me here in the first place.
I’m learning, rather forcibly I suppose, to be okay with things taking time. I’m also learning that often you end up with a better product when you take your time to get all the big and small details just right. It’s time well-spent.
American culture at large is no stranger to a Puritan work ethic, and that labor fanaticism is magnified all the more so in the startup “community” through legends of all-nighters and weeks spent sleeping under desks. Get over the guilt and bullshit, and realize that you’ll be happier, healthier, and more productive if you manage work time on your terms.
Interestingly, these results suggest that although almost everyone has problems with procrastination, those who recognize and admit their weakness are in a better position to utilize available tools for precommitment and by doing so, help themselves overcome it.
Head down, fingers tapping and teeth gnashing, that’s how you’d find me if I was working on someone else’s code. I want to rewrite it. I mean, it’s awful just look at it. There are no comments and there are ternary operators where they shouldn’t be and they aren’t used where they should be. And to make it all worse, the code is littered with tons of inane variables like temp and iter.
At some point in every programmer’s rich and illustrious career, we find ourselves in someone else’s code. And, inevitably, we start finding problems, things we would never have done. Ever. However, if you took one look at your code from a year ago, I’d bet you’d start finding problems too. So why, then, do we think that someone else’s code is awful and only worthy of a rewrite? Because understanding other people is hard.
The act of reading someone else’s code is hard, slogging through classes, methods and variables to try and understand what they were thinking. But that takes time, time I don’t believe I have. This needs to be finished this week and if I start rewriting it now, I might have time to finish it, but given my track record of estimation, probably not. But how long would it take if I took the time to understand what was happening in the code? What would it take to document it such that I understand the names and the flow? Realistically? Not that long, and it would save me from rewriting code that—for the most part—works.
Additionally, taking the time to understand what someone else was thinking could result in the ‘why’. That ‘why’ pushes you from just knowing what the code does to understanding it almost as well as the original programmer did. Sure, you aren’t them, you don’t think the same and it’s a different time and place, but this new viewpoint can answer why they used a ternary when they did and why that variable’s name is what it is. With that understanding, it’s no longer someone else’s code, it’s now our code. And the more code you read, the more understanding you gather. With that understanding you now see a whole slew of solutions when your next problem comes up.
So how often do you work with someone else’s code? I work with it on a weekly basis. Yes, it’s usually from a co-worker and because I’ve read their code a few times I’m starting to understand how they think. But even if it wasn’t, it’s not really that bad. It might seem like an interruption in productive work, but reading someone else’s code could be far more useful for the amount of time you put into it. Think about it, you’re gathering some of the understanding that it took to originally write the code in far less time than it took to write it. If that’s not productive, I don’t know what is.
Achieving expertise and doing creative work is all horribly complicated and difficult and paradoxical and frustrating and recursive and James Joyce-y—and any guide, blog, binary, guru, or “nice guy” that tries to suggest otherwise is probably giving you a complimentary colonoscopy.
Seeking advice is addicting and can become a proxy for action. Giving it can also be addicting in a potentially pretentious, soul-rotting sort of way, and can replace experimenting because you think you know how things work. Be suspicious of lists, advice, and lists of advice.
Your code will always be a mess. You will have learned a lot. It will never be perfect. And if you start all over, you’ll find yourself in the exact same situation when you get to this point again. It’s a terrible trap to think like this.
Stop looking for recipes about how to optimize your workflow. You want it? Get rid of stupid fluff, and do things that matter. Do one thing at a time. Work like your grandpa did. Yeah, the world is different now, but humans have always had to make decisions about where to put their attention. We’ve just lost our spine.