FWIW, I'm 40 and have been programming professionally for 15 years, and programming as a hobby for probably 8 years before that.

I still run across stuff I don't understand, all the time.

And I'm not one of those people who have "1 year of experience 15 times" instead of "15 years of experience". I'm pretty aggressive about learning new stuff and expanding my horizons. And yet the pace of change is so fast, there's always new stuff coming out, or areas of tech I'm discovering for the first time.

The moral of this little diatribe? Don't sweat it. Be curious, explore, learn, hack, and don't worry too much about comparing yourself to others. And don't assume everybody on HN is some uber-genius, super-brilliant "10x" programmer. I mean, sure, there probably are people like that here, but I'm pretty sure they are a small minority.

For another take, you might find esr's "How to become a hacker" essay useful:

http://www.catb.org/esr/faqs/hacker-howto.html

Other than that, my only advice would be to start a project (open-source or not, whatever you think) that gives you a venue to challenge yourself. That is, start a project that you don't believe you're really competent to complete, and then go do it.

Also, "read a lot".

Something to note on thinking everybody is a super-brilliant "10x" programmer: You're not seeing the same people post deep, insightful things here on HN. There are people who know a lot about this one thing, and can write very accurately and intelligently about it, but don't know anything about HTML or desktop programming (C, C++, others), server-side logic, etc.

The same goes for each of those fields, and every other field--there are certain people who know a lot about them, and when the topic comes up they talk about them. The reason it seems like there are a bunch of super-brilliant "10x" programmers is that there are many, many of these specialized people on HN and around the web, and at least a few of them always have something to say about a topic. It doesn't mean they're all super-brilliant "10x" programmers.

"10x" is one of the more destructive memes going around. It's a subtle shift in the discussion from talking about technique and actual work, to talking about something which is being used as a proxy for "your worth as a human being".

The only work which matters is the work which gets done. You can accomplish a lot by simply doing the things that need doing. Bad code gets written and all that.

10x isn't just a meme going around ... It's even referenced in "The Mythical Man month". If you're a "productive programmer" you should never have a problem finding employment but what "productive means depends on the context. Does NASA want code quickly or do they want well thought-out and thoroughly tested code? With Etsy's DevOps infrastructure, they're pretty confident deploying several times a day.

True. In fact it's quite likely when you read a comment about some Foo technology, that Foo's creator or someone on the original Foo development team was its author. I'd say it's unlikely that four years of programming Python will make you as much of an expert as this guy http://stackoverflow.com/users/818274/guido-van-rossum?tab=a... Yes, I should hope Guido Von Rossum's answers to Python questions make him seem like a 10x guy!

Wonderful response, thanks. I have attempted a handful of open source utilities and none of them ever received any activity from others at all. I would love to maintain a project or just work with others in general since I'm working in isolated 'for myself' territory.

So then you have a networking issue too then. The people kind, not the computer kind.

To bridge that gap, you might want to see if there are tech Meetups in your area. In NJ where I am, there are two extremely active groups that throw together entrepreneurs, investors, devs and developers a few times a month for very low cost. Establish who you are, and get assistance from others, advice sharing, make new contacts, find out where the industry is going, etc.. Normally you walk out of the meetings on a better career path than when you entered.

What are these utilities and how would I find them? It might be worth investing in some SEO experimentation to make sure you're stuff's actually findable by those who'd be interested.

I have little to add. This (parent post) more or less covers it.

