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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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!
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
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.
- 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?
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.
what do you think of topcoder?
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 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!
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.
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.
