

Ask HN: Career trajectory? I'm terrible - hoboon

hi, hn.<p>I&#x27;m in a fix, of sorts. All I&#x27;ve done in my career is fix bugs and I feel that I&#x27;m actually quite terrible at programming. I have no value in an engineering organization.<p>I&#x27;ve been on a few interviews and they always say I&#x27;m smart and have technical chops but not the experience they want. Even taking them at face value, I do realize that for someone whose been a software engineer for 7 years, I don&#x27;t have the experience of 7 years; more like 1-2 years a few times over.<p>How do people get good at this? Practice I assume. I mostly did embedded or c++ daemon work, again, fixing bugs. I know I did not satisfy engineering people at my last job; I tried to move in to a dev role and they said they were dissatisfied with me as an engineer.<p>I&#x27;m trying to learn more about programming and practice as much as I can but it feels like it&#x27;s so insurmountable. I can&#x27;t envision anyone wanting to hire me.<p>I feel like I&#x27;ve wasted the last several years and I should go away and do something else and let the real engineers work.
======
lsiebert
Dude, you sound like you are just depressed. You can't read that much into
things. We are surrounded by signals telling us how awesome other people are,
because they show us what they are proud of, and only the coolest of that
really get's seen.

Second, remember the best companies hiring are still basically only a little
better than 50/50 at predicting success after 18 months, and success isn't a
simple thing. If you support developers they do a lot better then if you just
throw them in the deep end, but still there are a bunch of factors,
expectations, time demands etc. that can effect the perception of a
programmer.

Third, coding ability isn't a singular thing. It's a mixture of various
talents, skills, and knowledges that each programmer has to a certain degree.

But let's say that you are a shitty coder. The truth is, with all the talk of
rockstar programmers who do 10x the work of the normal, most coders are not
awesome, and most code isn't written by rockstars, and that code runs, and
works, and ships/is put into production. There are people who will hire you,
and there is work for you, engineering work, that is a valuable contribution
to a company. This is a pretty good time to be in tech, and there are plenty
of positions.

Even if you lack innate talent, you can work to develop your skills and
knowledges and become a better programmer.

Or it's perfectly fine to do testing, automation, sys admin work, or take a
management role.

Still, I think you are probably selling yourself short, because you feel
discouraged.

~~~
hoboon
> and there is work for you, engineering work, that is a valuable contribution
> to a company. This is a pretty good time to be in tech, and there are plenty
> of positions.

This just drives home how much of a loser I really am. I live in SF. I'm
surrounded by it.

> Or it's perfectly fine to do testing, automation, sys admin work, or take a
> management role.

I think tech support or other stuff might be my only option. I'll take an
internship if I have to but at the altitude of late-30s, it hits me harder
that I've wasted many years.

> Still, I think you are probably selling yourself short, because you feel
> discouraged.

Or it's a fact. I have to lie from now on to sell myself.

Thanks for the advice.

~~~
scmoore
If you'll pardon my diagnosing you over the internet, you sound very
depressed. I've been there and it's difficult to deal with, but not
impossible.

For one thing, you've got to take a step back and realize that you're
distorting things quite a bit. For example -- "I have to lie ... to sell
myself". You need to focus on your strengths, for sure, in an interview --
everyone does. But that's not the same as lying, and thinking of it that way
is turning it into an all-or-nothing proposition. Either you are a perfect,
all-knowing software deity, or you are a liar pretending to be competent while
hoping not to be discovered. These kinds of all-or-nothing scenarios, and
other distortions, are very easy to fall into when you're depressed. Or so
I've read, and confirmed in myself and others diagnosed with depression.