I will give you slightly different advice than most people here (that advice being "just keep programming, and experience will come on its own). First, figure out what it means to actually be a good programmer. For example, do you want to be a JavaScript ninja? Or do you want to know everything there is to know about how your OS works? Or do you want to be able to put together a mobile app that is cleanly architected and maintainable all by yourself? Or do you want to be a full stack developer, able to develop a backend service and a front-end UI all at the same time? Or do you want to be a good computer scientist and solve theoretical CS problems and reason about complex algorithms?

Once you have picked your definition of "good programmer" (your goal), write out a map of stuff you do and do not know. For example, I am a full stack developer, but I don't yet know CoffeeScript. It would probably be a good addition to my toolset as I do a fair amount of JavaScript programming for the frontend. Having this map will help you fill in the blanks of technologies and concepts you are missing. Take your time and learn these slowly, usually as a part of a project, and not just an exercise. As you learn, adjust your map. You will inevitably come across stuff you did not know existed or was important.

Remember, it's easy to run in many directions at once with this approach. Don't do that. If you already know Ruby, don't go learning Python (and vice versa). They fulfill a very similar role. Instead go learn how HTTP works. Or how to work with a different data store you haven't used before. Or how to use a frontend JavaScript framework. Or go learn C.

Here's my recommendation learning technologies to become a full stack developer (in order, when starting from scratch): HTML/CSS, Python, Django, PostgreSQL, JavaScript + jQuery, AngularJS, HTTP, networks/socket programming, C + data structures and basic algorithms, functioning of operating systems (libraries vs syscalls, toy operating systems), compilers (build a toy one), Lisp, Haskell, Erlang, networking again but this time thinking about distributed systems.

Good luck!

Great response Igor. This is pretty much how i try to stay up to date. The thing i find frustrating is when you finally become really good at technology often there is already a new out there which you are totally clueless in and feel like you are back to being a junior. Being a programmer for an average intelligent person feels like you are constantly chasing your own tail...

I hear you. There will always be new and exciting technologies that will be developed that will supersede what you've been using. However, remember that not every technology is going to "stick". Instead of trying to chase down the latest and greatest, try to evaluate whether it's an actual improvement over how you've been doing things. For example, I recently learned Angular. It is a great framework and I like how it works. A competing framework, KnockoutJS, is not as good. I learned just enough of it to see that it's not an improvement.

Basically, focus on getting things done and building things. If a part of what you are building seems like too much work, someone probably has already built a solution for that. Otherwise, don't worry about using the absolute cutting edge stuff. At one point there was a tongue in cheek saying that "it would take more time to evaluate the popular JavaScript frameworks than to write a new one" (or some such). It still holds today, so don't sweat the name of the tech and stick to the stuff that you can be productive with.

Like everyone else here? I hate to burst your bubble but the vast majority of the programmers here are not nearly even close to as good as you think they are. Mostly they're good at talking like they are and memorizing obscure facts about computer science. The reality is that everyone who codes pretty much sucks at it or they get lucky a couple times and do something significant.

The same goes for painters, musicians, poets, writers, anyone that you think is "good" is actually just someone who found their thing and hammered the hell out of it until they squeezed out a handful of really good works if they're lucky. What you don't see is the massive pile of absolute garbage most of these people produce and keep from the public's eye. I think the defining characteristic of someone who's actually good at a creative activity is whether they can admit this and get past it as just part of creating.

So, instead of saying how can you be like all of these guys, how about how can you just improve your own skills? Since everyone sucks at this to some degree or another, all that really matters is how you improve what you do and get better at it. Ultimately, that just takes hard work, study, and trying to find any tricks and hacks that are being kept from you.

As an example, I'm teaching myself to paint and I suck at it, but I don't give a shit if I suck at it, I enjoy it. So for the last almost month I have been painting the walls of a box over and over again until I learn how to do it right. It's fun, I like it, and I don't care if other people are better at it than me because I'm finding my thing and I keep improving because I keep working at it and failing until I get it right.

This surely depends on your own personal definition of good.

It's useful to have a definition of good that allows people to feel confident about their experience and good about themselves because feeling this way helps to engage them further in the practice.

What you actually just did was entered a group conversation to tell almost everybody there that they are bad programmers before doing a humility display for everybody to see.

When I think of the steady progression from apprentice to journeyman to master, I feel that what is good is the progression, and what is bad is anything that stops the progression: lack of confidence, over-confidence, or the kind of severe lack of ability that causes people to be rejected from a market before they are ready to compete in it.

I've gotten the feeling that you are quite confident so while it's great that you are dialling back any arrogance and concentrating on continuing to learn I wouldn't say that it's necessarily healthy for everybody in tech to raise what they consider "good" to be top-1% of Google R&D as this could just serve to stop them from even trying.

"What you actually just did was entered a group conversation to tell almost everybody there that they are bad programmers before doing a humility display for everybody to see."

No, I was talking to the person who asked the question, not you, so I didn't "enter a group conversation". Yes, I did say most programmers are bad programmers because that's definitely the case, and that's the case in every single creative or technical discipline humans do. To say otherwise is nothing but pandering to the people posting here and does nothing to improve the education of people trying to learn.

What does improve their education is to show the reality of programming, which is that it's hard and most everyone sucks at it, but that you can improve, and that's why it's also fun to do. This is only a demoralizing belief if you're arrogant enough to think that you're better than everyone else. Real practitioners admit that they're barely capable most of the time and accept that they have to work hard to achieve their goals.

> No, I was talking to the person who asked the question, not you, so I didn't "enter a group conversation".

I am not a group actually so I certainly didn't just imply you were talking to me.

Additionally, this a threaded discussion board in which you are involved in a group conversation. There was already a group conversation when you joined so I think arguing that your post should be perceived as a one-to-one communication on a many-to-many platform is a bit rich.

> Yes, I did say most programmers are bad programmers because that's definitely the case, and that's the case in every single creative or technical discipline humans do.

The terms good and bad are subjective and we attach our own values to them when we use them. It is not definitely the case that almost everybody has been bad at technical disciplines unless you believe that your understanding of the boundaries between good and bad is better than everybody else's and subscribe to the utilitarian belief that there is more upside to using the term 'bad' to negatively reinforce bad work and lower people's self-esteem than to use the term good to raise people's self-esteem and positively reinforce their good work.

> To say otherwise is nothing but pandering to the people posting here and does nothing to improve the education of people trying to learn.

How certain of this are you? Have you heard of the terms "fixed mindset" and "growth mindset", did you read and disagree with the studies which show that many people exit from domains that they believe they are bad in (STEM, etc.)? Does your philosophy deny the benefits that come from the tendency towards competitive behaviour that confidence gives people?

> This is only a demoralizing belief if you're arrogant enough to think that you're better than everyone else. Real practitioners admit that they're barely capable most of the time and accept that they have to work hard to achieve their goals.

I thought it was common wisdom was that it was demoralising for most to feel that you they are bad at something.

Your description of "real practitioner" as an exclusive category of "realness" with membership rules set by yourself that by a strange coincidence also contains yourself is really funny by the way.

In reality, there are good engineers that consider themselves bad [0], average engineers that are poor, bad engineers that consider themselves average, etc. There are people that strive harder the worse they feel, there are people that strive harder the more their ego is stroked. There are great engineers that think they're barely capable of the work they do, and there are great engineers that think they are god's gift to technology. There are people that are attracted to work in which they are out-of-their-depth, as well as people that are driven away by the fear of failure.

It's really hard to say anything with certainty but I know I've met most of these people and I don't feel there's any piece of advice that works for everybody - my intuition was just that the guy at the top seemed like he needed his self-esteem raised not lowered to help with his learning. (For the record, I only responded to you directly because I felt you were contemptuous towards the arrogance of other engineers while also having decided you would be the sole objective judge of what it means to be a "real practitioner.")

[0] There are engineers working in extremely competitive work environments that contain only the top-10% of their domain and they will often forget this when they evaluate themselves. Valuing your status locally is easy, globally it is hard! Best view for me has just been: I am good at learning, I like that I try hard, I have mixed abilities but as long as I'm able to positively contribute I do not need to worry.

I'd add that blogging about programming experiences can help a lot. Because you have to formulate your thoughts and you need to do some background check before writing, the concepts are better represented in your mind than if you'd only read about it.

Writing is a very different process than reading. You start making connection between ideas and concepts when you write about them. And that's a process that makes you absorb more knowledge than you would normally absorb by only reading.

In this sense - continuously be building things. Repetition and practice are what lead to progress and mastery. However, it is not a plateau - progress requires slow growth.

I think this is the biggest thing beginners try to avoid. Especially if they're ambitious and want to be capable now.

I'm currently at the theory of becoming capable is a mixture of study, practice, and hacks. You study the things necessary, then you practice them producing results to evaluate, and then you find hacks that amplify your efforts. But, I have zero research to back this and it's just what I try to do.

i've been playing guitar for 25 years and I still am not SRV, but i do have a few good chops. I've been coding for about 8 years, and if I compared it to guitar playing, it's like playing an arpeggio, so many ways and so easy to fuck up.. but fun as hell to play!

simple answer, a lot of heroin.

If you'll allow me the arrogance of saying that I'm pretty good in my genres (web-app, mobile, and I'm starting to come into my own in game programming but really I have a shit-ton to learn in these fields I know enough to sound smart but I'm FAR from a genius), I'll say that most of what you are seeing is a bunch of subject matter experts answering questions. For example I might be able to tell you the in depth ins and outs of using RabbitMQ as a messaging queue for async processing in a web application but I know next to nothing about how to write an audio driver for Linux, or the math principles behind the best cryptography algorithms. So to answer your question I'd need to rephrase it a bit and say how do I become really good at a subject. Here's what I did: - I have 15 years of professional experience, sorry I don't think there is any shortcut on this one. 15 years teaches you things and processes that you will never learn in 2. THIS DOES NOT MEAN that all programmers with 15 years are better than anyone less experienced just that there certain things that the years drill into your head that's impossible to give to someone with less experience. - I read A LOT. Like 3-4 technical books a month. Immersing myself in the my area of study helps my think naturally in those techs. - I write a lot of experimental code. - I go to meetups and talk to other good developers - I constantly try to learn something that I think is over my head.

Never stop learning and never stop pushing yourself. I'm driven to know everything I possibly can about my areas.

>I read A LOT. Like 3-4 technical books a month

Could you please elaborate on this? As in, what kind of books do you look for? I have developed this feeling that focussed blog posts by experienced programmers teaches more than books. Also, there are way too many self published authors out there. I know it's a good thing in a way but with so many books, it gets tough to figure out which ones are worth your time. In other words, I'm looking for an example like "I wanted to learn x, so looked up and read y". Thanks.

Sure, I tend to target books I see mentioned on twitter. Then I also tend to stick to books by O'Reilly, Pragmatic Programmers, and Manning. I've found there quality of books to be much higher in general to others. Then I tend to try and find books that are written by a blog author or the library/open source project that I like. For instance Chas Emerick is pretty well know in the Clojure circles, has a good blog and a good twitter account, he has also written a book on Clojure for O'reilly so I picked it up. Then I've seen the PragPub book about Web Development in Clojure and I've seen at least 3 other people on twitter mention it positively so that was book number 2 for that month. For number three I took a chance and picked up a self published book, Functional Programming for the Object Oriented Programmer because it covered Clojure and I'm mostly an OO Programmer so it completed my deep dive into Clojure for that month. I don't always dive so deep on a subject but last month was my learn Clojure month :).

After my first quarter of procedural C++ in college, I thought I knew so much about programming. I was, obviously, under the influence of the Dunning-Kruger effect at the time (in other words, I was a clueless n00b).

Thirteen years later, I know vastly more than I did then. I've worked with a wide variety of languages, applications, and frameworks. I've spent untold hours reading blog posts, articles, code, and Reddit/HN discussions. Today, I still feel like I know a pretty good amount about programming, except now I also know (and accept) that there's effectively an infinite amount of possible programming-related knowledge out there, and I will only ever know a fraction of it.

Like you, I routinely see articles posted that make me once again feel clueless and inexperienced (such as raganwald's recent post on JS multiple dispatch, or anything involving Haskell / Lisp / assembly / cryptography). I sometimes worry about dealing with technical interviews if I ever move on from my current job. Ultimately, though, I know that I can get stuff done, and that while there's lots I don't know, I have the ability to research and learn.

The other posts give some pretty good advice. For me, it comes down to:

1) Learn by doing. No better incentive to learn how to do something than when you need that to make a project work right.

2) Keep reading technical discussions on sites like Reddit, HN, and tech blogs

