Ask HN: I'm a terrible developer, what now?
259 comments
> 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.
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.
I will second reading “Teach Yourself Programming in 10 Years”. I’m a self-taught programmer working with a lot of very smart CS grads, so I constantly find myself thinking that I’m not fast or good enough to keep cutting it. I remind myself of that essay very frequently to help with those feelings. It takes a long time to get _good_ at a skill like this, and you will always be behind someone else in that progression. The key is to find joy in the process and remember that it’s a long road.
> I’m a self-taught programmer working with a lot of very smart CS grads, so I constantly find myself thinking that I’m not fast or good enough to keep cutting it.
I'm just gonna throw my experiences out here: I'm self-taught who then got a BS in CS, and day-to-day, the vast majority of the skills I use are the ones I started developing before college. The CS knowledge is something that is extremely useful, but it's not a day-to-day thing - it's more like, it pops up in special circumstances, and the degree never really touched on the self-taught things.
I'm just gonna throw my experiences out here: I'm self-taught who then got a BS in CS, and day-to-day, the vast majority of the skills I use are the ones I started developing before college. The CS knowledge is something that is extremely useful, but it's not a day-to-day thing - it's more like, it pops up in special circumstances, and the degree never really touched on the self-taught things.
I love hobbyist development. I hate my professional development job.
I agree more than I can express in words.
In one of those scenarios I am writing code, working anticipating the needs of my users, and solving tough problems. In the other scenario I am mindlessly pushing buttons on top of some slow crappy framework while watching the slow motion train wreck of emotional insecurity all around me like a lake of syrup.
In one of those scenarios I am writing code, working anticipating the needs of my users, and solving tough problems. In the other scenario I am mindlessly pushing buttons on top of some slow crappy framework while watching the slow motion train wreck of emotional insecurity all around me like a lake of syrup.
I’m in an okay place right now as I’m not working a lot but in the past this has been a major issue for me. Hobby programming is relaxing and fun for me and it seems the more I dislike a job or task the more I feel compelled to code outside of work, which leads to overworking and neglecting other hobbies and responsibilities.
Maybe you just don’t like working? You wouldn’t be alone.
That's a possibility. I've enjoyed my job in the past though, like the first few year out of college. Then the BS and politics set in.
I first founded a start up for the fantasy of winning the lotto, which mostly didn’t happen. I stayed in start ups for the reality of being my own boss (as a founder) and the fuck-you status[1] of being a recognized world expert in a niche field. Maybe it’s time you switched career tracks inside your industry?
[1] Meant as comparison to “fuck-you money” meaning you’re rich enough to never have to work again, and therefore stand up to BS when you see it, not fearing the consequences. Alternatively, my “fuck-you status” is being so essential that you can just nope out of shit you don’t want to deal with and your employer works around it.
[1] Meant as comparison to “fuck-you money” meaning you’re rich enough to never have to work again, and therefore stand up to BS when you see it, not fearing the consequences. Alternatively, my “fuck-you status” is being so essential that you can just nope out of shit you don’t want to deal with and your employer works around it.
You mean switch to management or switch from finance to some other domain?
That's awesome that you're a world recognized expert. I hope I can at least be a company recognized expert one day.
That's awesome that you're a world recognized expert. I hope I can at least be a company recognized expert one day.
Do what you need to to work on something niche but very important, and then get recognition for your accomplishments. Work will then come to you and you can be more selective about what you choose to work on.
I agree as with this all well :/
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!)
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!)
I've been in marketing for a while and my technical chops extend to being able to "run the demo" and even that gave me opportunities that others didn't.
One of the most valuable people on my marketing team when I was at a large company was our "Tech marketing" person. Someone who could build the demos and POCs and answer technical questions from customers and prospects. Maybe something like this or a "Solutions Engineer" could be a good fit
One of the most valuable people on my marketing team when I was at a large company was our "Tech marketing" person. Someone who could build the demos and POCs and answer technical questions from customers and prospects. Maybe something like this or a "Solutions Engineer" could be a good fit
Also look into SEO. Its technical and marketing.
This is so true. I now get paid over twice what I got as a coder because what I do involves a combination of code knowledge, writing, and interviewing people. My skills in the last two make me a star there, and I am way more appreciated than I was in pure coding roles. Finding your "superpower" is the best thing you can do for your career.
What is your job title, or what is it commonly called elsewhere? I'm desperately trying to get out of coding roles but hate just leaving my senior dev titles to rot and not help me in my next step.
see above thread
That’s great!
What is it that you do for a Living now? Did you stumble onto it or made a gradual transition away from coding?
What is it that you do for a Living now? Did you stumble onto it or made a gradual transition away from coding?
I totally stumbled on to it - I was very lucky, and do my best to never forget that. I work as a consultant for a company that does deep technical due diligence on mid-stage tech firms getting acquired, mostly by private equity firms. I worked with someone who was doing it part time for the same firm, and then following that I was the CTO of a small startup for a year, which got acquired, so I went through the process on the startup end. When I decided to move on, I was able to get hired based on deep architecture knowledge but also the ability to interview people delicately in high stakes environments, and then write that up in an executive report and present to the private equity clients. It's an unusual job, and I think the average programmer wouldn't like it, but for me it's worked out really well and I now have the mental energy to do more open source and hobby hacking again. It's great to be in a role that actually capitalizes on my arts education and people skills as well as tech. :-)
Thanks for this. It sounds very cool but very niche. Seems like you'd need to know the right person to get into this sort of work. Congratulations on all your success.
Thanks! I wouldn't say you need to know the right person really, but you do need to be the right fit - which is a pretty odd fit. I think it would be a bad job for example for someone who was not ok with the work uncertainty as it's pure consulting. But if you are someone with high level (VP, manager, or C-suite) tech experience, strong people skills, and can write, and you think it would fit you, feel free to find me on linked-in and get in touch. We need more folks right now! :-)
This is a good list. I’d add that I’ve had two friends that didn’t like programming and became product managers and have been very successful at it.
I'd also add Quality Assurance to the list. The QA person on our team started out as an engineer and is much happier now (and damn good).
Is the salary drop pretty steep?
Definitely something to look at. I'm not a developer but have an undergrad in CS (very mediocre student). I really liked working through the degree but didn't feel cut out to do well in a career.
So I got a job in a different field and have been at it for quite a while now. Knowing the basics of programming and, more importantly, databases and data structures has really paid dividends. Once you get your domain (finance/marketing/sales/etc) knowledge down at wherever you work, you'll very quickly become a major asset and probably with a good dose of job security.
Instead of asking the engineers to query a database or build out solutions that interface with various BI tools, this would become part of your job.
So I got a job in a different field and have been at it for quite a while now. Knowing the basics of programming and, more importantly, databases and data structures has really paid dividends. Once you get your domain (finance/marketing/sales/etc) knowledge down at wherever you work, you'll very quickly become a major asset and probably with a good dose of job security.
Instead of asking the engineers to query a database or build out solutions that interface with various BI tools, this would become part of your job.
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.
why do we always say it's "imposter syndrome". not everyone can have "imposter syndrome". some people are actually imposters
It's a pragmatic thing. Telling an imposter syndrome sufferer that they have imposter syndrome is more productive than telling an imposter they're an imposter. On the internet when you can't be sure which person you're talking to, it's better to give advice that could be helpful if it turns out to apply to the person you're talking to, than to share commentary that wouldn't be too helpful either way.
i think it's less pragmatic and more "nice". such as telling people they can be anything they want to be even if they are 5'2 and want to be in the NBA
Programming ability is based on far fewer immutable characteristics and the pool of programmers is far less exclusive than that of the NBA, though.
I think it's more common that someone is simply not confident in their programming prowess and without that confidence may never achieve their goals. Knowing this, knowing that neither you nor I likely have the credentials or ability to prejudge someone's ability, and barring some obviously shady/impostor behavior like having bummed most of an assignment off of someone else and then asking for my help laundering it... you will almost always find me encouraging people to not feel like impostors and instead feel like programmers that are just early on in their careers.
I think such a default makes sense, and not even because it is "nice". Even pragmatically, people can often improve.
I think it's more common that someone is simply not confident in their programming prowess and without that confidence may never achieve their goals. Knowing this, knowing that neither you nor I likely have the credentials or ability to prejudge someone's ability, and barring some obviously shady/impostor behavior like having bummed most of an assignment off of someone else and then asking for my help laundering it... you will almost always find me encouraging people to not feel like impostors and instead feel like programmers that are just early on in their careers.
I think such a default makes sense, and not even because it is "nice". Even pragmatically, people can often improve.
People can't improve if they lack self-knowledge and others are wiling to bullshit them.
"I've got skill gaps as a programmer, especially at broad-level architectural design" is a belief that a mentally healthy person can have.
"If I express concern about my skill level, people will just say that I'm delusional" is a belief that will mess somebody up, especially if it is repeatedly re-enforced by reality.
"I've got skill gaps as a programmer, especially at broad-level architectural design" is a belief that a mentally healthy person can have.
"If I express concern about my skill level, people will just say that I'm delusional" is a belief that will mess somebody up, especially if it is repeatedly re-enforced by reality.
You're not replying to the comment I wrote and to the comment I was replying to.
There is no equivalence between "bullshitting people" and encouraging them to think of themselves as early on in their careers. There is no equivalence between encouraging someone to improve and ignoring someone's self-concerns about their skill level. There is no equivalence between someone currently lacking programming skill and someone being too short for the NBA.
In case I wasn't clear about it before, you shouldn't bullshit people who clearly aren't putting the work in or are having trouble getting to where they want to go. You should encourage them to think in a healthy way about their current progress and encourage them to find ways to get better and allocate the resources needed for their growth.
There is no equivalence between "bullshitting people" and encouraging them to think of themselves as early on in their careers. There is no equivalence between encouraging someone to improve and ignoring someone's self-concerns about their skill level. There is no equivalence between someone currently lacking programming skill and someone being too short for the NBA.
In case I wasn't clear about it before, you shouldn't bullshit people who clearly aren't putting the work in or are having trouble getting to where they want to go. You should encourage them to think in a healthy way about their current progress and encourage them to find ways to get better and allocate the resources needed for their growth.
> There is no equivalence between someone currently lacking programming skill and someone being too short for the NBA.
Agreed.
> You should encourage them to think in a healthy way about their current progress and encourage them to find ways to get better and allocate the resources needed for their growth.
Agreed.
> There is no equivalence between encouraging someone to improve and ignoring someone's self-concerns about their skill level.
It depends crucially on the words you use to encourage them to improve. I've often found 'impostor syndrome' to be stymie clarity. I might be guilty of replying to a comment that isn't quite your words though. apologies for that.
Agreed.
> You should encourage them to think in a healthy way about their current progress and encourage them to find ways to get better and allocate the resources needed for their growth.
Agreed.
> There is no equivalence between encouraging someone to improve and ignoring someone's self-concerns about their skill level.
It depends crucially on the words you use to encourage them to improve. I've often found 'impostor syndrome' to be stymie clarity. I might be guilty of replying to a comment that isn't quite your words though. apologies for that.
This guy was 5'3" (though, granted, that's the record and a significant outlier): https://en.wikipedia.org/wiki/Muggsy_Bogues
Definitely made his mark and I can only imagine the feelings of imposter syndrome he had.
Fun anecdote for those who aren't familiar: He's one of the players in Space Jam whose playing talent is stolen by the Monstars.
I think this just makes his point.
Telling an imposter syndrome sufferer that they have impostor syndrome without any additional evidence is telling a pyrophobic that you won't sell them a fire alarm -- and that they shouldn't expect anyone else to.
I think the main issue with imposter syndrome is everyone realises they suck but don't realise so does everyone else. If you look at the majority of private code bases in the world, they'll look like crap. Even the stuff getting leaked out of the major companies look like crap. Even some of the offical open source stuff coming out of the major companies get pulled apart for valid reason.
Everyone feels like they suck at programming, because they do, it's ok, everyone else sucks too.
Everyone feels like they suck at programming, because they do, it's ok, everyone else sucks too.
> If you look at the majority of private code bases in the world, they'll look like crap
I sometimes think that the first set of people working on most software are just trying to get it to work at all, with limited expertise and lots of duct tape. Then come some journeymen who have to add more things. And, well, when I am writing code it tends to look a lot like the stuff around it... things just get Progressively worse!
I am not a dev. I don't intentionally write bad code, but the code I write sometimes hits prod. I don't really know what "good" and "clean" really look like. Just "works" and "doesn't".
I sometimes think that the first set of people working on most software are just trying to get it to work at all, with limited expertise and lots of duct tape. Then come some journeymen who have to add more things. And, well, when I am writing code it tends to look a lot like the stuff around it... things just get Progressively worse!
I am not a dev. I don't intentionally write bad code, but the code I write sometimes hits prod. I don't really know what "good" and "clean" really look like. Just "works" and "doesn't".
You're correct that not everyone will be able to / will want to every single job. "X is not for everyone" is true, where X could be programming, or managing, or sales, or teaching, etc. We all have a finite amount of time on this Earth and no one person can learn everything about everything - sooner or later you gotta decide what things you're actually going to do.
So when someone posts something like this, why is it good to talk about impostor syndrome? Because encouraging a growth mindset [0] leads to better results. Saying "Yep, you suck" isn't going to lead a person to try harder. Saying "Yep, it's natural to feel that way, everyone feels that way sometimes, and Science^TM confirms it (aka Imposter Syndrome)" allows people to step back, go easier on themselves, and focus on what they do have control over (time invested, quality of time, how they get help when they're stuck, etc, etc).
One point I'd like to make to the OP: Whether you go into professional programming or not I think that the skills, background, and experience that you're accumulating can pay off. Maybe you decide that you'd rather not program all day. Perhaps you can go into a technical & interpersonal job, like management, or developer relations, or program/project management, or Q+A, etc, etc. There's a lot of jobs in the tech field and having a background in programming will make it a lot easier to talk with programmers.
Good luck to you, whatever you choose.
--------- [0] https://www.psychologytoday.com/us/basics/growth-mindset
So when someone posts something like this, why is it good to talk about impostor syndrome? Because encouraging a growth mindset [0] leads to better results. Saying "Yep, you suck" isn't going to lead a person to try harder. Saying "Yep, it's natural to feel that way, everyone feels that way sometimes, and Science^TM confirms it (aka Imposter Syndrome)" allows people to step back, go easier on themselves, and focus on what they do have control over (time invested, quality of time, how they get help when they're stuck, etc, etc).
One point I'd like to make to the OP: Whether you go into professional programming or not I think that the skills, background, and experience that you're accumulating can pay off. Maybe you decide that you'd rather not program all day. Perhaps you can go into a technical & interpersonal job, like management, or developer relations, or program/project management, or Q+A, etc, etc. There's a lot of jobs in the tech field and having a background in programming will make it a lot easier to talk with programmers.
Good luck to you, whatever you choose.
--------- [0] https://www.psychologytoday.com/us/basics/growth-mindset
An imposter is: "a person who pretends to be someone else in order to deceive others, especially for fraudulent gain."
So if you're honestly questioning whether you are capable or not, then by definition you're not an imposter. Some people are actually imposters but they are not the ones openly asking for advice about it and asserting that they don't belong.
So if you're honestly questioning whether you are capable or not, then by definition you're not an imposter. Some people are actually imposters but they are not the ones openly asking for advice about it and asserting that they don't belong.
So is "fake it til you make it" fraudulent or good advice?
Early in my career I faked it many times just to get those jobs. I dont have a degree so i did what I had to to survive. I didn't fake any documents or something like that, I just lied in interviews and lucky for me they didn't background check deep enough.
Now I don't have to lie about my education. I would like to think its because of my skills I developed over 16 years but it could also be the times changing.
Like many here I also enjoy hobby development projects. I also suffer from imposter syndrome probably because to some commenters' point, I am an actual imposter.
Now I don't have to lie about my education. I would like to think its because of my skills I developed over 16 years but it could also be the times changing.
Like many here I also enjoy hobby development projects. I also suffer from imposter syndrome probably because to some commenters' point, I am an actual imposter.
Telling someone to fake it, means you are telling him to lie.
Telling someone he is probably too harsh on himself, is not telling him to lie or cheat.
So no, fake it till you make it, taken seriously, is not a good advice.
So no, fake it till you make it, taken seriously, is not a good advice.
Things are not that simple. Many times I have encountered that people do not know that they know something, lack of confidence can undermine their abilities. By default they will say their perceived version of "truth" that they "do not know it" while in fact they do. In eyes of their boss lack of confidence can be perceived as reason for demotion or endless cycle of easy tasks that do not lead person to improve their skills and learn by doing. Fear of judgment can be parasailing.
Also, sometimes pressure forces person to learn something in a very short period. So, if you "fake it", but also put significant effort to quickly learn what is needed to succeed then it is not lie but a 'future promise' it would be lie only if you don't succeed.
Also, sometimes pressure forces person to learn something in a very short period. So, if you "fake it", but also put significant effort to quickly learn what is needed to succeed then it is not lie but a 'future promise' it would be lie only if you don't succeed.
The phrase "fake it till you make it" is also bad programming. Variable names should be intention-revealing.
Because the question contains many common symptoms of a good programmer:
The author can easily read code from others, there is no implication of other people complaining about his code, and can program in several languages.
There are also stuff that commonly causes impostor syndrome up there:
Very general surface level knowledge, problems with interview questions, and difficulty on understanding "very basic OOP concepts".
The only thing pointing to a bad programmer is that "although my solution is more likely to be a complete mess", but it's thrown there without any context on problem difficulty, code size or environmental restrictions.
Any of the best programmers I have ever met could have written that same question if they got reasons to doubt themselves.
The author can easily read code from others, there is no implication of other people complaining about his code, and can program in several languages.
There are also stuff that commonly causes impostor syndrome up there:
Very general surface level knowledge, problems with interview questions, and difficulty on understanding "very basic OOP concepts".
The only thing pointing to a bad programmer is that "although my solution is more likely to be a complete mess", but it's thrown there without any context on problem difficulty, code size or environmental restrictions.
Any of the best programmers I have ever met could have written that same question if they got reasons to doubt themselves.
Most are not. If you bet on the capability of most people to be able to reach a reasonable goal, you're likely to be pleasantly surprised.
Because the alternative is less likely/wrong - This is just the best you're going to get and you just have to accept it.
also TIL impostor and imposter are both correct spellings (even though I got dinged for the o spelling in middle school)
also TIL impostor and imposter are both correct spellings (even though I got dinged for the o spelling in middle school)
The impostors aren't (IMO) concerned with improving their skill level. They're normally just worried about what position they can hold on to, how much money they can make, or how to hide their incompetence.
People who are actually bad at what they do rarely realize it! I think that's the difference between an imposter and "imposter syndrome".
From the wikipedia page: In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people with low ability at a task overestimate their ability. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability. Without the self-awareness of metacognition, people cannot objectively evaluate their competence or incompetence.
[deleted]
> People who are actually bad at what they do rarely realize it
Apparently, they may often think that they are good at it! See https://en.wikipedia.org/wiki/Dunning–Kruger_effect
Apparently, they may often think that they are good at it! See https://en.wikipedia.org/wiki/Dunning–Kruger_effect
Because this guy doesn't seem like an imposter
Imposter don't present themselves as such.
Because actual imposters don't care.
My guess is the real imposters probably don't even realize they're imposters. Think the Dunning–Kruger effect. Often the most insufferable developers also have big egos and no drive to learn.
Mayvr. I've felt this on and off for maybe the past year or two alternating with short bouts of motivation
Imposter syndrome is not something that just goes away magically. People often feel it throughout their entire careers. Also right now everyone is under additional stress, so I wouldn't be surprised if this is exacerbated.
Also, you may want to get checked for ADD/ADHD if you find you can fixate on things, but have trouble focusing on broader tasks.
Also, you may want to get checked for ADD/ADHD if you find you can fixate on things, but have trouble focusing on broader tasks.
You're a couple years into developing and feel like an imposter? Welcome to the club!
Literally every programmer I know has been wracked by doubts and existential dread over their skills. I've mentored a lot of interns and I always stress how impostor syndrome is normal, everyone gets it, including everyone above them in their teams.
My history is more of the "programming wunderkid", been programming since I was 13 and (like many on this site) find reading HN and programming news relaxing and recreational. I say all of this to highlight the fact that I got impostor syndrome. It was particularly bad the first few years. Once you realize everyone feels this way it's liberating. In fact you can even use impostor syndrome for good; either by motivating your learning or by empathizing with others.
I'm constantly learning and growing, which means I still feel like an impostor in these new areas. I'm the Kubernetes expert for multiple startup and government projects, but I still feel like a beginner in out of his depth.
The way I see it, you have two options. You push your comfort zone, and get comfortable with being uncomfortable, or you stagnate. You either become a constant learner who always has a niggling impostor syndrome, or your knowledge becomes static.
Be like Socrates. "I know that I know nothing."
Literally every programmer I know has been wracked by doubts and existential dread over their skills. I've mentored a lot of interns and I always stress how impostor syndrome is normal, everyone gets it, including everyone above them in their teams.
My history is more of the "programming wunderkid", been programming since I was 13 and (like many on this site) find reading HN and programming news relaxing and recreational. I say all of this to highlight the fact that I got impostor syndrome. It was particularly bad the first few years. Once you realize everyone feels this way it's liberating. In fact you can even use impostor syndrome for good; either by motivating your learning or by empathizing with others.
I'm constantly learning and growing, which means I still feel like an impostor in these new areas. I'm the Kubernetes expert for multiple startup and government projects, but I still feel like a beginner in out of his depth.
The way I see it, you have two options. You push your comfort zone, and get comfortable with being uncomfortable, or you stagnate. You either become a constant learner who always has a niggling impostor syndrome, or your knowledge becomes static.
Be like Socrates. "I know that I know nothing."
Be kinder to yourself, and at the same time try to design a plan that motivates you to learn more.
Usually, if you have impostor syndrome, a good cure is to learn something that is unique in your environment and makes you feel valuable. Or to build something on your own and see it finished and working.
Usually, if you have impostor syndrome, a good cure is to learn something that is unique in your environment and makes you feel valuable. Or to build something on your own and see it finished and working.
> "alternating with short bouts of motivation"
I think you might have pinned it here. It may be that you are just fine as a developer but that you have burn out or some other mental health issue honestly. I don't mean that as a negative. I was burned out very badly a few years back and I felt exactly like you describe. It led to anxiety, depression, a lack of motivation, pain... nearly a mental breakdown.
I had been on a bit of anxiety medication for a while. I had a near breakdown (some would say a total breakdown). My doctor literally said "You need to go see a therapist. I mean it. You can either go on your own or I am locking you into the trunk of my car and taking you and you won't be let out until you talk to someone." (So, my doctor threatened to kidnap me, and thank goodness!) So I went and talk to a therapist. And talked. And talked so more. For months, then years. It has changed my life for the better. I am a better developer. I work better. I am a better husband and father. I FEEL better.
I really can't recommend highly enough that you take a look into your mental health. It will help a lot. So what now? Talk to a professional.
I think you might have pinned it here. It may be that you are just fine as a developer but that you have burn out or some other mental health issue honestly. I don't mean that as a negative. I was burned out very badly a few years back and I felt exactly like you describe. It led to anxiety, depression, a lack of motivation, pain... nearly a mental breakdown.
I had been on a bit of anxiety medication for a while. I had a near breakdown (some would say a total breakdown). My doctor literally said "You need to go see a therapist. I mean it. You can either go on your own or I am locking you into the trunk of my car and taking you and you won't be let out until you talk to someone." (So, my doctor threatened to kidnap me, and thank goodness!) So I went and talk to a therapist. And talked. And talked so more. For months, then years. It has changed my life for the better. I am a better developer. I work better. I am a better husband and father. I FEEL better.
I really can't recommend highly enough that you take a look into your mental health. It will help a lot. So what now? Talk to a professional.
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.
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.
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.
> I wonder if the technical stack you are working with is not a good fit for you.
That's a good point. I quit all of web dev because I couldn't stand the culture of constantly shipping dynamically typed code and being unsure of whether I typo'd a variable name.
Now I work more in systems programming and find it much, much more sane, if more difficult at times.
That's a good point. I quit all of web dev because I couldn't stand the culture of constantly shipping dynamically typed code and being unsure of whether I typo'd a variable name.
Now I work more in systems programming and find it much, much more sane, if more difficult at times.
Csn you provide more details on what you're doing now and how you made that transition?
Sure. I had some experience in systems programming, doing some hobby Win32 programming, and then systems programming as needed as a backend dev in a few domains.
From 2010-2012 I tried out webdev, and didn't really like it. My clients were happy with my work, but I ultimately ended up quitting the culture of shipping things and hoping for the best. (I know they're not all like that.) With little plan in hand, I started self-studying compilers because they seemed far from webdev, and I was interested in them.
I eventually found a job at a small R&D shop where I worked on an LLVM transform. Because they were small they couldn't guarantee that I'd always have that work, but I got almost two years of maintaining that transform under my belt. From there I continued to self-study interpreters, eventually landing another project there involving DSLs, compilers, interpreters and high-performance code...all of my favorite things. It was a lot of work. From that, I found a genre of companies that worked well for me and didn't involve fighting to get into a FAANG company.
That's where I am now, and I feel more valued here than anywhere else since I started working 15 years ago. Now I realize there are a lot of opportunities out there I could be interested in.
Webdev's hegemony tends to suck all the air out of discussions of computing. There is a huge need for skilled generalists in multiple domains that have nothing to do with HTML/CSS/JS.
The trick is to find the people who share your computing aesthetic, and can teach you things. Once you feel like you have not much more to learn from them, start looking elsewhere.
From 2010-2012 I tried out webdev, and didn't really like it. My clients were happy with my work, but I ultimately ended up quitting the culture of shipping things and hoping for the best. (I know they're not all like that.) With little plan in hand, I started self-studying compilers because they seemed far from webdev, and I was interested in them.
I eventually found a job at a small R&D shop where I worked on an LLVM transform. Because they were small they couldn't guarantee that I'd always have that work, but I got almost two years of maintaining that transform under my belt. From there I continued to self-study interpreters, eventually landing another project there involving DSLs, compilers, interpreters and high-performance code...all of my favorite things. It was a lot of work. From that, I found a genre of companies that worked well for me and didn't involve fighting to get into a FAANG company.
That's where I am now, and I feel more valued here than anywhere else since I started working 15 years ago. Now I realize there are a lot of opportunities out there I could be interested in.
Webdev's hegemony tends to suck all the air out of discussions of computing. There is a huge need for skilled generalists in multiple domains that have nothing to do with HTML/CSS/JS.
The trick is to find the people who share your computing aesthetic, and can teach you things. Once you feel like you have not much more to learn from them, start looking elsewhere.
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.
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.
"Eh, I've seen tons of terrible developers who still collect a pay check."
Terrible developer here. I can say the stress of never knowing when you might get fired and having job options is very stressful.
Terrible developer here. I can say the stress of never knowing when you might get fired and having job options is very stressful.
Do you not have a senior developer at your company you can pair with as a mentor? This should be someone who you can look to for not just software skills, but career management skills.
I'm intermediate and have filled the role of senior dev and tech lead in the past (unofficially). My problem is that tech was a dead end (Neoxam and FileNet).
Now I'm stuck learning/relearning multiple languages (python, java) and stacks (ECS, lambda, Dynamo, S3, etc). I've been on this team for 6 months and have never used the same tech twice. For me, that makes it very hard to become an expert when there's no chance to use the same tech again - I need some repetition. I want to get to the point where I don't have to think about the stack or the semantics/features of the language and just focus on crearing a great solution. That's never going to happen here.
I also lack the drive anymore. I've been screwed over, passed over, and had my prior positions outsourced to contractors. I feel like why should I try hard if the company is just going to throw me away again.
Now I'm stuck learning/relearning multiple languages (python, java) and stacks (ECS, lambda, Dynamo, S3, etc). I've been on this team for 6 months and have never used the same tech twice. For me, that makes it very hard to become an expert when there's no chance to use the same tech again - I need some repetition. I want to get to the point where I don't have to think about the stack or the semantics/features of the language and just focus on crearing a great solution. That's never going to happen here.
I also lack the drive anymore. I've been screwed over, passed over, and had my prior positions outsourced to contractors. I feel like why should I try hard if the company is just going to throw me away again.
Keep your head up. The dysfunction of an individual business definitely does not mean you are a shhitty developer.
It does. Because of the disfunction, I am no longer feeling the drive to become an expert. Why become an expert if the company has thrown me away in the past (outsourced my job to contractors)...
Oops, that should read not having job options.
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.
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.
This is a very insightful comment. I can attest this happens in other fields too, like music. If you compare yourself to how fast the unusual people progress, you'll be depressed. But in talking about this with some music profs who have taught thousands of people, they've said those people have their own challenges (ie. not able to function in society and thus hold down gigs), and very frequently slow learners get there too....but only if they give themselves permission to take the time.
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.
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.
Being a generalist doesn't get you a job though. I'm in a similar position to OP and, while I can figure out a problem given enough time and motivation, I can't adequately answer most interview questions and I fail most coding interviews. I don't know if I use ES5 or ES6 or whatever and I don't know the difference between Java 7 and Java 8 (8 has lambda expressions or something?) and I don't see why I need a wealth of experience in the latter in order to maintain a Java application. Before every interview I have to look up the difference between an interface and an abstract class because, while my brain knows when to use which, I can't explain it in concrete terms and I don't know the difference between the two across different languages. I can't explain DI and I have no fucking clue what a FactoryFactoryBean is because I've never had the need to write one so how am I supposed to have this experience? I don't have enough time to dig into the particulars of a language or its compiler/vm/interpreter or microservice design patterns and I'm sick of having to be passionate about programming outside of work in order to even stay employable. All of the jobs I've ever had have been through friend connections and that well's starting to dry up with the pandemic and all. I'm sorry for the frustration dump, but I've truly grown to fucking hate this field. I'd just quit and be a bartender or something if I didn't have tuition debt to repay.
> Being a generalist doesn't get you a job though.
It probably doesn't get you an absurdly-high-paying FAANG job rewriting code someone else rewrote the year before, but I guarantee you any competent generalist in IT can get well-paying job without much trouble. There are a lot of places out there that can't afford to have a specialist in everything they do, but can afford the kind of person who is willing to tackle any problem put in front of them.
It probably doesn't get you an absurdly-high-paying FAANG job rewriting code someone else rewrote the year before, but I guarantee you any competent generalist in IT can get well-paying job without much trouble. There are a lot of places out there that can't afford to have a specialist in everything they do, but can afford the kind of person who is willing to tackle any problem put in front of them.
I don't know what to tell you man. I live in the South and I've interviewed at my fair share of IT cost centers. They tend to ask the same kinds of questions. The ones that don't end up paying $50k/yr for 60+ hour work weeks and treat their developers like dirt.
Ever interviewed for a position in a profit center? Small and medium sized consulting companies can pay well and tend to value their developers.
They're a lot more competitive too.
I second this.
Hey, I think, what you need to do is go meta. Think about the way you think. If your brain know when to use an interface or an abstract class, then the next time when you make a decision like that, spare a few moments to think about why. You might not get an answer but you will get hints. If you do this enough times, you will understand why you decided to do what you did. Thus you will will what's the difference between an interface and an abstract class.
I hope what I said makes sense. Try not to feel frustrated. Frustration never helps.
I hope what I said makes sense. Try not to feel frustrated. Frustration never helps.
I feel the same way and it causes me to think about suicide all the time.
Oh man, that's heavy. I'm of the opinion that you have to enjoy what you do for work to have a decent quality of life.
If you don't enjoy it, find something else! If you hate it so much that it makes you suicidal, doubly so. I tried doing the "practical" money making thing, and it made me miserable. Programming is the thing I found later that brings me joy.
Find what brings you joy, and do it. Until you know what that is, explore. Hop on a bike and ride across the country. Move into the woods. Go volunteer in a developing country (some positions provide room and board, you just have to get there, but the pandemic does complicate things). Literally anything other than 1) what you are currently doing 2) suicide.
I have been there and I feel for you, truly. No matter how it feels, there are other options. Take care of yourself and hang in there. From someone that has been to the very bottom and made it back, it can get better.
If you don't enjoy it, find something else! If you hate it so much that it makes you suicidal, doubly so. I tried doing the "practical" money making thing, and it made me miserable. Programming is the thing I found later that brings me joy.
Find what brings you joy, and do it. Until you know what that is, explore. Hop on a bike and ride across the country. Move into the woods. Go volunteer in a developing country (some positions provide room and board, you just have to get there, but the pandemic does complicate things). Literally anything other than 1) what you are currently doing 2) suicide.
I have been there and I feel for you, truly. No matter how it feels, there are other options. Take care of yourself and hang in there. From someone that has been to the very bottom and made it back, it can get better.
How do you do all this with family obligations, reliance on health insurance, and little fallback cash in the bank? This is a good idea for someone struggling to figure out what they want to do in college but a lot of us millennials who can't hack it on the coast are still paying down debt and are anchored to our situations.
The short answer is you can't. The ability to fuck off because I hate my job has always been important to me, so I've always lived frugally, didn't have kids, never had an expensive wedding, etc. I have some cash in the bank and recently quit my dev job because it was also making me very mentally unhealthy.
>recently quit my dev job because it was also making me very mentally unhealthy.
What do you do now?
What do you do now?
Hey, total stranger on the internet here - I have no qualifications to help someone with suicidal thoughts but I have been an engineering manager for a decade and I'm pretty decent at it. If you ever want to talk to someone about your career and don't feel comfortable opening up to your own manager about it, please reach out. Email is in my profile.
Think as in a passing thought of "fuck all of this why bother" , or Think think? The former I'd estimate 90% of people have from time to time.
But if it's Think think you need to let some people close to you about this and look for some professional help, no point in suffering like this.
Sending you hugs
[deleted]
Seconded on the imposter syndrome point. I definitely have days in my life when my internal narrative sounds just like your post, but if I take a step back I'm much further along than at those low points.
Another issue is that it's entirely possible that your current role doesn't challenge you to learn or retain CS concepts nor deeper aspects of the practical tools you use. Many jobs can be done very well using the same shallow toolkit repeatedly. If that's the case, it's not really a question of your ability, but maybe you can start actively looking for projects to force yourself to start learning more.
Another issue is that it's entirely possible that your current role doesn't challenge you to learn or retain CS concepts nor deeper aspects of the practical tools you use. Many jobs can be done very well using the same shallow toolkit repeatedly. If that's the case, it's not really a question of your ability, but maybe you can start actively looking for projects to force yourself to start learning more.
[deleted]
I'm not sure I'd recommend highlighting your potential lack of competence to your manager.
Depends on their situation and environment. If they have a good manager who recognizes that "helping someone to grow" is better for both sides of the interaction than "drop 'em and take a risk on hiring someone else", and/or if they're in a situation where the engineer can accept the risk that their manager isn't that, it's certainly the best bet.
Employees are an investment. An employee who can take the initiative to flag-up areas that they could benefit from training is valuable.
Employees are an investment. An employee who can take the initiative to flag-up areas that they could benefit from training is valuable.
Comments like these remind that while I miss the US personally, I don't at all miss it professionally. While things in my current country (Norway) err on the side of making it damned near impossible to fire someone, the upside is as a manager I can have very frank conversations with the people on my team about how they're performing. They don't live in any fear of this, they see it as a way to improve.
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.
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 :)
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 :)
> The reality is, every good programmer thinks they are awful, and every awful programmer thinks they are amazing 10X developers.
I wish people would stop saying this. It just makes me question myself more. Am I good because I think I'm bad? But then that means I think I'm good, but I'm pretty sure I'm not... and on and on and on.
Maybe I just overthink stuff
I wish people would stop saying this. It just makes me question myself more. Am I good because I think I'm bad? But then that means I think I'm good, but I'm pretty sure I'm not... and on and on and on.
Maybe I just overthink stuff
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 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?
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?
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.
My point is: I hope some advice acknowledge that maybe OP is correct about his real skills.
> But you know they are bad, no tests, no best practices, not even consistency between code.
The question is: Why do you get away with writing bad code?
That's as much your fault as it is your manager's or the product owner's. My advice, therefore, would be to go find a job where you're held accountable and where you get pushed (to learn how to) to deliver quality work.
I myself am working for an IT consulting firm that predominantly hires math/physics graduates fresh out of school. And while they're usually very smart, they typically lack programming experience and might be rather bad coders. When they start. After one or two months of extensive training (both on and off the job) and a ton of advice by their colleagues, they're usually much better already. Years later they will be among the best coders under the sun because that's what our firm – and especially our clients – demand from them.
The question is: Why do you get away with writing bad code?
That's as much your fault as it is your manager's or the product owner's. My advice, therefore, would be to go find a job where you're held accountable and where you get pushed (to learn how to) to deliver quality work.
I myself am working for an IT consulting firm that predominantly hires math/physics graduates fresh out of school. And while they're usually very smart, they typically lack programming experience and might be rather bad coders. When they start. After one or two months of extensive training (both on and off the job) and a ton of advice by their colleagues, they're usually much better already. Years later they will be among the best coders under the sun because that's what our firm – and especially our clients – demand from them.
...so nobody notice the mess your solutions are. They work.
I’ve found what’s a mess and what’s not is often subjective.
Oftentimes the comments a guy makes in a code review come down to whether he enjoyed his breakfast that morning.
If your code solves the problem, it’s good enough.
I’ve found what’s a mess and what’s not is often subjective.
Oftentimes the comments a guy makes in a code review come down to whether he enjoyed his breakfast that morning.
If your code solves the problem, it’s good enough.
Couldn’t disagree more.
If your code is unintelligible, has no comments, cannot be maintained by anyone, has poor style, no tests, generic variable names, copy pasted code all over but solves the problem, it’s not good enough and should very much incur a code reviews with things to fix before it’s merged. That doesn’t depend on the reviewers mood either, it’s down to best practices and company standards.
I currently work at a place where “it solves the problem, ship it” is the norm. Codebases are 1–10 years old (depending on the project). It’s a living nightmare. No one knows how anything works, making trivial changes take weeks and will break something else, turnover is very high because life is too short to put up with such a low code quality and quality of life... I don’t recommend this approach of “if it solves the problem it’s good enough” unless you want to be unable to hire, kmrrtain your staff, and have a miserable work environment with constant fires everywhere.
If your code is unintelligible, has no comments, cannot be maintained by anyone, has poor style, no tests, generic variable names, copy pasted code all over but solves the problem, it’s not good enough and should very much incur a code reviews with things to fix before it’s merged. That doesn’t depend on the reviewers mood either, it’s down to best practices and company standards.
I currently work at a place where “it solves the problem, ship it” is the norm. Codebases are 1–10 years old (depending on the project). It’s a living nightmare. No one knows how anything works, making trivial changes take weeks and will break something else, turnover is very high because life is too short to put up with such a low code quality and quality of life... I don’t recommend this approach of “if it solves the problem it’s good enough” unless you want to be unable to hire, kmrrtain your staff, and have a miserable work environment with constant fires everywhere.
Being mediocre or bad at something is not the reason to left.
The reason to give up is if you do not want to do it anymore.
> 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.
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.
> if at the end of the day you can build something even if you write sphagetti code it's _something_.
I'd suggest that spaghetti code disqualifies one from anything but the smallest teams and projects. "Coding" is what we do on our own time w/o the likelihood of others interacting.
> 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.
+1 understand that most code comments are 0.5% more effort for 1% better result, death by 1000 cuts, style things. They by no means denigrate your skills (unless you believe yourself to be perfect, godlike) and do have value for the team because those gains compound.
I'd suggest that spaghetti code disqualifies one from anything but the smallest teams and projects. "Coding" is what we do on our own time w/o the likelihood of others interacting.
Software engineering is what happens to programming
when you add time and other programmers. [1]
> 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.
+1 understand that most code comments are 0.5% more effort for 1% better result, death by 1000 cuts, style things. They by no means denigrate your skills (unless you believe yourself to be perfect, godlike) and do have value for the team because those gains compound.
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.
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.
Unfortunately, this will teach you a bunch of cool stuff that you won't ever actually get to use in a real world job.
You'll go for an interview and they ask you about REST APIs or SQL.
You'll go for an interview and they ask you about REST APIs or SQL.
Most of your list is pretty irrelevant for the jobs out there in the real world that earn companies money.
I understand your concern, but I guess we are just coming at it from dueling perspectives.
I don't think being a good developer, which I will define as being able to understand and manage the choice / trade offs you are making when you write code, has anything to do with being marketable or being good at a job interview.
The OP is a hobbyist developer that wants to get better at making things. They specifically called out OOP principle as a weak point. I think this will help more than memorizing algos out of CLRS or learning the latest wizbag javascript doodad. I do admit those will likely get them hired more readily.
As an aside, I meet a lot of really great developers that have the worst case of imposter syndrome. They have great intuition, shave off bad affordance, balance growth well with quality and have the basics of code etiquette down pat. Yet the think they are golem SO CP cobblers, not fit to be seen doing this job. Lifting the vail of the language, knowing that there is no special trick some made up 10x can do that you can't, helps with that.
I don't think being a good developer, which I will define as being able to understand and manage the choice / trade offs you are making when you write code, has anything to do with being marketable or being good at a job interview.
The OP is a hobbyist developer that wants to get better at making things. They specifically called out OOP principle as a weak point. I think this will help more than memorizing algos out of CLRS or learning the latest wizbag javascript doodad. I do admit those will likely get them hired more readily.
As an aside, I meet a lot of really great developers that have the worst case of imposter syndrome. They have great intuition, shave off bad affordance, balance growth well with quality and have the basics of code etiquette down pat. Yet the think they are golem SO CP cobblers, not fit to be seen doing this job. Lifting the vail of the language, knowing that there is no special trick some made up 10x can do that you can't, helps with that.
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.
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.
Great post, I also think that approaching it from a higher level like product design is best. Knowledge travels down do lower levels easier than it travels upwards.
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.
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.
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.
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.
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.
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.
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.
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.
You could take some computer science classes, then you'd get some CS knowledge.
Or even just watch some of the foundational class lectures available online for free.
If you haven't been through CS in school, watching MIT's CS50 classes will introduce you to a lot of basic concepts and language that you'll find helpful.
If you haven't been through CS in school, watching MIT's CS50 classes will introduce you to a lot of basic concepts and language that you'll find helpful.
Nit. CS50 is Harvard (EdX). 6.001x is MIT's. But I agree. If someone hasn't studied computer science (but does have some programming knowledge), one of those is a good place to start.
Oops. You're right, it's Harvard, not MIT.
And hardly a nitpick. It verges on a fail. Sorry.
And hardly a nitpick. It verges on a fail. Sorry.
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.
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.
> The key is not what you have been until today. The only thing that matters is what you want to do.
I like this
I like this
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.
I would still fail a programming interview.
I'm a team lead who gets rave reviews from pretty much every client and senior manager I work with. I did an interview a couple months ago and was basically verbally assaulted with trivia questions I couldn't answer. Something people need to realize is that just because interviewers are in a position of power doesn't mean they know what they're doing and it doesn't mean there's something wrong with you if you fail one. Maybe you just don't fit their specific role, maybe they have a stupid evaluation model, maybe your skills are just not quite there. None of that is a statement about your general ability or worth as a human being. We need to stop defining ourselves by our jobs and how well we fit into the incentive structure of the economy and particular organizations. To everyone on this thread who is feeling like shit: you have value, don't let a fucking abstract entity like a business or a shitty interviewer or even a lack of a specific skill convince you otherwise. There's more to life than selling your talents for money.
Thank you for these words, i needed it.
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:
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.
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
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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."
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.
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.
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'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.
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.
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.
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!
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.
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 :)
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).
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).
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.
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?
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!
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
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
[deleted]
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.
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.
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.
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.
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.
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!
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.
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.
[deleted]
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.
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!
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).
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?
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.
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.
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?
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
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
[deleted]
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?"
> 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.
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.
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.
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.
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.
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?
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.
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.
It’s a very tempting career change some days!!!
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.
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.
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 ?
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.
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.
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!
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!
It was a purposeful misspelling lol
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.
[deleted]
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.
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.
[deleted]
Main problem is I'm not sure what quite to do about it. I'm not sure this is a "try harder" type solution, as I've been at it much too long for brute forcing to be realistic, but most of the alternatives seem dreadful. Not sure what options I have given my strengths and weaknesses.