In any case I would suggest that your first step (as in, today) be to hunt up
a therapist or psychiatrist. After all what is there to lose by doing so? It's
a challenge in and of itself, so you might mentally make room for the
possibility that it might take a few tries to find someone who gets you. Also
[http://devpressed.com/](http://devpressed.com/) might be worth a look. But
this thread, and that site, should be in addition to talking to a mental
health professional. I'm not a doctor, I think you should talk to one.

Good luck, and if you want to talk, email me (in profile).

EDIT: I see xaa has also recommended you talk to a professional. I'll echo
some of their advice, particularly that part of the challenge is the same as
most doctors -- you're going to have to be the expert on your own case. That
doesn't mean you have to do everything alone, but you have to recognize that
they're going to stick with a standard playbook, and you'll need to advocate
for yourself and work to discover what works for you and what doesn't. Also
agree that therapy/psychiatry isn't a cure -- it's a mental tool box. But it
can be a very powerful one. Best of luck!

------
pauleastlund
This is exactly what good managers are for.

Go get _some_ job doing what you know how to do -- hunting down bugs in
embedded C++ code is a skill the right employers will pay good money for.
Don't apply for full software engineering jobs if you don't feel confident
doing that. Be up front with your hiring manager about what skills you have
now and what skills you want to develop. ("Up front" does not mean "ruthlessly
self-critical." Do not say, "I'm actually quite terrible at programming," or,
"I have no value in an engineering organization." Say, "I've done plenty of
coding but to be honest most of my professional experience to date has been
tracking down hard-to-find bugs and I think that's where I'll be able to
provide the most value from day 1.")

Apply around to a lot of places, and look for somewhere that values the skills
you have but also will allow you to develop into the longer-term role you want
to hold. Make sure you meet your hiring manager before you accept a job, make
sure you talk through this with him, make sure you look him or her in the eye
and believe that they are a good person and are sincere about helping you grow
into the next phase of your career.

~~~
hoboon
> Apply around to a lot of places, and look for somewhere that values the
> skills you have but also will allow you to develop into the longer-term role
> you want to hold.

Applying for jobs is what I've been doing. Why would you assume I wasn't?
Perhaps because I forgot to mention that in my original post since everyone
seems to assume that.

Anyways, in general because bug fixing is not considered desirable work, it's
hard to find people who want to do it. I'm willing to do it again at this
point, despite having sunk considerable costs into learning about data
science/engineering. So, it's hard to find people.

Guess what? They won't let people leave sustaining engineering because it's
hard to find replacements. So, no sustaining engineering manager is going to
seriously entertain talking about tossing out an sustaining engineer. It's
either fix bugs or quit.

In fact, that was the situation my boss did to me last time. There's no
feature or tool development but he sort of lied about moving up and around the
company when I was brought on.

So I quit and tried to take initiative and now it's not working out like I had
tried to.

~~~
pauleastlund
I didn't mean to assume that you weren't applying for jobs. You said you'd
been on a "few interviews," and I was trying to stress that what you're
looking for -- a company that both wants the skill you have now and will help
you gain the skills you want to have in the near future -- is probably
uncommon, and you will have to cast a broad net.

You're right: many companies hiring for bug-hunters don't offer a good path to
real developer roles from there. And many will not be totally honest about it.
Those are difficulties. That's why the search will be hard. But there are good
managers out there who will deal straight with you, and there are employers
that will let you make that transition -- and even assist you in making it.
You're just going to have to really look for them.

~~~
hoboon
> You're just going to have to really look for them.

yes, that's true. But how long? Especially compared to the brilliant people
fresh from school I'm competing against. Thanks for the advice, though. and I
wish i had talked to someone like you years ago.

I guess I drew up the unlucky lottery and I'm trying my best to fix it.

------
topkai22
Let's break it down a little. First, you probably aren't terrible at
programming. I've seen terrible at programming, and if you are even LOOKING at
code worth millions of dollars a minute someone thinks you are above average.
Besides, you are actively looking to improve, which terrible coders don't do.

You are in a technical space (C++/embedded) that seems to have more than its
fair share of technical machismo and bullying, so you may be picking up on
that. And frankly, I get the feeling SF is much worse developer culture than
the others I've experienced. You can find a different culture. I've spent some
time doing C#/JS/SharePoint development for small teams and that is a
completely different experience than writing a massively scalable ETL
pipeline.

What is "good at this?" I think you are trying to say "How do I become a
technical ninja" but I think you really want to ask (or what I want to answer)
is "How do I advance my career?" In my opinion, the answer is pretty much
"Fake it till you make it." Pick something good you did and fly it to the
rafters. You are apparently fixing bugs on a multi-billion dollar software
platform- you'll impress the pants off of many hiring managers with the scale
you are working at alone. Advertise that. Make the conscious part of yourself
believe and act like you are super-competent and people will start assuming
you are. You'll get that new job or possibly that internal advancement
(although it sounds like your current org is wrong for you), and eventually
your subconscious will start to believe it, too.

Of course, that's hard if you are depressed. As other commenters have
mentioned, go see a mental health professional, make sure you diet is healthy,
get plenty of cardiovascular activity, and check on your sleep.

Good luck!

------
smt88
Your #1 problem is self-esteem. I strongly recommend that you see a therapist
or counselor. Self-esteem, confidence, mental health, and success are all
deeply intertwined.

Your #2 problem is that you think writing code is the most important skill of
a programmer. It's not. _Learning_ is. Are you a fast learner? If so, there
are hundreds of companies that need you.

With a little additional training, you could be highly paid as a QA engineer
or project manager (depending on your personality and enjoyment of those types
of roles). Or, you could just find a small-ish company that would allow you to
wear multiple hats: bug-fixer, but also programmer of novel code. You'll get
better as you go along.

You also keep talking about "engineering". The majority of software companies
aren't writing code in a way that could be called "engineering". It's sloppy,
and the developers are embarrassed by it. But that's what you do when your
time/budget are very limited.

~~~
hoboon
> Your #2 problem is that you think writing code is the most important skill
> of a programmer. It's not. Learning is. Are you a fast learner? If so, there
> are hundreds of companies that need you.

I'm told in my interviews that I don't program well enough for them.

I'm not so stupid that I don't know what you're talking about. I'm not the
fastest learner that I know of. I do like learning new things, however.

Given your answer, I'm thinking you aren't a hiring manager or don't get
involved in interviewing much. If a candidate takes too long to answer a
question, even if they get it right eventually, it's as bad as getting it
wrong, in the eyes of management.

> You also keep talking about "engineering". The majority of software
> companies aren't writing code in a way that could be called "engineering".
> It's sloppy, and the developers are embarrassed by it. But that's what you
> do when your time/budget are very limited.

It's industry parlance for the area of the company that writes novel code, as
you put it.

~~~
smt88
I'm not a hiring manager, unless "hiring manager" = "someone who hires". I've
interviewed more than 100 devs and hired a few dozen. I've done it internally
(leading a dev team) and externally (as a consultant). Assuming I don't know
what I'm talking about, just because your experience differs from mine, is
presumptuous. You're the one who came to HN and asked for advice, after all.

My response didn't imply that you're stupid. Everything I know about you is
from your short post. Maybe you already know everything I said. If so, there's
no harm done if I re-state it. If not, then I've helped you. I always err on
the side of "too much information" instead of "too little" when helping
someone.

~~~
hoboon
I was wrong, then. I apologize.

But I felt like you were talking down to me -- like you don't trust me.

Yes, I understand solving problems is part of the job. Every software engineer
has had that told to them forever, it seems. It's common advice.

The feedback I've gotten in interviews is that I can solve problems but I
don't translate them into code quickly enough. Again, spending too much time
on an answer I would eventually get right.

This is why I think the advice about solving problems not code is not really
true. Look at the various tomes about ace-ing job interviews: it's all code
problems. And you have to do it quickly. Solving the problem is not enough for
most interviewers; they want code in a few minutes, too. Perhaps you are the
exception.

Thanks anyways.

~~~
smt88
No hard feelings. Text is a poor medium to convey tone, and misunderstandings
happen. It seems as though you're unnecessarily hard on yourself, and I hope
that improves as time goes on.

What you're describing in interviews (penalizing slower coders, even though
they'll eventually get the right answer) has been discussed a lot on HN
recently.

The consensus seems to be this: a lot of companies do code tests, and they do
care about speed, but those companies are wrong. It's not a good way of
testing someone's usefulness as an employee.

That said, there definitely are companies who do not hire this way.

As you spend more time coding on your own, rather than fixing bugs, you'll get
faster, and these tests will no longer be an obstacle. Eventually, your resume
will be good enough that the tests won't be necessary.

If you think you're at a dead end, or you've made mistakes you can't fix, I
know how you feel. I've been there several times. And things ended up working
out so well that I looked back and wondered how I could have felt so little
hope.

The same will happen for you, but it does require work. That might include
coding in your spare time, going to networking events, asking your friends for
tips on job openings, applying to more than 100 companies, or even a drastic
career change. But all those activities I mentioned _do_ pay off.

Best of luck. It sounds like you're smart and have a lot going for you.

------
rifung
You're obviously depressed, and as a result being ridiculous. I've met many
SDEs who are pretty poor developers, and unless they are completely fresh,
they usually just aren't good because they don't care.

You obviously do care, and realize (and exaggerate I imagine) your
shortcomings. Better still, you are trying to improve by asking here. So, I'd
like to begin by saying that while you may (feel as though you are) not good
enough, you just need to be patient because I'm sure one day you're going to
be awesome.

Now for more practical advice, I would say the best thing to do would be to
just code more. That sounds stupid, but it really is the best thing to do.
Even better would be to code with someone else on a project together, so that
you can see each other's code. I definitely learned a lot from reading other
people's code, either from learning new things or also from finding ways to
improve their code.

If you can't find someone else to code with, that's fine, but try to read some
code. Finally, I would really recommend you try to do a relatively big
project. The reason is that when you work on small projects you don't really
have to worry about maintenance and thus code structure, but when you work on
bigger projects having your code be concise and clean is much more important.
Even having good style is important.

In any case, I'm sure you'll be fine! Find something that interests you and
keep doing stuff! If you can't think of a cool project you can always go on
HackerRank or Project Euler. Maybe you could even prepare for this year's
Google Code Jam! You could then start building your own little library for
competition problems!

------
geebee
Ug, sorry to hear that.

Of course, I don't know your specific situation. But I've had stints where my
main job was to fix bugs and/or add features to an existing code base, and I
don't consider it "easier" than designing and developing a greenfield project.
In fact, I consider it considerably more difficult.

To fix a bug you typically have to 1) figure out someone else's build and
probably partially documented dependencies, 2) adapt to someone else's
programming style and conventions, 3) figure out what the feature was supposed
to do without the benefit of the business context in which it was created, 4)
figure out how that feature was implemented in code, and then 5) not just get
into the mindset of the programmer who wrote it, but keep enough distance from
that mindset to find the flaw.