3) Never be afraid to say "I don't know", and go research the subject.

Realize that programming is an incredibly broad field, so you're absolutely guaranteed to run into many areas in which you have no experience yet others have achieved expert status. Feeling inadequate is normal. As mindcrime said, don't sweat it. Nobody knows everything about every area of programming.

IMO you should decide what you want to do in more concrete terms. Being a "good" programmer can mean a lot of things. Do you want to become an expert in some specific area of computer science, i.e. machine learning? Do you want to design your own language? Or an OS? Or your own framework? Do you want to be the ideal super-productive jack-of-all-trades startup first-hire/tech founder? Do you want to strive for the broad knowledge, wealth of experience, and leadership + mentorship abilities of an effective CTO? The list goes on.

You can't have it all. Pick one, or pick a few. Then spend years challenging yourself, ideally working on real projects that are meaningful to you, alongside other great programmers who give you something to aspire to.

> like everyone else here

You need to realize that there are a lot of people commenting on hacker news (or for instance Stack Overflow). On any given topic, specialists of that field will show up and share their insight. For instance, on an article on technology X, it's not uncommon that someone that helped developing X shows up.

You also need to remember it's not the same person that knows everything :) it may be the case for instance that the distributed algorithms expert is clueless about PHP for instance.

Exactly what I wanted to say. It's a bit like Facebook where everyone seems like they've got more interesting lives than yours - but that's just people cherry-picking the interesting bits of their lives and putting that on display.

