What recession? An annual survey conducted by Java Pro found that top Java skills are paying more than ever. The career survey sampled Java programmers' work and compensation and compared it against geography and gender, education and training. Check out this salary survey to see how we can still bring in the dough (as long as we have a job?).
The survey is here
Is this survey correct? I have seen many people looking for work, and when they found jobs they didn't seem to be getting more. Their is also a big difference between the top notch developers (who do fine), and the people who came in at the end... who only know that Java isn't just a drink!
In the last two weeks I have gotten two offers over 10K apart (Guess which one I took? ;)). Even with the better of the two I am still less then these averages and less then I was a year ago. I guess I still have more work to do get paid more.
I found this ComputerWorld story a good balance to the Java World survey:
BTW, how much importance do you place on Sun certification? The Java World survey says that certification worth an extra $1000 per year (Stay in Skul
section, page 5). Where does certification help the most, making more money or finding a job (or does it have any value at all)? What specific certification do you most value (if you value this process at all)?
I have found that Java certification doesn't mean too much.
If you are a junior programmer, going for a junior position, THEN having a programmer/developer certification may prove that you at least know something about Java.
If you are going for more senior roles then the only one that would even make me think, is the architect certification. I don't even put the other certs on my resume, as I have seen people view them as negatives.
"He is an architect, yet he is telling us about that cheesy sun programmer cert?"
But, I could be wrong, and it depends who you are, who the people are looking at you, etc.
I personally would leave the programmer and developer certs off the resume. The only reason I can think to do the first two Java certs is to get to the Architecture one, which I would consider putting on my resume. I would probably leave even the Architecture cert off the resume except when it is a requirement or a 'nice to have'.
Sorry for drifting a little away from the topic, but my experience is, writing an application software has more to do with applying common sense. I saw a message, somewhere, mentioning that the Java certs do not really matter. I guess, that's very true. Because, nobody can remember everything, and you mainly learn by working with experienced professionals. Its more of the attitude, that matters in mission critical projects, more than the technical skills.
I've interviewed a fair amount of Java developers in the past 6 months. I honestly don't give much credence to the Programmer certification. Experience, experience, and experience are much more important to me when I'm interviewing someone. I think the Developer and J2EE Architect certifications carry much more weight, but I don't see either of those two certifications much here in Minneapolis/St. Paul.
-- chris bartling --
More than 2000 years ago, Jesus Christ, in front of 12 deciples, set an example by baptizing himself and others followed. Can we do that in java certifations? Lead by example?
In my opinion, Sun Microsystems should force
James Gosling to take the java certification exam so
that it will give credence to the java certification.
I will never take the java certification exam as
long as James Gosling is not a Sun certified
Currently, Sun's architect certification doesn't require any other certifications, even not requiring you know how to program in Java. And I never see anyone who play the role of architect has this certification in companies I worked. Maybe this is the least useful certification.
I see not too many developer certification in market. This is not because it is hard, but because it is expensive and time comsuming. As for Java Programmer certification, although not too many people have it, not too many people pay attention.
So I think Sun need change this certification process, making its certification respectable. And REQUIRE all Java programmers must pass Java programmer certification on their web site. REQUIRE people pass Java programmer certification and developer certification before they can take architect certification. Learn from Microsoft to simplify Java Developer and Architect certification to make Java Certification meaningful and respectful. Otherwise, what's the point people do Java certification?
BTW, I don't think everyone can pass Java Programmer Certification even it may seems simple. I see many so called Java Programmers don't even understand classpath.
Your observations are understandable. I do have one thing to discuss. I wonder what kind of deliverables the architects in the companies you worked for handed over to your development teams. If what you got is a visual model consisting of a set of UML artifacts showing the system structure for development and deployment, you should consider yourself one of the lucky few. From what I heard and my own experience, many projects start with an ambition to model the system visually with UML (that is why we have UML and Rational Rose or whatever tools on our resumes) but eventually gave up, falling back to the old way that the codes are the design and the word documents (with a few UML diagrams, maybe) are the architecture. There is nothing wrong with that. We have been doing it this way for decades afterall.
However, I believe Sun clearly sets up its certification structure with the roles of the candicates to play in a software project in mind. My understanding of Sun's vision is that an architect should present a (visual) model to the programmers/developers to implement. S/he should know when, where, and why use a (public) interface and when and why to publish an interface. S/he should decide when the system requires a collection and the developers should decide when and why to use an arraylist or linkedlist or set or whatever implementations. They should optimize the system in different ways. Therefore, an architect probably may not know Java programming but still be a super archtect. On the other hand, there is no guarantee for a super developer (coder, to be exact) to be able to play the role of an architect. These two groups just require different sets of knowledge and skills. Mike has listed quite a few of the knowladges that an architect is required to have in Sun's view. (Un)Fornately, the term architect has been so overused in the software industry. Sometimes we just do not know what should be expected from an architect or a developer, architects in particular.
By the way, if you know someone who is an architect in the construction industry, please ask him or her how often s/he touches a brick at a constuction site.
Every company seems posting they want perfect employees who knows all the skills you mention, i.e. UML, Visual Modeling, Software development life cycles, OOA, OOD, J2EE/EJB, and 10 plus years experience overall, 3 years Java, etc. I have all these and Java Certification. In today's economy, I don't think those companies really want hire more peoples. It is said 80 percent new jobs are created by small companies with 50 or less peoples. Today, small companies go bankrupt, so there is no good job market at all. I suspect those interviews are not really needed. One with all the experience cannot find a pay exceeding the Java salary survey (namely $117,000 in Boston) these days.
BTW, if one is so good, why not do his own business and compete with those big companies? I think more people with experience like mine will do this--this is not too difficult at this time. This is the only logic way I can see. I know my strength and weakness and I can control my destination.
Even those decision makers in those companies can not guarantee their job will be secure next month. One reason so many companies posted help wanted can not find people for a long time because those guys doing interviews really don't want give good recommendations to company. Why? If new guys are hired and company need to cut people, all employees are in danger, including those who do interviews. Less people, less danger. And rejecting people make one looks good in his company. They always want company see how smart they are? But I don't think they are smarter than anyone else (even the most inexperienced candidates) if they themselves look for a new position. This is not personal.
I think that the Sun certification is
something that helps you get the job faster more
than anything else. Its just a matter of comfort
for the employer.
I used to think that certs didn't help experienced Java people much, but recently I've seen some evidence to the contrary. I know of at least one good Java consultantcy
located in the City of London financial district which views them as a distinct positive, and it seems to me I am seeing them more often in Job ads as a 'nice to have'.
Hi Fellow Java Gurus!
I've been trying to get through a few employers in the US for an H1B job, this is the story for more than a month. If there are jobs in USofA, then why dun the employers sponsor H1B these days?
I believe things are still very bad for developers in the US. Also, there are plenty of candidates for H1B visas right there on the ground in the US already. Indians coming from grad programs and the like. You might be better off trying to land a job with Microsoft, Sun, Motorola, or another big US company right there in India for the time being.
Oh ****! In Finland we would be so happy to get half the salary you US guys get :). (with M.Sc degree and 4 years of experience, 40 hours/week plus our normal month lasting summer holiday and week winter holiday). Any available jobs there for europeans...?
But the americans pay so much in taxes.... oh wait, no, that is the Finns again :)
You do have healthcare and the #1 school system in the world though!
Oh, I forgot the taxes. In Finland if you earn say 40000 EUR (36,070.51 USD), you tax percent is about 35%. But of course we Finns have free healt care. But expensive gas.
OK.... wanna talk taxes.... In belgium we almost need to give half of the earned money to taxes!
But you have those waffles.
The heck with the waffles: Belgium has the best beer in the known galaxy! You get to drink Kriek and Hoegaarden every day!
Geeh, the booze is expensive there, right? And if you do a booze run to Germany, you gotta pay the gas. And if you work in Germany, your taxes are 50% plus. But if you wanna work in the US, you need H1B-visa. And visa is not the same anymore. Not the same, I tell ya.
Compairing countries salaries for Tech workers could be the source of a whole new discussion.
Academic requirements and what they mean is very different based on the country. Tell people in the UK that you have a MSc and they will wonder why you could not get a job after University. Certain proffesions in the US do require a Masters. Tech however is not one of them and will mean nothing to your pay level.
As for getting someone to sponsor a H1B visa at the moment. You'll be lucky. ;-)
Anyone else think these salaries seem a little high? (Part of me is hoping for yes, part for no.)
I gotta say I am very surprised. The AVERAGE numbers seem kinda high. Also, the average hourly rate for consultants is way too high. This survey has gotta be old ?? I mean, $117/hr in the Northeast ?? Thats ridiculous. 3 months ago, I had trouble trying to negotiate for more than $70/hr.
here in Brazil the programmers/architects Java do not receive a lot money. For a programmer with experience in java, with high knowledge about j2ee,j2me,java card, OO, etc, the maximum payment by hour they are 20$. The tax is less 10%, more, the healthcare and a good school are paid by the programmer. The public school no very good.
This him the programmer work like not regitered in compny, no staff, the gross value in the month is: 20$ x 160h = 3200$ - 10% = 2700$ - 100$ = 2600$.
Case the programmer be recorded in the company, he will go a staff from the company, the monthly salary is: 1956$ - 27,5% = 1417$, but the healthcare is paid by the company.
When it will be that is going to improve?
Adilson de Souza Dias
master at adilson dot com dot br
São Paulo - Brazil
What is the cost of living like in Sao Paulo?
I agree, I don't think these salary averages are right... the numbers may be reasonable for senior dev'ers or architects, but definitely not for AVERAGE java developer. Perhaps this just shows that folks like to inflate their their salaries on surveys! Now if it was a survey conducted by the IRS, then you'll see exactly the opposite; funny how that works. ;-)
The numbers are total compensation, aren't they? Including benifits, vacations, etc?
This is for people who dream about big salaries in the US or in other country for the matter. I immigrated from Finland to Canada (yes, with the MSc. degree and some 8 years of exp.).
It will take years before you will get paid that kind of money, no matter what your experience or education is when you arrive to the country. You can not move in and move out with your fortune. It just won't happen.
Why? Simply because nobody knows about your Finnish education, or about your Finnish work experience. What is not known means nothing and is worth nothing, and believe me, nobody cares. You can try to certify your education at least but that will not get you through any corporate HR people (how do you get through them, I am still puzzled).
You need to have connections. Without them you will not work, not very soon anyway, not in Canada. :)
You will have to accept close to entry level positions.
This is what I mean when I say it takes years. Eventually your experience and education will take you there.
The only way around this is to work for a Finnish company such as Nokia. Nokia can take you to US with less trouble and pain. Well, you still won't be making the money as a transfered worker but it gets you in faster.
I personally do this for the heck of it, and perhaps for a bit of life experience, but not for money. Of course I love to program too! Hell, I am not doing too bad in Canadian standards, in fact, I am doing damn good.
One more thing. Finnish programmers live in an ivory tower where nobody can touch them. The number of IT people who graduate from the universities is very limited (university is practically free, and the government even pays you to study). In fact, techies are highly respected in Finland. You can be pretty sure to be just about the last person to be fired if things go bad. The Finnish programmer has it pretty good I would say, enjoy.
A foreign programmer who moves to Finland is expected of extreme performance with crummy pay, of course! :)
OK Tero, Thanks for the advice ("don't immigrate to US/Canada and expect to get great salary immediately"); you're right about the finnish employee situation - many IT companies have recently fired a lot of folks, but the programmers seem to be last to leave. And the free university education is a good thing too.
A possible reason why this survey might be accurate is that the relatively lightweight people have been shaken out of the market and because very few entry-level people have been hired this past 18 months. This leaves a core of veteran developers who have probably several years with their current employers and probably got a salary hike last year.
In fact it's possible that with the demise of the 70K 'guy who can spell Java' that salaries for the hard core guys may have fallen but the average salary could still rise. Example:
Let's say that last year a company had 5 hard core guys making 95K each and 5 'Java spellers' at an average of 70K each, for an overall average of 82.5K. This year the company has 5 hard core guys at 90K each. The average salary has risen even though pay has fallen!
This is exactly what has happened at my company. Luckily I'm one of the 'hard core' guys ;-)
Don: "In fact it's possible that with the demise of the 70K 'guy who can spell Java' that salaries for the hard core guys....."
Don: "Let's say that last year a company had 5 hard core guys making 95K each and 5 'Java spellers' "
Shane: "Luckily I'm one of the 'hard core' guys ;-)"
Dion: I don't even put the other certs on my resume, as I have seen people view them as negatives. "He is an architect, yet he is telling us about that cheesy sun programmer cert?"
What exactly is the definition of a "hard core guy"? What are the requirements? Do you have to be a consultant? Have "Architect" in your job title? I'd like to know the answer to that one.
Perhaps there should be a "Sun Certified Hard Core Guy for J2EE" exam.
The whole argument that certifications are good only for lining my cat's litter box seems rather elitist to me. Not everyone thinks of themselves as the Michael Jordan of Java/J2EE.
Certifications are what they are: rubber stamps that, depending on the recruiter or HR rep, may distinguish you from the competition for a job. If a ton of resumes arrive for a Java/J2EE programmer/developer/architect position, and the top candidates all have equal experience and qualifications, then a Sun certification can be the difference. I've seen it happen.
Anyone who would look at a Java certification as a negative is not the type of individual that I would want to work for, or have work for me. They obviously have high opinions of themselves. Being humble works wonders in the workplace.
I don't understand comments like 'Java spellers'. You don't just wake up one morning and BOOM, you are an expert on J2EE. Everyone has to start somewhere.
Answer the following to see if you are hard core,
To statisfy you thurst for knowledge do you build code demos in your own time?
Do you constanly read technology books/articles to keep up on things?
Are you an active member of several technology groups/message boards?
Do you write white papers on the things you do?
Do you get an great sense of achievement when something you build works?
Have you been writing code since you were 8?
Do you think that certifications are fun ways to test your knoweledge and who cares what people think of them?
Does you girlfriend think its weird that you have a complete wireless network in your house and a computer in nearly every room?
If you answer yes to all these I would call you hard core.
David....I loved your definition of HARD-CORE!!! Excellent stuff...I'd add that to be a Hard-Core Java guy you should have at least read Joshua Bloch's "Effective Java" book *AND* actually understood what he was talking about; or even better developed those practices on your own!
I think you just described *exactly* what "hard core" is. Unfortunately, I don't think most interviewers know how to sniff out whether a candidate is hard core or not.
Although experience is valuable, I think absolutely quantifying experience in "number of years" is a mistake. You can be in the software developmen industry for ten years and still suck. You also be under three or four years removed from college and be a kick-ass developer. Being a crusty, verteran programmer doesn't mean you are cut out to be an architect of a complex system!
I wish more companies would recognize this and hire people based on talent rather than on a misleading criterion like years of experience. Too bad it usually takes a hard core developer to recognize one - many of those in charge of interviewing/hiring are not hard core.
I have to agree with Ryan!!! Particularly on the experience and conversion to be an architect from a developer.
I have seen too many people with fancy resumes but could not deliver. Some of them even have years of experience older than themselves or J2EE experience more than the years of J2EE existence. But these people were often hired for whatever reasons. I would hire someone with some experience and certifications. For short term contracts, I would look at experience more heavily. But for longer term employment, I would definitely look for someone willing and eager to learn and with certifications.
I recently was minted by Sun to be a certified J2EE architect with a passing score of 100 on the practical assignment. I have to admit even with a number of years of programming experience I learnt a lot! The process enables me to develop a mindset of an architect. Also, there are significant implications on how you approach a system in terms of OO, component-based or service-orinted. Going through this, I just picked up way more stuff that what is the minimum to pass the exam. So, if I were a hiring manager and had to hire an architect, I would absolutely look at this heavily in terms of technical competence.
I do not understand why people sometimes downplay the importance of certifications. I understand they are not the only things to consider while hiring a person. After leaving school a few years, I consider only certifications can prove I have been keeping up with the develoment of technology. It is easy to "make" a resume but hard to get a certification!!! You can gain experience by copying someone else codes. But only the ability to know "why" can separate you from the ordinaries.
I don't know you, so don't be offended by my comments.
The reason I cast a negative eye on certifications on resume is that I have interviewed SO MANY SUN certified J2EE architects who ONLY spell J2EE and nothing else. Let's face it, has everybody paid money and not getting his certification?
Here is no substitution for hands on experiences, period. One needs to learn from one's mistakes and this learning process can not be replaced by remembering a few questions in a certification guide.
While I agree that the number of years of experience is not a great indication on how good or bad a developer is, the lack of years of experience is a DEFINITE sign of inexperience. I just won't hire someone with less than five years of experience, period.
Just my 2 cents.
".....I have interviewed SO MANY SUN certified J2EE architects......"?
Please read Chris's comment which I copied below:
"I've interviewed a fair amount of Java developers in the past 6 months. I honestly don't give much credence to the Programmer certification. Experience, experience, and experience are much more important to me when I'm interviewing someone. I think the Developer and J2EE Architect certifications carry much more weight, but I don't see either of those two certifications much here in Minneapolis/St. Paul.
-- chris bartling -- "
I am in the Boston and I have interviewed at least five to six "J2EE certified Architects" and needless to say, I hired none of them! In fact, none of them passed the first round of interview. Just my experience, not badmouthing.
Hmm, very interesting how everybody jumped to TECHNICAL QUALIFICATIONS so quickly.
Whenever I get interviewed, the first thing I do is talk about what I've done in the past with my experience in Java. Yes, I don't know EVERYTHING about Java and would probably get a poor score on the SUN certification because I am not "book-smart", but I have coded nearly every legitimate enterprise application out there.
I am finding that the reason I am getting above-average pay is because of my attitude and work ethic. My employers do not give a damn about magical pieces of paper, they want me to show them the money. They also don't give a damn that I programmed in "JMS" or whatever buzz-word is all the rage at the moment -- all they care about is that whatever technology they choose to use, I have to be able to learn it pretty quick. Show me a certification that measures that, then I will get it.
I think this quote is also relevant:
"..In essence, programmers know enough about the algorithms underlying distributed computing to make design decisions and to choose alternative algorithms quickly. They then consult a programming manual to find the details needed to write a program that implements a particular algorithm on a particular system. The point is that if the programmer knows WHAT a program SHOULD DO, finding out HOW to do it is straightforward..."
In other words, who cares what you can memorize and regurgitate on an exam. Are you smart and do you have experience is all that matters.
Good to hear that there are some people doing the interviewing that can quickly spot a fraud :-). Let me pose this question to you...
It is evident that you can bloat/fake/whatever your resume to appear more qualified than you are to get an interview for a position you have no business holding. This is usually done for said position's compensation.
But what about the flip side? What about the dude/dudette who is two or three years removed from college, but is a whiz at this Java thing. Although they may have shown great design skills and leadership qualities, there is little chance of them getting even an interview for a lead position. How can somebody like this get their foot in the door for a position that they rightly deserve, but don't have the requisite "experience" to qualify for the interview process?
IMHO, the dot com boom flooded the IT market with posers. There seem to be an awful lot a ex-COLOL/C/Pascal/whatever developers that took a one-month crash course in Java (to cash in) and are now "Java developers" with fifteen years experience. This "noise" in the job pool drowns out many qualified candidates.
BTW - I am not knocking those who came to Java from another language. I'm sure they are many talented Java developers who have accomplished this. I just pesonally know *many* who suck.
We have instituted a three-round interviewing process, phone screen, and two rounds face to face interviews. Most frauds won't even pass the phone screen.
As for your last question, most hiring managers are looking for years of experience in relevant technologies, as well as overall experience. Let's why you see ads like, "10 years of software development experience, with at least 3 years of Java, etc". So at least with me, a simple question like, "how many years have you developed commercial products in Java?" would clear things up. And it really doesn't take more than five minutes for me to spot a fake over the phone anyway. The key here is to ask technical questions during phone screening.
Your fisrt question is a lot hard to answer. Again, I don't know you so please don't get offended, as I can only speak about my experience.
I am sure there are super stars out there with less than two to three years work experience with Java. But I highly doubt it, as I have not seen one even though I have been interviewing people in the past 12 months. The key here is enterprise software development experience and to me, language is relevant but not the most important thing. I would rather hire someone with 10 years of PROVEN software development experience but only 1 year of Java experience, vs. a developer with 3 years of Java experience only. Remember Java is still a language, a platform, and a tool. It is the mean not the end.
And if one is a true super star with less years of working experience, I agree with you that the chances of them finding a lead/architect position is slim to none. I would take a more junior role, just to get my foot in the door. Once you are in, you can prove yourself to be a super star. Dude, in this economy, we have to prove ourselves everyday anyway. A little detour won't hurt your career in the long run.
It occurs to me that you represent the "hiring decision maker" I am preparing for with my Java studies. Let me ask you a couple of questions and get your opinions about hiring decisions you face.
First, you claim you look for someone with 10 years overall experience, and three years java experience.
I would more than cover the overall years requirement, but would fail on the 3 year java experience. As I've stated, I am looking for the first Java gig.
I understand that experience rules in this business, particularly in this economy. That said, what could sway you into considering someone looking for the first java gig? For example, for the first time in my career, I am now including a Java Study path addendum to my resume. The goal is to relay the serious effort that has been spent in ramping up on the J2EE platform (Books read, Vendor product documentation read (i.e. WebSphere Redbooks), LAN development environment setup a home, hands on experience with IDEs and application servers, ...). Bottom line, what would you recommend for someone looking to break into their first java gig... other than a better economy :) ?
One thing that has occured to me, is to develop a complete J2EE application (even if small in scope), and be able to walk thru all of it during an interview.
How do you divide up the hiring of J2EE skills that you are looking for? Do you look for the same person to be able to cover the web tier (JSP, tag libraries, Struts, Swing) and also the EJB tier? What about requirements gathering (UML) vs development? What about developers vs production infrastruture support? How about employees vs contractors?
Also, you say three years java experience. I assume you mean three years J2EE experience. Wouldn't there be a huge difference between three years of RMI java, vs three years of J2EE? What about a particular application server experience (which one do you use by the way?).
Obviously years of experience can be misleading. It is quite possible to have one year of experience, 10 years in a row. :) It has also been my observation, moving from one large development effort to the next, you often end up responsible for a very narrow portion of a project. I have learned the most in the past on small team development efforts where you get to (have to) do it all. In fact, for my first java gig, I am much more interested in getting to touch as much as possible as opposed to salary or rate. I think there is a question in there somewhere. :)
How much would you value previous non-java n-tier development? My last job was an VB/COM+ n-tier development effort. My observation was much of the learning curve had nothing to do with the actual technology. For example, requirements definition, UML, object modeling, state management, failover, clustering, database failover and backup.
Look forward to your input.
I have a feeling that you might not like what I have to say.
Because of the current economy and job market, everybody I know who is hiring is looking for the PERFECT candidate, meaning someone with 10 years software development experience with last three years in Java/J2EE, who is also an expert in UML and OOD, good writing, communication skills, good project management skill, and more...
No one is willing to settle for less. No one is willing to train. The new hire must be able to hit the ground and running the next day. No relocation. No H1 sponsorship. No signing bonuses, etc. You get the picture.
So it is probably pretty hard to look for your first Java gig if you don't have prior experience. If you can, try to find and get assigned on internal projects that use Java Server side technology. I suspect there should be a lot of re-engineering going on right now in all organizations. The other choice is to take a junior Java position just to get some experience.
Hope this helps and good luck.
Some people may cast a negative vote on you after looking at your own home page on Geocities.
- 4 broken links;
- poor design;
- J2EE page somewhat limited. :)
So you are 'the J2EE architect' ? Based on your CV, you are your own PERFECT candidate for sure, your own reference aren't you ? But you do not seem to apply your architecting principles to your own page. Isn't that a contradiction ? I'm not trying to be rude there. I'm only trying to show that it's easy to 'cast negative votes' based on any principle. Yours is certifications but others' may be the quality of your actual home page.
But nice resume indeed. And some good book recommendations too. You did not recommend the J2EE specifications though. Why ?
You must have read quite a few times of "The Art of War" by Sun(not the company). I think Mike can easily add a few more J2EE ESSENTIAL components to the list on the Web site, which only includes EJB, JDBC, JMS, JNDI, and JSP by the way. Also, I think I saw another copy of THE resume.
It did make you feel great after the completion and pass of the architect assignment, didn't it. Personally, the process have changed completely how I viewed and approached component-based UML modeling. Before that, I thought I knew it all about UML modeling. It should be understandable because the language was matured during the OO time. I think at this moment it just requires a little creativity to get things done until the extensions under consideration are finalized. Good day.
I am glad you took the time to look at my web site. :-)
And I thank you for you suggestions.
I am sure Yahoo/Geocities would allow me to deploy a N-tier solution behind its host side, rigth?
"You did not recommend the J2EE specifications though. Why ?"
Because I don't believe J2EE spec is complete, nor is it perfect. There are huge holes regarding security, web services, and persistence mechanism.
And to be honorest, I don't mind you cast a negative opinion on me, because the only opinion that matters to me is my boss's and so far he thinks I have been doing an excellent job!
"I am sure Yahoo/Geocities would allow me to deploy a N-tier solution behind its host side, rigth?"
Did I say you should have deployed a n-tier solution ? I don't think so. I only mentioned broken links, poor design and the contents of the J2EE section. You missed my point, I'm not criticizing you in any way. From your CV, on the contrary, I'd say you are certainly excellent. At least your CV is impressive and I'd take you for an interview. :) I just took a different viewpoint to 'cast a negative vote' on you as I felt directly concerned by your negative opinion of certified people which I deem absolutely unfounded. :)) I did not mean to offend you in any way.
The only opinion that counts for me is actually that of my boss's customers. If they're happy, then by extension, my boss is happy. But it's customers first.
I guess we just have to agree to disagree on this issue until someone proves to me in the future that a Sun certified J2EE architect is a true J2EE architect.
"Did I say you should have deployed a n-tier solution ? I don't think so"
Sorry, that comment was for someone else who also commented on my site.
While I respect your true motivation of going through the certification process (for learning), most people I know/interviewed were only doing it so that they could put it on their resume.
To tell you the truth, I actually thought about doing the J2EE architect certification one and half years ago. After interviewing a few Sun certified architects, I promptly dropped the idea.
"Because I don't believe J2EE spec is complete, nor is it perfect. There are huge holes regarding security, web services, and persistence mechanism."
Nor is it perfect!! Do you know anything that is perfect ??? The JCP is an on-going process that is trying to identify and adapt to the generic business requirements. How can you expect something generic to be perfect ? By the way, web services was purposely left out of J2EE 1.3 but should be included in version 1.4. It will still be imperfect I guess. But no spec will ever be perfect. I for one recommend everyone to read the specs because that's the common denominator between vendors, developers and clients. And for this unique reason it is worth it.
I just assume, unlike me or you, most people enjoy reading books than specs. :-)
But J2EE specs actually are pretty readable.
"I guess we just have to agree to disagree on this issue until someone proves to me in the future that a Sun certified J2EE architect is a true J2EE architect."
You miss my point again! I never even pretended a certified architect is a true architect, that would be *pure nonsense*. I was only saying it is wrong in my opinion to automatically cast a negative vote on certified people. It's like casting a negative vote on people with a degree in the end. But everyone has to learn, even confirmed architects with tons of experience due to the very simple fact that technology evolves very quickly. But I agree with you that a SCEA is not necessarily an experienced architect. On the contrary, from what I could gather on the crowded egroups.com SCEA board, I'd say most people do this certification with very little experience. But most of them show a very strong will to learn and are eager to apply these concepts to reality, which are basic requirements to become true architects.
And finally I believe there is no such thing as a "true" architect, nor is there anything like a "perfect" or "unique" solution. These are manichean "all or nothing" concepts, therefore largely unrealistic. There are only good solutions that meet the specified requirements. And the architect is there to make that meeting happen. No need to get religious about that, really.
>>"You did not recommend the J2EE specifications though. Why ?"
>Because I don't believe J2EE spec is complete, nor is it perfect. There are huge holes regarding security, web services, and persistence mechanism.
No, It's not!!! It's just because you don't have much idea of J2EE specs.
We can see your hugh knowledge base on them by your posts:http://www.theserverside.com/discussions/thread.tss?thread_id=3209
I respect your position in the industry and your obvious experience in this matter, but don't you think you should tone it down a bit? This "perfect candidate" requirement you speak of is bound to rile a few people up -- <bait> the only perfect people I know are you and Sartoris Snopes! </bait>
I guess it's akin to a Java developer saying that he will never work for a company that has recruiters who only hire Java developers based on what their resume lists for experience.
Are you at all concerned that you may be missing out on candidates who may not have the experience that you require but who would otherwise make excellent employees? Or is there just SO MANY people applying for Java jobs at your company that you have the luxury of being so concrete in your demands?
If it's the latter, I would like to offer this shred of hope to some of us unemployed "less-than-10-years" experience people out there: I have 4 years Java experience and ZERO C++ experience and I live on the West Coast USA. I recently found a job above the average wage listed on JavaPro and it only took me three weeks. This is because, while I may not be "perfect", I am determined and people like that. While Lei may only care about what you have down on paper, there are others who don't give a rat's a** about how much experience you have.
Good luck to you all, don't believe the hype.
I think you misunderstood me. When I listed the job requirements, I DIDN'T use myself as an example. (Please, my ego is not that big)
I did it just to show how job market has changed in the past two years. Employers can afford to be picky, in our case, extremely picky, because for every job we posted we got literally hundreds if not thousands resumes. That's why in the past nine months I have gone through fifty face to face interviews, hundreds of phone screening in order to fill four senior positions.
And I am sure we have missed out on some of the good candidates with lesser years of experience but it comes down to statistics. Say I could find10 good candidates out of 100 with 10+ years of working experience, vs 1 excellent candidate out of 100 with 10- years of working experience, whose resumes I would choose to look at? So if this means I have to lose some really good candidates, so be it.
People say job searching is a full time job, finding good candidates is almost a full time job.
To me, all those hypes one puts down on paper will only get him five minutes with me over the phone. That's how long it would take me to spot a fraud!
Good luck at your new job.
Can you give me your definition of "architect". Note my comments to Ryan above. As I stated earlier, I'm suspect of looking for one individual (or one consultant company for that matter) to be an expert in all things J2EE. For example, wouldn't the following all be different skills (maybe one person doing several of them or not).
1) Initial requirements gathering (interviews and use cases)
2) Initial Class design
3) Initial Sequence diagram
4) Business logic specifications to support UML diagrams
5) Final class and sequence diagrams that implement infrastructure plumbing (i.e. Struts, MVC, desing patterns, cacheing, state management, security, yada yada).
6) Development environment setup and standards (i.e. developer desktop, integration testing, staging, production, yada yada).
7) Project standards in general (does Architect set these up... s/he's the expert, after all).
8) Production configuration (DMZ, load balancing, clustering, monitoring, deployment standards and scripts).
So again, how do you define "Senior Architect" and what responsibilities are assigned to him?
Hey, the ball is in the "client's" court, at the moment. I sure hope that pendelum swings back soon so I can hammer you on the rates again. I miss that $85/hr. :)))))
I can spell java and I make $112,000 a year.
Java Architect, Shmarchitect... I think it has more to do with your ability to BS and mingle with the powers-that-be. Many super-programmers make nowhere near the salaries listed in the survey simply because they lack the skills to please and impress the management-types. Remember, if you want to make more money, forget about technology, J2EE, blah, blah, blah... Just concentrate on making good PowerPoint slides, calling meetings to discuss things that could be solved otherwise in a 5-minute impromptu hallway meeting. And when things go awry, you always have the developers to blame. I don't know what world you guys live in, but the software development life cycle that I have followed could be described as such:
(For the remainder of this discussion, assume for a moment that you followed my advice and became a project-manager at a prestigious IT shop.)
Out of sheer boredom and to make yourself look important in a meeting, you come up with the most hair-brained idea. Other MBA's love it to death. They pat each other on their backs, and, voila! What that means is that the project never had popular backing by your users since it was conceived by you. Also, make sure that there's at least one more group in your company working on a similar project. It just encourages healthy competition.
This basically includes three main elements: you, the sales rep, and lunches at expensive restaurants. Other activities involve reading white-papers on the toilet. The key here is to keep the developers as far away from this process as possible. This way they'll never have a full-grasp of the system and the resulting design would be insufficient. One might argue that such logic goes against conventional wisdom but conventional wisdom is more like a waterfall approach. Where's the "extreme" in this?
Before you start your project, make sure to gather as many buzzwords as possible. This will impress the heck out of the powers-that-be because chances are that they have heard about these buzzwords too at one of those expensive lunches I mentioned earlier. You can never go wrong with true-and-tried buzzwords such as "innovation", "integration", "cost-effectiveness", “vertical supply chain”, etc. For more resources on this topic, just look at any Microsoft technologies.
Call design meetings every day and discuss project-management related issues for 45 minutes and give the developers about 5 minutes to describe the trivial (from your point of view anything technical should be trivial regardless of whatever that anti-social developer tells you) technical aspects of the design. The key here is to hire an UML-specialist to draw nice pictures. This, as we all know, will impress the heck out of the powers-that-be because they're all marketing grads. At the end of this activity, throw out all the UML artifacts in the trash can and give the developers about two days (and a weekend if they've been good to you) to finish the design. An important point to remember is that if the meeting has even one technical person involved, do not order lunch or even bagels. If it's all management-types then order whatever you like. Remember, fat programmers write bloated code.
Blame the programmers for insufficient design and fire half of them. The other half has probably already left as a result of your "innovative" management techniques. Hire junior programmers and interns as replacements. This will give you an opportunity to try out new ideas such as "pair-programming". Redesign generally includes making programmers work 90+ hours every week. This is the first time you let the programmers know what the system is all about. It generally goes something like this: “Well, we missed some very important requirements early on and the management really wants to see those changes made before the next release. Since, you did not read our mind the first time, we’d like you to try your psychic abilities this time around and write code accordingly.” Or at times, you make them write code with either incorrect or incomplete requirements. This doesn’t serve any specific purpose other than satisfying your sadistic alter ego.
I guess this phase does not need further elaboration. For one thing, the elaboration phase should always coincide with the "Requirements Gathering" phase. And, it's kind of late for that anyway.
By this time, the powers-that-be have recognized your superior intellect and could relate to you very well. So, you get a promotion and you become a director of whatever you like. Another intended side effect is that you join a different group (and a brand new project) justified by the "re-structuring phase" (which is the topic of another discussion).
This is the first time the end-users and developers come face-to-face. End-users hate the system and you start seeing requests such as: "Why doesn't this button do my laundry when I double-click it?" The developers, of course, know better. So, they do the users' laundry on Sundays.
These are good times for the middle-tier developers. All the blame is heaped upon the poor front-end (HTML/JSP) developers. They get to find out what WYSIWYG really means.
By the time this phase hits the road, you're already in the Requirements Gathering phase of another project. So, why the heck should you care? Besides, you've already cashed out quite a few of your stock options and thinking about retiring early.
Sometimes, the new manager might consider outsourcing as a last-ditch effort to salvage the project. This phase usually involves moving the development efforts to India. The anti-H1B crowd cheers at the effort as there's now less need to import those greedy H1-B workers. Besides, since the Indian workers don't have to pay U.S. taxes (federal, social security, medical, state, etc.) anymore, it must be good for the U.S. economy, right? India retains its pool of highly-skilled workers who pay high taxes and buy new cars, homes, jewelry, etc. It also attracts foreign investment in the I.T. field by the likes of Microsoft, Oracle and IBM. But, hey, at least the anti-H1b crowd is happy.
Remember, if you want to succeed you must "dumb-down" your technical abilities. I challenge you to look around and see who's more successful and makes more money. I can bet its always your manager with a limited amount of technical knowledge. Upon closer inspection, you'd realize that there's an inverse relationship between your technical abilities and your decision-making powers in the IT field. The less you know about technology the more the powers-that-be would rely on your abilities to pick platforms, vendors and make hiring/firing decisions.
Hey Lei, is there any of that going on in your company?
"Upon closer inspection, you'd realize that there's an inverse relationship between your technical abilities and your decision-making powers in the IT field. "
you have nailed it grasshopper.... let me add one.
Upon closer inspection, you'd realize that there's an inverse relationship between your technical abilities and the PC workstation you are provided with. :)
Dude, that's really funny.
But your post illustrates the exact one thing that prevents us (star developers) from climbing the career ladder. We, (as a group), are very intelligent and sometimes far too arrogant toward product management and the business people, viewing them as dumb and inferior to us. We fail to realize that intelligence takes many forms and we should work with business people to achieve the common goal, MAKE MONEY! We need to communicate our ideas and jargons to the non-technical and yet important business people. Thus dumb down. I view the ability to dumb down and communicate with business people an invaluable asset. I think we have a responsibility to help business people develop artifacts that are usable for architects and developers.
I know I am in the minority here and just offer my opinion.
To put together that, you got to have 50 years of experience playing checkers plus 10 for chess (thanks Nick).
In my company, we (senior architects) roll up our sleeves and do it all! :-)
OK, you HAVE been very helpful, UNTIL this post. It's probably late and you are heading home. Maybe I can talk you into more feedback tomorrow. :)
If you are doing it all, you must be doing some part AVERAGE. :) Do you disagree that this J2EE monster needs to be a divide and conquer type of effort? :)
I agree with you that one can't be expert in everything. That's why in our organizatin we broke things into different tiers, the thin client tier(HTML/java script), prsentation tier(JSP,Servlet), business tier (Session beans), data persistence tier (EJB/JDBC), database tier, and integration tier (JCA, other kind of EAI/B2Bi). Each one of us becomes experts in one or two areas and with general knowledge about other tiers. My expertises are mainly in the middle to the back end tier, as I find them most challenging.
We also have a database group who takes care the database aspect of things and a performance group, who helps us with performance issues.
As you can see, even "super man" needs a lot of help to succeed. :-)
I like that comment, Lei; it seems to imply that intangibles that cannot be measured on the resume, such as teamwork and interpersonal skills, are just as important to getting the job done as having 10 years of experience.
Talk to you in 6 years! :-)
"4 years of experience and loving it", Basil
Thanks for the reply. That makes sense how you divide the skills at your company. Yeah, you mention the database guys. I never wanted to be a DBA, but it occurs to me during the J2EE learning curve that these guys jobs basically stay the same. I guess that could be both a plus and a minus. :-)
It would seem like you would run into situations where you needed just a "JSP" expert or a "Business EJB" expert. Anyway, there can't be that many perfect candidates out there. Someday, imperfect ME will get back to work. :)
This was a good thread. Thanks for the input.
Excuse me for asking this question again, but I don't get out much (studying at home :).
Surely someone on this <bait>talented board</bait> will share thier concept of "architect" on a J2EE development effort. What is their job description and what are their responsibilities? Should there be 1 geru architect per project, or different types of "architects". I'm asking in context of project phases 1) Requirements 2) Development 3) Production support. Also asking in terms of project standards, UML deliverables, architecture plumbing (MVC, design patterns, ...).
<suckingup>Thanks in advance</suckingup>
I recently read on USA Today or something else that US workers are so cared about their job title that corporate America invents a bunch of innovative but hard-to-be-comprehensive titile to replace those traditional ones, for instance, janitor, receptionist, secretary and so on. Does that practice reflect on the IT industry? I think so.
I'll take a shot at this one...
In my mind, an architect is somebody who has a fair amount of software development experience in all the key areas: requirements, design, development, testing, deployment, software/hardware configuration, platform/product decisions,etc.
That said, they don't have to be (and probably can't be) and expert on all of these. They should, however, know the right questions to ask the people who are also working in these areas to figure out what is good for the project as a whole.
As we all know, each of these areas has different "solutions" and each of these has its pros and cons. One hardware stack may be faster while another may be cheaper. One design may be more effecient while another may be more flexible. Blah, blah, blah. An architect must be able to communicate well with the others involved, get all necessary information they need, and make all these areas come together for what is good for the project as a whole.
In other words, they are the "big picture" person for the project from a technical stand point. They need to have some involvement in all stages of a project that impacts development.
As for the details (plumbing, standards, etc), I would argue they are more of a guiding force rather than a dictator. They make suggestions for how things should be done based on their experiece, and the team/department can decide as a whole what to adopt. Chances are, though, an architect will be able to present some compelling reasons why things should be done one way over another.
That's my two cents.
No, you can't be an architect unless you have 10 years of experience and a SUN cert that says so... c'mon get with the program.
So funny.. my last job, I guess you could say I was a "Junior Architect", if there could ever be such a thing. I worked side by side with a proven Software Developer for about 13 months. I participated in every single design decision he made, and got to code some very extraodinary applications in EJB, JMS, and JCA.
I only had 3 years experience at the time though, so it doesn't count.
Basil McRae writes:
"So funny.. my last job, I guess you could say I was a "Junior Architect", if there could ever be such a thing. I worked side by side with a proven Software Developer for about 13 months. I participated in every single design decision he made, and got to code some very extraodinary applications in EJB, JMS, and JCA."
Frankly I would not call myself a 'Java architect' at this time, nonwithstanding 18 years of experience. I perhaps *was* one first in the Unix/C and then the C++ area a few years ago, but not in Java yet. That is my target.
You might well qualify as a Java architect, particularly if you have worked on demanding systems and possess more than a passing acquaintance with design patterns and some of the client-side technologies such as JSP and servlets.
In any case I believe that you are well on the way both from your comments here and on other threads. Quite possibly closer than I am at this point.
Very good point -- since Java is still a child, who really should be considered experienced or not? I guess Lei put it best when he mentioned that he is looking for past experience with other languages to complement existing Java experience. Sounds like the message is getting through to people that the title "architect" is still just a euphemism with regards to Java.
I jumped into Java straight out of university. Never really programmed any other language professionally ( about to change though ). After talking to some of the chaps who have experience in the industry before the Internet became a household name, I can see why it's going to be more painful in some respects for newer-to-the-industry people like me to gain the "Right Kind" of experience. So many concepts that C/C++ programmers had to suffer through for years are automatically abstracted and taken for granted for people like me... If only there were a pill.
There are a few, perhaps more than a few. Ed roman, Floyd Marinscue, Scott Ambler, Tyler Jewell, Dion Almaer, etc. There are others, many of them active on this site!
Another insight into the 'Whom is an architect?' question. Being an architect consists of knowing a great deal about the relevant technology.
It is a process as well as a steady state. It can be a matter of luck in part. choose the wrong technology to lay your bet on and you won't be a (saleable) architect for too long! Refuse to take the time to have a long hard look at the new things coming along and the same thing will happen to you. A Java architect in 1997 who stayed with plain JavaBeans and applets is not a J2EE architect today - no matter how good she is!
Basil McRae writes:
"Very good point -- since Java is still a child, who really should be considered experienced or not? I guess Lei put it best when he mentioned that he is looking for past experience with other languages to complement existing Java experience."
I think other experience can be important, though not always rigorously necessary working in the Java world. For example I often hear that C and C++ programmers who have converted to Java (such as myself) are more valuable because they understand more about how Java works and are more performance-oriented.
There is some truth to this kind of thinking, but only a little. I would rather have a good 'pure Java' person who has made a close study of Java performance and the VM than a C++ person any day. A strong Java developer who has studied the design pattern literature and understands patterns at the 'why' level rather than as mere templates for UML diagrams would be a strong candidate.
I believe that the stereotype of being a C++ versus a pure Java person is really a proxy for experienced versus inexperienced. Not a completely valid proxy!
Experienced is experienced and good is good regardless of the background. A Java person who has made a close study of how to do Java right will be more valuable than her exact C++ counterpart on the first couple Java projects before the C++ person comes up to speed. But I'd take a C++ person who is a student of the profession over a Java person who has learned just enough to get by.
Dion Almaer made an interesting point when he noted that we truly need senior developers rather than so-called architects. I rather agree. My personal definition of 'architect' is actually a very senior and knowledgeable developer with project-wide design and review.
Perhaps we should 'Refactor' the discussion and call this person a 'Principal Developer' rather than an Architect.
"Sounds like the message is getting through to people that the title "architect" is still just a euphemism with regards to Java."
Not exactly. The 'Principal Developer' role I postulate will be good enough to take on the most difficult design and implementation challenges the project offers while being able to serve as design authority and mentor. In my book this means that they have to know one heck of a lot.
Another thing which is important is being able to visualize a complete system in your head and to be able to estimate (formally and informally) and 'size' a system or subsystem. This is classic software engineering type work and not really language-specific. If I have an advantage on you it is in this area. BTW, if you wish to get a start on this area (apart from what they taught you in school) I would suggest starting with "Code Complete" by Steve McConnell (M$ Press), which is a fine book itself and then have a look at his chapter about a software engineer's library.
Fred Brooks 'The Mythical Man-Month', Gene Weinberg's 'The Pshychology of Computer Programming' and Barry Boehm's book about software estimation are other necessary reads IMHO, as well as Jon Bentley's 'Programming Pearls' and 'More Programming Pearls'. Moldy oldies but some things don't change. Bentley in particular has some great essays on back of the envelope calculations and sizing.
I've been this good in the Unix/C area and was close in Unix/C++. I'm not there in Java/J2EE/Web Services/JINI yet. I could probably handle a Senior Developer role under someone like Dion Almaer or Gene Chang. Particularly if they cut me a little slack at the beginning and gave me some time to pick their brains for practical information.
Basil, thanks for the excellent book suggestions. I'd love to hear any more suggestions on essentials for an architect's bookshelf.
On a more granular level I would like to suggest Java in Practice by Warren & Bishop. I think this book is a big boost for anyone wishing to become a "student of the profession" in Java. And on a higher level I recommend The Art of Innovation by Tom Kelley--an excellent study of user-interface design on products ranging from shopping carts to software. I realize this may not seem relevant to a pure code-head, but I found it fascinating. It's one of those rare books that lays down what seems like plank after plank of plain common sense, except for the fact that the mehtods described are implemented so uncommonly in the real world design process. (Little things like actually observing your customer using the product in *their* environment rather than emailing them a survey.) It can never hurt to have a decent understanding of what the people you interface directly with actually do--be it a conceptual level above, below or sideways.
Actually, that was Don Stadler who recommended those books. I only do the set up by b*tching about everything, then he comes in and saves the day.
Another excellent book in the estimating/ technical management area is:
Peopleware by deMarco and Lister
I always thought 'architect' was just another new term to enhance salaries; we use to call them System Designers back in my youth, many years ago.
I've ordered the Kelley book after looking it over on Amazon.
I've a question about the 'Java in Practice' book though. It was published in 1999, and I have to wonder what it covers. I already own the Bloch 'Effective Java' book and a couple other good ones on general Java practice. So what value-added does 'Java in Practice' give us?
That's interesting. You define the architect as more of a mentor. Based on that definition, I would think the architect would be an excellent person to invite to interviews.
I will comment more after lunch. :)
Ryan Breidenbach wrote:
"In my mind, an architect is somebody who has a fair amount of software development experience in all the key areas: requirements, design, development, testing, deployment, software/hardware configuration, platform/product decisions,etc."
An excellent description as far as it goes. I would add that an architect needs a strong knowledge of software engineering (in the formal sense) and in particular a grasp of software economics. Kent Beck touches on this aspect in the book "Extreme Programming: Embrace Change". An architect has to be capable of recommending how to deploy scarce resources.
A few years back I was asked to review a design for a large system with four subsystems. My conclusion was that three of the subsystems were way overdesigned (using Posix threads for systems with expected transaction load(s) ranging from once an hour to once a month is definately overkill).
The fourth system was specified to handle up to 360,000 transactions a day (and a "back of the envelope" calculation revealed that it could be much, much more than that at peak load). So in my report I pointed out that the three 'light' subsystems could be easily handled with very simple designs and that subsystem #4 would require every resource they had to do optimally. Overdesigning three subsystems would lead to a misallocation of scarce resources.
"That said, they don't have to be (and probably can't be) and expert on all of these. They should, however, know the right questions to ask the people who are also working in these areas to figure out what is good for the project as a whole."
Correct. Part of the job description would be 'an expert generalist', someone who knows a lot of things at considerable depth.
I guess my first question would be is your architect just a mentor, or is your architect in charge of any piece of the project? For example, would you setup a control point where any changes to the OOD has to come thru the architect? Is it the architect's responsibitity during use case definition to select and enforce appropriate design patterns, or is that type of detail left to the discression of the development team?
Note: I reference job titles below as a context of what we are used to, but my point is not about titles.
Let me challenge your definition. I don't thing J2EE projects need "A" architect. I think they need "lead" positions in finite skills areas reporting to the Project Manager. As you might guess from previous comments, a Project Manager by definition would have many of the architect traits you mentioned (i.e. I expect a J2EE Project Manager to be able to do more than spell J2EE).
OK, so everyone at least indirectly reports to the Project Manager. The first "lead" position I would define is one responsible for initial requirements definition (I would hate to have this job, but I hear some actually enjoy this stage. Probably the smoozers... they like meetings. :). What I mean by initial is requirements taken as far as possible which would be valid regardless of OO platform. This would include use cases, class definitions and sequence diagrams. High level business logic requirements (specs) should also be provided (again, not platform specific). By the end of this stage, the "What" will have been defined. I would like to at least see a first cut at UI requirements here. You would know if you are about to JSP or Swing at this point.
Now it's time to pass work off to a different "lead" and skillset... Development. I think this "lead" position is the one I would call Architect. I few of the responsibilites that come to mind:
1) Extend requirements documentation to define the "How". This is where plumbing details like MVC and design patterns will be added to the class and sequence diagrams. This extended documentation becomes a contract for "the life of the software" (i.e. even update this stuff for enhancements and modifications to production system).
2) setup delevopment environment (unit,integration,staging)
3) Define team... Lei's sounded pretty good above
4) Define development standards
5) Select tools, create scripts, ...
6) walk throughs with team members for design pattern selection and script based testing before slinging code. I think the XP idea of writing tests first is excellent. I think the XP idea of paired programming is for marketing. :)
7) yada yada yada
Production configuration and support is another distinct skillset. A "lead" to oversee this needs to exist.
I can only speak about small projects (<15 developers), because that is where my experience lies. In those cases, I agree that the project does not need *an* architect, but rather at least a few seasoned developers. Having more than one very knowledgable developer will lead to dialogs that yield better solutions in the long run. IMHO, one lead chef can lead to picking solutions from the same menu each time and never trying new things. This can eventually to short-sighted decisions and designs.
As for roles, I think you should use whoever is good at the required task. At my company, our "customer" is internal, so we are all involved in requirements gathering to some degree. Once requirements are gathered, we do one of two things. If the task is small, we will sit down and code and let the solution "evolve". If the task is a little more daunting, we will meet, sketch an initial design on the whiteboard, give it a try, rinse, repeat.
We also practice a good bit of XP - just about all of it. Therefore, everybody is involved in design, testing, etc. If one person is very knowledgable in an area and somebody else is a newbie, we pair them up. Works well for us, because after a while, everybody knows a little about everything: why a particular design was chosen, who the build works, how are tests are run, etc.
So, in answer to your question, you don't really *need* an architect per se. Let everybody have a chance to do everything. Eventually, the cream will rise to the top. You will see a handful of people doing most of the heavy lifting across the board. These are the de facto "architects".
I have been at many sites where they split up their team:
Architects (make all the calls)
Developers (have to do the work)
After awhile the "Architects" don't know anything, other than fluff, and the developers have to put up with it.
I prefer to have blurred lines, after all each member of the team brings unique qualities.
I like having a team use something like Together* as they can see both the design (model) and the code at the same time. This makes the developers "feel" the design, and be able to manipulate it too.
With XP practices, we can mentor and share information amoung the team, so everyone gets to be decent at various tasks. I would hate to be "The JSP guy" :)
"I would hate to be "The JSP guy" :)"
Yeah, but being the server side EJB slinger without having to deal with gathering requirements or building UI would be sweet. I have spent a lifetime building UI. I think all newbies should break in with user requirements and UI. That's cold, even for me. :)
The problem is with the titles. Architect is above 'senior developer', and 'senior developer' tends to be handed out to anyone who can design and code a subsystem without help.
Shall we coin a new title? How does 'Principal Developer' strike you?
Dion Almaer writes:
"I have been at many sites where they split up their team:
Architects (make all the calls)
Developers (have to do the work)"
Usually these Olympian characters are called 'Solutions Architects' in my experience. In one case I've seen a 'Senior Consultant' driven into a nervous breakdown trying to implement one of these architectures. Admittedly the 'senior' was actually a pretty decent junior promoted beyond his experience. But had he been working with my design I would have made dang certain that he knew how to do it! The 'solutions architect' could not be bothered to ensure the quality of the end system, he was too busy making presentations and taking the credit for work he had not done.
"After awhile the "Architects" don't know anything, other than fluff, and the developers have to put up with it."
Sadly true, assuming that the architect ever knew anything but Powerpoint in the first place. I worked with such a creature (a 'Technical Architect')on a large project last year. He completely forgot about security (and several other things) until the last minute. The senior developers on the project had to identify the architectural problems and oversights, work out solutions, then convince the architect to go with them rather than impose his own after 20 minutes of discussion about topics he knew little about and had not thought about. Perhaps he knew something we didn't. He left for home before 6 each night while the senior developers were frequently in the office until midnight......
The pity was that there were at least four people on that project who would have done a far better job as TA than this guy. He did client face work very well I will admit.
I think of a proper Architect as a very senior developer with a project-wide design and review brief. But his boundary does not end with architecture and design.
Her responsibilities include detail design and cutting code as well as keeping track of what is going on with the development of other subsystems. A major responsibility is to make certain that nobody 'gets lost' and starts to slip schedule. It's a delicate role requiring a strange mixture of arrogance and humility. Confident enough to be able to intervene where intervention is needed. Humble enough to know where to keep one's cotton-pickin' hands off and leave well enough alone! There is no reason why there could not be several of these people on a large project. Mentoring is a major part of it too. Sometimes all you need to do to get a good guy back on course is hand her a book and say "try reading Chapter 5". Of course that assumes that you have read and understood chapter 5 yourself beforehand. Which can be difficult to do if all you ever work with is Powerpoint or Rational Rose!
"I prefer to have blurred lines, after all each member of the team brings unique qualities.
I like having a team use something like Together* as they can see both the design (model) and the code at the same time. This makes the developers "feel" the design, and be able to manipulate it too. "
Yes, this works best.
"With XP practices, we can mentor and share information amoung the team, so everyone gets to be decent at various tasks. I would hate to be "The JSP guy" :)"
"IMHO, one lead chef can lead to picking solutions from the same menu each time and never trying new things. This can eventually to short-sighted decisions and designs."
My experience has been almost entirely large projects, but I have come to believe the following:
With production code, programmer creativity has to give way to standards. The most important thing is not how good your standards are, but rather that you have them in the first place. I don't want programmer A doing an indentical task as prgrammer B in a different way. Now, that's not the same thing as saying quit looking for better ways to do things. As soon as a team member comes up with a better mousetrap, figure out the impact of switching. If it's worth it, refactor all occurences, or maybe just start from this point forward with the better solution.
You mention you use the XP pairing concept for mentoring. Actually, that makes as much sense as any technique to me. Do you use it for two veteran team members. That wouldn't make much sense to me. Having walk throughs with other team members (more than two allowed :) for design choices before slinging code would seem to be a good way of "having dialogs that yield better solutions ".
Don't get me wrong. I am not saying that standards are not important. On the contrary, I think standards are vital. How these standards are decided is up the team. We sort of "vote" on standards as issues arise, and then we all agree to follow them. Sometimes begrudgingly :-) However you arrive at these standards, I think they are must before proceeding with any coding.
As for programmer A doing the same thing that programmer B is doing, only in a different way...XP sort of handles that for us. We program in an open environment - literally. No walls around the development machines; out in the middle of the room. So you can always hear other pairs talking to each other. If somebody hears another developer discussing a solution that solves the same problem they just solved, they tell them and they both find a good, common solution. Pretty soon, everybody knows how about the solution. Make sense?
In answer to your other question, pairing two senior team members works well in some circumstances, especially for complex tasks. In my experience, veteran programmers *very* are good at arguing. Having to defend a solution to another seasoned programmer (playing devil's advocate with a lot of "what ifs") before it gets committed to the code base ensures that the solution is sound. In this situation, 1 + 1 > 2.
Personally, I am not a big fan of code walk throughs in the postmortem sense. I like design discussions, but anything kind of review "post-coding" has always seemed dumb to me. If the solution is good, the design should be evident in the code. Perhaps they have there use explaining designs to newer developers.
"Personally, I am not a big fan of code walk throughs in the postmortem sense. I like design discussions, but anything kind of review "post-coding" has always seemed dumb to me. If the solution is good, the design should be evident in the code. Perhaps they have there use explaining designs to newer developers."
You and I would get along great. You said it perfectly. You would be surprised how many think "post-coding" makes sense. With me it's easy... we have standards and you follow them.... or you will be learning somebody else's standards. :)
"We program in an open environment - literally. No walls around the development machines; out in the middle of the room."
I think I learned Powerbuilder in an XP environment, and didn't know it (at least the no wall thing... not paired. :) I have said for several years, nothing beats what we call the "development pit" for learning a new skill. It worked exactly like you said at first. The problem arose when we all basically had it down, and would have given anything for somewhere quiet where we could do some serious code cranking. I hope in an XP environment, you have a workstation somewhere where you can get away from the pit when you need to. Also, what about "reading time". No such thing as J2EE without research time. :)
Really appreciate the feedback. Sounds like you may have a good work environment. Work? What a novel idea. :)
Ryan Breidenbach writes:
"Personally, I am not a big fan of code walk throughs in the postmortem sense. I like design discussions, but anything kind of review "post-coding" has always seemed dumb to me. If the solution is good, the design should be evident in the code. Perhaps they have there use explaining designs to newer developers."
Aren't code reviews sort of redundant and even outdated in the XP methodology? It seems to me that such a review ought to actually be a refactoring session with two or more participants. Perhaps you could do this in a small meeting room with the code listings and design charts projected up on the walls from a laptop hooked into a projector. Everyone could have light pens and the guy at the keyboard could make the agreed changes. People could switch off in that role.
Does anyone think this is a good idea?
"<bait> the only perfect people I know are you and Sartoris Snopes! </bait> "
There's only been 1 perfect one to walk this earth. And it's been a couple thousand years since. But I thank you for hodling me in such high regard. :-)
BTW - Basil is a cool name. Are you from the south?
Yah, I second the motion on the Perfect One: for those of us who may not understand what Sartoris meant, read into "The Matrix" a bit more and try to place that movie's plot in correlation with a certain Book and what it claims to be prophesizing ;-)
Sartoris, I have been reading your posts for months now and the reason I baited you there is because I remember you taking on several faithful Java posters on some very controversial subjecs -- eg. I think you were making a point that C++ was still a superior language to Java a few months ago. I remember that you had a comeback for everything and everyone, and in the end the only thing that made me feel better was to say to myself, "Well, this guy just thinks he's perfect, doesn't he?!?!?". hahahahahah - so my comment had a little bit of history attached to it....
Thanx for your good sense of humor, though. By the way, I am from Canada.
"BTW - I am not knocking those who came to Java from another language. I'm sure they are many talented Java developers who have accomplished this. I just pesonally know *many* who suck."
My response is not meant to be provacative but I have a very differnt experience. I've found that most Java only developers are lousy overall. Particularly in the OO realm. For example, it seems that most think that Java uses pass by reference! I think that what Java hides from the developer has a way of dumbing-down the developer. Garbage collection gives way to a "who cares where it comes from - who cares when/where it goes" mindset.
I think, too, that people who know Java think that because they know an OO language that what they write is OO or good OO.
You "... think, too, that people who know Java think that because they know an OO language that what they write is OO or good OO. "
Point well taken. Something I called "localized monolithic programming" should be avoided at all cost. Partition is the key. There are so much ART in it from architecture to code. That is why there are no correct code or architeture, only the better or best ones. I try to keep reminding myself of this all the time.
"I've found that most Java only developers are lousy overall"
I wouldn't go so far as to say "most". I would however say that a limited amount are very good at what they do. Good OO design is not obvious. It takes time to develop this, but it really helps to have a mentor to lead the way. Unfornately, as I said before, not all "senior" developers are good OO practitioners. And bad habits beget bad habits.
"...people who know Java think that because they know an OO language that what they write is OO or good OO"
I agree. But again, I don't think this is isolated to Java programmers alone. It main seem more prevelant in Java, because this is the language de jour. Their are tons of Java developers competing for jobs right now, and some lousy developers are bound to slip through the cracks.
On a side note, of the Java developers who do not have sound OO skills, I would divide them in two categories. The first is those who do not have them *yet*. These are the ones who are new to the Java/OO game, but are smart and have a thirst to learn. These guys deserve to be taught and mentored, because can and are willing to learn. And then there are those who just don't get it. This is not for everybody. Some people just don't get it and never will get it. These people need to find another industry and quit mucking things up.
That last bit may sound elitist becuase it is. Software development solves complex issues with complex solutions.
This requires some degree of intellect. If you do not possess this - please find another career.
"But again, I don't think this is isolated to Java programmers alone"
You are absolutely right about that! We were all in the lousy category at one time. Some stay there longer and some never get out. ;-)
Tell me why good OO is so important in J2EE? For example, let's say you have addressed your "finite set of problems" with project standards using patterns (i.e. session facade). I love how the industry invents new words all of the time for problems that have existed for ever. Templates and cut and paste -> foundation libraries -> Patterns. The short version is we are looking for an assembly software development process vs individual developer creativity. So if we follow good assembly standards (patterns) and we do basic OO stuff like making sure not to declare methods that should be private as public, what else is critical. For example, I believe using inheritance correctly could save alot of code, but what if you blew it. I'm pretty sure we have had successful software develpment prior to languages that support Inheritance. If you can, give me a list of OO concepts that a J2EE developer MUST understand to be a good J2EE developer. I'm not trying to be argumentive, just interested in other's opinions.
By the way, I'm in the *yet* category. I will rock!!! :)
Indeed, good software was developed way before OO. However, if you are going to develop with an OO language, you need to leverage the benefits it gives you over other languages. IMHO, the key benefit that must be maximized is to decouple your "layers" by programming to interfaces. To list a few OO "concepts" that I see often overlooked...
1) Do not abuse inheritance. I rarely find it useful for a concrete class to subclass another concrete class. Do not force and inheritance hierarchy just to reuse a few methods and attributes. The "is a" vs. "has a" relationship example has poisoned a lot of developers thinking of how inheritance should be used.
2) Prefer object factories over direct instantiation for creating objects. This can allow you program to an interface rather than an implementation, as well as control when/how many of a certain object is created.
3) Uses interfaces/abstract classes! This is crucial for so many reasons. You can code to an interface that has not even been implemented yet. You can create mock objects that implement an iterface for unit testing. You can switch implementation with no impact. This one is a biggie!
These may sound obvious, but they are often overlooked. Is is much easier/faster to develop concrete class -> concrete class in the short term and this is fine for prototyping (I guess). In the long haul, this naive approach will lead to brittle, inflexible apps.
There are dozens more examples - I just don't want to get too off topic. Basically, ten successful years of software development in a non-OO environment means that you have good software development practices and problem solving skills. It does *not* mean that you can write good OO code. OO takes a while to wrap your brain around, and it is probably a little trickier coming from another (non-OO)language that it is starting from scratch.
Hey, if those are some of your main OO points, I think I would pass as not being OO illiterate. I believe you are right about them being common sense. It would be good to keep a reminder list handy on the major issues going into design. Developing to interface/abstract classes makes absolute sense. I always thought alot of the inheritance banter was hype. As Bruce Eckel states in his book, "Thinking in Java", inheritance should be used rarely, and it should be fairly obvious when you need to (something like that). I guess I view OO as similar to all of the entity modeling hype years ago. Neither is an exact science. Understand the basics and use some common sense. I did not know object factories would be considered part of OO design. I had planned on using them when implementing the session facade pattern. Makes total sense. Maybe I should not view the entire pattern discussion as seperate from OO design?
I will still stand on my original premise. Selection of appropriate design patterns (assembly cookie cutter approach) will be more important for development and maintenance than how "exact" you get the OO design. I'm not discounting OO, and your short list makes total sense as things to do. And yes, by all means, take advantage of what the OO language provides. But other major design decisions like which patterns to standardize on and technical design decisions like using MVC and Struts will be much more critical. JMO. I reserve the right to change my mind after the first java gig. :)
Maybe all of this is off-topic, but one more question. In J2EE projects you have participated in, when / who does the OO design? What's the hand off from the Requirements definition and design. I'm not a UML geru, but I'm very familiar with the sequence diagram. This is how I suspect I would setup the process if I was in charge. I would have the requirements gathering team take it from use cases, to intitial class and sequence diagrams. I would think the design team would take these initial class and sequence diagrams and requirements and add the detail required to implement the final desing (i.e. session facade pattern and objects). Something like that.
Based on that, it makes me wonder where you plug in what everyone refers to as the "architect". Seems like you would have someone good in OO class definitions on the requirement team that you could call an architect. I don't think that person has to be also the design architect. This could be two people, or one, but it definitely seems like two different skill sets. As O'Reilly say, "where am I going wrong"?
I lied... one more question. The only project I was on where we used UML, we didn't use a tool like Rational. We created our own sequence diagrams and backed them up with Microsoft Word specification documents. Does tools like Rational provide for the capture of business specifications along with their diagram creation ability? I definitely am not sold on the concept of expensive design tools like Rational. I would require the UML documents to be kept up to date throughout the life of the software, so I'm of the mindset to keep the UML documentation as narrow as possible. Seems like free tools and good standards would work just fine. Now way off-topic. :)
Hi Lei and other hiring managers,
Just an analogy:
COBOL and other non-OOD languages are like playing the game of checkers.
Java and other OOD languages are like the game of chess.
And the controversial questions to the hiring mangers and others out there:
How can a 10 years checker player compete against a 5 years chess player while playing chess?
Then the ten year of programming experience is useless. From a pure coding stand point. I don’t think you can bring the strategies learned from COBOL to OOD.
I think if you have 10 years of programming experience in COBOL and you have 3 years in java. You can throw out the 10 years of COBOL because it’s useless. The rules of the game have changed completely.
How can you guy tell the difference between one person with 5 years of “pure” and “hard-core” programming to a person with 5 years in a big company doing 5 hours of real programming a week?
Please let me know what you guy thinks.
And to end it:
From a fortune cookie: “There is no wisdom greater than kindness.”
Like the analogy - Checkers vs. chess! As for your question about differentiating between the guy busting his ass for five years and the guys sitting on his ass for five years...
This requires a skilled interviewer, I guess. This sucks because interviewing is a time consuming process, but I can't think of a better way.
For me personally, I can think I can sense when a person is passionate about development, and this is a big deal for me. I usually start with a very open ended question like, "So, tell me about some projects you have worked on." If they haven't done any real work, it should start to show about now as they try to smother you with buzz words and fuzzy details. If they have done some cool stuff, they will know the ins-and-outs and will want to show if off to you.
Also, I like to find out about a certain technology they have used (e.g. Struts) and play devils advocate by suggesting an altenative (e.g. Tapestry) to see how they put together an argument. This is a sure-fire indicator as to whether or not they know what the hell they are talking about.
Tapestry is presented as an alternative to JSP (i.e. non-J2EE). I think as long as JSP is part of the J2EE spec, I would lean towards solutions like Struts. Noone knows exactly what J2EE will look like in a couple of years. It seems like it would be a dangerous practice to start fighting the tape.
How did I do?
Thanks for the reply. This thread has been very help!!!
Yes...I was trying to pick a fight. Come and get it!!! Just kidding... : )
Actually one of my good friends was a COBOL programmer for 12 years. He actually gave me the analogy. This was after he went back to school for C++.
I came from a RPG (s*cks) background. And when I moved to OOD and Java, it was overwhelming. In my current employer, I am surrounded by 20 years experience ?COBOL?-like programmers trying to implement OOD concept and design. They are constantly making common mistakes that someone with just a few years of experience would not make.
You are right if you are good, you will be good no matter the language. However, I don?t think that procedural concepts are a significant part of OOD.
Anyhow, that?s just my two cents from my personal experience.
Thank again everyone for the very informative thread!!!!
And taking a line from Star Wars:
(People) ?beware the dark-side; fear, aggression, and anger.
Thanks Ryan for the relpy!!!
You asked "How did I do?" You tell me, please. I got so many questions for you. But I am sure you are having fun here. Enjoy!
I don't understand your post.... you seem peeved at me? Ryan had posted a typical interview question: Compare Tapestry to Struts. I took a shot at it and asked how the response measured up.
Maybe I should make it more explicit, that was really a compliment.
You appears always ask pointed questions at the right time on OO, J2EE and so on. I was amazed! Maybe you were playing chess on a checkers board during those 18 years (once again, thanks Nick). Maybe you can tell us something about Expresso or Pizza or whatever? Or your true bio?
Anyhow, good day. On the beach??? Hey, someone please send Mike back to Adnan's corporate America.
Nick, nick, nick.....
Are you trying to pick a fight? :)
"Then the ten year of programming experience is useless. From a pure coding stand point. I don’t think you can bring the strategies learned from COBOL to OOD."
Well, picking COBOL was good for your argument, but it's still horse s&^*
If your a good programmer, you can be good on any platform... period.
I was good at Natural /Adabas and was told client server (Powerbuilder) was to different. Oops.. picked it up in a couple of months and was pretty good at. Just got lucky. How the heck did I figure out to stuff all of that code in events, as opposed to procedural code. Just got lucky.
Guess I won't be able to pick up J2EE coming from Powerbuilder. N-tier is just to difficult and different. How the heck will I figure out how to stuff all of that code in components instead of client side event code? This time, the vendors have knocked themselves out to provide enough confusion to support your premise, but I woudn't bet against me.
If I'm in charge, I wouldn't allow my developers playing chess. All chess games would be broken down into as many checker games as required, until only checkers was being played. Chess needs to be reserved for acedemia and open source. :)
One was a COBOL programmer with 8 years in the banking industry and one guy had a PhD before he was a senior developer.
I am 2 years out of MS CIS and I can code both of these guys together under the table. I have my own J2EE community website. Can I get a senior programmer job?!!
HA! I don't even make the HR interview cut.
But watch out, you lousy pea-brained architects and status quo holders -- I am coming for you, and boy, am I pissed!
Greg Nudelman writes:
I'll bet they do a good presentation though!
"I am 2 years out of MS CIS and I can code both of these guys together under the table. I have my own J2EE community website. Can I get a senior programmer job?!!
HA! I don't even make the HR interview cut."
Lots of people are in this position. Some of them might even be able to code YOU under a tables! Do you think 'coding people under a table' is the sole criteria of a senior developer or architect?
"But watch out, you lousy pea-brained architects and status quo holders -- I am coming for you, and boy, am I pissed!"
Is this a general slur or a specific one?
Is this a general slur or a specific one?
In this case, I am simply lamenting to the Java world the obvious. That is, so many so-called "architects" are really frauds that can toss buzzwords around and appear important to the big boss and HR. Yes, they can present themselves well, but so can I (if given a chance). The point is, I will NEVER get this chance, because I do not have 10 years of so called "experience".
In reality, they are not interested in OO or J2EE technology or even in producing good software in general. They are in my mind akin to doctors that don't care about patients, just their Mercedes. These guys are interested in holding down their position not by getting better at what they do, but by playing political games, screwing with the specs and deadlines and accidentally obliterating you source-safe submissions.
I can post the code written by these guys, if you like. It has a great entertainment value if nothing else! :-)
I really am a nice guy; I just got fed up a little with the job situation yesterday. Sorry. I am all better now. :-)
"In this case, I am simply lamenting to the Java world the obvious."
Let me clue you in. This didn't begin with Java. It didn't begin with C++, or C, or Cobol. For all you know the Cobolguy used to be a whiz - at Cobol. Life can be a sad thing. Twenty years from now YOU might be 'that old Java guy', can't he get a clue?
There are a helluva lot of architects or senior developers on this board who started with other technologies. Idiots don't last around here very long no matter what their background or job title. But there are a helluva lot of us in our late 30's and 40's!
I've been architect-level with C and Unix and in C++ before, but I'm not one in J2EE and probably won't be for another 6 months or a year. I know what it takes and have worked very hard to get where I am today. I might even be better than you, that remains to be seen.
Everyine faces political games. I could tell you stories about my current employer which would curl your hair. And indded I'm looking to get out and start again once I have reached my knowledge goals. Because my next job will be an architects position.....
"These guys are interested in holding down their position not by getting better at what they do, but by playing political games, screwing with the specs and deadlines and accidentally obliterating you source-safe submissions. "
I've seen this at all ages. Up until the last year it was actually easier for younger guys to get away with it. I saw a guy in his mid-20's double his salary despite knowing nothing. He knew less than your architects!
Hi there, im afraid I don't have much of anything useful to add to the current discussion, but im really enjoying being a lurker so far!
I was referred here by a helpful person on the Austin Java User's group list who agreed with my surprise at the results of the salary survey. I'd be happy to even be earning $25 an hour right now.
I've held "Senior" and "Lead" developer titles and have 6 years experience since getting my bachelors in CS, but only really 1 year or so in "Enterprise Software", and another year or so before that writing servlets for web sites with a fancy web site studio (prior to that we used Python for several years, then a brief year or two with LiveWire, UGH).
I quit my job a year ago because I felt like I was being forced to write round pegs to fit in square holes, just to adhere to "coding and architecture standards" that reflected problems with the EARLIEST of the Microsoft JDK implementations. I.E. "You may not throw exceptions in constructors!" We were doomed to repeat the CTO's poor architecture decisions forever in the name of consistency. Unfortunately I COMPLETELY underestimated how hard it would be to find something new! Guess I was still stuck in early 2000 when I got offers to interview with pretty much every job I applied for. I figured things couldn't have gotten THAT much worse.
Anyhow sorry to ramble, but I got a nice laugh from Mr. Nudelman's rant, after a year of applying for jobs, and having a total of five (unsuccessful) interviews, I have those fits of pique every other day :) I sure wish if nothing else that I could get a "no thanks" for every job application Ive made where they weren't interested, so I could at least be saved the bother of trying to follow up (and be ignored). I'd like to think i'm not THAT dumb, so it's sometimes perversely satisfying to hear of other experienced developers having trouble finding a job. :)
Glad to hear that most of the people in the discussion whose opinions I value (after reading the whole thread) agree that im not wasting my time working towards the Java Developer certification. Im certainly enjoying it and have learned a fair amount, despite having used all the pieces before.
Keep it up!
My job frequently is like having dental work, but I am holding on and learning what I can. No lectures, it's an easy mistake to make. Particularly for someone who hasn't been through an economic downturn. And this is a particularly bad one, particularly in Austin from what Tracy Milburn writes.
The Developer cert isn't a waste of time. If I were in your position I'd go for the whole banana, Programmer, Developer, and Architect. But I wouldn't put the Programmer cert on my CV unless it was a listed requirement.
Have you joined any JUG's in the Austin area? It's a good way to network. In a market like this one it's one way to get first crack at new jobs. They often prefer to ask about friends before listing on Monster and going through 100 resumes. 'Well, I know someone from JUG who might be interested'...
Sun Programmer Certification passing SCORE is too
low. That's why many people don't consider it an asset.
I think it's meaningfull to put Programmer's certification
on you resume if your score is HIGH. And vice versa.
If I see a person with ~100% score I know that he/she
spent quite some time preparing for it, that shows
he/she is determined and quality - oriented.
I have an opposite viewpoint about the Programmer Certification scores. I think the point of it is Pass or Fail. I can't imagine posting your score on the resume. To me, the Programmer Certification just proves that at a minimum, you have spent some time understanding the fundamentals of the Java language. It certainly doesn't prove you have slung alot of code, particularly in EJB land. It's probably more important for someone with few years of actual experience, or in my case, 18 years of experience, but looking for the first java gig. I have spent the last 12 months dedicated to J2EE education. I spent the first 8 months on J2EE foundation reading (J2EE, EJB, Patterns, JDBC, Struts, MVC, ...). It was very hard to put of coding for this long, but in hindsight, I think it provided the necessary foundation. Then I spent about a month and a half (a long month and a half... I'm a contractor on the beach for a year, so this is full time education) preparing for the Sun Programmer Certification test. I read two books (Thinking in Java, Exam Cram by Brogden), took a couple of mock exams posted at the JavaRanch, and passed the test first try with a low score. Two observations. The test required to much memorization (who really memorizes method signatures) and was weighted to heavily on areas that have very little to do with EJB development. (Maybe they need more than one base Programmer certification... like one geared for J2EE). I scored high in areas like the fundamentals, and low on File I/O, AWT and Java threads. My goal is EJB server side programming. I could have spent more time to come up with a higher score, but it seemed like a waste of time in the scheme of things. I accomplished what I intended... obtain a solid base understanding of the Java language. That by the way, seems to be only a small part of the J2EE challenge. Instead of spending extra months on a better certification score, I'm spending time on other required learning curves (N-tier development, Specific application server - WebSphere AEs 4.0.2, IDE, debugging (JPDA), Clustering and Load balancing... vertical and horizontal, CMP - PM issues/products, state management, cacheing, source control, Ant, JUnit, UML, security, HTTP server and application server configurations, DMZ zones and firewalls, web services, JMS, ....). You get my point. A wise manager will look for actual J2EE experience first, and then look for proven years in the business plus a broad J2EE understanding plus the ability to pick stuff up quick. I figure everyone with J2EE, even the veterans, are stuck with a committment to many hours of continued education. If I'm the one doing the hiring for a J2EE development effort, I would much rather hire someone with a broad J2EE understanding without hands on Java vs a veteran Java programmer without J2EE knowledge. Java is just another language (although an excellent one... a big thumbs up for the exception catching feature of the language).
Just my two cents.
Ditto. Well said and that's exactly what I look forward in a candidate.
This was an interesting post. I've been working three years part time on a similar programme of study. I decided to opt out of the programmer certification. I looked into it and decided that I could spend the better part of 2 months of free time preparing for the test and memorizing the details of AWT and I/O or learn something useful like Web Services well. I accomplished what I intended...
>> obtain a solid base understanding of the Java language. That by the way, seems to be only a small part of the J2EE challenge. <
You can say that again! There seems to be no end to the J2EE/Web Services universe. To be a proper J2EE architect you need to know about JDO, the full suite of XP build and testing tools (Ant, JUnit, HttpUnit, JMeter, JUnitPerf, and Ant), at least one of the major application servers, all in addition to master all of the material in the Roman and Marinsecu EJB books and at least one major MODERN text on both Servlets and JSP.
It's a huge job and I confess I'm not there quite yet. I have hopes that I'll finish by the end of the summer but realistically it's a moving target and aiming for the end of the year might be more likely.
>> ...required learning curves (N-tier development, Specific application server - WebSphere AEs 4.0.2, IDE, debugging (JPDA), Clustering and Load balancing... vertical and horizontal, CMP - PM issues/products, state management, cacheing, source control, Ant, JUnit, UML, security, HTTP server and application server configurations, DMZ zones and firewalls, web services, JMS, ....). <
First, I commend you for being able to stick with this in part time mode. That's awsome. I've been on the beach for a year (contractor jargon for unemployed), and have had the luxury of making the J2EE education my day job (and sometimes night). I think skipping the Java Programmer certification to use the time elsewhere makes perfect sense. In my case, I didn't know java yet, and it provided a fairly quick goal oriented way to learn a foundation of the language. I was very disappointed that the test was so heavily weighted towards AWT and File I/O. But hey, I'm still putting it on my resume. The test was definitely not easy... and I've taken more than my share (I'm your age + 1). Those saying it is worthless haven't taken it. :)
Yes, the Java language seems to be a very small part of the J2EE learning curve. I would be interested in what others think, but it appears to be something like this for J2EE developer education:
1) java language fundamentals - 20%
2) J2EE (JSP,Servlets,EJB,JNDI,Application Server,...) - 50%
3) tools and frameworks (IDE,MVC,Struts,Ant,JUnit,...) - 30%
I didn't even include Swing. If you have to go down that trail, it seems to be a beast by itself. :)
I also did not include the learning curve for production configurations above. I'm viewing my learning curve as preparing to be a developer. I would love to also be an expert on production environments, but part of what you have to learn early about the J2EE learning curve, is when to fight your thirst for knowledge, and say "I know enough about this for now". For example, I have always wanted to know more about load balancing and clustering. I selected WebSphere (started with JRUN and Orion) for my education. I read the first 100 pages in the IBM Redbook on Scaleability, and learned what I needed for now as a developer. The other 400+ pages looked very interesting, but that trail would divert me from my number one goal of being "J2EE developer ready". :)
Good luck to you. I consider it a mission now.
"Here is no substitution for hands on experiences, period. One needs to learn from one's mistakes and this learning process can not be replaced by remembering a few questions in a certification guide."
No one is claiming that a certification replaces anything. It simply confirms that you have attained a certain level of knowledge required by the certifying authority, in this case its Sun. It also shows that you made the effort to study for it and take it. It augments experience, not replaces it.
Level of work experience can be exaggerated. People claim all kinds of experience that they do not have. If they have ever run a HelloWorld EJB demo, then you can bet the resume will include EJB experience. You cannot exaggerate a Sun certification. You either have it, or you don't. If the certification process was a total joke, Sun wouldn't offer it. It's not like they make a ton of money on it.
To those people without certifications who bad-mouth the exams and those individuals who make the effort to take them, I say either take the exam yourself or shut up about it.
A good interviewer can always pick apart an unqualified applicant, but sending a resume to the bin ONLY because it contains certifications sounds just plain shortsighted to me.
My two cents.
First of all, I never said I will send a resume to the recycle bin just because it contains some certifications. All I said was I would cast a negative toward those candidates.
I misunderstood the intension of my post. I was NOT badmouthing Java certificates. All I am saying is that Sun needs to do a better job at determining to whom it hands out the J2EE certified architect certification. All those pretenders have made this certification useless.
And yeah, I HAVE picked aparted so many so called J2EE certified architects in the past six months and you wonder why I have such a low opinion toward Java certification? :-)
If you think it will help your careers, go for it.
You'd 'cast a negative vote' on people who spend some time learning ?! Do you know how much effort it takes to pass those certifications (especially SCJD and SCEA) ? I have the 4 Sun certifications and WebLogic 5.1 and 6.0 and I'm proud to have gone through that. And I'll go on with jCert now irrespective of people like you who 'cast a negative vote' on certified people. In order to succeed, I had to read the full Sun specifications for J2EE and the different modules, read half of the chunky WebLogic documentation, study the design patterns, study OOAD, without speaking of the different domain related books I had to go through. You have to work to get these and work hard! I don't think the average uncertified programmer goes through all that. At least, I have not seen many in the different places I've been. Now you can argue all you want that reading specs is not needed for programming work. I'll then argue about the quality of your deliverables: experience only is almost synonymous of hacking. Ok, you don't need to be certified to read the specs. However you need to read the specs to be SCEA and SCWCD certified. And when you're certified, you keep this habit of reading as much information as you can in order to improve your knowledge and by extension, the quality of your work.
I've been in Java since its very beginning as a student. But it's only been since the different certifications that I am able to really be productive and understand the big picture in a project. People who pass these certifications should not automatically be given heavy responsibilities I agree. But at least they have proven to have enough self-motivation and good will to go through this heavy process on top of a daily job and family life in some cases. Certifications are a catalysor in the experience process.
In my opinion:
- experience + certification > experience
- experience + certification > certification
- experience > certification
Just the same as:
- experience + degree > experience
- experience + degree > degree
- experience > degree
Certification brings the fundamentals, experience brings the real-life situations. I think every serious IT expert need both fundamentals and real-life situations. People who arbitrarily 'cast a negative vote' on the hard work one has to carry out to achieve those certifications are arguably worth working for Mr Lei.
Let me repeat what I said, that's I have interviewed a fair number of Sun certified J2EE architects and none of them has passed the first round of interview. Draw any conclusions you like. I certainly have drawn mine.
And one needs to constantly learning, upgrading one's skill set all the time anyway, and doesn't have to do it for the sake of passing some memory test.
I have read J2EE and J2SE specs, not because I have to pass some tests, because I ENJOY reading them!
And last but not the least, I trust my own ability to judge people's qualification more than the result of some machine generated tests.
What I'm saying is that you should avoid generalisations based on your own experience. If you were looking for an experienced architect for a critical project, a certificate is not relevant: it is neither a good sign nor a bad sign. A certificate shows a will to learn at most.
For people like me, certifications are a very good incentive to read and understand the specifications because I don't particularly enjoy reading them, I much prefer reading books about history or play some music in my spare time. You're lucky if you enjoy reading them without any incentive.
The fact that you talk about machine-generated tests prove that you do not know what those certifications are: only first part of architect certification is a test. The architect and developer certifications are toy-projects assignments and you have to provide deliverables.
- code, Javadoc, user manual for SCJD, justification of your design;
- UML diagrams, justification of your design for SCEA;
These are not real life cases of course but it took me more than 100 hours each to complete. That does not include the reading. I would not call that machine-generated tests. That's where the added value in those certs is.
What I'm concerned about in what you said is your negative prejudgement on certified people. Of course, a certification is not supposed to replace your own ability to judge candidates. Nor is it supposed to be.
I think I agree with you that "A certificate shows a will to learn at most." and let's just leave it as that.
Would you then agree that the will to learn is not something to cast negative votes at ?
Some free advice and opinion, FWIW.
1) If you are a young genius, figure out a way to make use of it outside of corporate america. Figure out how to sell your product (i.e. software) to corporate america, rather than sell your skills to corporate america. It will make for a much happier experience.
2) If you do remain in corporate america, treat the old guys with respect, even if your IQ blows them away. This is a dumb request, because I'm fully convinced this will always be a cut throat business where we throw out the old because the technology changes every 5 years giving the young guns the chance to arrive and announce their superior intellect and skills. This business is much more about accumlated experience than IQ. This is why Lei is telling you he would take the 10 year dude instead of the java slinging youth. By the way, I can almost guarantee you will be the old guy one day. :)
"You also be under three or four years removed from college and be a kick-ass developer."
Not at any company I ever run. Anyone under 30 need not apply. :)
Thanks for the advice. I wasn't trying to take a shot at developing veterans OR plug myself as a "young genius". When I was referring to the hot shot right out of college, it wasn't self-referrential, just a hypothetical. In fact, I am quickly becoming that "old guy" - my receding hair is already there :-)
Also, I don't think it takes ten years to become quite experienced. From what I see, there is very finite number of devleopment problems to solve. They just keep popping up in different forms and they usually require a similar solution each time. The only difference is the solution's context. The sooner you have a proven solution in your mental tool bag for a large subset of these problems, you are ready to call yourself an "experienced developer".
I guess my conundrum is that what it all boils down to is how well you do your job, but you don't get hired on how well you do your job. You get hired on how well others perceive you can do their job. I guess if you can't wow prospects with your experience on the resume, take whatever job you can get and then wow them with your work, right?
Oh, and just out of curiosity, anybody know how old these guys are: Ed Roman, Floyd Marinescu, Marc Fleury, Rickard Öberg? I am guessing, they are all close to that "Anyone under 30" crowd, and I would probably hire any one of them ;-)
"From what I see, there is very finite number of devleopment problems to solve."
Exactly, no matter what technology. Of course with n-tier development, the industry is pushing for infinite set of problems vs finite. :)
"When I was referring to the hot shot right out of college, it wasn't self-referrential, just a hypothetical. In fact, I am quickly becoming that "old guy" - my receding hair is already there :-)"
I'm sure I'm older than you, but my hair is hanging in there. :)
Sorry, I read it that way. As you might guess, I have lost my patience with the young egos. Actually, to be honest, I have probably lost my patience with this career. The 18 years of experience are contractor years (I think that's the same as dog years :). Calling contracting a career is an oxymoron. It's more of a trade, like being a plumber, although a plumber get's to apply his trade without others helping. :) I find myself constantly providing services to a 26 year old middle level manager. The company puts the burden on that individual to be the decision maker and manager of the experienced help. In my opinion, few are ready for that. I certainly was not at 26. Which by the way, points out that a conversation about hiring based on experience needs to be more specific. Are you hiring someone to manage 20 people on a project, or are you hiring a technical wirehead ... I think on this thread referred to as "hard core java". Granted, Rickard Oberg is fully functional under 30 :), but does that make him ready to manage 20 people. Maybe he could, but the point is it's take alot of different skills these days to pull of a J2EE project. This is where I differ with Lei's response.
"Because of the current economy and job market, everybody I know who is hiring is looking for the PERFECT candidate, meaning someone with 10 years software development experience with last three years in Java/J2EE, who is also an expert in UML and OOD, good writing, communication skills, good project management skill, and more..."
I think the perfect J2EE candidate is actually 2 or 3 folks experts in their niche. You are bound to be average at some of the above if you claim to be an expert in all of them.
"I guess my conundrum is that what it all boils down to is how well you do your job, but you don't get hired on how well you do your job. You get hired on how well others perceive you can do their job."
Perception... yep. I'm a contractor, so my experiences will be different than an employee, but I've seen the smoozer beat out the one with superior skills time after time. It all comes down to the purchaser decision. Seems like there should be a third party service out there to audit such decisions for companies. :)
We are all in the same boat. It's a tough business, and getting more complicated every day. How do you measure experience when the technology and platforms change so often. Let's say I'm looking for my first java gig and I'm up against someone with 5 years overall experience, but the last two has been J2EE. I have 7 years mainframe (COBOL, Ideal/Datacom, Natural/Adabas), 7 years client server (Powerbuilder), 2 years n-tier (VB, COM+). Does the 5 year guy beat me out of the job? My answer has always been based on "how long is the project". For example, if I was about to start a 2 or 3 year Powerbuilder development effort, I would hire proven skilled labor without PB experience in a heartbeat over the 5 year person with 1 or 2 years experience. I would make sure to have at least one stud with the skill on the team (the answer man if you will). I'm not sure I stick with that premise anymore with J2EE. I don't think you can come to the table without at least Java, or J2EE, or UML. You have to have some head start. Like I said to Lei, I think a very good J2EE education without much Java slinging is a good enough head start.
Hey, we all need to write custom J2EE software that we can sell to companies for huge $$$$. We only visit the client site to smooze and install our awsome software. We work in our own offices with the folks we want to hang with (over 30 :). We aren't paid hourly, so if it's nice outside we take the afternoon off and head to the golf course.
OK.. back to reality and WebSphere tutorials. jeeze!!!
I agree with you on that if an architect has been certified by Sun and if his job is only doing design, he is better certified.
One thing I noticed is that Microsoft and Oracle always stand by their certifications. If one get their certification such as MCSD, MCSE, Certified Oracle DBA, others know that he is technically prepared and good at what he is doing. You may put logo on your resume. And Microsoft and Oracle declares you are good and may be one of the best in market at their technologies. Certainly not many people argue that those certification useless and you are worse than a guy with no such certifications.
Sun forbids you put Java certification logo on your resume. Sun don't support you by declaring that you are one of the best.
I guess the purpose of certification is to establish a standard that those got certifications be an expert in this technologies. Sun failed to do this. Maybe others should do this. Just like Sun propose specifications for all technologies but others implements specifications. Sun can not do a good job implements anything they proposed (J2EE is one example).
We certainly need a standard to messure everyone's ability in Java programming. If we don't have a standard, everyone can claim he/she is the best in the world in Java technology. How do you know the guy who interviews you technically is technically qualified?
"If we don't have a standard, everyone can claim he/she is the best in the world in Java technology." How do you know the guy who interviews you technically is technically qualified?
Fat figured the previous post.
"If we don't have a standard, everyone can claim he/she is the best in the world in Java technology." Everybody is already doing so, just take a look at this thread. :-)
"How do you know the guy who interviews you technically is technically qualified? "
In my opinion, it is my job to show the interviewer that I am technically qualfied for the job. And I could care less about the interviewer's own technical qualification, as long as he can make sound judgement on my technical qualification.
Of course if the interview is a fool and is the chief architect of the company, then one might have to think about turning down the job.
Lei, since everyone assume he/she is the best of the bests in mastering Java technologies, there are needs in market to establish some standard to measure people's Java skill. Maybe w3c is the place where to establish the standard?
I also have observed something in real life. When a manager or other non technical people look for a job, many people put title "architect" on their resume. This is not kidding! I saw these resumes. So guess what is an architect? architect = manager in real life. I think Sun cooked this title to sell their technologies.
Someone said to invent new titles above senior developer, such as "Principal developer". I know there are "Principal Engineer" and "Principal consultant" and "senior principal consultant". (I am one of them). But "senior principal consultant" is reserved for managers only. So you know in real life only managers have the highest title, maybe architect was designed by Sun as a title for manager or someone who can decide to use Java. I don't remember Microsoft or Oracle have given an official title for people like "architect"? Anyone knows Microsoft has a certificate called architect? or Oracle has a certificate called architect? (although unofficially people like to say data architect, but it is not given offically by Microsoft or Oracle or any other company except Sun).
Ed Roman posted a piece here last fall which agrees with my working definition of an architect:
Some snips cadged from Ed:
"Architects use a deep, low-level knowledge and experience to help make their projects succeed. In recent years, they have been perceived as rare, valuable, and necessary for organizations to succeed."
"So what's the secret of the architects? It's actually quite simple. They gain this knowledge and experience because they are always positioning themselves to learn new things. Many I know seem to be able to set ego aside and work happily in a team without much concern for how they rate on the IQ scale."
Jack Xu writes:
"I also have observed something in real life. When a manager or other non technical people look for a job, many people put title "architect" on their resume. This is not kidding! I saw these resumes. So guess what is an architect? architect = manager in real life."
In my firm sometimes it seems to mean 'assistant manger' or future manager. Or sometimes 'salesman good at *appearing* technical.
The 'architect' Ed mentioned tend to be senior developers.
"I think Sun cooked this title to sell their technologies."
Nah, it's been around for years. Did the Middleware Company coin the term to sell their course 'EJB for Architects'? Nah. I want to attend that course in the worst way. Been begging for it. But it ain't going to happen, not here. So I have to do it the hard way. Them's the breaks.+
Not to beat this "architect" discussion to death, but I will take one more shot at it.
I'm more interested in defining a productive development team environment than in titles. I think to have this discussion, you have to define the context (i.e. a two man development team will not have the same luxuries to divide up areas of responsibilities as a large team). Also, you need to define the scope (i.e. are you including resource planning, requirements definition, production environment). For my following observations and points I will define the development scope to include everything from resource planning through production support and enhancements, and let's say a team with 5+ members.
I start with the premise that building J2EE software is analgous to building a house. It takes several skills to pull it off, and noone is an expert in all of it. For example, you don't want the framers doing the plumbing, or the plumber's laying the foundation (you may have a plumbing helper help with another area, but they won't be the expert). Their needs to be a responsible party for overseeing the construction of the house, but this person is dependent on many specialized skills to pull it off. The art is deciding what level of compentency is required by the one overseeing the construction, and at what points is it best to just rely on the experts.
So with that in mind, I don't buy into the concept of one "architect" for the life of a J2EE project. I do need someone to oversee the entire project skillsets (Called Project Manager from here forward). This person will also be the bridge between the project sponsers (one's paying the bills) and your skilled labor force. I share the belief that almost everyone needs to be "cutting code", but this position would probably be the exception. It's been my experience that the Project Manager's time fills up pretty quickly with resource planning and overseeing the project (meetings, interviews, manager tasks, yada yada yada). I would think you could delegate many of this positions historical responsibilites throughout the team, which may actually allow the Project Manager to also sling code. ??
OK, so again, you have to have lines of authority and responsibility. I have defined where "the buck stops" on my team. It's the Project Manager. The Project Manager should be broadly educated on J2EE and n-tier. What does that mean? Have they had to already been on a successful J2EE effort? Do they need to have slung J2EE code before. I actually don't think so. This person will rely on compentent skills below him, but does have to have the knowledge to steer the ship in the right direction, and know how to audit the process. A skilled Project Manager will monitor the interactions of his team, and make appropriate judgement calls when required. Maybe, even on occasion, s/he may bring in outside consultant help to help make tough decisions.
So how do you divide up the team under the Project Manager. This is an art and not a science. Remember, I'm looking to give team members responsibilty and authority on areas of the project. Nothing like making a team member responsible for an area to motivate the learning curve. :) At a minimum, I see requirement gathering (UML, tools expertise like Rational, ...), development (standards, development enviroment configuration, tool choices, J2EE expertise, testing and integration, ...) and production oversight (production environment configuration and maintenance, monitoring, dba functions, ...) as three distinct skills areas. As a side note, I would think some skills are easier / safer to outsource than others. For example, I would almost always want my production systems to be maintained "in house", but that's another discussion. In my opinion, I think areas of responsibility could be broken down much more than these three. For example, let's create some new titles. Principal of UI, Principal of Rational tools, Principal of client side presentation, Principal of server side presentation, Principal of Business EJB, Principal of Data EJB, ...). You get the idea. Divide the pie, have the team member really be an expert in their area for the rest of the team, and the project benefits. Note: being a Principal in one area doesn't mean that's all you do. On Ryan's 15 man team where everyone does everything still works. You have just divided up responsibilites and learning curves. I don't care what EXPERT "Architect" you find... the learning curve will still be there. It's a frickin moving target. :)
Another important part of the team definition, will be the issue of mentoring. Ryan uses the paired concept for mentoring. That actually seems as good as any. I think with my concept of different Principals, I would have them have team wide meetings when required to share with the team new standards or techniques that will be adopted in there area. If you need a team voting mechanism beyond the Project Manager, like I think Ryan's team has, that would work just fine. Mentoring is a discussion in itself. You need to define base skills and J2EE paths required to participate in your project. For example, if someone shows up at the table without Java and J2EE, it seems almost like to daunting a challenge. Maybe require Java fundamentals OR J2EE fundamentals as a minimum before mentoring. Like I said, another conversation.
One last point. If your current team is not ready to divide responsibilities, nothing wrong with bringing in the "architect" to mentor the entire team. I would view this as temporary, and delegate skillset responsibilities as soon as possible. Let your team members know early which area they are expected to nail down. If possible, let the team members select their areas of responsibilities. If you have a huge project, maybe have teams responsible for certain areas, but select ONE as the point of authority. "By committee" just doesn't seem to work well in this business.
Ok... my rant is over.
You're not too bad, Mike. And we're not actually that far apart.
I think a good team is going to have several principals as you mentioned, and I agree completely about your view of the Project Manager.
What I'm saying is that it's just not enough to specialise in one area. An EJB principal is going to have to know something about the client-side (servlet, JSP, JMS, etc), and the JSP guru needs to know about the container. Not at an expert level but enough to be a team member on the other side at a push.
To take your analogy about building a house a bit further, what I'm saying is that the fellow who designs the plumbing susbsytem better jolly well know something about the electrical system and the balloon frame. This will enable her to avoid cutting the electrics or making it impossible to install them, and will also prevent him from putting in a poured-terrazo floor which the frame isn't strong enough to support!
Of course she also needs to know the container (or Model 1 and Model 2 in the Client layer) cold.
"What I'm saying is that it's just not enough to specialise in one area."
No, you missed my point OR I didn't explain myself good enough. My assignments of "responsibility and authority" does not limit what work you actually perform". I totally agree with your point about knowing MORE than your specialized area. For example, EVERYONE should have very solid J2EE and container knowlege. I'm just talking about splitting up "where the buck stops" for a skillset. As a developer, I would like to be assigned Use Cases, and be responsible for the entire implementation. That's not the same as saying I had to be the geru on all of it. In area's where I may be a little light, I can become skilled by getting guidance from my other team members who are gerus in those areas. There is a finite list of skills needed once the "assembly" line has been defined. The heavy lifting happens in defining the "assembly line and standards" in the first place. Now, with J2EE, you also have to constantly stay tuned... because you are likely to have to refactor that assembly process constantly. Like I said... a moving target. Things use to change at a slower rate. :)
Mike Jones writes:
"Principal of UI, Principal of Rational tools, Principal of client side presentation, Principal of server side presentation, Principal of Business EJB, Principal of Data EJB, "
BTW, you subdivide too much. On an optimal project team size (usually less than 10) you're going to get all chiefs and no indians that way.
An optimal beakdown on a 10 person project might be something like 2 principal generalists who also qualify as senior specialists in an area or two each, 3-5 senior specialists, and 3-5 junior specialists or generalists.
"BTW, you subdivide too much."
Agree to disagree. I like the idea of team members being a chief in some areas, and an indian in others. Rather than force the team buy in with traditional boss vs subordinate, I'm ready to try another way. I've given up on companies respecting their IT staff. At least we should try and devise methods were we respect each other. That's all we are likely to get. That and BIG rates when the economy comes back. :)
"Agree to disagree. I like the idea of team members being a chief in some areas, and an indian in others."
They already are, at least if the senior joes have their heads screwed on right. I've seen many so-called juniors who were excellent and many so-called seniors who couldn't find their tookus even when sober. I have one title within the team for anyone pulling their weight. Colleague.
"Rather than force the team buy in with traditional boss vs subordinate, I'm ready to try another way."
Within the team there should be no boss versus subordinate. There will be leaders (what used to be called lead programmers), but the most delicate and crucial task of any kind of lead is to know when to get the hell out of the way!
Every time I did a lead role I remembered the first rule, which is that the person cutting the code is the supreme expert. That good enough for you?
"I've given up on companies respecting their IT staff."
And this is the problem in a nutshell. We need to encourage developers to continue to develop and expand their skills. Why? Because in my humble opinion (and direct experience) great software is built by small teams composed of members wearing several hats each. People who know a lot about a lot of things, but most of all who know how to build software. Expert specialists who are also specialists. It's a damn hard thing to do, and even harder to keep up. These people need to be rewarded, and the way things work you usually need to pin a title on that. The way of the world I'm afraid.
My point is that an principal/architect is a polymath developer first, mentor second, and perhaps a leader. Not a manager.
Jack Xu: "Someone said to invent new titles above senior developer, such as "Principal developer". I know there are "Principal Engineer" and "Principal consultant" and "senior principal consultant".
At the end of the day, it doesn't matter what fancy titles and certifications you can put on your resume. What matters is whether or not you can deliver the goods. Fancy titles are nothing more than overused Personal Marketing tools. I could spend my whole career with the title of "Developer", and be completely happy about it, because I know what I am capable of. Unfortunately, the non-technical people who typically hold the keys to the front door of your next job like to see fancy titles like 'Certified Senior Enterprise Architectural Principal Solutions Consultant." But if you get by them to the technical interview, you had better know your stuff. Many do not, as Lei Gu pointed out.
"At the end of the day, it doesn't matter what fancy titles and certifications you can put on your resume. What matters is whether or not you can deliver the goods. Fancy titles are nothing more than overused Personal Marketing tools."
Unfortunately it does matter very much, in one important area. If you have a look at Jobserv (the UK equivalent of Monster.com), the salary range for developers is between £25K and about £55K, even for senior developers. Architects start at 45K and go to more than £100K.
To be honest I am looked down upon by the management of my firm for my nasty hands-on habit. I ought to be able to make smooth sales presentations. Making working software is not important.....
"To be honest I am looked down upon by the management of my firm for my nasty hands-on habit. I ought to be able to make smooth sales presentations. Making working software is not important..... "
You are so right. At many companies, the managers encourage this type of behavior. Its always the quality of your B.S. that would get you to the next rung on the ladder. By the way, have you ever been frustrated by the fact that there's no one in your company who even understands let alone appreciate the design decisions that you make? Do you have to continuously fight senior developers or managers who do not get the concept behind three-tier development or who do not know what a "class invariant" is? Yet, they're your boss and you can't do crap about it!! I see so many people who do not even know the ABC of object-oriented programming or any software engineering principles, but they get promoted based on their smooth-talking skills. Maybe I am just too cynical, but, I see this happening all around me all the time.
P.S. I am thinking of getting an MBA soon. Its good to get a decent pay without the fear of becoming obsolete every 3 years.
Adnan Rafiq writes:
"By the way, have you ever been frustrated by the fact that there's no one in your company who even understands let alone appreciate the design decisions that you make?"
I believe that Sweeney Todd and Son of Sam may have had the correct approach in these cases, though Jeffery Daumer went too far in my (cook) book..... ;-)
"Do you have to continuously fight senior developers or managers who do not get the concept behind three-tier development or who do not know what a "class invariant" is?"
No. Either completely ignore their existence or bury them in the swamp out back. BTW, have you swallowed the jargon dictionary? Class invariant, what dat? And why should they care? Personally my preference has been to serialize them, but now that I'm into design patterns I think I'll turn them into a Strategy pattern. Though a Facade may be more appropriate. Certainly not an Adapter.
"Yet, they're your boss and you can't do crap about it!!
"I see so many people who do not even know the ABC of object-oriented programming or any software engineering principles, but they get promoted based on their smooth-talking skills."
Frustrating, ain't it? It's their turn right now. Propeller heads like us are a pretty arrogant bunch, and normally managers cannot properly put us in our place(s) because we're too scarce. So it must be doing their wizened little hearts a world of good to be able to pick and choose and tell us what they really think of us at review time. And promote the Power-Point jockeys of course. Don't worry, tons of psuedo-programmers are leaving the profession in droves to become hermits or something more rewarding. Like working at Pizza Hut. Pretty soon we'll be back to the same chronically undersupplied labor markets and the yahoos will have to shut their mouths again. Until the next recession.
I've seen good techies who have acquired business skills in these spots also. I believe the internet revolution somehow put a premium on the smooth-talkers rather than the smooth-doers. Perhaps because it was so swift and (at times) shifty.
"Frustrating, ain't it? It's their turn right now. Propeller heads like us are a pretty arrogant bunch, and normally managers cannot properly put us in our place(s) because we're too scarce. So it must be doing their wizened little hearts a world of good to be able to pick and choose and tell us what they really think of us at review time. And promote the Power-Point jockeys of course. Don't worry, tons of psuedo-programmers are leaving the profession in droves to become hermits or something more rewarding. Like working at Pizza Hut. Pretty soon we'll be back to the same chronically undersupplied labor markets and the yahoos will have to shut their mouths again. Until the next recession."
That's so good and so accurte I'm tempted to print it and put it on the wall. I can only speak for myself, but I've always been able to produce quality software for users and gain their respect. You would think that would always automatically be the same thing as saying you have pleased your IT management, but it hasn't worked that way. I realize they have a tough job (actually one I don't want), and I understand the need for Power-Point. :) The problem I run into to often is that the decision makers for the client (the one that controls my services provided to the user) is less experience then those they are managing. This isn't their fault. It's the company's fault for setting it up that way. I think there actually is a business opportunity to provide a third party DMZ between the IT management and the worker bees. :) If I was providing the DMZ services, however, I would eat lunch with the worker bees. :)
Note: If you are a "code slinging" manager, ok, we can have lunch. Just resource planning and Power-point... nah. :)
SOME of this is just kidding. It takes all of us to do the job.
"That's so good and so accurte I'm tempted to print it and put it on the wall."
You have my generous and lofty permission, though may I suggest that it be posted in the place where (I at least) do my deepest thinking? That is on the stall door or possibly over the urinal. ;-)
"I can only speak for myself, but I've always been able to produce quality software for users and gain their respect. You would think that would always automatically be the same thing as saying you have pleased your IT management, but it hasn't worked that way."
Nope, this is my experience also.
"I realize they have a tough job (actually one I don't want), and I understand the need for Power-Point. :)"
Yes. But not to the point of disregarding the boys and girls who make the rubber meet the road, which is what is happening now.
"The problem I run into to often is that the decision makers for the client (the one that controls my services provided to the user) is less experience then those they are managing. This isn't their fault. It's the company's fault for setting it up that way. I think there actually is a business opportunity to provide a third party DMZ between the IT management and the worker bees. :)"
There is, believe it or not. It's called 'architect'!
"If I was providing the DMZ services, however, I would eat lunch with the worker bees."
I don't eat lunch with the 'worker bees'. I AM a worker bee! There is a difference....
BTW, while I am formally rated as the least kind of 'manager' in my firm, I am not a manager of any kind. I've led programming teams of as many as 8 people as a code-cutter but that is it. I get systems written and going. I don't do reviews, though I might contribute to them.
Don Stadler writes" Nah, it's been around for years. Did the Middleware Company coin the term to sell their course 'EJB for Architects'?"
Firstly, As I know middleware company have "architect" after Sun proposed it. Who was the original creator of this term?
Secondly, who has official certification called "architect"?
thirdly, Middleware Company propose 'EJB for Architects' because 'architect" title is in market for awhile. Do you know who has architect certification before sun has?
I believe Sun was the original creator of "architect". Unless someone found evidence that some other major company has official "architect" certification before sun, I still think so.
I would add these points to show, whether you are a
HARDCORE Java programmer or not:
- You know that JAVA is not only a coffee brand in USA
but also one of the most populated island in
Indonesia (Occupied 80% of the total 250 Mio. people).
- You can speak the "real" JAVA language and
not only the artificial one. And of course you
can play GAMELAN as good as speaking the language.
- You have been in JAKARTA before and survived
one week living over there. And also you have
helped poor people at the Java island, especially
in Jakarta with your BIG salary as the JavaPro salary
survey showed us.
I wonder now, how many real Java HARDCODE are out there... ;-)
To statisfy you thurst for knowledge do you build code demos in your own time?
Do you constanly read technology books/articles to keep up on things?
Are you an active member of several technology groups/message boards?
Do you write white papers on the things you do?
Do you get an great sense of achievement when something you build works?
Have you been writing code since you were 8?
Do you think that certifications are fun ways to test your knoweledge and who cares what people think of them?
Does you girlfriend think its weird that you have a complete wireless network in your house and a computer in nearly every room?
If you answer yes to all these I would call you hard core.
Sure, and you think that it is the people answering yes to all those questions that make the big bucks? Sounds more like the wacky linux administrator at my university...
uhm, which girlfriend?
To statisfy you thurst for knowledge do you build code demos in your own time? <
>> Do you constanly read technology books/articles to keep up on things? <
Yes. Amazon.com has given up on recommending *new* J2EE/Java books to me because I already own them.
>>Are you an active member of several technology groups/message boards? <
>> Do you write white papers on the things you do? <
>> Do you get an great sense of achievement when something you build works? <
>> Have you been writing code since you were 8? <
Nope. I started at 19 and am 43 now.
>> Do you think that certifications are fun ways to test your knoweledge and who cares what people think of them? <
Maybe. My personal opinion is that the programmer cert is a syntax-checker, the developer cert might be worth doing, and the architect cert could help me round out some areas I need.
>> Does you girlfriend think its weird that you have a complete wireless network in your house and a computer in nearly every room? <
I don't have this.
>> If you answer yes to all these I would call you hard core. <
I guess I fail then. ;-)
Jason Boutwell writes:
"Anyone who would look at a Java certification as a negative is not the type of individual that I would want to work for, or have work for me. They obviously have high opinions of themselves. Being humble works wonders in the workplace."
I don't regard a Java Certification as a negative. I I had to vett a pile of resumes for a junior programmer I would look for two things. The top thing would be someone who had done hard Java development, in an industrial or academic setting (in that order). If the resume tells me that the person has cut code that weighs the most with me. If I see an inexperienced person who has a Java developer cert I'd certainly jump them to the top of the list.
Failing obvious experience or a developer cert I'd pick out the people with a Java Programmer cert on the grounds that it shows effort and some knowledge.
The point that Dion and I were making is that beyond a certain point the Java Programmer certification doesn't say very much about you. That degree of knowledge is assumed, and the fact that you passed an exam means you were able to talk your employer into writing a check.
"I don't understand comments like 'Java spellers'. You don't just wake up one morning and BOOM, you are an expert on J2EE. Everyone has to start somewhere."
True enough. You download free tools from the Sun website and learn how to write Java programs. You show (in an interview) that you know what a classpath is and how to access a jar file by setting a classpath. Maybe you show that you've figured out what to do when you're trying to use a tool incompatible with the version of your SDK currently installed. That you know what a servlet is and the basics of building one.....
All this knowledge is available free or nearly so for the downloading. Perhaps a book or two. To be honest, the 'Java spellers' I referred to often haven't bothered. They took advantage of a very little knowledge and the hot employment market in 1999 and 2000 to land high paying jobs. But unless they took that opportunity to build their skill base they are not terribly useful in a programming team. No matter what their salary and title was.
QED. If you know something useful and can be assigned a task and do it with minimum help you aren't a 'speller' If all you can do is spout a little jargon I suggest a skills upgrade quickest.
Lei Gu: "But your post illustrates the exact one thing that prevents us (star developers)..."
LOL. "Us star developers". Hehe. Humility must definitely NOT be a requirement for a true J2EE architect. :-)
Yann Caroff: "But most of them show a very strong will to learn and are eager to apply these concepts to reality, which are basic requirements to become true architects. "
Amen. For job candidates with similar experience and qualifications, a certification tells me that this person gave enough of a damn to go through the process. The developer and architect certs are NOT trivial. Sure, you aren't designing and developing an industrial strength, distributed banking/brokerage application. But that's not the point. It's the desire to learn and improve. It's says that this applicant chose to burn the midnight oil, on his/her own time, either to better themselves as a programmer/developer/architect, or to just confirm/brush up on what they already know.
Don Stadler: "The point that Dion and I were making is that beyond a certain point the Java Programmer certification doesn't say very much about you."
Everyone seems to agree on one thing. Anyone relying on certifications ALONE will have trouble getting a job.
Don Stadler: "the fact that you passed an exam means you were able to talk your employer into writing a check. "
In this economy, that achievement should receive a certification as well. Certified smooth-talker. ;-)
Jason Boutwell wrote:
"Don Stadler: "the fact that you passed an exam means you were able to talk your employer into writing a check. "
In this economy, that achievement should receive a certification as well. Certified smooth-talker. ;-)"
There is a title for this. How about "Certified Solutions Architect"? ;-)
Don Stadler: "There is a title for this. How about "Certified Solutions Architect"? ;-) "
I'll immediately add this one to my list of buzzword job titles to never put on my resume. ;-)
What aout just plain Certified? ;-)
Which java technologies do you hard core java gurus think will be hot in the next years?
What is going to be hot? On a guess I'd say JMS/Message EJB, JCA, SOAP, XSLT. Plus the usual J2EE suspects like JSP/Servlets and EJB's generally. Knowledge of how to set up App servers for best peerformance will be good as well.
From the article:
" Our average Java programmer this year is a 36-year-old man (compared to 33 years old last year) with at least a bachelor's degree. He's been a professional programmer for nine years and a Java programmer for two and a half. (Californians have been programming in Java longer than any other demographic group, except for people with Sun certifications.) Our typical programmer has been with his current employer for 3–4 years. "
It's funny that the average programmer in the survey has *9* years experience. I think most people out there who would be interested in the survey don't have that many years on their resume.
It's also funny that the average programmer in the survey has held his/her current job for *3-4* years. The salary of someone who has had a job that long is probably still fixed at .com levels (sky high.) What about people who got laid off a year ago? How much are they making in their new jobs? I think that's what the people in this thread would really like to find out.
I talk to recruiters all the time and the best way to find out how much you can expect to make in your *next* job is to ask those guys. Of course, if you can find a job without a recruiter you may make a little more, but you could argue about that, too.
My gut feeling is that overall, salaries are going to stabilize down to about %20 less than their peak in recent years.
"$117/hr in the Northeast ??"
Yeah, that's about the lowest I've seen for an intermediate Java programmer, though that's billrate, not take-home. Senior devs or architects are near or over $200 .. I've seen up to $300/hr.
I'm 20 years old and live in Sweden for the moment where I work in a project as a Java Developer (Servlets, JSP, SQL, some EJB and some Lejos - Java for Lego Robotics). Right now I'm thinking of either taking Computer Science (3 years or maybe 4 years for a Master) and I do not know wheter I should take it here in my hometown or if I should go to Stockholm KTH (Royal Institute of Technology). Does it matter a lot where you graduate, and does it matter much wheter you graduate at all?
What do you think?
Regarding the definition above as a "Hard Core Guy" I'm one of them. :-)
Thankful for comments and tips...
"I'm 20 years old and live in Sweden for the moment where I work in a project as a Java Developer (Servlets, JSP, SQL, some EJB and some Lejos - Java for Lego Robotics)."
Interesting. How did you get into that?
"Right now I'm thinking of either taking Computer Science (3 years or maybe 4 years for a Master) and I do not know wheter I should take it here in my hometown or if I should go to Stockholm KTH (Royal Institute of Technology). Does it matter a lot where you graduate, and does it matter much wheter you graduate at all?"
There are two considerations I believe. You already have a good job on which you can learn and it is important you do not lose that. In the long run it is important that you get a baccalaureate or Bachelors degree as a minimum. Whether to go with the masters is more of a judgement call and it largely depends on where you intend to make your career. In Sweden or Continental Europe the Masters will open opportunities. In the US the degree itself doesn't matter much, but the opportunity to work on a bleeding-edge research project can be important.
So if it is possible I would look for one of two things: Either find a part-time program which you can pursue while keeping your day job, or negociate with your employer to remain part time working with them so you can attend school full time. Another possible path is to attend a top-notch research university which will use undergrads as staff on research projects or doing programming for the university.
I would also consider going for a program other than computer science if I were you. Most college-level programming classes are going to strike you as very basic. Even the advanced comp sci courses are going to teach you things like operating system scheduling algorithms, something called Z (don't ask), and provably correct programs. You would probably be happier taking another major and 'cherry-picking' comp-sci classes you are interested in. Most of the things useful in industry may be better learned out of books or from internet downloads.
In assessing graduate programs in the US there are only two criteria I would use: Research projects and networking. I would select research projects I wanted to work on and contact them directly to learn whether they would want me to join. Then I would apply to the associated universities. I would also assess whether the school and research program had an 'old-boy' network which could help me (perhaps placing a lot of people into high positions in Sun or IBM for example).
The problem is, the jobs and they pay well, but there are so few.
This survey has to be wrong .. or the number of people surveyed seems to be very less or selective ..
Although i have seen people on java getting jobs eaiser than others, i havent seen such high salaries .. salaries have gone down sooo much throught the world .. what do u say finland team? :)