In short, I consider "bug fixing" on a new and unfamiliar code base to be a
pretty substantial mental challenge.

I wish the industry gave more credit to what you've been doing. I have found
that open source communities do give a great deal of credit to people who can
get up to speed quickly with a code base and do things like improve testing
coverage, fixing bugs, or improving documentation.

That said, have you tried creating a side project? Probably the best thing to
do would be to think of some software you think would be interesting, and try
writing it. Pick a relatively new stack, and create a web app, or mobile app,
or something that you think would be useful. I know, this is a lot of extra
work on top of an existing job. But it might get you out of the rut.

------
AnotherMarc
Reading through your responses, I'm not sure I can give you great advice
because the two large software companies I've worked at welcomed moves out of
what you call sustaining engineering. It was a pretty natural and repeatable
process of fixing small bugs to fixing larger bugs to fixing bugs that
impacted multiple areas of code. People would get assigned other people's
regressions to fix. At that point, even if a sustaining dev manager doesn't
want to let you go, the new dev team will damn sure want to have you.

If you really are terrible at programming, or maybe you just don't enjoy it
very much, then explore something else. But if you do enjoy it, you have to
figure out what's going wrong before you can make a plan or get good advice to
fix it. You say people were dissatisfied with you as an engineer. Why? If you
ask a more senior engineer or a manager what you can do to improve, you'll get
a better answer than HN will be able to give you. But you have to be willing
to hear some things that might not make you feel good. In the long run,
though, it will be worth it.