I used to feel inexperienced and self-conscious until I started looking through the code of open source projects I use, seeing sloppy and sub-optimal code. We're all human, and we can always improve.

I noticed that when at work, I usually end up doing one of the following three things:

  1. Explain things - either to my co-workers or to the computer.
  2. Explore - navigate the codebase figuring out how different pieces connect to each other, building an adequate mental model of the system.
  3. Debug - search for the root cause of a problem by examining the state of a system in between steps.

Sometimes my mental model ends up being insufficient and I have to do 2 and 3 together to "update" it.

Thus, I think that to become a better programmer, you need to get better at these three things.

"Explanation", I think, is the most difficult one. I have found that studying math has improved my explanation skills dramatically, and it helps not only when talking to computers, but also when talking to people. Of course, not everyone has the opportunity or desire to study things like calculus or differential equations, but I think that reading computer science books is a nice way to exercise that math/logic muscle.

To get better at things like debugging, I had to tear down some mental barriers. Sometimes you'll have to go out of your comfort zone. Never think "oh, this is too hard for me". For example, if you're writing something in Python, you must be mentally prepared to dive into the internals of a 3rd party C module. The key is to approach it with a "we must get to the bottom of this!" mentality.

Don't worry too much about technology. Your "goodness" as a programmer isn't defined by how many languages you know. It's better to know a few very different languages than a lot of similar ones. For example, I think that knowing Java and Lisp is better than knowing Java and C#, because you can quickly pick up C# using your previous knowledge of Java, but knowing Lisp may teach you something you wouldn't know if you decided to stick only to enterprisey languages that give you higher employability.

