views:

88

answers:

3

I recently got a job for a company that develops and manufactures high grade electronics (company will not be named for reasons that will become obvious).

I was hired from being a floor tester to being a test development technician about 2 years ago with the clear intent of being a software developer. (I have next to no electronics background tho I have picked up a little in the last 2 years.) Upon joining the department I was faced with a few facts.

1). Pure Hardware Engineers all think they can engineer software because software is an easy afterthought. 2). Source control and pretty much the entire Joel test are out the window and then some. 3). C is the language of the gods... except for when rapid responsive change is the standard, everything we developed was written in C by what appeared to be a team of monkeys.

I was faced with spaghetti code, no documentation, no standards, no source control, and no bug tracking. I've made it a point to hold myself to high standards but getting the department to adopt new development platforms (like .Net) is proving to be a nearly impossible task... How can I stay sane in this environment? How can I thrive, grow as a developer, continue to LEARN! One thing that miffs me is that I am literally the most qualified developer, and the lowest ranked person in the entire department (although at least they realized my value, when all the engineers moved into the new offices and the tech's got left behind, I did move into the new offices)

What can I do to work my way into a higher position without coming off as an elitist jerk? I was fortunate to even get into this position because although my code skills are mediocre, I'm a big fish in a small pond when it comes to my department. I ALSO HAVE NO DEGREE! I'm trying to remember to let my work speak for it's self but so little is really seen by management (much less understood, remember point #1 above) that it's becoming really frustrating to continue to put my best into my work. HELP!

I have a mostly good relationship with my boss, but he's a bit spineless when it comes to HIS boss. My boss was the only semi-competant programmer in the department until I started (he got promoted a week later) and he respects me as a peer in software. He's pretty approachable but I don't feel that anything I say really matters because of HIS boss.

Source control is in place but it recieved a rather... cold reception by my team beecause we were initially forced into using the corporately utilized Rational Clearcase (which sucks if you aren't using an IDE that integrates well). We're moving to SVN with Trac shortly thank god.

+3  A: 

IMO this all hinges on your relationship with your boss. Does your boss call any technical shots? Does he respect you? Can you come to him with your concerns? If you don't have this good relationship, or if your boss doesn't care about his own job, you'll want to look elsewhere.

But in your position, I would recommend taking one bite off at a time, starting with source control. That's a must. Find someone else in your department who you work with and set up a file-share based SVN repository. After working like that for a while, people generally will start to see its merits...

Dave Markle
read my additions at the end and revise if you wish.
Firoso
Crap. I had a similar relationship with an ex-boss of mine. Great guy, but his boss was a tool and micromanaged him. I quit. At least you're getting SVN. That's a big step in the right direction IMO.
Dave Markle
+1  A: 

The key is to find a way to introduce various practices that have a short-term win that can be seen as something that gets you more credibility to introduce other things but keep it small and simple. Another question is whether or not anyone within your team wants to help you try to improve things by introducing this and that.

Have you tried improving the existing methodology to see if that can perhaps be changed to improve various parts of the job? While you may have a big mess to deal with now, the question is whether or not you are making progress in getting this down some or is it still growing? If the latter, then yikes I'm not sure what to do while in the former the key is to remember that you should periodically have reviews where you should be able to bring up that there should be tools used for this and that and is it possible to get them for the department?

JB King
thanks for the advice, I'm not sure if peer reviews in a department this small would even be beneficial but i'm considering them, code mentoring might be a good idea tho but with only ~12 people and only 3 people that really write any significant amount of code (2 actively) it's a bit... messy.
Firoso
How well do those few that do weite a significant amount of code communicate?
JB King
on a scale of 1-10? 4 or 5.
Firoso
Ah, so then improving communication may be something that can be assessed and improved upon possibly.
JB King
+1  A: 

You'll find it extremely rewarding if you can improve the place you work at, be it through code reviews, source control, best practices etc.

The question you should ask yourself is do you think it can be done, and if so are you up to the effort and uphill struggle? Sounds like you want to go to a software house that already has this in place and become a better programmer, this is valid and understandable, but not as potentially rewarding!

ChrisFletcher