I'm a terrible developer, what now?

> purely as a hobbyist

This is my first clue that you're not nearly a bad as you think. The biggest obstacle to becoming a good programmer is hating to program. Many people nowadays want to get into software because they can make money. There's nothing wrong with this, but if you really don't enjoy programming it's going to be more painful than it's worth. The fact that you like it is a good sign.

I saw in the comments that you've been doing this for a year or two. Programming takes a long time to get good at.

I recommend reading Peter Norvig's classic essay "Teach yourself programming in 10 years" https://norvig.com/21-days.html

It takes two years of programming to really break out of the beginner stage in my experience. I define this period as the period where you have to think much more about writing code than about the problem. The means that you really can't do much software development in the true sense because just getting programmings to run and run consistently take a lot of mental effort.

Years 3-5 are the intermediate stage where you can solve most common problems without having to think about programming too much, but programming itself is still a source of friction when it comes to completely projects. At this stage you begin to think more about how to structure larger and larger projects, learning some clever techniques, and understanding some of the more specialized techniques in your language of choice.

Expertise happens when you don't have to think about programming any more and are exclusively concerned with larger design problems. This is the point where you can reasonably write a program and, barring a few typos, will run on the first try.

Don't stress too much about being a great developer, just keep coding and you will improve.

Hey! A lot of people have mentioned you should keep going, and that's really good advice. You're probably better than you think you are.

But if you don't like it, you have other options! There's a lot of jobs out there that you might like more, and will benefit a ton from you having a background in engineering. You now have a superpower... you know enough about engineering to be dangerous!

For example – sales, CSMs or support teams for technical products will love you, because you can debug and figure things out – and your job will still involve more talking to customers than code. Look at solutions architect jobs, too.

Same goes for marketing. Most companies would kill for someone who does marketing but with a background in engineering who can do the work of setting up tracking/funnels/etc, rather than bugging engineering teams.

DevOps is a place where the hacker mentality will go a long way. There's not many "languages" you need to know deeply; but rather be really good at figuring things out and understanding how everything works together.

The list goes on! (EDIT: check the replies for more ideas!)

Imposer syndrome alert. First, wait till tomorrow, see if you feel the same way. From experience, you're probably just in a mood bad because of some difficult task. If you still feel the same way tomorrow, then my advice will be to just take a more deliberate approach to learning. Nobody holds on to details like "very basic OOP concepts" all the time. If you're in a funk because of an interview screw up, get over it. Interviewing is a job in itself. Take time to prepare (3 months at least) and see if you still feel the same way.

If you can read and tweak code, you are already useful for 90% of necessary work. For maintenance you have little need for OOP concepts. 95% of code out there is crap anyway. What matters is: Is it being used / is it useful? If you can manage to create such code, you are already competing with the best of the crap. There's never enough time and money to do it right anyway, don't be too hard on yourself.

Recognize how powerful circumstances always are.

There are things you can do to improve or feel better. It needs to be deliberate and you need to care enough to put extra effort into it and manage your training as you would do a project.

Lots of talks on youtube can provide pointers and inspiration. But it's hard to get the chance to put it to use. A hobby project would provide that opportunity, but it need to be something you really want to do and something that will provide you some value.

I wonder if the technical stack you are working with is not a good fit for you. I was miserable when working with PHP (5.x) and considered quitting my job/industry altogether. Would you consider exploring different languages lightly to see if you can find a better fit?

As for failing whiteboards/screens, I have counterexamples: two of the smartest and understated people I know do fairly badly at these, and a person who was brilliant at these turned out to be quite unproductive. While the whiteboard/screen is the gateway for a lot of companies, there are still more that don't use such antiquated and lazy filters and are also very satisfying places to work.

Eh, I've seen tons of terrible developers who still collect a pay check. If you acknowledge you need to improve you can't be the worst of the bunch.

It depends on what your goal is. Do you want to get better at creating software as a goal in itself? If so you might want to think about optimizing for lower pay check jobs at startups where you will get to work with talented engineers and do new and different things although be careful they actually have good engineers who can mentor. This could prove to be the most monetarily rewarding path over a 5 or 10 year time frame as well if you drastically increase your skills.

Do you just want to make money off of it? If so look for skills that are highly valued in job listings, maybe react.js right now, and spend a few months of your free time studying that one thing as much as you can and maybe build a test project like todo mvp. If you can do anything at all with react you can collect a paycheck somewhere.

Software has a lot of froth these days. You don't have to be incredible to get good outcomes in the industry.

I used to think I was good at calculating math but very bad at proving theorems because only geniuses prove theorems but us ordinary people just compute reliably. I couldn't make any headway at proving a theorem.

Then one teacher gave me an assignment and I looked at it and could not make headway. Then he told me: take your time. This should take you 2 hours or so.

That single instruction changed everything. I just stared at it and worked on it and stared at it and 30 minutes later I had figured it out.

Then the professor approached me to let me know that I should maybe consider go into theoretical comp sci as my major.

I have met math geniuses and I am not in their ranks. As Bezos once said in an interview, their brains are different.

However, it is worth pointing out: just give it more time. You don't have to see progress right away. If you set up a website or are doing some data science, you should expect little issues that will eat your time. This may be as trivial as simple as your python library is 2.7 vs 3.x or you have to load in C++ compilers and the error message is obscure etc.

The worst part is this drudge work is front loaded: before you start your app you have to pay these dues. Then once it is up and running you can experiment and you find a lot of progress being made.

This simple truism hurts newbies who don't see progress right away.

It sounds to me like you need to have a real discussion with your manager - this is what they're there for. Maybe their perception isn't as bleak. Maybe this is a case of imposter syndrome. Or maybe you really do need some improvements and they can help you with a development plan.

Not having deep knowledge on particular subjects, not knowing OOP, being a generalist - these are not signs of being "terrible". Everyone has blind spots. Some people work on font rendering or audio codecs their whole careers and don't know how to build a decent web app to save their lives. That's ok.

I think you've realized you're not a Rockstar or 10X, not that you're terrible. Most people aren't Rockstars or 10X, and some question if those even exist.

Your best bet is to try to specialize in the tech within your professional space. If you're working for a company, work hard to understand the technology and codebase they are using. Try to learn best practices, and see how you can integrate them into the existing codebases. You'll maybe learn the patterns you feel you're lacking, and also learn that a lot of times stuff is not coded with best practices in mind. There is tons of production code hacked together and barely working, and in a lot of cases that doesn't matter, it only matters that it's technically working.

Management may be an option for you down the line if you're feeling you're still not confident coding is the right thing for you. I am sure people would love to have a manager that is at least relatively competent at reading code and tech literate.

You do realize, there is a sliding scale of confidence with all programmers?

Specifically, confidence levels decline the more experienced and knowledgeable you become.

Eventually you start talking in generalities, what should or should not happen instead of absolute outcomes. You'll start using words like "probably" quite often.

You'll find yourself paralyzed by indecision. What's the best way to do X? What if I need to change Y? What would my peers think about this code? Golly, that will be a lot of work, maybe I shouldn't start that project...

This is all normal, and I'd say it means you're becoming experienced enough to understand what you don't understand. When you're green... you'd just go forth guns ablaze regardless.

The reality is, every good programmer thinks they are awful, and every awful programmer thinks they are amazing 10X developers. Be wary of overconfident programmers.

Welcome to the club :)

Keep programming. The only permanently bad developers are the ones who like the bad code they write. If you don't like the code you write, and you pay careful attention to code that you do like, you will naturally start to write better code if you let yourself.

> I have basically no CS knowledge

Lots of people have this knowledge, and it comes into play rarely enough that asking for help when you need it won't put a huge burden on your coworkers.

> my solution is more likely to be a complete mess

Think of yourself as a writer. Don't publish first drafts. Don't give people estimates based on when you can finish a first draft. If you can tell it's bad, you can fix it.

> I can recall my last interview tripping up on questions about very basic OOP concepts, which you'd think I'd have internalized now

Don't feel ashamed of that. What people consider "basic OOP concepts" is strongly driven by the language they use as their reference for OOP and even their style in that language. Javascript and Java have very different OO fundamentals. Learn what good code looks like in the language you're using, learn why, and practice.

I've met some terrible programmers who thought they were awesome.