> 1. Explain things - either to my co-workers or to the computer.

That is SO true. Explaining things to others is a great way to make sure you really understand something. Hence the old saying "to truly understand something, you must teach it".

I'm ashamed to have forgotten to include this point in my response, but I think people looking to learn new things should make it a point to look for opportunities to teach / lecture / explain / whatever, as much as they can. What has worked well for me is volunteering to present at the local Linux User's Group or Java User's Group or something like that. It forces you to really do a deep dive into a very focused area for a while, to make sure you can do it justice.

Do you feel like your skills are steadily improving? Do you critically examine your code from a year ago, and have the urge to rewrite it because you could now do better? When you're coding, do you think "What's the best possible way to do this," instead of just "How can I get this code to run?"

If you answered yes to all of the above, then you're probably already a "good" programmer, and you'll only get better. If not, then let's maybe discuss why not. E.g. is there something about your job that's getting in the way of you improving as a coder?

I think there may be a mixture since your question:

> When you're coding, do you think "What's the best possible way to do this," instead of just "How can I get this code to run?"

I do both. Mostly begin with phase 2 (mentally) and then go back and look at the 'best way' and design schema and business objects around that. I end up making a lot of sacrifices and doing things that are probably not optimal due to what I think is poor real world experience and experience working with other, more seasoned developers. My knowledge of design patterns is fairly limited and I tend to churn out projects that work, are fairly reasonable but yet I think they lack the elegance of many of the open source projects or example githubs I've seen.

