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.

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.

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.

> 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.

> 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.

> 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.

> 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.

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.

> 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 wonder if they're going to do the same for the lab manual? I have a copy of the 2nd addition and there are instructions to mail a physical paper letter to addresses for parts.

I'm at least a little excited to see this. I've been reading about home automation for decades in the likes of Popular Science, and now, to perhaps see it really happen, finally. It makes me feel old, feel young.

congrats! :D

I once heard about a system based around a game: Where Are Your Keys? (http://www.whereareyourkeys.org/)