I think most of us wrestle with imposter syndrome from time to time. It doesn't help that there's no grading system for programming, no professional body that will certify us, no systematic learning program that we can work our way through. CS degrees don't teach actual programming skills (seemingly as a point of pride). There is literally no external source of validation except comparing ourselves with our peers - which is always a source of misery if you're not a narcissist.

There are constantly stories from famous, objectively good, developers who failed technical interviews. As with all interviews, a lot of it depends on social skills rather than technical skills. Failing technical interviews doesn't mean anything.

But, let's assume you're right and you're a terrible programmer. What do you enjoy about programming? Usually our talents lie in the direction of the things we enjoy. "Software development" as a career incorporates a huge range of sub-careers, and there are advantages in non-IT careers for people who understand coding. Can you head in the direction of your interests?

Most comments seem to be encouraging to stick with programming, which on one hand is great.

But you asked a more general "what to do" I think/interpret; can you edit your post as to what other skills or interest or career background or experience you may have?

If you are a generalist techie with surface understanding of large number of technologies, and willing to explore that more / dig into things, there are "architect"-type roles you'd potentially be good at (and an even larger you'd be terrible at of course; the title covers a huge breadth of scope).

Are you good with people, communication, customers? Do you understand business needs? A manager who at least understands technical aspects can be invaluable. Yes, management is a tricky word in the world of technology and on HN, but I still believe that experience with dozens of bad managers is all the more reason to try to be a good one :)

Sales, advanced support, etc are all also options.

System administration of some kind may also be for you; fwiw I've been a "PeopleSoft Administrator" (PeopleSoft being an ERP like SAP, JD Edwards, Oracle eBusiness, etc) for 15 years (not one anymore but I'm still in similar space), and my breadth of skills was an advantage - a bit of DBA, a bit of sysadmin, a bit of middleware, a bit of scripting and programming, a bit of architecture, a bit of business and functional understanding, a bit of operational awareness, and tremendous curiosity and willingness to research and "figure it out" - that cross-section of curious understanding made me well respected and sought after in that particular niche, and there are hundreds out there like it.

I think important question that only you can answer but you haven't given one in your question is: do you want to stay a developer, or are you willing to explore other options close to or further away from that?

Almost all the responses here talk about impostor syndrome or being mediocre. But maybe OP is really bad. Like really, really bad. I know that is possible because I'm a very bad developer myself, I know it's possible to be a bad developer (not mediocre) for years on. We still deliver, we work on very small teams or in places where we are the only developer, so nobody notice the mess your solutions are. They work. But you know they are bad, no tests, no best practices, not even consistency between code.

My point is: I hope some advice acknowledge that maybe OP is correct about his real skills.

> There's not a single language I'd consider myself good with, maybe one or two I can write and maybe one I'm ok with.

Can you get things done in the one or two languages that you can write? If yes, that's already something. Forget OOP, forget whiteboarding questions - if at the end of the day you can build something even if you write sphagetti code it's _something_. I'm of course not encouraging writing unreadable code and I'm in no way saying that OOP is not required-knowledge, but if you can (somehow) get things done you are sufficiently intelligent. The rest is all a matter of putting in some effort (writing clean code takes some practice)

> and there's no way in hell I'd make it past a phone screen for your average whiteboarding company

One of my friends has never (AFAIK) passed a whiteboarding interview. Regardless, if I start a company, I'd pick him over everyone else I've ever worked with - not because he's the greatest engineer ever, but because I like working with him. He loves what he's doing and he get things done, and engages in interesting conversations. Leetcode skillz (IMHO) are so overrated.

> I also suppose that I'm an ok "hacker" in that I can get very interested / fixated on certain problems, although my solution is more likely to be a complete mess.

Most people I know are day programmers - they'll do what you ask them to do, but they'll never do something for the fun of it. This does not make them worse programmers, but I'm inclined to think that given enough time, people who do things for fun tend to get way better than people who just see it as a job. You got to love the process and not just the results.

Also, if you are feeling terrible because you tend to get harsh comments during code reviews, I'd whole-heartedly recommend detaching yourself from the code you write. Now that I look back, a lot of the code review comments I got were annoying nitpicks rather than genuine design/code critique.

I would bet a red cent you are one course on programming languages away from being an amazing developer.

I get classes are for loser. But seriously, If you have to force yourself to take/self study one class for the rest of your life nothing, and I mean _nothin_, will make you a better developer than a proper course on programming languages. These sorts of classes always seem to be wasted on people just learning how to program.

They really should be thought to developer that have been at it for a while. Experience primes one to really put that information to use.

I am not suggesting one of those "flavor of the week" language and move on to the next language survey courses. Find a class where you are forced to:

Write the algebraic laws for your underlying data type and turn them into code

Know the difference between structural and generative recursion

S-expression

Structure vs syntax

HOFs and Currying

Functional vs Imperative

OO through the lens of the Curry-Howard relation

Has you write some parts of a programming language or prove important things about a language

Don't survey. Who care if you "one time kind of wrote some Scala?" Get intimate with the nuts and bolts of language theory and have it guide your choice when you write software.

In some ways I feel this is quite similar to myself. I've been doing bits and pieces of programming since I was ~8 years old, but I've never felt like I've necessarily loved coding, and for the longest time I felt the dreaded imposter syndrome. My tech friends would often talk about code with such excitement, but I couldn't get that feeling myself. It was just a tool to me.

But once I hit my 30s, I realised that actually what I enjoyed was finding a problem and solving it. Programming was part of the solution, design was another part. I'd been doing all the different parts, but just labelled myself a full-stack developer because I thought I had to fit into a bucket somehow.

That lead me to thinking about what actually I want to focus on, and I came to the conclusion that product (management, design, etc.) is actually what I enjoy. Programming, design, marketing, and the like, are the tools I use to make products. I don't necessarily "love" any of the tools, and I'm certainly not the best at any of them, but I have a broad knowledge of all of them, and that alone had helped me in so many ways that I hadn't realised before.

So perhaps you need to do something similar? You say you get interested in problems — that's a great start! While you might not be able to come up with the best technical solution yourself, you could be the person that's needed to research the problem, and to motivate and steer others towards the solution.

Also, having that broad knowledge of the surface of many topics is also a great advantage. I'm often the person my friends will come to when they're looking for a tech solution that they haven't found. The chance is that I've heard of something that I can point them towards, even if it's not something I would want to work with myself.

Essentially, even though you feel you're not good enough at programming, it seems like you have talents that are big strengths in slightly different areas.

The good news is most business problems are not that hard.

There are domains where you really have to be a crackerjack engineer, but most jobs just need you to know how to push and pull things out of datastores, make network requests, map data structures, and maybe render the results on a web page.

Technical job interviewers loves to grill candidates on reversing binary trees, or obscure programming language trivia -- but the job itself will be building a CRUD app.

So what should you do? If you enjoy programming, I'd say stick with it. Not everyone needs to be working on ground breaking cryptography or compiler optimizations. Sounds like you just need to find a tech stack and problem space where you can feel comfortable working on it.

Look at positions that ask for prototyping engineers. The goal is to get it working anyway possible. You're not going to bogged down by larger programming concepts, reusability, performance, etc. Try fast growing startups with the culture of shipping fast.

I went from working at a large company to writing software for a startup and had the unlearn a lot of these concepts. Since you don't care for these concepts anyways, you'll probably be a better prototype engineer than I ever was. Also, look at related fields that require scientific programming using tools such as matlab as they also (mostly) focus more on getting the solution working rather than how it works.

Just a heads up

1) OOP concepts don't mean everything.

2) Forcing Whiteboard interviews is bad. Some people prefer writing code (on computers) to think. Some people prefer whiteboards.

Please dont write yourself off because of these things.

> I also suppose that I'm an ok "hacker" in that I can get very interested / fixated on certain problems, although my solution is more likely to be a complete mess.

This is a good skill set to have and build on. If you care about code quality or improving your skills, try to find people who can mentor you in those directions.

Sounds like me on a Tuesday:p. Several things: Are you trying to learn JavaScript deeply beyond hacking? if so, there is your problem, no one really knows that language. Maybe try different programming languages to see what clicks? Also remember that average mortals don’t know how to program or even how to open a text editor without getting terrified. Everyone has imposter syndrome. There will always be someone way better at programming than you. Don’t be so hard on your self.

Setting aside all the imposter syndrome, confidence, etc stuff...

The only devs I've known who I thought were legitimately bad were the ones who thought they weren't. The devs who couldn't accept that their code was overly complicated, because in that moment they had no problem reading it. Or who would come out of the end of a project without any ability or desire to think about why or how the project went wrong.

