About Java Programing

Question

hi ,
I think over twice before asking question here. so anyhow time to ask
I here by , to grab the important points for the following question.
Now'days Most of the ide is enhanced/simplify the work for the java programmer.
say as eg: syntatic errors, casting works, Exception handling,grab the file from the path(importing) Most of the time, if any thing happens directly intimate to programmer.. except runtime exception.
ok. if a programmer doesnt had any ide means just notepad and with command prompt., means setuping ah path and complitation error : from syntax to run time exceptions most typical.. picking up lot of time
My bottom line of the question is pretty simple
A programmer using ide means pretty working good as well finish in time. but if he doesnt had ide means simple notepad struggling ah lot?
how does filter/iterate a good programmer? in other words how to certify a person as good programmer.

Answer 1

gimbal2 wrote:
First of all: nice post. Thank you for taking them time to write it.
morgalr wrote:
1 - personality: does the person's personality fit well to our team dynamic. Do they play well with others? You don't have to be gregarous, but you do have to be able to get along with all the existing players.I find this an interesting one, because it is very open to assumption. "Personality" is quite vague and people will likely want to replace that with "being nice". But that doesn't have to be the case, sometimes having a colder business attitude fits the team better. I've worked in business environments and I've worked in "family" environments where form is more important than result; me personally I can't do my job in such an environment because there is far less discipline when it comes to dealing with people that do not function properly; in stead of people going into the confrontation you get avoidance strategies and problems just fester until a breaking point. You need a well-oiled machine when doing development, being too chummy gets in the way of that.
Of course it isn't black and white either.
>First of all: nice post. Thank you for taking them time to write it.
morgalr wrote:
1 - personality: does the person's personality fit well to our team dynamic. Do they play well with others? You don't have to be gregarous, but you do have to be able to get along with all the existing players.I find this an interesting one, because it is very open to assumption. "Personality" is quite vague and people will likely want to replace that with "being nice". But that doesn't have to be the case, sometimes having a colder business attitude fits the team better. I've worked in business environments and I've worked in "family" environments where form is more important than result; me personally I can't do my job in such an environment because there is far less discipline when it comes to dealing with people that do not function properly; in stead of people going into the confrontation you get avoidance strategies and problems just fester until a breaking point. You need a well-oiled machine when doing development, being too chummy gets in the way of that.
Of course it isn't black and white either.
Team dynamics is one of the most difficult thing to fit an interview for, and it's correct, you don't have to be Mr Social to fit in. I'm fairly introverted, but play well with others. I work quietly and often do not even see the entire floor or department of the company I work for until years of working at that location, but I have learned to effectively network with the other developers in the company and the local area.
At one time we convinced one of the middle managers we needed a 2 hour lunch on Friday for networking. We'd go down to a local restaurant, sit back and talk, and see each other in a more "natural setting". What the newbies didn't figure was all of those senior leads there were evaluating them for personality and if they thought they could work with them. We had a pool of about 60 people that would show up for our "no host luncheon" from various companies through the area. We had a great time--we blew off some steam, we networked with others to find solutions to what we were looking at, we even recruited a few people, but ultimately we found out what everyone was really like. Those sessions very much allowed the senior programming staff to evaluate who they wanted to work with and rate how dependable they thought each person was and who would mesh on what teams. I have to say during that era, I didn't care for my boss much, but when we suggested the networking luncheons, and they went along with them, I will admit my opinion of them went up significantly.
On another instance I had a mainframe legacy programmer working for me that was, to put it mildly, kind of crotchety. Most fortuitous for me my wife took a workshop about that time I was able to read over her materials. They identified 5 basic personality types. This guy fit one of the descriptions perfectly. I decided to try working with him using the protocols described in the workshop: he turned out to be one of the best employees that I ever had. Great programmer too. The key there was: once you told him what needed to be done, he was going to complain, stomp his foot, and do the "humph!" type of purging sigh. If you knew that was just a basic mechanism he had to cope with new stuff and not to take any notice of it, then he worked out great. He ended up working for me on 3 major development systems, learned to write web based live reports, and basically retooled his toolset 3 times over the period he worked for me. This was all before Java, Web Devleopment, or laptops became popular. Basically back in the time of bear skins, stone knives, and sharp sticks.