I started coding really early and I used to think I was pretty good(and maybe I was at the time), but then I burnt out and started really stagnating/regressing.<p>It's kind of fcking up my self esteem to see classmates who were learning a lot from me a few years ago and who are now doing better than me.<p>I remember a senior at my last job who after I spent a day struggling on a problem was like "ppfffft, here, i did that in 30 minutes" in a very condescending way, and looking back I'm thinking, was he an a-hole?was he right?both?<p>How do you know if you're decent and not some mediocre fraud?<p>I never know if I have impostor syndrome or dunning kruger.<p>I've done some projects I would consider fairly complex but they weren't great:
The code quality never was amazing, the code was rarely as fast it could/should be, rarely bug free etc...<p>Is there any kind of objective metrics to know if you're actually decent at this?<p>I get interviews and jobs relatively easily, but I wonder if it's just because I oversell myself, went to a good school and recruiters are desperate
Do you drink a lot or do a lot of drugs? Should probably stop those. They eat up your time and over the long term are not (IMO) great for your brain. Programming is a brain thing, so you need to take care of it.<p>Anyone who wants to be really good at something is probably never as good as they want to be. Every day you have to start where you are and work to become better. If you enjoy programming (I always have), it's easier because it doesn't feel so much like work. But being good at something also make it feel less like work, so if you're not feeling the love for it now, but want to, you'll have to put in some consistent work to get up to the level you think you can or should be. But it's like any sport, musical instrument, or other challenging activity: you'll never be done honing your skills and trying to be better at it.<p>Everyone's on a different path. Stop comparing yourself so much to others.<p>Now get back to work on your self-improvement plan. It's your main job every day!
Two things:<p>1. It really does not matter. For any measurable skill, there will be millions of people stronger than you, and millions more who are weaker. Unless you are aiming for the very top (think Usain Bolt) <i>and</i> being the best will be recognized somehow (as opposed to being, say, the world's best cherry kernel spitter), try not to worry too much about it.<p>2. Rather than take the infamously arbitrary job interview dance as a reference point, you can look at how good you are at your actual job. Are you helping forward progress in any way? Do your colleagues appreciate you? Are you bringing something positive to your community? If so, you can be more than satisfied.
If you can, look at code you wrote, but haven't seen in a long time.<p>I'll go first... here's some Turbo Pascal code I wrote back in 1987/1988 to do cooperative multitasking. -- <a href="http://www.retroarchive.org/swag/MISC/0153.PAS.html" rel="nofollow">http://www.retroarchive.org/swag/MISC/0153.PAS.html</a><p>In reviewing it, I'd say I didn't document things quite enough, but even now it's easy to see what's going on, and why. I forgot that I saved the cursor position for each task, which is a nice thing to do for the user of the library. Overall, I'd say I did ok. After all, it was sufficiently useful enough that someone on the internet archived it for me.<p>If you have a sufficiently old piece of code, try that exercise out, and see how you think you did. If you can, post a link to it, and get critique.
I work as a programmer. I'm not very good. But then hardly anyone is.<p>There are certainly exceptions, but I think as a whole we're still working everything out. And that's why it's so fast moving, we can easily find better ways of working each decade because last decade's status quo left so much to be desired.<p>If you find avoiding unemployment as a programmer easy, then I would suggest that you are what people want. Maybe you don't write the fastest code, maybe there are bugs, but it seems our customers (employers) are quite happy with that, and perhaps don't want the tradeoffs that would come if we were to ever seriously attempt to produce a zero bug project.<p>(I speak to/of the vast majority of programmers, there are areas where one can not compromise on program correctness but they are rare.)
Your opinion about where you lie on the spectrum of capability has everything to do with your own perspective-building and very little to do with "reality", whatever that is. You're comparing where you are with where you can imagine being, and both of those valuations are fraught with error. One of the harsh realities of acquiring skill and sophistication is that those enable a vision of where you <could> be, which is inherently frustrating.<p>Perhaps the real problem is finding a sense of satisfaction in your work. The algorithm for acquiring that is fairly straightforward: work your edges, i.e., focus on tasks that challenge your current capabilities, but not too much.
> I've done some projects I would consider fairly complex but they weren't great: The code quality never was amazing, the code was rarely as fast it could/should be, rarely bug free etc...<p>Code doesn't need to be "optimized" by some random metric if that is not important to the business. If you are spending too much time to write code optimized to be the fastest possible on a given hardware, and that effort has no tangible benefit to the company, you are not a good developer for that business.<p>> I remember a senior at my last job who after I spent a day struggling on a problem was like "ppfffft, here, i did that in 30 minutes" in a very condescending way, and looking back I'm thinking, was he an a-hole?was he right?both?<p>I have found that it is very common in people to forget how they were before they learnt something. These kind of people are terrible teachers, terrible leaders and terrible long-term systems thinkers... but are incredibly confident and can do things that are good for short term incredibly quickly. Sounds like one of those people.<p>>Is there any kind of objective metrics to know if you're actually decent at this?<p>IQ test is one good metric. A high IQ means you are able to see patterns and hence learn and grasp things quickly (given that you spend time learning). Mensa has online test you can take.<p>Similarly, OCEAN/MBTI may be something you want to try to see if you learn something about yourself... which can be useful to a point.
On any level, i think what matters is curiosity.<p>I have "Jr programmers" ( because lack of progress, asking me questions about basic functionality of AutoMapper, while they have already been using it for 2 years. That deeply saddens me.
I have one rule about my less than steller coding abilities: if it works, then it's good code.<p>Life is too short to worry about whether your skills measure up to anyone elses, as you'll always find someone better at it then you.
>The code quality never was amazing, the code was rarely as fast it could/should be, rarely bug free etc<p>This describes just about every software project in existence. You are probably being too hard on yourself.<p>I just always keep in mind that yes, this thing I created is not perfect, but given enough time, I could do better. The question is simply whether it is good enough and whether that time should be spent elsewhere.
Can you scratch your own coding itch ? Have you customized your dot files ? Could an employer do worse than you ? Would you pick yourself to code yourself out of a life or death situation or pick a random person off the street to help you ?