Some devs dig deep into the language and libraries, some don't. There's need for both kinds of devs out there, even if there isn't at your company. Some devs know every design pattern out there, some don't. I often prefer the devs who don't -- my goal is to quickly build software that is easy to debug and easy to add on to, and people seem to usually get caught up in putting whatever type of factory where a factory shouldn't be and...

Really, though, we all suck. I've got senior devs from Amazon and Microsoft who don't know or care about dependency management or how to write integration tests or... whatever.

What do you want to be good at? Intentionally pick a thing. Not "programming" but do you want to be the best at debugging your team's software? Do you want to know all the gotchas and tricks of your team's language & framework(s)? Do you want to own a particular bit of your company's business logic? Pick a small thing you want to be the best at, figure out what that actually means, and then master that thing. Even if "that thing" is just being able to quickly add simple, not-awful-to-maintain features. Grade yourself on that, not every single thing you might see some particular other developer do better at than you.

Consider Sales Engineering. Often in tech companies, there are two types of salespeople: nontechnical folks, and sales engineers.

The nontechnical folks have titles like Account Exec, Sales Development, Inside Sales, Regional Manager. These are the "people people" in sales. Extroverted, greater social skills. Your classic salesperson.

But software is technical, and often gets sold to technical folks. At some point in the sales cycle, a company's sales team needs to talk "brass tacks" and show what the software can do. This means technical presentations, demos, pilot projects. It will be more at infrastructure companies like, say Snowflake, and less at SaaS companies like Salesforce.

For these technical jobs, you need to have sales engineers. You don't need to be a great developer. Instead, you need to enjoy learning technology on your own, and able to "geek out" with fellow geeks. Given your work as a hobbyist, it seems like you definitely have the first attribute.

Hope this helps.

Totally echo all the other comments in here about imposter syndrome.

Also:

> I can recall my last interview tripping up on questions about very basic OOP concepts, which you'd think I'd have internalized now and there's no way in hell I'd make it past a phone screen for your average whiteboarding company. I know many people much less experienced or even relatively new who are significantly better at this.

Okay, so depending on the question, I'd probably have the same problem. It's hard when someone asks a question like "what are all the uses of static in C++?" It's just not the way a programmer thinks about it, or at least, not how I do. It's a tool, and when I see that word I know what it means, but I can't just rattle it off my head.

So let's say one of the "basic" OOP concept was about multiple inheritance, which is basic in that it's easy to implement (and screw up), but given all the problems, I'd never implement something that way personally if there was any way around it. So I'm not familiar with all the ways vtables and inheritance might work, or which function gets called. I'd probably just say "I'd run the code and look at the output"

Internalizing knowledge is hard. It's more of an instinct I feel than something that is necessarily easy to explain that you know to someone else.

Also, a lot of people are great at interviewing and shit at getting work done. Interviewing has nothing at all to do with work. (which is why hiring is broken)

> I also suppose that I'm an ok "hacker" in that I can get very interested / fixated on certain problems, although my solution is more likely to be a complete mess.

This I think is the first rung for any solution for me. Get it working. Prove it's possible and that you have something that will work, not just "might work" or "hope it works". Then you can refine it. Look at things like names, lines of code, repeating yourself, etc. I've seen a lot of code that looks great but doesn't work. Messy code is sometimes the outcome of a messy problem!

Also let me just close by the fact that at least you have self-awareness of your issues, which is required on fixing them (even if it's just a psychological issue). Many devs write terrible code and think they are gods. I'd rather have someone I could teach.

I never considered myself a great developer. I studied design at university because I wanted to broaden my horizons but I already knew that I eventually end up coding at some point (just because I enjoyed it so much). I guess it took me around 8 to 10 years to get confidence in my work. Now around 20 years after starting to learn how to code, I'm runing my own studio. managing some code projects for major cultural institutions, a AR project and the manufacturing a physical product. Still not a great coder, but probably a good generalist.

My advice is focus on the skills you're good at, the ones that bring you joy and the ones that other value. Make sure you keep challenging yourself and getting better at whatever it is that you do. Also keep yourself curious about the world and the people living in it. Things will will eventually work out just fine.

> I have basically no CS knowledge

You could take some computer science classes, then you'd get some CS knowledge.

Wanting to clear whiteboard interviews and becoming a good programmer are two different things. They have a very small part in common but that's it. Not saying wanting to clear interviews is bad, but you got to decide what you want to focus on.

Hi,

You seem to do a lot of retrospectives right now. That is probably a necessary skill to be a good developer. You are questioning your solutions, looking at other developers' works, understanding that they are doing a better job. I can only say congratulations to you about that.

Do not focus too much on the technology or in what you know at the moment about the technology.

As a first step, you must answer if you want to be a better developer in a specific language or a better professional in one particular industry.

Technologies are too many nowadays, focus only on something you like, even if you know nothing about it at the moment.

The key is not what you have been until today. The only thing that matters is what you want to do.

Don't expect to be anything but terrible for the first couple of years, be realistic with yourself, most of us are. It takes years to build up enough engineering knowledge to be proficient in most cases. Even then you will still have blind spots and short-comings. I'm approaching 10 years now, and I still unearth really obvious things I didn't know from time to time. I only really understood heap vs stack very recently (I've been mostly doing web stuff, so I never really needed to know it until I started learning Rust...). Go easy on yourself, accept your limitations and keep going. The shroud will slowly lift, you'll suddenly notice you're doing more and more on auto-pilot, without needing to look everything up. You'll pick up more CS concepts along the way. Embrace the process, but know that there's no such thing as being 'naturally bad' at something, with the right practice and patience you can be as good as anyone else. Good luck, keep at it!

