Am I Ready Yet? and Imposter Coders

[Zac Roberts]

I am an experienced (2 years) web designer aspiring to become a java web developer, here are some questions:
1. I recently got the SCJP2 certificate and I have some experience with small JSP apps, mainly JDBC data entry type of thing on Tomcat. With these qualifications am I ready for a real java web developer job or should I just keep plugging away at small apps forever?
2. I don't want to be an "Imposter Coder". By this I mean I don't want to be one of those people who says they have all these skills (like java for instance) but all they really know how to do is manipulate other peoples code. What is your experience with these Imposter Coders and how do you avoid being one, or is it OK to do this type of work?
Thanks for any thoughts.

[David O'Meara]

If you have your SCJP and some JDBC and Tomcat experience, it sounds like you are more prepared than I was...
The SCJP should protect you from being an 'imposter', not really advertising, but I recommend the Javaranch CattleDrive as well since it enforces a minimum level of programming knowledge.
It is theoretically possible to get through the SCJP without being able to code well, but you're going to have to learn for the CattleDrive!
DOM

[William Barnes]

Not sure what you mean by "Imposter Coder". For about 50% of the time which I have been paid to code I have maintained other people's code. Lots of people get paid to maintain code and don't end up writing any code themselfs. If you are just starting out I wouldn't worry about the distinction of maintianing someone else's code or writing your own. After you get some experience you will have more oppertunity to write code.
Not sure if that answered your question.

[Merlin M Koppula]

Just my 2 cents about "imposter coders"
Anyone who only does new development or who only maintains others code all their life is not having an alround experience.
However, maintaing someone elses code also require a lot of talent which a lot of people dont realize. In fact, a lot of times writing new code is a lot more easier than mending an already written code. you can code an application in your own style. But, when you make a correction to an existing code, you have to understand the application, you have to understand the code (from the source if you dont have the documentation), you have to stick to the original style of coding so that it wouldn't look like a patch work and doesnt confuse the next developer.
I think every developer will (and should) have their share of 'imposter coding'.
Hope this helps.

[Zac Roberts]

Thanks for the responses, I guess I was more thinking along the lines of people who say "Oh yeah I know Java pretty well" and have Java right on the top of their resume but they don't know what a constructor is because their only experience is with copying and pasting some code from the internet and hoping it works. I guess it really doesn't matter, if your app works then that's all that matters, right?

[Mark Herschberg]

Zac,
I'm glad to see that you care about being a good coder. I have seen many people, including quite a number of SCJPs who are what you call "imposters." They throw every buzzword onto their resume, but don't know them well. Even if they know the basics, they don't have the deeper understanding which makes a programmer strong.
WRT maintaining other people's code, that can be a great way to learn. You'll see a lot of bad code. If you're smart, you'll make note on why it's bad, e.g. poor documentation, highly coupled classes, poorly named variables, etc. Then think about how it could have been done better and, most importantly, make sure your coding habbits don't mimic these mistakes.

--Mark

[John M Brown]

In today's times, where the Job Market it very tough for Java programmers, there are some important aspects to this.

First of all, I think that as many keywords you can get on your resume (the most marketable ones current), the better. Even if you only know a little. The reason? Because the resumes are put into a database and logged and searched by HR people (including recruiters), who only know them as buzzwords. These are things that can get your resume noticed and hopefully get you in the door for an interview. I even leave a lot of my very old skills (like Fortran, and other vertical market skills) in case somebody does a search for these technologies when looking to redesign a legacy system.
Now once you get in the interview, you better be honest about how much you know about everything, because you say you know something like EJB, Design Patterns, you will get grilled by the tech interview. If I'm not particularly strong in a skill but have some experience, I explain how I was involved in it. What I mostly push is proof through my job experience that I can pick up a new technology quicky and run with it.
Some companies may need a particular skill right away and don't have the time, or resources to have someone develop it.
For example I had a 2 1/2 hour interview (where I was really grilled on my knowledge and experience). They really wanted someone that had direct experience with MQSeries, MQSI (and message oreinted middleware. I had only worked on projects where integration of an in-house messaging system that used MQS under the hood. They picked another candidate that had that specific experience. But I was called up a week later because they opened up a new position and thought I would be a good match to fill it.
MQSeries was prominent enough on my resume to get me in the door, and it indirectly led to a job.
Please keep this in mind when looking for a job. A good company will appreciate your skills and your aptitude to learn more than a specific nitch.
The interesting thing is that my 1st assignment has been to develop a process based on RUP, which is something that I don't have as much experience on, but I'm learning much about along the way.
So my advice is to use everything you have to get your foot in the door, and be honest at the interview (so you don't get in over your head).
[ March 04, 2002: Message edited by: John M Brown ]