~~~
hoboon
> Reading through your responses, I'm not sure I can give you great advice
> because the two large software companies I've worked at welcomed moves out
> of what you call sustaining engineering

I've heard this is what they do at MS, possibly others. It sounds great. My
first job was like this but we got acquired by cisco.

I really do like programming even if I'm terrible at it and other engineers
think I'm terrible. If I try to work on my own stuff I feel like less of a
loser even if it's shit. Other engineers just said that I took too long to
understand stuff, asked too many questions. I do panic when I can't figure
stuff out and google doesn't produce results.

Thanks for the advice.

~~~
AnotherMarc
Couple things. You identified one thing to work on, which is not to panic.

The other thing is that if that's all the feedback you got, it's pretty
subjective. If you have a good relationship with an engineer or architect you
admire, you might run some of your questions by them, along with the steps you
took to figure them out on your own. I would ask them whether they thought the
questions were reasonable ones, and whether the steps you took to resolve them
made sense.

If they say yes and yes, then take heart and keep at it. If they say no, you
can ask them their advice for speeding up your understanding or better ways to
search for answers. Once you open up your thought process to them, they will
be able to better help you, if they care to.

To that point, whatever you do, avoid getting defensive or arguing back. Only
further questions you should ask are ones where you need more clarification.
It may be tough, especially if you don't agree, so be ready for that. Good
luck!