These posts come up often on HN and I always comment in agreement. I am the same. I have 7+ years experience and have worked on successful projects. I rarely have bugs in production (I can't remember any actually). I maintain projects that are 5+ years old so I know my code stands the test of time. (5 years might not be a lot to some I guess). I've mentored junior programmers and I spend my time reading about tech/programming stuff. I've probably listened to most of the software engineering daily podcasts.

I would still fail a programming interview.

To give you good advice, we'd need to know more about you. You haven't really said that much about why you think you're bad, or what you've tried to do to improve.

You say four things about why you're bad:

  am not even really that great with the "practical" stuff despite having been at it for so long

  I must stress the 'surface level' part

  can recall my last interview tripping up on questions about very basic OOP

  although my solution is more likely to be a complete mess

The first seems relevant, but too vague to get much of a grip on. The second seems of dubious relevance--it can be useful to know about a lot of technologies, but it's neither necessary or sufficient. The third is about interviews. That may hurt you in a practical way (and is something you can practice!), but doesn't actually bear on whether you're a good programmer. The fourth is relevant, and actionable. But why do you think your solutions are messes, and what have you done about it?

Supposing that you do really have a problem, you have to decide what your real issues are. Then you have to identify ways to work on them.

Ideally, you'd find someone you trust who can work with you, who knows something about coaching people, and can give you an accurate assessment.

P.S. All this assumes that you have a problem. I don't think we can assume that. It also assumes you want to stick with programming. But that's not a requirement. There are plenty of good comments about how you could switch fields and be happier. There's no shame in doing that, if you decide it's your best course of action.

Well, if you're not very good, or feel like you're not very good, get better.

How to get better?

Evaluate your strengths and weaknesses (ask a friend/manager who's willing to give critical advice).

Plan and practice, practice, practice.

It's a mental game, too. I find the sheer volume of knowledge out there to be overwhelming -- don't worry about this. Start where you are, and add, incrementally. Nobody goes from A to Z.

You got this. Ping me further if you want a mentor or accountability partner.

I guess you just need some mentoring to get some skills/structure. Difference between hacking and engineering is the "structure:. I can't find the right word in english, I would say "rigueur" in French.

Any if you can't find mentoring at your current position, try some books. My first mentors were Andrew Hunt (The Pragmatic Programmer) and Martin Fowler. Start with them, or find your own.

Code mindfully, go deep to understand every little detail of the code you write or read. Ask questions. A lot. Don't stop at the first draft. Don't stop a the first pass of questions.

Keep at it for a while. That one day you'll wake up with the feeling that the code you write yesterday was good. And hell if it's not a beautiful day to make it even better!

Get some CS background if you feel you miss it. https://teachyourselfcs.com/ gets one Hacker News every now and then.

Work on architecture/design. Try to understand design patterns for example. Be critical. Try to understand architectural decisions of the code you read.

Don't understimate the efficiency that comes with really being fluent with a language but do not give fluency too much credit either.

This is a lifetime journey. Improve step by step, little by little, every day. But improve mindfully. Get a direction. Get learning goals.

It's not a "try harder" it's juste question of better orienting the energy maybe.

That's my 2cents.

Good luck, I'm sur you can get, better you just need guidance.

Facts - We all suck at this.

This career is so subjective it hurts. There are no right solutions, only okay solutions. There are also so many different types of programmers. It's okay to be the hackish type. That type drives value to customers while unearthing complexity so that the system can be rebuilt around that complexity... To further my point about "types", there is going to be a whole subclass of dev that will read what I just said and think "No, you must find complexity before writing code!". Usually this type has pulsating veins in their forehead. Guess what? We need them too...

On surface level knowledge - this is the most powerful thing ever if utilized properly. Once you know enough high level concepts you can organize them into a plan and dive deep on them. There is no use in knowing everything deeply. Strive to learn depth only when it's required.

On beating yourself up - Stop. It's not helping you. Find the value in what you do and how you do it, and then go deeper on that. You'll create yourself a niche. A good manager will see it, and you'll quickly start getting passed around a company so you can go do that thing you do.

> I've come to realize I'm not very good at it and thats unlikely to change.

Citation needed.

As I manager I hear this sort of thing regularly,

1. Imposter syndrome, a large portion of developers have it and this could be you. Chances are if you have a job and continue to ship code to prod you are at least partially suffering from imposter syndrome.

2. Overwhelmed by the wide variety of skills, being a software engineer in a professional environment requires way more than coding skills. You need to be adequate with GIT, Programming Languages, Unit Testing, Various Frameworks, CI, Deployments, Team Dynamics, and more. If you are only able to write code every day will feel like a big struggle to get anything done. Identifying which area is giving you the most trouble and doing focused learning will help you.

3. Lack of methodology in learning, a lot of people rely on their feelings to help decide what to do next. For some people that means learning a bit of this and a bit of that but never learning enough to be productive. Having a plan for what you need to learn and the order you want to learn it in can be tremendously helpful for growing your career.

4. Lack of methodology in coding, most coding jobs have similar steps when solving day to day problems. Making your self a checklist of steps can be very helpful for taking the stress and guesswork out of your day. For instance, step 1 pick up a ticket and understand the requirements. Step 2 pull from the git repo and run all tests. Step 3 Right down a development plan. Step 4 write code. step 5 write unit tests. step 6 submit a pull request. These steps will probably look different for each project and developer but help to ease the tension of figuring out what's next.

I'm sure there are more things specific to your situation but don't give up and keep working towards your goals.

You don't mention what your manager and peers think of you. Do they all agree that your a shite programmer? If they don't, you're succumbing to imposter syndrome. If they do, you might all be correct.

But, that aside, if you just want out of daily programming, you can... - move into a BA or product owner role. Your technical background will serve you well as you interface with R&D teams (and communicate their concerns back up to senior leadership)

- Sales. Same as above, but requires a certain personality.

- MBA or some other graduate program. Could help you break out of tech completely. Or, move into some other tech-related role.

If you want to stay in programming, the best bet is to just stay in programming. I wouldn't worry about flubbing a few interviews, not all companies do ridiculous white-boards. And not all expect everybody to be the equivalent of a semi-genius from Stanford. There are aplenty of programming jobs where you can solve interesting business problems with more ordinary technology (vs solving interesting technical problems and building new tech stacks or whatever).

First of all, thanks for posting this. That takes bravery and you've started a really interesting thread. I have a couple of suggestions as someone who is self taught in various fields, and the world of programming and music have some bizarre parallels.

First, you might be wrong. You may be fine, and just need to back to fundamentals. This is very common in many complex fields. I have gone through multiple rounds of taking stuff back to beginning level. I'm doing it all over again right now in programming. I highly, highly, highly recommend reading "How To Design Programs". Putting time in to truly and deeply master the very basics as well as you can is the road to mastery in anything complex, and it's never too late to do this.

Second, you may not be totally wrong, you may be slightly off target on how you like to think best! There are a lot of people out there who like computing and programming, but discover that really, they are better off as someone in a related field, or that they like a different kind of coding. In my experience, the best low-level coders are often terrible architects (very high level software design), because they can't imagine being wrong! Also, some people naturally gravitate for whatever reason to sysadmin/dev-ops style stuff, or security testing, or embedded electronics. Or perhaps you have better than average ability to understand how people make software and would be an excellent development manager.

So my advice is to take a two-pronged approach:

A) Go back to fundamentals and learn new languages, both high and low level.

B) Experiment with related areas and see if one of them makes you say "ah damn this is what I should have been doing".

And C) give yourself like a good year or two to figure this out. It'll take some time.

Not sure what you specialize in, but going deep into a specific subject/framework might help. Maybe work on a project that incorporates things that you feel you are weak on. Perhaps you can create something that incorporates OOP will force you to put things in context and understand how to use it. I find it easier for me to understand things when I build useful stuff. For me I find that projects force me to move past my previous comfort zone. Also you can read other's code, and then pull it apart and understand it. I'm always amazed by my peers coding styles and choices that they make. I try to understand why people make certain choices and that usually opens me out to deeper understanding of a particular language. Finally, I found everytime I learn something new from another language it offers me insight into choices/styles that I make with my current language. Computer science/coding in general is a deep subject, give yourself time as there is a lot to know, or a lot you may never know.

There are plenty of jobs that I get given that I absolutely hate as a developer as they are too complicated for non devs, but frustrating for someone that does enjoy "proper" software development (typing code).

Salesforce and Marketing Cloud were projects that I was asked to integrate and I hated them, I just don't enjoy the dumbed down way that they work compared to being able to express things in Python or SQL. Maybe something like that would suit you. There will be plenty to learn but it won't require as much of the creative part of coming up with solutions that more normal programming requires.

In fact I bet a huge chunk of developers would be happy to have someone on the team that doesn't mind the grunt work style tasks that require some knowledge of programming but aren't actually very intellectually challenging.

You probably aren't as bad as you think. Most jobs are maintaining crappy old code rather than writing from scratch, where you spend most of the day reading through code, to change a line or two to fix a bug.

I'm not sure if this will help, but what really helped me when I got started was making something I really wanted. My coding skills were not great, but I was obsessed with building things and that forced me to get better. You start to realize that if you want to finish your work faster, you just need to get better at writing code. You also start to see patterns in how code is written and you just naturally want to start restructuring duplicate code here and there.

That can only get you so far, of course, since a lot of things take time to "discover" on your own, but as a starting point, I found it works wonders. This might be controversial, but in general, I think that desire to get things done is more powerful and useful than a desire to do things right. Obviously you can't go too far in "get this out the door" because you will make decisions or design things without taking into account the future sometimes, but that's something you can dial back over time as you gain experience.

The first question to ask yourself is if you have the desire to be good. If not, find something else.

The second question is more of an assessment of yourself. Do you possess any of (there’s a lot of overlap here) tenacity, persistence, gumption, chutzpah, drive? If so, is it enough to keep you engaged in solving a problem until you succeed? If not, find something else.

If you can clear those obstacles, then you need only choose something to focus on and run it down to the end. Then you have that in your tool belt. You might have to start with running down how to triage the best thing to learn next. But if you stay engaged in the process and never give up (seeking recreation or sleeping on it isn’t giving up) you will become great.

Anyway, I acknowledge it is easy for me to be cut and dry in how I see your challenges. I just never gave up. Here’s an example, it took me like 3 weeks in high school to understand what an array is and how it works. We were given one week and my fellow students cleared it on time. Very frustrating, but I persevered.

I would suggest taking some time to evaluate what, specifically, you are observing that leads you to believe you are a terrible developer.

Your one example is interviewing and OOP. This is a specific skill that you could practice: by reading, perhaps some memorization of terms, or even trying a side project with an intentionality of implementing in an OO way.

What are other things that you would like to be able to do, but feel that you are unable to? That can serve as a starting point for things to learn.

Bear in mind that there is no clear definition of a good or terrible programmer. The good ones are perhaps fast, or have deep knowledge of systems, or have wide knowledge of many types of technologies, or can write very fast code, or have a lot of expertise in an industry, or none or all of the above.