Oh yeah, absolutely! I didn't mean to imply you should never ask "How can I get this code to run." I meant that you shouldn't stop there. And it sounds like you're not stopping there.

> My knowledge of design patterns is fairly limited

I'd recommend reading articles and books on that. And also reading open-source code. The latter can be very challenging, but also very rewarding. You should study it until you understand not just what design decisions were made, but why they were (most likely) made. If you can't figure it our, ask :)

> I tend to churn out projects that work

There's nothing wrong with doing that as a first step. Many programmers will make something that works, and then refactor it into something that works and is nicely architected. Have you tried that approach? Is the issue that you don't have enough time per project?

> I think they lack the elegance of many of the open source projects or example githubs I've seen.

It's a good sign that you recognize as much. That means you have an eye for good code, which is huge. What's your biggest obstacle right now? What prevents you making the jump from merely appreciating good code to writing it?

The best thing you can do is read & write a lot of programs, and pick them based on what is new and unfamiliar to you. Try writing programs from different domains (compilers, parsers, network protocols, distributed systems, data structure libraries, desktop GUIs, web GUIs, mobile GUIs, graphical visualizations, machine-learning, data storage engines, geo data, command-line scripts, testing, automation). Try writing programs in different languages (Haskell, C, Javascript, Erlang, Prolog, Go, Common Lisp, Python, etc.). Try writing programs of different scales (weekend hobby projects vs. Google Search), and try entering them at different points in their lifecycle (starting with a blank editor window vs. parachuting in when the company already has a million lines written and the original authors have long since left).

I'll second what mindcrime said about never really feeling like you know everything. The rate at which new CS knowledge is being created is far faster than the rate at which I can learn, so I've long since given up being able to learn it all. But what I can do is see patterns. I can see that the new single-page Javascript MVC frameworks are reinventing patterns that were common in desktop GUIs a decade ago, or that what Chrome's rendering engine is doing when it schedules JS execution isn't all that different from the Win32 message pump, or that Guice/Dagger are basically introducing data-flow programming to Java, or that Go's channels & goroutines are basically the same as Erlang messages and processes. Then I can apply what I already know about those other programming paradigms to the new technology, and only focus on learning the differences. That's a lot easier than picking up a new concept from scratch.

Imposter syndrome: you're clearly good enough to pay money, but you can see just how vast the area of stuff you don't know is.

Imposter syndrome is a good sign! It means you have some understanding what "good" actually is. It's the opposite of Dunning-Kruger. You can go forth and slowly learn the stuff you're missing.

Stay humble, but don't forget that you are some good.

Imposter syndrome is absolutely part of this.

The other part, as you mentioned, is that as you learn more, you realize how little you know. This humility is the beginning of true knowledge. Novices feel like they know nothing. Apprentices feel like they know everything. The truly wise feel like they know nothing compared to all there is to know.

Besides, in software, this is completely normal. People are inventing new frameworks faster than any of us can learn and master them!!