------
JSeymourATL
> How do people get good at this?

Embrace the suck of your underachievement and get busy learning to master your
craft. Lots of guys have been in your shoes before, you might find Robert
Greenes book a timely read>
[http://www.goodreads.com/book/show/13589182-mastery](http://www.goodreads.com/book/show/13589182-mastery)

~~~
hoboon
> Embrace the suck of your underachievement and get busy learning to master
> your craft.

That's what I'm asking. How do people get good at this? I figure it's practice
and acting on things I can control but I don't know what I don't know.

~~~
xaa
Having gone through this stage myself and now mentoring others going through
the same thing, I think it is an inevitable part of learning to code. A few
pieces of advice:

\- The first key is to keep trying -- it WILL get easier and become second
nature. Problems that once challenged you will become trivial as you develop a
personal bag of tricks and reusable code, and generally "level up".

\- Become opinionated -- decide for yourself what programming
languages/paradigms/methods will solve problems the quickest (and correctly),
because that's what bosses care about. Maintainability and "best practices"
CAN be important, but it depends on the exact industry and type of code you're
writing. Each paradigm has something to offer, but not all paradigms fit all
programming styles. You will need to try several different languages to
achieve this. I would venture that it is almost impossible to be a good
programmer without writing a substantial program in at least a half-dozen
languages.

\- Find a mentor. Ask them how they think you should proceed when you get
stuck, ask them about what aspects of your code need improvement, and
_listen_. If it is your boss, and they have the programming expertise, they
will almost certainly be glad to help, because it will make you more
productive. Otherwise, a friendly and experienced coworker.

\- Code on the side. Lots of people want to work 9-5, but you will
unfortunately not be competitive in this field if you do. Pick side projects
that are fun and challenging. Volunteer patches on a OSS project, or find a
nonprofit to do (challenging and interesting, not "can you build our
website?") work for. If you want to, these side projects can also be for your
job, but don't feel obligated to do this.

\- Build a personal library of reusable code and algorithms suitable for your
field. For example, mine is bioinformatics, and I have amassed over the years
a toolbox of scripts and algorithms in various languages. I can then string
together my code to solve a problem in one line of bash that would be hundreds
of LOC if developed de novo. Put a lot of effort into documenting and
generalizing this library (but also don't re-invent the wheel, use external
packages when they exist).

\- Familiarize yourself with critical relevant libraries in your field and
language of choice. For example, in Python, this could be numpy, pandas,
scikit-learn -- packages that have broad applicability. If you need statistics
or linear algebra, learn it (for me, the best way to learn these abstract
subjects is by using them -- implementing a statistics method or linear
algebra-based algorithm by reading a paper and translating the equations into
code).

EDIT: one final point that is very important:

\- Realize that the purpose of programming is to solve a problem, NOT to write
code. If you can find a simple way to solve a pain point for your boss or
stakeholder, that is far better than writing hundreds of LOC. Sometimes this
can even take the form of explaining to them why a certain feature they have
requested is actually a bad idea. Somewhere along the hierarchy above you,
there is a person who does not know how to code, and only cares about results.
Always be asking yourself: how do I make this person happy with a minimum of
effort?

~~~
hoboon
Thanks for your advice. I do code on the side. I have a github and some OSS
patches I've put in. Feedback from interviewers regarding it is that it is all
amateurish and not so great/clean/beautiful.

Usually people don't look at it, though. People usually don't read my resume
until they're at the desk, which seems to be common. I've hidden .gifs in the
README.md files so they get triggered when someone loads. Though, the way
github works specifically is that it loads it into a cache some where onto ec2
so I don't know who is looking at what; I just know someone is looking, and
possibly others, too.

I do like python and am familiar with pandas/numpy/scikit (although all three
are kind of more appropriate for experimentation than finished products).

> Realize that the purpose of programming is to solve a problem, NOT to write
> code.

I mentioned this to someone else: during an interview, code is all I have. I
do take too long to solve some problems but I do solve them. I usually trip up
translating them into code.

I remember one time I wanted to make a way to have JIRA automatically know
what fix version goes into a bug but my boss said don't waste time on it. One
of his complaints was that I would get fix versions wrong. I'm starting to
wonder if maybe I didn't have a good boss.

~~~
xaa
OK, then I misjudged your situation a bit, and in this case, your problem is
likely not the code side of things, but the communication side.

One thing is that you are obviously down on yourself. That is self-defeating
and self-reinforcing, because if you are unconfident, people will also assume
that there's a reason, and most likely the reason is that you are incompetent.
It's not fair, but it's true, and it's very easy for people to sense if you're
not confident. This is independent of whether you actually ARE competent or
not.

Also, if someone says or implies that you aren't competent (as it sounds like
your boss did), that does not mean they're right. YOU are in the best position
to know your strengths and weaknesses, and rather than telling yourself "I'm
not good at this, I should take a job in tech support", you should be asking
yourself, "how do I get (even) better?". Which you have, in this post, and
that's a great start. It helps to remember how far you've come since you
started. If a boss repeatedly treats you as if you were incompetent, it's time
to find a new one. A good boss will be helping you get better, always
challenging you but not throwing you in over your head, and giving you a good
deal of independence. I myself would prefer independence, challenge, and
feeling valued at the expense of a less shiny title or even a pay cut, but
that's a personal choice.

Secondly, people do not make hiring decisions solely or perhaps even primarily
on technical skill. In my experience, they want a candidate who has a certain
skill threshold, and above that, they weigh other factors. Those factors
typically include: how well do they fit in with the team, how self-directed
are they, how well can they communicate to find what the real problems are,
and can they solve them. So, in an interview, unless the interviewer is an
idiot, you will get more "points" for clearly showing that you know HOW to
solve the problem rather than showing you can write a syntactically correct
program on the spot on the whiteboard. Again, communication.

I would be remiss if I didn't add that it helps a lot as an applicant to know
or be known by someone at the company. That is the real purpose of using
GitHub as a resume: not so you can say, here, look at a sample of my code, but
so that someone you're interviewing with might say: "OH, you're the author of
the widely-used XYZ library? Well, we can just skip the formalities and start
discussing salary." I can almost guarantee that if one of your repos has a few
hundred stars, you will not get any negative comments about your coding style.

Finally, your referencing Python as a prototyping language and mention of JIRA
make me strongly suspect that you're at a BigCorp. BigCorps are, in my
opinion, not a good place to learn, grow, and get independence. You will be
treated as a replaceable cog. I would apply at a place where I could find a
niche, master it, and be valued, rather than be viewed as "bug fixer #1057".

~~~
hoboon
this is very helpful advice. i thank you for it.

I think I might be below your threshold, though.

I agree with you about a great github. though i don't know what i could make
that people would want in the dozens or hundreds.

my quip about python was more about np/pd/scikit. python is great.

i'm distantly aware that i'm whining. the past couple of months have been bad.
in the past week i think i may have had a solid psychotic break.

~~~
xaa
> I think I might be below your threshold, though.

No. At least for a huge fraction of the available jobs. What you have said,
plus the very fact you are on this site, makes this almost certain. You need
to realize what "incompetence" really looks like, and how bad many developers
really are. I'm talking "copy and paste code from StackOverflow", "take 3
weeks to parse a simple file format", "how do I load a MySQL dump" level of
incompetence. I have seen all these things.

> i don't know what i could make that people would want in the dozens or
> hundreds.

Make something that scratches an itch you have, that nothing else (good)
exists to solve, then generalize it and write clear documentation so it will
be useful to others. A hint: the main factors I use before deciding whether to
bother with a GitHub codebase are: 1) the quality of documentation and 2) the
frequency of updates. These two things indicate that someone cares about the
code and is likely to continue supporting it. Think of this as a test of your
ability to identify and solve important problems. It is far from necessary to
have a popular codebase to get a good job, but if you do, you will have no
problems at all.