A good programmer is characterized by a set of skills that make them effective in the role of building things that are valuable to users. So the exercise is to try and identify those skills, and from there you could find ways to develop them.

I have in the past I have been in similar situations "Hmm I don't really know how this works but everyone else seems to know it". Stuff that keeps coming up at work with that nagging feeling of not knowing what is going on, but I should etc.

I've taken a deliberate approach to try to learn "bite sized" bits and then write it up like I am writing a blog-post or a training page or something with a bunch of "copy-pasteable" examples. Even if I am not going to show it to anyone else, I at least have my own reference material I can quickly jump back to to refresh my memory. Try to use something accessible from work/home/mobile etc - perhaps github or a personal wiki or something. I have a few nicely structured and interlinked things now that I like to refer back to from time to time when I forget the details of stuff I've had to go learn.

I think this is the "if you cant explain it simply, then you don't understand it" quote thing coming true. You need to learn it well enough to write it up. And then the process of writing up helps cement it in memory. And even if you forget, you have your own notes you can quickly flip up and re-read to remind yourself.

So e.g. you could start small with "basic OO concepts" write-up with a bunch of examples. For example I recently did this for HTTP CORS request and JavaScript modules. Now you've learnt it enough to write it down, and written your own personal learning material (that I find is way better than other people's since it is yours and your brain seems to prefer that IME) that you can go back and look at over and over.

The coolest bit I like about this approach is every time you come across the stuff you've gone out of your way to learn and write up when doing your job, you get a small little dopamine hit: "I know this. I've got this written down."

So what you're missing is the 'drilling-in' you get from a CS program. Don't worry! You can do it to yourself in much less time. The rest sounds like consequences of that as well.

First, start a memorization program. This means Anki, really. Start putting in the basic OOP concepts you've forgotten that you feel you should know. Then put in more as you learn it.

Second, start reading up books on interview questions and (a) practicing them and (b) shoving facts to memorize (complexity of algorithms, basic implementation notes for common data structures) into anki.

Third, you need a project that stretches your skillset and lets you work deeply with areas that you need development on. That's either a low-priority side project at work or something at home.

What you're describing is exactly what's normal for engineers I've met who didn't get a formal degree. Nothing that can't be fixed with a bit of studying and practice. Honestly.

If this all fails, you can always play MIT open courseware at 1.5x.

I feel we really need to normalize a tech hiatus in our industry. Whenever people see gaps on resumes it usually brings up red flags, but more and more I'm thinking people taking 1-2 year breaks from technology to work in another field will more than likely make them better (or at least more happy) people when they re-enter the tech workforce.

I wouldn't worry about it. We've all had bouts of imposter syndrome, or just realizing the limits of our natural abilities compared to others. There's nothing wrong with being a "working-class programmer", as long as the job gets done.

To become better and not "terrible", it takes persistence and continuous improvement - same as any other skill like playing a musical instrument. Keep writing code, paying attention to what's good and what feels messy. Keep learning new patterns and tricks, ways of organization.

What helps me the most are role models: find people whose works you admire, read their books, articles, the code they write. Find examples of software you'd consider excellent, and study what makes it good. Spending time with the best quality material, you'll become more familiar and fluent, to be able to produce works of similar quality and excellence.

In my experience good developers end up being good because they tend to do a lot of coding, read a lot on how to code correctly, and on how to improve their skills. Most people that I know don't do this because they need it, but because they are motivated to do it. So my question to you would be: do you like coding/developing? Are you up to spending time improving your skills?

You're saying you're not sure what to do about it, but from your post it sounds obvious to me that a next step would be to spend some time learning about CS, practicing coding/maintainability, and such?

I'd also add that not every developer needs to know every single aspect of CS, all the theory behind it, or even be an excellent coder. There are different areas in developing and you might find one that motivates you without needing a lot of any of the specific areas you mentioned.

You have one great advantage. You can self-teach. Don't try harder just focus on things you don't know.

I'm self-taught as well and my degree didn't do a great job of introducing concepts that are common place in CS degrees (and hence job interview hazing rituals). It took a long time of me feeling bad about what I didn't know to actually go out and learn about these things. Turns out most aren't nearly as scary or complex as you'd think. As with a lot of academic topics simple concepts are dressed up in domain specific terminology.

Also don't knock breadth of knowledge, lots of very useful prods to problems come from having a wide set of things to draw on. Sure it might be finished by a specialist but they didn't make that leap.

And if none of that is true for you, you are good enough to be here as evidenced by being here. Enjoy it for what it is.

Knowledge generally isn't something you brute force.

If your solutions are bad, read a book on Lisp (that wasn't intended to be a pun, even if On Lisp was a good book and would fit the bill).

If you're not planning on leaving the OOP space, read a Smalltalk manual. It'll probably stick more, and I've never read a Smalltalk manual that was worse than contemporary books on OOP.

Knowledge is a problem that can be solved programmatically: profile where your bottlenecks are, then read until you understand the topics.

It doesn't sound like you've had any formal education (from the hobbyist comment), which actually means your situation is pretty hopeful. There's a lot of low-hanging fruit for people without formal education to grab that can sometimes even double their abilities. Grabbing a book on algorithms would probably do you a world of good.

One big thing is making sure that when you're working on learning that you're focusing one one major stack if you can.

Pick a programming language you feel the most familiar with and then focus on learning it. If there's a framework or set of established best practices you can follow, try to stick with that and build some applications with that.

It's easy for us to get excited about working with new software and cool technologies, but that works against us when we're skill building. I couldn't count the number of times my mentors had to set me back on track when I was a younger developer, because I was off chasing something new.

Learning a lot about a bunch of technologies is useful, but you should make sure you spend some time getting familiar with one or two stacks in particular and forcing yourself to build skills there.

"programming for a while" and "been at it much too long" are pretty nebulous time frames. However, in general, I personally feel that time is not a great indicator of whether or not someone should be good at something.

My opinion is that you need to take a serious look in the mirror and ask yourself why you're not where you want to be at and if you want to get better. If you do, start with something small. You say you have no CS knowledge, so start there. Take an online course or find a syllabus from a CS course and buy the textbook. Don't worry about how long it takes you to grok it. Just work on it consistently and keep looking in the mirror and being honest with yourself.

If you end up not wanting to put the work in that's fine as well, move on to something that interests you (CS related or not). Good luck!

I think you need to make your concerns more objective and focus on what can change about each one.

You don’t seem to lack the critical thinking skills that are the hallmark trait of a good developer. The most objective criteria you can ever pull from is, regardless of the messiness or efficiency of the solution, whether you’re able to solve problems. If I asked you to do some work, and you could do it in any amount of time, that is the most difficult milestone many fail to achieve — And it seems that bar is more than met with you.

Perhaps you are worried with the quality of your solutions. I’d argue that in many situations, it comes down to domain knowledge. That is something you will naturally gain as you continue to code and read about CS theory, and especially so if you keep exposing yourself to new things out in the wild or at work. Brilliance is often witnessed or measured by the application of domain knowledge, but the genuine underlying brilliance comes from your ability to recognize patterns and having the discipline to see things through to a working solution.

You’ll almost always find yourself with company that can work faster or slower than you and be different shades of brilliant, because our brains gravitate towards different things when we hear about a problem. It is not easily compared, and when forced it easily becomes unfair and unproductive.

If you had to leave this post with anything, it’s this: don’t you dare judge your programming abilities by the typical big tech interview. They are created in a way that tries to gauge your critical thinking skills, and sometimes that is executed quite well, but more often it requires arcane domain knowledge that demands deliberate and specific attention you would be unlikely to give and come across otherwise. It is a specific process that is related to our daily work, but do not get it confused with the actual work we do. Many incredible programmers are rejected because they haven’t nailed the interview domain — that’s okay and can still be consistent with being a good developer. It’s a different isolated problem you can focus on.

i'd guess you're like most programmers.

we start doing it, get better, and then stop getting better. and that's it.

if i had to do it again and actually get better?

man, tough.

i would guess by 'better' we actually mean 'faster'. we could talk about quality/bugs/big-O/etc. but that's boring.

i know some of these will be off the table for various reasons, and not saying i would do them myself, but i would consider:

* ask better devs how to get better/faster. -- including shadowing them for an hour or two once a week -- this also includes learning how to use a debugger properly/etc. or anything else that you don't _have_ to know to be a dev * take a formal comp sci class. to me, the main goal of doing any kind of certification/class is to boost your self-confidence. of course you'll learn, but having confidence is important so you can dwell in a hopeful/contented present -- i.e. your coding won't be distracted. * learn LISP * _really_ learn the languages/tech you're working with. instead of being 'just' a hacker, take some amount of time each week to go deeper. * switch to a non-coding position :)