Whether you spend three years in continuous integration and test suites, service oriented design, embedded assembly, high/low level network stack, Javascript, Python, or even a PaaS, you just have to keep challenging yourself. Never settle and keep expanding your views. Bridge the gap by learning and engaging in things that interest you.

Just the amount of understanding required to comprehend the keyboard press to the letter appearing on the monitor is insane.

Remember, you're not useless and inexperienced. The stigma from those words alone are holding you back. I have a feeling you are bored. You have a thirst!

Also, recall that articles and comments are much like Facebook, a peek into someone's good life that makes you feel bad about yourself. The good always seems great, and the bad goes untold. I'm on revision 744 of a 10 page website/service layer right now with only 30% of the requirements met.

I suggest you learn a bit about perspective and human psychology, starting with The Imposter Syndrome: http://en.wikipedia.org/wiki/Impostor_syndrome

Sometimes, folks who think they know everything just don't know how little they know. Some of your smartest people sound not terribly confident because they know the limits of what they know and how many things are unanswered. Sometimes, really talented, amazing people feel like shams and really mediocre people feel like they have conquered everything and are The Bomb.

After that, you also need to find out some kind of objective measure of "good" for x thing. I don't know enough about programming to suggest what that might be for that domain.

Pick better things to read... HN is super awesome for general interest stuff, but it will never make you better at anything. Google some deeper terms from whatever you are learning, and find 5 people that are good at it... read their stuff, try it yourself and get in touch with them if you get confused. You learn by failing as a developer...even some really smart people who did great coloring between the lines at school drop out because they can't handle that dynamic. That's how you go from "novice" to "good". The jump from "good" to "great" invloves some deeper understanding of architecture and algos/systems that comes with time, reading, education, etc..

> Pick better things to learn

Awesome advice.

I'm sure if you wrote a technical post about something you have deep experience with in mobile or web dev, many people would probably feel the same way reading your article. There's too much for any one person to know.

Read those articles and take the time to research the parts you don't understand until you really grok it. Read and try to understand good code, take every opportunity to go a little bit deeper into the tools you use (web frameworks, libraries, etc) if they are open-source. Getting better sometimes means knowing more, but mostly it's about not being afraid to dive in.

Change jobs every 1-2 years (not just a salary bump, but a varied experience as well). Get a long-running side project, where you allow yourself to refactor as much as you want.

" 'seriously' building fairly complex web and mobile apps"

You may already be "good". The thing is that there is something or someone better out there than you and this applies a lot more when it comes to HN. I feel like a loser when I browse HN because well, a lot of ppl are faaaar better than me at the things that I want to be good at. It is all relative. Stop sweating it and focus on what you want to achieve. If you get what you want, who cares whether you are good or xyz.

Being a programmer will definitely humble most people. It is probably impossible to know even a significant part of what makes up Computer Science. Add to that the requirements for knowing Software Engineering which generally bears little overlap with CS and you're probably always going to be behind.

The important thing is to keep learning hard things unrelated to your current development stack and methodologies. Don't get stuck on only doing tasks where you are already an expert.

It's simple... for any software you run into ask yourself:

How can it work? How does it work? How it should work?

And the most important thing:

Avoid involving yourself into code that is a mess before knowing how it should be written in the first place.

Also, if you're into OOP, think about access modifiers as:

private - if it's called from somewhere it has to be only in this class... (or im gonna slap someone!)

protected - only this class and its child classes...

public - does this really has to be part of an interface?

Once you start thinking this way you know you're on the right track.

...and read a lot. :)

First define what "good programmer" means to you. Good programmer could mean having the skills to lead and code a functioning start up venture that can scale. For others "good programmer" could mean being an amazing architect - building products that are complex, yet in simple concise code and in a way that is easy to extend down the road. Yet for another person it can mean becoming a great hacker. What does "good programmer" mean to you?

It's simply gained through study and experience.

However, the idea that you can keep up with the output of the computing industry (that employs tens/hundreds? of thousands of people) is an impossibly lost cause.

