Ask HN: Career trajectory? I'm terrible
16 comments
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.
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.
> 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.
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.
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/ 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!
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/ 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!
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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!
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!
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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!
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!
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.
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.
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.
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.
> 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.
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.
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!
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!
> 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
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
> 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.
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.
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?
- 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?
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.
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.
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".
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".
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
I would suggest go to 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.
I've been looking through some of these. I hope it works out for me.
what do you think of topcoder?
what do you think of topcoder?
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
You probably burnt out long ago, you should try and reset, go travel somewhere but do it slowly like by bike or by foot.
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?
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.
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.
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.
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.
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.
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.
> have u tried rewriting most critical parts to do things in different ways?
Also keep in mind that these critical paths of the code produce more money for the company in a minute -- globally -- than I will produce in my entire life.
You don't just 'change' that part of the code without good reason and it's old enough that it's been throughly explored.
Also keep in mind that these critical paths of the code produce more money for the company in a minute -- globally -- than I will produce in my entire life.
You don't just 'change' that part of the code without good reason and it's old enough that it's been throughly explored.
Have you considered jumping into QA and becoming a leading professional in that space?
I'm in a fix, of sorts. All I've done in my career is fix bugs and I feel that I'm actually quite terrible at programming. I have no value in an engineering organization.
I've been on a few interviews and they always say I'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't have the experience of 7 years; more like 1-2 years a few times over.
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.
I'm trying to learn more about programming and practice as much as I can but it feels like it's so insurmountable. I can't envision anyone wanting to hire me.
I feel like I've wasted the last several years and I should go away and do something else and let the real engineers work.