> I've come to realize I'm not very good at it and thats unlikely to change.

I may be wrong here but my impression from this comment is that you _want_ to improve, have a sense of where you can improve, but you have not found an improvement plan that works for you.

I can relate to the frustration of seemingly not being able to move the needle for your skills. One thing that has helped me over the years is adopting more effective learning strategies.

I highly recommend the books "A Mind for Numbers" by barbara oakley and "5 elements of effective thinking" (don't remember the authors) for some ideas on how to deepen your knowledge (so that you don't just feel like you possess purely surface level knowledge).

It's all about what you WANT to do. Most of us developers who have been in the game a long time have times where we have periods of doubt. Only you can know whether your doubts are real or not.

If you don't want to develop software there are many ways to use that experience. You could move into QA. If you can write, you could do technical documentation. If you can organize things well, maybe technical project management is up your alley.

There's lots of options, if you think about what your strengths are. You can use your development knowledge to make your other strengths into a great job. Or stick with development. Most of us aren't ____________ (insert rockstar developer you've read about in a blog, here).

Wow so many points to address.

First up, you wrote quite a bit but never expressed something super important - do you enjoy developing, do you feel happy doing it? Or is it just a job and a means to put food on the table?

Secondly, technology is a broad area and I actually knew plenty of developers who quit within 6 months and went into other tech areas (sales, project management, etc.).

Finally, I've been coding for decades and sometimes I feel crap about my own work too when I look at the quality of stuff that some others are able to produce. I'm at peace with that though, because I know my real skills lie elsewhere. That, and I'm happy doing what I do, I feel good about it and I figure if I keep trying I can only get better.

I spent 20+ years as a professional software developer, yet there were always days where I felt like I didn't know anything. That's part of the business - there's always something to learn and someone with more experience in some niche.

Separate from that - it sounds like you need to decide whether this is really something you want to do professionally. Technology is a vast field, so even if you decide you don't feel good about being a software developer / programmer, that's not to say there isn't a place for you.

Finally, I'm reading between the lines that you are primarily self-taught. Perhaps what's really needed for you to reach a level of comfort is simply more education?

There's going to be some overlap with my suggestions and other comments here, but I'll give them anyway. These are some thoughts that might be helpful.

1) I've known several great programmers who didn't have formal education and that definitely exacerbated their impostor syndrome. Try to be easy on yourself; as others have said here, it takes time to build up your skillsets and it's super easy to compare yourself with someone who seems to know more.

2) Maybe you aren't on the team that could help you grow the most. It sounds like you can hammer out code that does the thing you want to do. Going beyond that is about judgement and patterns and processes and experiences. The right team can really help you grow those skills. Does your team do code review? Do they do pair programming [0]? Maybe some sort of mentor relationship would be helpful?

3) I generally find solutions are easier to understand when I've personally struggled with the problem they are trying to solve. Look at code for problems you are familiar with and try to figure out what patterns/OOP concepts are being used in the solution. When you can wrap your mind around the problem, you can learn more from solutions.

4) Do you have an interest in the people/product side of software development? If so, you could try to move into a neighboring field. I've got a notion that a strong technical background would make it easier for product/project managers to do their jobs.

5) You don't have to be the best; most of us aren't :) if you enjoy the work you are doing and your employer and team approves of your work, then maybe you shouldn't stress about it? Work to improve your skills for the fun of it :)

6) Maybe pick a single language and focus on getting great at it. Preferably one that enables you to work on a passion project. All else being equal, Javascript is probably one of the best good to haves.

[0] - I've been programming for more than half of my life and I've only come to really appreciate pair programming in the last year. As a way of sharing knowledge, it may be the best approach.

Good luck!

For practical knowledge start with databases. Declarative is a great way to program, and a good starting point is https://use-the-index-luke.com/

About CompSci, it might get a bit dry at times. Seduce yourself into it, watch some Computerphile YouTube videos instead of a textbook. Then when you get the interest bug, search for what you are interested in. Try to keep it fun.

Once you built stamina, TAOC and SICP.

https://web.mit.edu/alexmv/6.037/sicp.pdf

I don't usually comment, but I had a talk with a coworker today who felt exactly the same and had a similar background. I told her that just by being humble to recognise that she has much to learn is a great sign she is willing to learn and to improve. Most mediocre professionals I dealt with would never be able to question their skills and are unwilling to improve and also they don't actually like their job. The feeling I get from your post is that you like what you do and that is also a major plus. Don't be so hard on you. Things will get better with time, I know they have been with me

As others have mentioned you may not be as bad as you think, especially if you enjoy coding as a hobby. But if you really are bad, then consider what related skills you may possess: Do you have strong opinions about what functionalities a program ought to have and how they should work? Are you good at project management? If so look for Program Manager jobs. This is not a people manager position, although it does require strong people skills. It is about defining what a product should be, working with designers and developers to get it implemented and talking to customers and collecting their feedback.

I was going to suggest looking at a QA/testing role. I bet you can break down problems, and you can trace through code (even if you didn't write it), and... QA is definitely a needed role in many companies.

Find one thing, one small dimension, that really interests you and do a deep dive. Let your interest become a thirst, completely master that.

From there everything else will naturally happen. The problem most people have in situations like this is too much shallow knowledge, which doesn’t lead to real stimulation of curiosity and creativity. Find something that fascinates you and go for that.

Alternately audit the MIT CS106b course for free online and see if the intro to CS stimulates you intellectually.

Second alternately change careers to something where you deal primarily with people (like sales or product) or where you spend time outside.

Width is hugely valuable. It allows you to quickly pick things up; quickly draw connections; quickly get up to speed.

What you need now is a chance to apply this. Get a thing you know roughly about and make it your job. You will pick on it more quickly than most people would think. Use that time to do it properly. The things you will learn from this will help knowing how to do it properly in all the other wide things.

Key here is to get a mentor that will help guide you, show you how to do it properly, and show you how to judge what is and isn't proper. That experience usually widely translates.

I would suggest you to find something that you like and makes use of your programming knowledge. There are things like programing music for example, check the live coding scene that also makes use of programming visuals for a concert. Look for: Sonic Pi, SuperCollider or TidalCycles if you wanna learn more. That is only one example of things that you can do if you know how to code, that would give you a momentum and discover that maybe you only needed more inspiration. There are opportunities making games, visual arts or ton of more stuff to explore thru coding.

If you don't have a CS education or a lot of professional experience yet there's no logical reason to expect you just "know" things - even what is considered basic knowledge. It's okay to not know what you don't know, you just need to address that.

Seek education (either a CS course or the multiple online courses), seek the help of a mentor (someone at work? friend w/ more experience?) and keep working on getting more experience.

Don't think people are "born programmers" - the good people invariably sank a lot of time into it.

Professional programming is less about raw ability and more about you being able to function within a team, discern what customers/clients are really saying, and deliver that in a way that doesn't create more problems. It's not as much about skill.

Many tech interviews are BS. You cross that bridge when you need to.

Also, there's a pandemic at hand, and that has an associated emotional cost that is not often accounted for. IME, it amplifies whatever fears you have.

Perhaps you've forgotten why you like to write software. Figuring that out might open a path forward.

I think you can still succeed at development if you want. Interviews are stressful-- don't take that trip up as a gospel reflection of your knowledge. And there's a chance that your "not very good" is better than a lot of people.

But it depends on what you want. There are plenty of tech paths from where you are that don't require hard cs knowledge. You can lean into the people side, building teams. You can focus on wiring up big systems with flowcharts. Or you can imagine this a speedbump and keep going in the direction you know.

Have you tried JavaScript?

All kidding aside, it takes ten years to stop being awful. If you look at code you wrote a year ago and think it looks bad, that's a good sign. On the other hand, if you look at code you wrote a year ago and it seems about as reasonable as code you write today, maybe you're right. If you love tech, there's always devops, and if you're in the same boat there, you can try project management, or become an expert in some niche field. Or maybe tech's not for you. That's ok!

I think we are similar in this aspect. I'm self taught as well, no CS knowledge to speak of from any formal training. The thing is, while most of my colleagues at work stopped caring about programming many years ago, I stayed with it.

The key to becoming a "good" programmer is basically just continuing to do it and to ask yourself "why did I design this like this" every now and then.

I've been at it for like ten years now, and every two or so years I'll have an "aha" moment where something clicks.

Maybe. Others have speculated maybe you have imposter syndrome. But maybe you're right.

So?

There is a wide spectrum of talent out there and you don't have to be in the top 1%, 10%, 50%, etc to be useful and successful.

My go to weed out question is 'write a function that, given a list of numbers, returns the min, max, median, and mean'. If you can do that, you'd have gotten an interview with me because I encountered so few who could just do that. People who had 'senior' titles at companies for years.

Being able to read and understand other people's code is a tremendous skill. Passing technical interviews is a skill in and of itself. Everyone has room to grow, and even the most experienced software engineers have gaps in their knowledge. Seek honest feedback from your peers, explore data structures, "Big O", and software design patterns (OOP isn't the end-all-be-all), and watch yourself grow. Most of all, believe in yourself, keep coding and making things happen.