Instead specialize, while keeping an eye open for large shifts such as GUI, Web, and mobile have been in the past. I would avoid technologies such as php, that do not sufficiently encourage you to do the right thing.

Pick something and get good at it.

If you aren't familiar with something that you see, look it up. If it looks useful to you, build something with it.

A group of people will always look smarter, more knowledgeable and more accomplished because you will see the acomplishments collectively, and compare them to your own, individual work.

tl;dr - Don't let it get to you, carve out your own niche.

>If you aren't familiar with something that you see, look it up. If it looks useful to you, build something with it.

This is essentially what I do. Thanks for the tldr.

Reading other people's code can be hard, especially if you are used to a different coding standard. There's no promise that someone's article contains good clean code either.

Also, don't sell yourself short. Impostor syndrome is real. Just because everyone in the room is smart doesn't mean that you are not smart. Intellect is not zero sum.

Computer science is such a huge topic. It will humble the most experienced programmers.

It's possible that you right now today may know somethings that the person who made you feel like your underwater has no idea about.

I always feel like I don't know anything and that's a good thing, it keeps this subject interesting.

FWIW, I suggest: Do hard things you don't know how to do until you know how to do them. ;)

Personally, I just am happy dicking around with programming and never being better than an average programmer. I'm more interested in money and other things. :/

Do extensive work within a code base that is recognised as being well written and design and architected. Try to be mentored by great programmers, ask their advice on specific questions about your code.

"Yet, every day I run across articles here and comments that make me feel incredibly useless and inexperienced."

You're 'Good' now. When you stop getting that feeling, you're no longer good.

Meaning, I'm better than good? Or worse (because I'm no longer challenging myself)

You're good now because that feeling is how discovery feels (Dunning-Kruger effect and all that). It challenges and humbles you, and sometimes makes you wonder how you'll ever catch up. As long as you feel this way, you're probably doing something right. As soon as you think you know everything, that's when you're backsliding. Just try not to compare yourself to anyone else. Even Fabrice Bellard and John Carmack don't have the exact same demands placed on them as you, and therefore won't be developing the same skillset. But by all means, respect and listen to them.

When you have that feeling, it means you know enough to recognize what you do not know.

You've escaped the Dunning Kruger effect for now: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[Teach Yourself Programming in Ten Years - Peter Norvig](http://norvig.com/21-days.html)

1> Do you have a "Real" CS degree?

If not, doing a good portion of the exercises in some books on [compilers](http://www.amazon.com/Compilers-Principles-Techniques-Tools-...), [DFAs/State Machines](http://www.amazon.com/Introduction-Theory-Computation-Michae...), Algorithms (http://www.amazon.com/Introduction-Algorithms-Thomas-H-Corme...) and theoretical programming (https://mitpress.mit.edu/sicp/full-text/book/book.html) can give you some common foundational lenses with which to see these articles

2> Learning the history of your field

Nothing informs the current state of the field more than how we got here! Learn the foundation of your field from people who lived it. The podcast [Debug](http://www.imore.com/debug) is Guy English (Creator of Napkin and other apps) along with Rene Ritchie interviewing people about the history of Cocoa and CocoaTouch

I found [this episode about AutoLayout and Key Ferry illuminating](http://www.imore.com/debug-33-ken-ferry-auto-layout-passbook...).

3> Go through early versions. Few systems START complex. Look at OLD books for EARLY versions of systems, and why old php made such silly choices is obvious (hint, they weren't that silly for what it was doing). Read books and commentary through the timeline. Understand the history of what's happening to the language, then you'll understand why you are where you are.

4> Go DOWN the stack. Understand the bottom of Objective C by reading [the open source implementation of Core Foundation and more](http://www.gnustep.org/). Also available elsewhere (and I think somewhere on Apple's Site still).

5> Do what you shouldn't! Don't ship it, but really use those implementation details to do something awesome and amazing. You'll learn tons about what's happening.

PS: To the mods, those aren't affiliate links

Keep banging your head against a proverbial wall until there is no wall.