> i'm distantly aware that i'm whining. the past couple of months have been
> bad. in the past week i think i may have had a solid psychotic break.

Consider seeing a psychiatrist (not a regular MD) who specializes in
depression and/or adult ADHD. My work improved significantly when I was
diagnosed with mild depression and ADHD and was medicated for it. This will
not be a panacea: you will have the same problems, but will be better equipped
to cope with them. IANAMD, but it seems quite unlikely you are actually
psychotic. However, deep depression combined with a bad life situation can
combine to make your mind do very strange things.

Realize that you are not alone, this happens to many people, and instead of a
negative feedback loop of depression and failure, you can get into a positive
feedback loop of confidence and success. Your fortunes can change surprisingly
quickly if you take the proper steps, and you are very much on the right
track. The biggest problem with depression is that it makes it difficult to
take steps to fix it, but you are tackling that.

A final word on dealing with psychiatrists, though, if you choose to go that
route. Do research, decide what condition(s) you likely have, and then present
the psychiatrist with the relevant facts to help guide them to the proper
conclusion. Also, if you are having suicidal thoughts, I would not recommend
you mention them. This has ended very badly for people I know. A psychiatrist
would be horrified at this advice, but the fact is that psychiatrists are
busy, and will jump to conclusions based on very little data unless you are
informed and help them along.