I feel like I could have written your post, even today when I am in a fairly senior position and paid an uncomfortable amount of money. My advice for when this feeling gets overwhelming is to just put your head down and get a bit better than you used to be.

I don't mean study really hard, just learn any small new thing and over time you'll improve.

There's no rush and it's ok to be average. The fact that you say the "alternatives seem dreadful" means you are probably in the right career!

You have to learn on the job, which demands a different skill set than getting the job. You sound humble and willing to learn, which makes you perfectly qualified for junior positions. Don't be so hard on yourself, your primary focus should be to pass coding interviews. The rest will sort itself out, you will do fine. You'd be surprised how many people in this indutry get by without having much of a clue what they're doing, lol. It's human

> temporarily sounding smart or experienced

This is real talent. Don't underestimate it. Others can code like a superhero, but sound like a meathead when you talk to them (me often).

You have my sympathy. I'm not in exactly the same boat, but I sometimes feel really inept. It can be an awful feeling, especially for people whose self-esteem is on the line.

It might be helpful if you could share a few more details about your situation:

- Do you need to stick with programming in order to make enough money to survive and/or provide for your dependents?

- Is your current job at risk because of your programming skill level?

- Are there any other marketable skills you have outside of programming?

If you enjoy doing it, and you always stay open and ego-less about solutions you come up with and code you write then there's no need to worry.

The most important skill in engineering is an honest ego-less judgment. If you can admit that what you come up with is might not be good, at least you're leaving yourself open to seeking help and advice, incorporating suggestions, and dropping your flawed approach as soon as you find a better one.

"There's not a single language I'd consider myself good with"

If possible try to focus on a single language. Build a lot of different little things to cover the breadth of the language. Find a job where you only need to contribute in that language. When you become proficient at that language (this can take years!), then you can pick up other languages much easier, and you should feel more confident in your knowledge.

You know what I'm missing from your post? What you like to do.

I mean, why do you want to program? What do you get out of it? Which kinds of problems interest you?

Most of what you're talking about isn't that important. People don't pay you to be smart, they pay you to build things that will make them money. Interview culture is only tangentially related to this so it can be a bit weird but the #1 thing to be thinking about is "how can I make people money" and if you can talk about that you can usually get work with a smaller or less prestigious company.

First thing first, Do you enjoy programming ? If yes, then in my opinion you are already good.

One advice that I will give to you to become better is read. Read a lot of code from seasoned programmers, existing open source applications. You will understand patterns on how to approach problems. Talk to people about your design, build some opinions of your own (but dont hold onto them)

I will be happy to mentor if you want. Ping me on my twitter @namagg

Sound like you "feel" like you're a bad programmer. What are some specific examples where it can objectively show you as being a bad programmer?

> I also suppose that I'm an ok "hacker" in that I can get very interested / fixated on certain problems, although my solution is more likely to be a complete mess.

In what way is this a bad thing, and how specifically are your solutions "a complete mess?"

Keep it simple stupid. Simple code is better than hard to understand code.

It's okay to just write code for the sake of writing, but keep in mind the idea that what if new requests comes thru; given the current state, can the code be changed easily?

Code organization is a work in progress. Can your code be easily/separately testable?

Being good at coding is subjective.

Sometimes, it may just be the tool (programming language) you are using. Try Ruby. Try Vue.js.

The only reason I did well in my OOP interviews is because I read a book on OOP design patterns in the months before I graduated with my CS degree- I didn't know any of that shit from school.

The only reason I did well whiteboarding is that I spent months doing codewars.com bullshit to prepare for white boarding.

That's how people do well in these interviews- they game the system and optimize for the interview, not the job.

I feel very identify to this thread, I push myself to create software and yet don't feel I'm good enough as my peers. After feeling this way for a long time, I started learning how to manage developers instead of developing software. . I've come to realize I understand how software works and came still be involved in technology but on a different path. Hope this can helps!

People who can pass the whiteboard interview might have a problem persisting on long, not very challenging grunt things. Migrating that database over a period of a year. Overhauling some bits of that terrible UI. If you are already employed, look for the opportunity of improving something terrible that no one finds sexy enough. The role will be appreciated.

Learn some basic stats, get knowledgeable in another domain, mix it with your coding knowledge, and BAM! Data Scientist.

No, but seriously, you don't need to be a rock star dev. to succeed in the world of tech. Usually, it's when you're good enough in skill A, and good enough in skill B, and combine those, that you get some interesting opportunities.

It's either some kind of career change or identifying your weak spots and working on them. It's impossible to tell whether you're actually that bad or just being extremely hard on yourself. You don't have to be the best at what you do to make a living you know. Are you getting by? Can you keep a job for more than a year?

for me programming mainly consists of code organization, logic, and communication. i guess what are you bad at? Do you write code which is not logically sound? (missing edge cases, not being able to simplify which results in spaghetti logic), or do u write code that can't more or less be maintained, or is architecturally unsound or maybe you just don't understand the business problem you are trying to solve and have a hard time figuring out the right questions to ask and get the answers. Those are three different problems, for the logic part, i would try doing leetcode (as much hate as it gets), it will help you reason about problems better and studying the solutions give u new ways of thinking about certain things. Clarity is essential to coding, if you are not clear about what problem you are trying to solve, or clear about why your solution must work, then you will always feel like a poor developer.

This sounds like the majority of developers i've worked with. The main difference being you have self awareness.

It's not up to you to decide if you are good or not.

If you like coding, just keep doing it.

You will struggle at some things, be better at others, be a total ignorant in others. That's fine, it's part of any complex job.

You can decide to expand your area of knowledge too. You feel you don't know basic OOP concepts then work on that.

Check this hard against all our tendency to have "imposter syndrome". I've suffered from it in the past, and eventually I found my groove. Now I lead teams.

That said, you could also pursue engineering adjacent paths. Things like project/product management, QA engineering, sales engineering, etc.

As they say, there are three things that help - practice, practice and practice. Don't know CS? There is tons of books, courses and tutorials available. OOP in specific? Ditto. Being a better sw architect? Build some non-trivial hobby project, then rewrite and refactor until satisfied.

You are asking for an advice, but it is not clear what is bothering you. You think that you are a terrible developer. What is the problem you have with this?

Do you think this impedes you in your career?

Do you feel bad about not being good enough at work?

Are you unable to follow pursuits which interest you?

Or do you just want to be better and smarter?

Consider “Developer Advocate” or “Developer Evangelist” roles. You need to know how to code and be able to correspond with technical people, but your code won’t typically go into production. You might find helping others use a platform to be more rewarding than doing so yourself.

Do you have a Bible? https://biblehub.com/sermons/auth/greenwood/spiritual_blindn...

Sounds like you need a good dose of stoicism: Don't worry so much about how good you are or if you can get better. Just focus on what you can control, practice your programming and focus on areas which you enjoy. You'll get better with time.

How much time do you dedicate to learning?

If the answer is "over half an hour a day", then maybe you need more focus (like just focusing on your strongest language/industry and dropping the others) or a more structured learning approach.

You’re probably not as bad as you think. Most good developers I’ve met are critical of their own abilities. The worst developers I have met are critical of other’s abilities with no clue of what they are doing wrong themselves.

