Javalobby: What traits do top notch Java/J2EE developers have?

Discussions

News: Javalobby: What traits do top notch Java/J2EE developers have?

  1. Javalobby has promoted "What traits do top notch Java/J2EE developers have?" to their main page. While it's geared to drive traffic towards an education/marketing site (offering books on J2EE Q&As), the question is worth asking: what makes J2EE developers "good" J2EE developers? The traits offered on Javalobby:
    • Passion to learn and build quality Java/J2EE Systems. without passion one can not achieve anything.
    • Ability to think not only from the technical perspective but also from the business perspective.
    • Ability to analyse "What if" scenarios like what if I want to support new products in the future? What if I want to support web clients? etc.
    • Ability to look at the big picture (like design concepts, transactional issues, concurrency issues, performance, memory etc) and drill down to details when required to do so.
    • Right attitude. Avoid "I know it all" attitude. I have come across some talented Java/J2EE practitioners who hardly listen and believe that they know it all would not like to be corrected.
    • Good interpersonal and communication skills.
    • Eagerness to learn and keep up with the emerging technologies and frameworks like Spring, Ajax, JSF, Hibernate etc.
    It's an interesting list. Part of what's interesting is that only one of the qualifications is technical in nature ("eagerness to learn and keep up with emerging technologies and frameworks") and the rest are relationship skills. Also interesting is the focus on J2EE solutions - which seems contradictory in an "enterprise" technology. Shouldn't a "top notch" enterprise developer be willing to use the appropriate technology for the task at hand, rather than limiting oneself to a Java solution?

    Threaded Messages (75)

  2. A top notch J2EE developer should above all be clean, and handsome. But clean is most important. Customers has a right to expect good personal hygiene from a enterprise developer.
  3. A top notch J2EE developer should above all be clean, and handsome.

    But clean is most important. Customers has a right to expect good personal hygiene from a enterprise developer.
    Say tall with acne free skin and neat, clean cut hair instead of handsome. Handsome is too subjective. How do you test it? It's a bad requirement.
  4. A top notch J2EE developer should above all be clean, and handsome.

    But clean is most important. Customers has a right to expect good personal hygiene from a enterprise developer.


    Say tall with acne free skin and neat, clean cut hair instead of handsome. Handsome is too subjective. How do you test it? It's a bad requirement.
    Erik Engbrecht and John Brand, good hygiene and professional appearance is good for all professionals, not just J2EE...i am not in agreement with acne free, and handsome..this isn't American idol guys..
  5. i am not in agreement with acne free, and handsome..this isn't American idol guys..
    I wish it was american idol. Software architecture is of course incredibly glamorous, but still not quite like the music industry.
  6. Doesn't use any version of EJB Doesn't use the cut & paste patterns (J2EE core patterns) Doesn't use JAAS Doesn't use JSP Doesn't use Struts Doesn't use the WS-* and SOAP stack of technologies Doesn't use XML configuration files Understands SOA is not a new thing (big companies have to sell new products, now that EJB servers are a dying breed) Understands the value of REST
  7. Understands SOA is not a new thing (big companies have to sell new products
    Old products. With new (slow) clothes. Guido
  8. Doesn't use any version of
    ...
    Understands the value of REST
    What is the rest of J2EE beyond this list? Oh, I get it now. The top notch Java/J2EE developer uses RoR or PHP, right?
  9. Doesn't use any version of

    ...

    Understands the value of REST


    What is the rest of J2EE beyond this list? Oh, I get it now. The top notch Java/J2EE developer uses RoR or PHP, right?
    Spring + Hibernate = new javaEE sudhir jYog!
  10. Spring + Hibernate = new javaEE
    Just hype. In 2 years Spring and Hibernate will be what Struts-1 and JDO are today: yesterday's fad.
  11. Spring + Hibernate = new javaEE

    Just hype. In 2 years Spring and Hibernate will be what Struts-1 and JDO are today: yesterday's fad.
    Boring. Can you sing any other tunes?
  12. What about Queens: "Who wants to live forever"... William.
  13. Obviously, you missed a lot of J2EE stuffs: Spring JMS REST Xfire AOP and lot of more ... Top notch J2EE folks should be able to use ordinary (not so-called j2ee) technology to archieve secure, quality and performance for need of any enterprise. Nice looking and handsome are plus :-)!hahaha!
  14. Doesn't use any version of EJB
    Doesn't use the cut & paste patterns (J2EE core patterns)
    Doesn't use JAAS
    Doesn't use JSP
    Doesn't use Struts
    Doesn't use the WS-* and SOAP stack of technologies
    Doesn't use XML configuration files
    Understands SOA is not a new thing (big companies have to sell new products, now that EJB servers are a dying breed)
    Understands the value of REST
    Whaaaaah. Now I'm not a top notch J2EE developer. Or, maybe a top-notch developer wouldn't type up a one-size-fits-all list like this?
  15. Or, maybe a top-notch developer wouldn't type up a one-size-fits-all list like this?
    We have a winner!
  16. Doesn't use any version of EJB
    Doesn't use the cut & paste patterns (J2EE core patterns)
    Doesn't use JAAS
    Doesn't use JSP
    Doesn't use Struts
    Doesn't use the WS-* and SOAP stack of technologies
    Doesn't use XML configuration files
    Understands SOA is not a new thing (big companies have to sell new products, now that EJB servers are a dying breed)
    Understands the value of REST
    Doesn't use JSF
  17. Doesn't use any version of EJB
    Doesn't use the cut & paste patterns (J2EE core patterns)
    Doesn't use JAAS
    Doesn't use JSP
    Doesn't use Struts
    Doesn't use the WS-* and SOAP stack of technologies
    Doesn't use XML configuration files
    Understands SOA is not a new thing (big companies have to sell new products, now that EJB servers are a dying breed)
    Understands the value of REST
    Really?
    I have always thought that there is no silver bullet for anything. Isn't it about the skill to take the right tool for a situation instead of insisting that one single tool is ansver to everything.
    Btw AJAX is also in feature stack of these big companies selling their good old servers with some new toppings. Meybe we should stay away from that too.
  18. understand modeling & the stack[ Go to top ]

    First and foremost, a top level developer (J2EE or not) understands domain modeling and object-oriented design. To then be such a J2EE developer you have to understand the stack. Of course the stack has changed over the years. JSP Session EJB Entity EJB Database Has become... AJAX JSF/Tapestry/Wicket Domain model Hibernate/iBatis/Toplink Database
  19. One that does not insist on still calling it "J2EE" over a year after the next rev came out. A next rev, BTW, which connotes a lot of different things right off the bat (and ends half of the discussion about what "not" to use and so on).
  20. Left handers[ Go to top ]

    I've noticed quite a lot of J2EE developers are left handed. Is this a mere coincidence?
  21. Re: Left handers[ Go to top ]

    Left handed and proud of it! :-)
  22. Resistance to Groupthink[ Go to top ]

    The judgement and confidence to avoid using crap like EJB2, JSP, JSF, etc. just because a bunch of companies or a self-proclaimed "expert group" declares them as "standards." Understanding that given how complicated creating software is, and appreciating how limited human intelligence is, that choosing the right tools, libraries and frameworks to build on top of is essential to succeeding. Taking responsibility for technical problems as technical problems instead of blaming the pointy-haired boss and reciting stupid slogans like "it's always a people problem," which is only true in as far as some people have inadequate technical skills.
  23. John, Erik and Bruce. Yours are among the best post I have ever seen on TSS. Blessed you are. Guido
  24. J2EE is a stack...[ Go to top ]

    ...providing many services. The good J2EE developer knows HOW to use these services to deliver an efficient and scalable solution to a business problem. A bad J2EE developer generalises problems, misuses configuration, makes bad design choices and blames the stack. EJB (any version of it) is not bad. It has it's uses and it's limitations. As a data service, it makes little sense. The same patterns and best-practices slammed else-where in these comments have long since identified both and advised correct usage patterns. A bad J2EE developer ignores such advice coming from experience and instead insists on re-inventing the square wheel and arguing that the square wheel is far far better than the round wheel. Above all, a good J2EE developer recognises that the J2EE stack comprises of components that have, and continue to, evolve with community input. A good J2EE developer therefore joins the community process and contributes his/her experience towards making the J2EE stack better.
  25. Re: J2EE is a stack...[ Go to top ]

    The good J2EE developer knows HOW to use these services to deliver an efficient and scalable solution to a business problem.
    A good developer also can tell when a solution doesn't need to be particularly efficient and will most likely never have to scale. Oh...and a I think a good developer is unlikely to tag himself with an acronym particular technology. He doesn't confuse a tool for a profession.
  26. Re: J2EE is a stack...[ Go to top ]

    I like that one. No profession tagging. Is a Microsoft developer better that a Java developer? .NET application architecture against J2EE? Would all require the same things? Would it be harder to work on either one? What about RoR developers, or Perl/PHP/Python ones? William
  27. Re: J2EE is a stack...[ Go to top ]

    I like that one. No profession tagging.
    Is a Microsoft developer better that a Java developer?
    .NET application architecture against J2EE?
    Would all require the same things? Would it be harder to work on either one? What about RoR developers, or Perl/PHP/Python ones?

    William
    A good developer recognizes that those are all tools, and is capable of identifying and learning how to use the best tool for the job. That's not to say that expertise in a particular tool cannot be important. It can be extremely important. But it shouldn't be part of one's identity.
  28. Re: J2EE is a stack...[ Go to top ]

    A good developer recognizes that those are all tools, and is capable of identifying and learning how to use the best tool for the job.

    That's not to say that expertise in a particular tool cannot be important. It can be extremely important. But it shouldn't be part of one's identity.
    Good!. Now we have to convince bosses about it...
  29. Re: J2EE is a stack...[ Go to top ]

    A good developer recognizes that those are all tools, and is capable of identifying and learning how to use the best tool for the job.

    That's not to say that expertise in a particular tool cannot be important. It can be extremely important. But it shouldn't be part of one's identity.


    Good!.
    Now we have to convince bosses about it...
    Unfortuneately I can't extend my intellectual bubble beyond a few technical discussion boards without it bursting. Extending it to the real world would be impossible.
  30. Re: J2EE is a stack...[ Go to top ]

    +1
  31. Re: J2EE is a stack...[ Go to top ]

    +1 Every Enterprise computing system is about three things: Database. Transport. (Middleware/AppServers/WFengines) Presentation. (HTML/Swing/client apps) Transport/middleware and presentation techs/tools change every few years. Despite the best efforts of OODB vendors, databases are still relational, and still use SQL. I've found that comprehension of SQL is a major "wheat from the chaff" test for any dev worth their salt. If you can't understand multiple joins, inner joins, outer joins, subqueries, data integrity, primary/foreign keys, and indexing, then you don't understand the fundamental basis of all enterprise apps: data. Databases are also the only thing likely to be reused when a system is reimplemented. BTW, when did we start calling the Database tier the "Domain"? This sounds like stupid arbitrary academic obfuscation.
  32. Re: J2EE is a stack...[ Go to top ]

    when did we start calling the Database tier the "Domain"? This sounds like stupid arbitrary academic obfuscation.
    Carl Mueller, Well i remember when i started calling the "database tier", the "domain tier" is not just about databases..but any repository or external system, I was on a project that required read/write/transaction to a device(not a database a piece of hardware)... presentation tier business tier EIS tier(has access to database and devices in this tier..) I actually wrote DAOs for the device with CRUD methods, etc.. - my two cents.
  33. Microsoft/Java[ Go to top ]


    Is a Microsoft developer better that a Java developer?
    Everybody knows it's the other way round. ;-)
  34. Re: Microsoft/Java[ Go to top ]


    Is a Microsoft developer better that a Java developer?


    Everybody knows it's the other way round.

    ;-)
    I am doing both, so I must be super good then. If you are good at Java, you should be good at Microsoft as well. Technology is just a tool or media to carry out your programming idea. The different is the syntax, it is not creativity.
  35. Re: Microsoft/Java[ Go to top ]


    Is a Microsoft developer better that a Java developer?


    Everybody knows it's the other way round.

    ;-)


    I am doing both, so I must be super good then. If you are good at Java, you should be good at Microsoft as well. Technology is just a tool or media to carry out your programming idea. The different is the syntax, it is not creativity.
    Oh, "Microsoft developer" covers quite a large area. VB.NET isnt quite the same as good old (said with a very sarcastic tone) COM+ or a device driver.
  36. Re: J2EE is a stack...[ Go to top ]

    The good J2EE developer knows HOW to use these services to deliver an efficient and scalable solution to a business problem.


    A good developer also can tell when a solution doesn't need to be particularly efficient and will most likely never have to scale.

    Oh...and a I think a good developer is unlikely to tag himself with an acronym particular technology. He doesn't confuse a tool for a profession.
    The comment was specific to J2EE and in response to comments elsewhere under this title bashing J2EE for various reasons. The point is of course that J2EE isn't good or bad. It is a stack. You'd consider J2EE if your problem needs services already provided by J2EE - this is implicit. You would certainly not require J2EE to write a Hello World program.
  37. Re: J2EE is a stack...[ Go to top ]

    A good developer also can tell when a solution doesn't need to be particularly efficient and will most likely never have to scale.
    Really? And when does a solution not need to be particularly efficient? I can't think of any production code that is allowed to be inefficient by design. Scalability is something dictated by the requirements of a solution. Efficiency is not. Not for a good developer.
  38. Re: J2EE is a stack...[ Go to top ]

    A good developer also can tell when a solution doesn't need to be particularly efficient and will most likely never have to scale.


    Really? And when does a solution not need to be particularly efficient? I can't think of any production code that is allowed to be inefficient by design.

    Scalability is something dictated by the requirements of a solution.

    Efficiency is not. Not for a good developer.
    Premature optimization is the root of all evil, and many developers (myself especially) like to do optimization. I'm not saying it's ok for code to be stupidly written and a developer should use an O(n^2) algorithm when there is a perfectly obvious O(n log n) one or read half a database into memory prior to processing when only a small subset is needed. I'm talking about resisting the temptation to do premature optimization. I probably should have stated it that way.
  39. Re: J2EE is a stack...[ Go to top ]

    A good developer also can tell when a solution doesn't need to be particularly efficient and will most likely never have to scale.


    Really? And when does a solution not need to be particularly efficient? I can't think of any production code that is allowed to be inefficient by design.

    Scalability is something dictated by the requirements of a solution.

    Efficiency is not. Not for a good developer.


    Premature optimization is the root of all evil, and many developers (myself especially) like to do optimization.

    I'm not saying it's ok for code to be stupidly written and a developer should use an O(n^2) algorithm when there is a perfectly obvious O(n log n) one or read half a database into memory prior to processing when only a small subset is needed.

    I'm talking about resisting the temptation to do premature optimization. I probably should have stated it that way.
    Optimization is different from efficiency. A good developer knows that to provide a good solution he/she must: 1. first do the right thing (effectiveness) 2. do the thing right (efficiency) Optimization may then be applied depending on run-time requirements. So your contention that "premature optimization is the root of all evil" is highly debatable if your intention is to say that (1) & (2) mentioned above are not important at development time. If you meant runtime optimization then I agree - but that is orthogonal to efficiency. A good developer absolutely MUST ensure (1) & (2) up-front.
  40. Re: J2EE is a stack...[ Go to top ]

    Oh...and a I think a good developer is unlikely to tag himself with an acronym particular technology. He doesn't confuse a tool for a profession.
    Quite like an automotive engineer doesn't have to tag him/her self with the "automative" tag, eh? I mean whoever said an automotive engineer can not design an aircraft?
  41. Re: J2EE is a stack...[ Go to top ]

    Oh...and a I think a good developer is unlikely to tag himself with an acronym particular technology. He doesn't confuse a tool for a profession.


    Quite like an automotive engineer doesn't have to tag him/her self with the "automative" tag, eh? I mean whoever said an automotive engineer can not design an aircraft?
    Automobiles are an industry. Java is a technology within an industry. But calling oneself an automotive engineer is probably just as bad, because it says nothing about the engineer's discipline. Incidentally, many skills used in automotive design are very portable to aircraft design. The same thing with telecommunications if you are talking about the electical and software pieces.
  42. Re: J2EE is a stack...[ Go to top ]

    Oh...and a I think a good developer is unlikely to tag himself with an acronym particular technology. He doesn't confuse a tool for a profession.


    Quite like an automotive engineer doesn't have to tag him/her self with the "automative" tag, eh? I mean whoever said an automotive engineer can not design an aircraft?


    Automobiles are an industry. Java is a technology within an industry. But calling oneself an automotive engineer is probably just as bad, because it says nothing about the engineer's discipline.

    Incidentally, many skills used in automotive design are very portable to aircraft design. The same thing with telecommunications if you are talking about the electical and software pieces.
    Simillarly, Automobile engineering is a specialization within the broad transport industry. Specifically an automobile engineer specializes in engineering road going vehicles. In that it DOES say EVERYTHING about the engineers discipline. While core concepts - e.g. the concept of an IC engine - apply to all vehicles that use IC engines, there are a million (if not more) specializations that differ between road, air and sea transport vehicle design, production and maintenance. Your contention is simply hot air. Tagging WRT to specialization is always required. A J2EE architect/developer SPECIALIZES in the J2EE platform. A generic developer will be of little use without learning the specifics of the J2EE vertical. I mean, you may be saving a lot of money on healthcare by going to your GP and trusting him to perform brain surgery on you - but you will probably not be saving your life. Specialization DOES require tagging. Each development language within the software industry has spawned a vertical - exactly like automobiles is a vertical of transportation. You can not be a GP and perform brain-surgery. Although every brain-surgeon is also a GP, a brain-surgeon SPECIALIZES and develops skills FAR BEYOND what those of a GP. A brain-surgeon BUILDS UPON the base knowledge and skill-set of a GP and delivers highly SPECIALIZED services within a SPECIFIC AREA. Tagging a brain-surgeon as a brain surgeon is ABSOLUTELY IMPORTANT in differentiating such skills from the BASIC skills of a GP.
  43. Good Observation....[ Go to top ]

    A lot of time complex systems are justified saying .. they can be made scalable. In my opinion one certainly needs to identify which components of the system really need to be scalable or resuable
  44. A top notch J2EE developer should know he is now a top notch Java EE developer.
  45. An acutal example of development of libraries that have been used by others. This library must have some form of inheritance. While others may scoff at my request, I have been dealing with this sort of issue in my 10 years of Java consulting.
  46. http://en.wikipedia.org/wiki/Linda_Richman
  47. Passion to learn and build quality Java/J2EE Systems. without passion one can not achieve anything.
    I am totally agree wid, One need to have passion to learn new things, and ofcourse to implement it in real life, Java is a community where every morning sun rises with some new frameworks, and ideas, Ability to analyse is also very important thing, Java community is full of frameworks and specifications, one need to have ability to identify what is suitable for what. choosing right technology and implementation is the first step toward successful j2ee application. Sudhir Nimavat jYog
  48. Here is a famous quote from a famous architect "good developer is one who knows how to apply design patters. A best developer is one who knows when to and where to apply design patterns" In current context, it means a gud developer is one who has all the things mentioned above, but a best developer is one who implements this in real life. Sudhir Nimavat jYog
  49. A top notch Java/J2EE developer is a top notch developer who also understands how to use Java/J2EE. You first have to understand and excel at your profession. Without that your knowledge of any particular toolbox has little value.
  50. I posted my a-hole reply now here is my more reasoned one. This is mostly off the top of my head and probably just translates into the kind of people I like working with. Definitely not a comprehensive list. I'd skip the J2EE prefix and say what a good developer needs: 1) Courage to stand up and make his/her ideas heard, even when they are in the minority. Of course they must have the humility to know and admit when they are wrong, but that takes courage too. 2) Good communication skills: oral and written. Must like to argue but also be willing to listen to the other side. 3) Breadth of knowledge - Must have a lot of experience with a lot of different technologies. UNIX, Windows, networking, databases, messaging, services, protocols, etc. 4) Depth of knowledge - Must have some deep knowledge in several areas, obviously nobody can be an expert at everything. 5) Have some failures under their belt. Good developers are forged in the fire of past screw-ups. Nothing teaches better practices than getting burnt when you are young. 6) It factor - You need to have "it". Maybe this translates to passion but at the same time passion alone isn't enough. If you have it you know - you learn fast, you can absorb a lot of data and cut through the hype and baloney, you can memorize the important parts of an API and quickly Google the knowledge you need, you can transfer your skills to new technologies. I've known some people who were dedicated but just weren't able to be good programmers. They all eventually found happiness in related IT fields (project management, business analysts, etc). 7) Confidence - I think this is slightly different than courage. Confidence comes from knowing your field and knowing your limitations. A good developer knows when he/she needs help or needs to request time to research. 8) Must love code - I'm not sure how put this exactly but a good developer must like looking at and understanding code. The coders I know and respect live and breathe code. They communicate better with code and only resort to boxes and lines when a higher than API-viewpoint is needed. The coders I respect participate in forums, write blogs, have a heavy bookshelf, and always have something interesting to talk about regarding frameworks, technologies, etc. 9) Knows that there are 100s of coders that are, and always will be, way better than they are and is fine with that. Maybe even takes comfort in knowing that there will always be more to learn. 10) A sense of humor doesn't hurt. Our industry is insane with more charlatans and hacks than probably any other (except maybe the entertainment industry). If you can't sit back and laugh at the crazy stuff even when you are neck deep in it then you'll soon become a jaded non-developer. 11) Seeks out gigs where they'll be working with better developers. If you are always the "guru" where you work then you probably are part of the problem.
  51. Pattern people like to talk about Alexander. But more than 4000 years, a Chinese Butcher talked about Domain Driven Design and Divide and Conquer. The story is, A Chinese butcher used a knife to separate cows into pieces of beef. He used his knife for more than 20 years but it looks like new. Other butchers had to change knife every year. So the king asked the butcher why he can keep his knife new for more than 20 years. The butcher said, in my eye, the cow was not in whole piece, I saw it in small parts assembled together so I looked for the gap between tissues that I never chopped. The other butcher had to change knife every year because they chopped too often. This butcher was awarded The Best Butcher in Year -2002 by Chinese Butcher's Association. In my consulting experience in companies in China, Singapore, US and Australia, I have seen too many domain concepts were a whole piece or chopped apart instead of being separated according to its natural boundary. And the resulting systems are very fragile and difficult to change. I learned from this Chinese butcher to understand the domain correctly and design based on natural boundary, not by other forces.
  52. along the same line of thought[ Go to top ]

    I used to know a musician who said, "everything I know about playing guitar, I learned from a 1 legged toad." I personally don't get the point of some stupid checklist of what a "good developer" should know. It isn't what you "know". It's what you can do. peter lin
  53. I quite enjoyed this post (about the butcher). Thanks.
  54. Pattern people like to talk about Alexander. But more than 4000 years, a Chinese Butcher talked about Domain Driven Design and Divide and Conquer. The story is,

    A Chinese butcher used a knife to separate cows into pieces of beef. He used his knife for more than 20 years but it looks like new. Other butchers had to change knife every year. So the king asked the butcher why he can keep his knife new for more than 20 years.

    The butcher said, in my eye, the cow was not in whole piece, I saw it in small parts assembled together so I looked for the gap between tissues that I never chopped. The other butcher had to change knife every year because they chopped too often.

    This butcher was awarded The Best Butcher in Year -2002 by Chinese Butcher's Association.

    In my consulting experience in companies in China, Singapore, US and Australia, I have seen too many domain concepts were a whole piece or chopped apart instead of being separated according to its natural boundary. And the resulting systems are very fragile and difficult to change.

    I learned from this Chinese butcher to understand the domain correctly and design based on natural boundary, not by other forces.
    This is very interesting and new information and knowledge, because here in the west we all learn to design based on un-natural boundaries AND forces. This keeps our knife industry very happy, but leads to much sorrow in all other areas of our life. Thank you for sharing this inportant information from the east.
  55. This keeps our knife industry very happy, but leads to much sorrow in all other areas of our life.
    I am glad that so many people liked my story, but I have difficulty understanding the above. What I learned from the story is to partition the system into high cohesive, low coupling subsystems or modules or concepts according to its logical boundary. But too often, we see the opposite. Goodliffe did interesting definition of several kinds of programmers in his book, Code Craft, it is worth reading.
  56. Beer....?[ Go to top ]

    Drinks beer - no?
  57. Fine, you want to keep banging letters on your keyboards, go ahead do that. Cut and paste DAO's, DAO factories, biz delegates, upteen facades, Value Objects, DTO's, helpers and utils everywhere. Strewn presentation logic in all the exciting xml config files, taglibs, etc. This sort of programming has nothing to do with Problem Solving skills, OOP, or DDD, but sure looks very COBOL like. I have seen some Javascript code that looked way better that most of the J2EE code out there. And if it makes you happy to call yourself a top notch Java developer with those skills, then all power to you.
  58. a good jee developer just know when to kick ass while the bad ones always kiss ass
  59. I think the most important thing a good developer must have is skeptcism. There are lots of "me-too" developers around, that would jump off a bridge at the first glimpse of "the latest and the greatest". A good developer in my opinion would stop, analyze and then decide if it's worth or not to use whatever thing. He also knows that "frameworks, languages and platforms" aren't pure ideas without any contact with reality, and reality matters and sometimes the theoretically "perfect" (i.e., perfectly hyped) solution is not even good enough. Spring xiites are a perfect example of cult-following-brain-damaged developers who wouldn't recognize a good solution even if it was thrown at their faces. They only check if the solution is "acronym-compliant", with the letter soup they came to adore. Another example, another type of "I am better than you"-developer is the one that will argue that some unknown or lesser used technology is better just because... only 6 guys (he included) know it! That's like those teenagers that worship some obscure garage band from some rural area of Bangladesh, just because that looks "refined". You know, what kind of people like the most popular ones? "We are cool, because we like what nobody else does".
  60. I think the most important thing a good developer must have is skeptcism. There are lots of "me-too" developers around, that would jump off a bridge at the first glimpse of "the latest and the greatest". A good developer in my opinion would stop, analyze and then decide if it's worth or not to use whatever thing. He also knows that "frameworks, languages and platforms" aren't pure ideas without any contact with reality, and reality matters and sometimes the theoretically "perfect" (i.e., perfectly hyped) solution is not even good enough.

    Spring xiites are a perfect example of cult-following-brain-damaged developers who wouldn't recognize a good solution even if it was thrown at their faces. They only check if the solution is "acronym-compliant",
    LOLLLLLLLLLLLLLLLLLLLLLLLL Is there any copyright ? Guido
  61. I agree 100%!!! Too many developers now a days don't bother to look at the problem they are trying to solve and apply the correct solution/framework/technology to it, they just rely on stuff they've heard from a collegue who may or may not know what they're talking about or read on a geek board.
  62. After Reading many of the posts I have to post my own list. 1) They have a Brain. 2) Both sides of the Brain work. The Artistic side sees their solution as providing someone else pleasure. Not a means to stroking their ego and packing mindless techno-babble in to some form of glittering light show and/or fireworks display. The Technical side sees their solution as providing a concrete service. Not some far-fetched, inoperable concept-vehicle that could not carry the kids to Soccer practice and return home to pick up the groceries. This applies to all developers of Computer Science solutions. The fact the title has Java in it shows a predisposition to a Technology and mindless self-gratification that the Industry has pursued. I guess it is posted on ServerSide ... but the last time I checked there were millions of lines of Cobol Server Side code as well. Anyway, Java does present it's own issues in a highly open fragmented solution space ... but the issues of good Developers is the same and always will be regardless of Technology.
  63. Shot Yujun - I enjoyed your post about The Chinese Butcher - it illustrates the all too hidden/lost earnestness of applying ourselves in our profession. A good enterprise developer is one who is of the most benefit to his profession.
  64. I have a side-topic, and I haven't decided where I stand on it. If you're a top-notch developer, then by definition most co-developers and people who come after you aren't as talented as you. So, do you, despite the desire to build the perfect system, and despite the inevitable frustration, use lowest-common-denominator tools and code, so as to allow the maximum flexibility for the business, OR do you use your skills to the max, leaving the business highly dependent on you, but while you are there, providing their customers with the best solutions?
  65. So this is the difference between being good (skills) and being good (not evil)? A Computer Science professor I had many many years ago said that he "hated clever programmers". Being a young smart hotshot I wondered why he didn't appreciate clever tricks and techniques as much as I did. I know why now.
  66. I have a side-topic, and I haven't decided where I stand on it.

    If you're a top-notch developer, then by definition most co-developers and people who come after you aren't as talented as you.

    So, do you, despite the desire to build the perfect system, and despite the inevitable frustration, use lowest-common-denominator tools and code, so as to allow the maximum flexibility for the business,

    OR

    do you use your skills to the max, leaving the business highly dependent on you, but while you are there, providing their customers with the best solutions?
    If you are a truly outstanding developer and work in a decent environment (that's a kicker..) this shouldn't be an either-or. It's OK that you write so top-notch hyper-sophisticated code so long as it is unlikely to need to be changed, and you document it thoroughly enough that if your employer/customer hires someone of similar skill they will be able to make sense of it. Ask yourself: If I suddenly had amnesia, would I understand this code? That means that the code has to work. The tests better hit all the corner cases and edge-conditions, and the code better pass. In many ways, if you are truly the superior developer, the lesser developers are your users. They will call your code to do magic. They don't have to understand the intricacies of how it works in order to know how to use it. But if your teammates look at the public interface to your code and scratch their heads, then you probably aren't as brilliant as you think you are. You can work all sorts of magical cleverness but you can't skim it with a veneer of elegant simplicity. I think many of us can have flashes of brilliance but almost no one can do it consistently. I'm not sure if anyone can do it consistently.
  67. I have a side-topic, and I haven't decided where I stand on it.

    If you're a top-notch developer, then by definition most co-developers and people who come after you aren't as talented as you.

    So, do you, despite the desire to build the perfect system, and despite the inevitable frustration, use lowest-common-denominator tools and code, so as to allow the maximum flexibility for the business,

    OR

    do you use your skills to the max, leaving the business highly dependent on you, but while you are there, providing their customers with the best solutions?
    I think if you happen to be the "guru" then you have an obligation to try to bring everybody up a notch or two without leaving them in the dust. Especially if you are a contractor and won't be tied to maintaining the code. Good design is an intelligent compromise between requirements and constraints. A team of junior developers is defiantly an environmental constraint that you need to take into account. Of course there are other options like prototyping a more sophisticated design and letting the juniors try it out, training, better documentation of the more sophisticated design, etc.
  68. How about this? A good J2EE developer is one who 1) writes software that work as required without tons of bugs, 2) fixes his/her own damn bugs. 3) makes it easy to modify and extend functionality. All the "do use these technologies and do not use those" are nonsense. If it works well, I don't care if it was written in egyptian. The technology field is like political campaigns these days. Those IT politicians just follow wherever buzzword wind blows. JSP, Struts, EJB, XML, SOA, Spring, JSF. When the hype is here, they proclaim you must use it or you are behind the time. When the hot air blows over, those same people makes a 180 turn and say you must not use it because it is bad. They sounds very much like political speeches such as "I was for the war before I was against the war..." or "We must stay the course".
  69. I'm currently trying to hire some of these very "top-notch enterprise Java developers", and had to give this question some thought when I wrote our job posting. Here are the relevant bits, with specific technologies (which are much less relevant to the general case of "top notch") omitted: ---- We're looking for people who
    1. are brilliant,
    2. get things done on time, and
    3. work well with the rest of our team.
    We're looking for "A list" developers who are "generalizing specialists." We're going to be developing high-performance, mission-critical enterprise software that needs to be rock solid and very, very scalable, and we expect you to either come to us with a track record of successfully developing such systems, or prove to us that you're sharp enough to get up to speed on the problems involved very quickly. We're very picky about who we hire, we're unapologetic about that fact, and we care a lot more about your problem solving skills and your ability to write well-tested, well-designed, efficient code than we do about how many years of experience you have with which specific technologies. That said, having any or all of the following characteristics would make you more attractive to us:
    • Recent enterprise Java experience, particularly with frameworks such as [currently fashionable ones]. [Experience with similar languages] will do in a pinch if you have a track record of quickly learning new languages.
    • Familiarity with [a bunch of technologies].
    • An informed opinion about [a particular technical question], and the ability to clearly articulate it.
    • [A big pile of additional technologies, meant to filter out people uncomfortable with learning new ones, and to filter *in* people with a love of learning.]
    • Skill and interest in mentoring junior and intermediate developers.
    • A regular habit of reading up on the latest technologies, and a track record of applying them to help projects you've worked on.
    • A facility for quickly learning and applying new languages and other skills.
    • Superior communications skills.
    • Passion and enthusiasm.
    We don't expect every successful candidate to have every one of those qualities, but they're all pluses. And successfully convincing us that there's an important point that we left off that list, and bringing to us relevant experience in it, would make you particularly attractive. ---- (For the curious, the full version is available at http://futabachan.livejournal.com/145014.html.)
  70. Susan, So basically you're saying that having really thick alphabet soup on your resume will get you an interview, and you'll try to determine the other characteristics later. I'd say that is pretty common. I think if I were looking for a developer, I would ask that all applicants provide the following: 1. One or more links to "articles" (blogs, webpages, actual publications, etc) written by the applicant on technical or development-process type topic. 2. One or more links to actual code written by the application. It could be contributions to an OSS project, academic project, or a personal project. 3. One or more links to threads on online communities where the applicant actively participated.
  71. We're looking for people who

    1. are brilliant,
    2. get things done on time, and
    3. work well with the rest of our team.
    ... (For the curious, the full version is available at http://futabachan.livejournal.com/145014.html.)
    Amen.
    • Ability to think not only from the technical perspective but also from the business perspective
    In my past experience, quite often it would have been totally sufficient if the business would have been able to think from a business perspective.
    • Ability to analyse "What if" scenarios like what if I want to support new products in the future? What if I want to support web clients? etc.
    Gold plated software is one of the surest roads into desaster.
    • Right attitude. Avoid "I know it all" attitude. I have come across some talented Java/J2EE practitioners who hardly listen and believe that they know it all would not like to be corrected.
    On the other hand I have seen a lot of projects, where the developers could not stand their ground on perfectly reasonable issues, because they were deemed "know alls" by some vendors and managers.
    • Good interpersonal and communication skills.
    Not sure if we need a developer for this. That is what management is for.
    • Eagerness to learn and keep up with the emerging technologies and frameworks like Spring, Ajax, JSF, Hibernate etc.
    Generally learning is a good thing. On the other hand, one cannot jump every bandwagon. Above all, a good developer should be able to judge if and when a particular technology makes sense in his or her context. Unless confronted with a total greenfield, new technologies tend to increase entropy and complexity of your system. Yet another object factory, yet another interface component technology, yet another interceptor technology and so on....
  72. Maybe there's another way of looking at this: Given that it's so hard to find top-notch developers, should the industry instead move towards looking to develop products and processes that most employees can handle? For example any monkey can work at McDonalds, because their processes are designed with that in mind. You can still be innovative, just your business shouldn't DEPEND on having to find a top-notch developer.
  73. Maybe there's another way of looking at this:

    Given that it's so hard to find top-notch developers, should the industry instead move towards looking to develop products and processes that most employees can handle? For example any monkey can work at McDonalds, because their processes are designed with that in mind.

    You can still be innovative, just your business shouldn't DEPEND on having to find a top-notch developer.
    CMMI?
  74. Maybe there's another way of looking at this:

    Given that it's so hard to find top-notch developers, should the industry instead move towards looking to develop products and processes that most employees can handle? For example any monkey can work at McDonalds, because their processes are designed with that in mind.

    You can still be innovative, just your business shouldn't DEPEND on having to find a top-notch developer.
    GRRR not again, read this and come back : http://www.martinfowler.com/articles/newMethodology.html
  75. Maybe there's another way of looking at this:

    Given that it's so hard to find top-notch developers, should the industry instead move towards looking to develop products and processes that most employees can handle? For example any monkey can work at McDonalds, because their processes are designed with that in mind.

    You can still be innovative, just your business shouldn't DEPEND on having to find a top-notch developer.
    Selling developers by the pound. It is quite frequent here in Italy. It may work if you are ready to manage angry customers. Guido.