EDIT: One final small thing. Keeping with the theme of communication, I would
suggest that whenever you're writing anything -- an e-mail, a HN comment,
whatever, you always use proper spelling, capitalization, punctuation, etc.
(unless it's to close friends). Don't be a pedant, but these basics mark you
as an intelligent person who considers their thoughts carefully. Notice how
_all_ the top HN commenters do this here, even though this isn't a formal
venue. This isn't a coincidence: people will automatically give words more
weight if they seem to come from someone who thought them through. Although
proper grammar doesn't guarantee this, using informal grammar definitely makes
a bad impression.

------
fsk
Maintaining someone else's code is MUCH HARDER than writing something new.

Any business older than 2 years needs someone to maintain their existing
codebase, rather than rewriting it from scratch for each new employee.

Maintenance is seen as lower status, even though it's usually much harder than
new development.

For my current job, I'm doing mostly maintenance, even though I thought it was
a combination of maintenance and new development when I took it. When I go on
interviews, when I say "I'm doing 100% maintenance now and would like to get
back to a job where I'm doing new development.", they always respond "Oh, your
unqualified to do new development."

So it is kind of a career death spiral. Once you have several bad jobs, people
assume you're unqualified for anything better.

------
dpatterson2008
I fully understand how you feel at the moment. It's not the case you're a bad
programmer. As someone mentioned it could be down to a number of factors. You
could be just burnt out and need a break. Alternatively you can always decide
to work on something outside of work that can help sharpen your skills.
Currently at my place I got moved from doing bug fixes/client work to doing
testing. I feel as though my development skills are no longer being put to use
and I want to say something but do not know how to. But the best thing I do
and recommend you do is try not to let it get you down and keep actively
learning.

~~~
hoboon
> Alternatively you can always decide to work on something outside of work
> that can help sharpen your skills.

I do, a lot. It's all garbage, though, and no one really looks at it.

Don't get trapped into work you don't want, but perhaps don't quit your job
yet, either. Don't wait. You don't want to be a near-40 year old loser like me
before this hits you.

Thanks for the advice.

------
logn
You're a maintenance programmer. And a C++ one at that. That's a hard job. I
think you've been trying the live up to the standard of people in the
JavaScript/valley bubble where each week a new NPM module comes out that's
going to revolutionize the world. Get that out of your head. Apply to jobs
where you skills are an asset, and a job where you can ultimately move
horizontally to something better to your liking.

------
ngcode
I would suggest go to [http://hackerrank.com](http://hackerrank.com), try to
solve some problems, start from warm up section and move up. Search on
internet for alogrithms etc before you look at other peoples code. That will
give you a lot of confidence and will help you identify the areas where you
lack and need to improve.

~~~
hoboon
I've been looking through some of these. I hope it works out for me.

what do you think of topcoder?

------
jhildings
Maybe you can try to move to a team leader position or similair? You seem to
have great experience with a lot of different bugs and strange user cases, and
know which questions to ask programmers in a team etc

------
panamafrank
You probably burnt out long ago, you should try and reset, go travel somewhere
but do it slowly like by bike or by foot.

------
lingua_franca
u don't seem to have taken any initiatives in ur jobs. E.g. the systems u have
fixed bugs for, do u really understand how dots are connected? have u used
profiling tools to analyze its performance and tried to improve it? have u
tried rewriting most critical parts to do things in different ways?

~~~
hoboon
Yes, I figure out how dots are connected.

In sustaining engineering, if it's not assigned to you, you can't really do
it. I'd thought about doing what you suggested many times, but throughput is
the #1 thing about bug fixing. I wanted to do a lot of things to improve
process and the products I've worked on but it's not only not allowed, it's
practically insubordination.

Bugs bugs bugs -- fix fix fix. No time to spend on anything else, my manager
told me.

~~~
lingua_franca
yes u can do it, in ur spare time and on ur local disk. i didn't suggest u to
replace production code w/ urs, but just play w/ it a lot to fully understand
it.

after reading all ur reply, I think ur problem is lack of practice. no matter
how many open source side projects u put on github, they r just too
simple/small/repetitive. u need to do bigger green field projects, either on a
new job or in ur spare time. build something from scratch, write ur own
library w/ advanced features like multithreading etc. develop application on
top of it, test the crap out of it. like u said u r not the smartest guy in
the room, u have to take lots of extra efforts to do well in this highly
competitive field.

~~~
hoboon
I've thought about what you said. It's not terrible advice, I think, and I can
see what you mean.

It was difficult to apply in my situation, though. on top of my many-hour
commute, family commitments, normal day-to-day work (bug fixing is all
throughput, no down time), I just don't know how many more hours of my day I
could commit, which is why I ended up quitting that job.

Others seem to make more progress for less work, so I'm doing something wrong,
or just not seeing what they are, or whatever.

Thanks for your advice.

------
gargarplex
Have you considered jumping into QA and becoming a leading professional in
that space?