You didn't mention whether you really want to be a developer or not. Alternatively there are lots of ops and sysadmin jobs around, maybe that is an option. Or project management, business analyst even sales.

Everybody sucks at programming and there's always somebody who's better at it than you. Don't beat yourself up and keep doing what you enjoy. Things will fall into place when the time is right!

It sounds like you enjoy programming, and have managed to get a job doing it professionally. Maybe just try to enjoy it? You might not be the world's best programmer but why does that matter?

Could take up goat farming.

Have you looked into being a QA / Tester? Good ones are hard to find but you don’t need to be a great programmer even though you should absolutely try to automate most tasks thrown your way.

Operate with the skills you have and the connections you have made. There's room for many kinds of folks, doing work at every level and with most any tools. Its a big world.

The notion that you can reflect on yourself and see where you need to improve shows that you are indeed learning and growing as a programmer. Be patient.

Stay humble! Stay curious! Keep going.

I'm not sure what to tell you. I feel like I'm in a similar situation. I've stuck with it, and the past 5 years out of my 8 year career have been miserable.

Do some Hacker Rank and LeetCode exercises to evaluate your knowledge. Despite a lot of criticism those sites are very useful to train/evaluate knowledge of CS concepts.

Everybody sucks at programming and there's always somebody better at it than you. Just keep doing what you enjoy and things will fall into place from there.

Impostor syndrome etc..

Also, who are you to judge that you're not good enough? As long as you are employed or employable that does in fact mean you're good enough.

If coding isn't your strong suit but you're still passionate and knowledgeable about tech, maybe tech-evangelism or a PM role would appeal to you?

Money though right? You might do well as a test engineer

The thing with the IT field is that it's more an ocean.. with different currents every 100miles and you can drown in every one of them.

Is there a single ladder ?

You know you're a terrible developer, which automatically makes you a better developer than most of the terrible developers out there right now.

"What to do about" any self-revelation is a huge, huge topic. Some high level pointers:

1. Get some perspective, and a community

It's important to have a realistic assessment of one's skills and goals, strengths and weaknesses. Especially important about things that one thinks one is "terrible" at, or that one thinks one is "great" at.

There are a lot of lenses through which to see one's own capabilities, and it is not uncommon for a person to be a consensus of one about themselves. Others may think a terrible person is great, and vice versa.

It's important to have conversations with other folks about these issues, to understand where one stands. If one does not have such a local trusted "community" in which to have these conversations, that is the most important thing to try to develop. How to do so is its own huge topic.

2. Get an assessment of safety/vulnerability

In the near term, being sufficiently skilled and ergonomic to a job is important, for obvious reasons. If there are specific concerns- which to be clear are more about "ergonomics" and nuanced compatibility, than some intrinsic binary good/bad system- that's an important conversation to have with deciders at the employer.

How to have these conversations is another big topic all on its own.

3. Get an understanding of the landscape

Developer isn't the only job in the world. It's not even the only good job.

Think of "developer" as a "translator" job- operating on a "border" translating from one community of humans to another of very quick but exceptionally stupid beings. There are many, many, many other "translator" jobs, both more and less "technical" than developer and more and less "domain specific" (whatever industry the job is in). If one is uncomfortable in one kind of translation role, there are many other kinds, many other trajectories.

OP mentions having wide knowledge of other "tech" topics- I would advise thinking about that as a skill and think of it from a "translator" perspective. What community does the person with those skills translate from, and who do they translate to, and what domains would they work in.

There's much more, but those are my top level thoughts:

1. Get some perspective and a community.

2. Get a sense of safety/vulnerability.

3. Get some understanding of the landscape.

The world is a BIG BIG place. Lots of things to do, ways to help and engage.

Best wishes.

Buy and read the books "Cracking the Coding Interview" and "Domain Driven Design". You'll feel better.

Get a job where honesty is valued - because you are obviously an honest person.

You probably aren’t any more terrible than most other developers in the workforce. You really can’t be that bad because you are actually capable of some level of self-reflection, which is completely counter to the following.

I frequently observe that so many developers are experts, but they are experts in the way that my children are experts. They talk a big game to hear the sound of their own voice: Dunning-Kruger https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...

This is evidenced on HN right now where the top thread on the front page is a security anti-theory with many clueless comments full of conjecture not based on any form of experienced security practice. Information security jobs require certification and education while software jobs only require passing an interview. That said it’s easy for any software developer to believe themselves to be a security expert when in reality actual security experts won’t have anything to do with them.

Worse still is that since this is all vapor with ego and self worth riding on it people quickly become hostile on any discussions of the subject. That completely brazen emotional insecurity isn’t something common to actual qualified professionals.

easy. just stick it out for couple of years and move up to management. I know tons of ppl who did this.

Welcome to Sales Engineering Friend

Take a 10 day vipassana meditation course. Things might look different afterwards. You're not as bad of a programmer as you think. A good sw eng develops good mental habits and strength of mind before anything else, and you're brave enough to admit very hard and difficult realities, which puts you in the top 10% (at least). Good luck!

I've been programming for 40 years now and can tell you that I'm still learning. Embrace it! You describe keeping up with technology and keeping up with programming (switching languages/frameworks, etc) is no different. I'll also tell you that it's common for me to look at code I wrote six months ago and hate it. That used to concern me but I now realize that it's because my craft has improved in those six months.

Finally, others will surely tell you if you're a horrible software engineer. If you're getting constructive feedback from peers you consider superior to yourself, that's a sign they see something positive in you (why would they invest in you otherwise).

TLDR; Classic imposter syndrome

EDIT: Unless you've purposely misspelled your handle here, please, please, please make sure your spelling is correct in your software. It drives me nuts to search on a term I know should be in the code and fail to find it because of a transposition or homophone error!

Become a Product Manager?

Have you considered a product role on a technical product?

Feel free to reach out – happy to see if I can help.

You can always make a career in project management.

Give yourself more credit. The rest will come.

read Dijkstra's "Structured Programming". it will improve your programming reasoning.

Oh, this post hits home. Me too.

Maybe not a try harder situation, but a "try smarter" one. Many people are quite bad at learning because the process is counterintuitive. People mistake the feeling of mastery for learning, and it's not at all a productive feeling (if you want to learn; it's great at building self-confidence). My advice:

1. Focus. Acknowledge that you have surface level familiarity in many things, but that nobody can or should go deep in everything. Pick a language you're using professionally, and focus on that. If you don't currently have a job, try to pick something with broad applicability like Python or Golang. Also eliminate distractions: email popups, SMS, facebook, HN/reddit, Slack, all must go while you focus.

2. Study. Now that you have a language you want to build expertise on, study it methodically. Start an Anki[1] deck for it (and run through reviews daily) -- this is your tool to "try smarter". Get a set of beginner books from the library/amazon. Run through a codecademy or similar online course series. Make new Anki cards as you go. When you've finished a book, start working on the easiest online problems you can find online. Sort Leetcode[2] by acceptance rate -- many make the mistake of trying them in order, or by difficulty tag, and get frustrated when they hit a stumbling block. Learn from their failures. Once you solve a problem, review how others solved it and try to understand their code: did they use arrays or objects? did they use recursion? obscure syntax you need to look up? Which code base is cleaner, and easier to read?

3. Pace yourself. This is a marathon not a sprint. Improvement will be slow, and it will not feel good. If you have a job, I'd limit myself to 1 hour a day on professional improvement. If you're searching for work, I'd still limit myself to 4h daily. I try to spend about 10 minutes a day on Anki, just to retain what I've learned. People spend 4 years of their life on this stuff, after all.

4. Advanced study. As you advance beyond the material in step 2, look for conference talks at your level. Read through the official documentation. Start browsing StackOverflow or similar for your language tag[3]. Keep making Anki cards and reviewing them. Maybe pick up a CS textbook to shore up theoretical shortcomings and study 10 pages a day (textbooks tend to be denser reads than other reading material, so again, pace yourself.). Start with freshman undergrad stuff like Data Structures -- nearly universal in application and immediately useful. Or since you feel anxious about it, a book on OOP.

[1]: https://ankiweb.net/about [2]: https://leetcode.com [3]: Little known secret: the most viewed questions aren't the ones with the most votes, they're the ones that novices google the most. Top viewed question is like 'how to quit vim,' but those people don't vote up the question or answer. Unfortunately, SO doesn't make it easy to find the most viewed questions, presumably because cream skimming their 100 most viewed pages is an existential threat.