Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There's been a buzz in my local tech community about being an 'Efficient Java Programmer' can someone explain to me what is an Efficient Java Programmer? what is their difference between average java programmers? how can you be an Efficient Java Programmer? (I am still in college, I want to get acustomed to doing the proper practices when it comes to programming) and how can you tell someone is an efficient java programmer?

share|improve this question
TBH this sounds like a management / marketing buzzword as opposed to an actual technical meme. –  mcfinnigan Jan 27 '12 at 9:20
Can you provide a quote or context? Without more information, we're mostly only able to guess. –  S.Lott Jan 27 '12 at 10:44
Are you sure you're not confusing "efficient" with "effective"? –  FredOverflow Jan 27 '12 at 10:50
The most efficient Java Programmer would be one who understands where and how Java shouldn't be used :) –  duros Jan 27 '12 at 10:58
I my opinion, this is too broad a question. Without a context, "efficient" and "effective" mean different things to different people. –  Andres F. Jan 27 '12 at 12:53
show 1 more comment

closed as not a real question by gnat, Yannis Rizos, Martijn Verburg, maple_shaft, ChrisF Jan 27 '12 at 13:23

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers

up vote 4 down vote accepted

Efficient could mean anything... my guess is:

  • Know and use the libraries (instead of reinventing the wheel)
  • Use an IDE (Eclipse, NetBeans, whatever fits you)
  • Use version control (okay, not so Java specific)
  • Know advanced features (concurrency, generics)
  • and many more...
share|improve this answer
Knowing and using libraries is something that was really not taught at my university but in my day to day job is something I am always doing. Well worth looking learning about how to use them! –  stuartmclark Jan 27 '12 at 9:43
Being a minimalist (Google page for example) - Avoid unjustified bloat in code when the same can be achieved in fewer lines. Less is more, as it were as long as clarity is preserved. –  Constantin Jan 12 at 14:10
add comment

For me an efficient Java Programer has the following attributes.
Knowable of:

  • Computers in general: e.g. Understand a proxy to set up an application that needs access to several different networks thru for example VPN.
  • Exotic but simple tricks like in memory caching.
  • Different frameworks, Java is nothing without it's vast framework and external APIs. For example reason the choice of a controller (Play, Spring MVC or Struts). Few things is wore than fossil developers that choose historic frameworks because they have years of experience with it.
  • People skills, know how to work in a team and sometimes resign to inferior solutions for the team to be happy. The mindset that the job should be fun and not work.
  • Write code that is easy for the team and new members to understand.
  • Have basic sense of economics. For example don't write complicated code to optimize performance when you could fix that for 1000$ in hardware instead. Lets say you cost 100$ an hour and you spend 2weeks making shit spaghetti code that is optimized and cant be adapted to CRs that will come.
  • Don't be afraid of management and project leaders. You are the expert not them. Get involved in management questions. For example say and repeat that you need 3 month development freeze each year to focus only on refactoring. Many developers are conflict afraid chickens, they know what's the best but are afraid to motivate it.
share|improve this answer
If you need to spend more than a quarter of your time (three months out of a year that includes vacations etc) doing nothing but refactoring, then you are doing something wrong. If you let refactor-worthy code pile up for well over half a year before doing anything about it, then you are doing something wrong. Refactoring should be an ongoing process, not a separate item to cross off one's checklist. –  Michael Kjörling Jan 27 '12 at 10:10
I absolutely agree with you in theory. But if you are several developers you will share experiences, after implementation where the experience comes from, and find ways to refactor nicely implemented code to a coherent stack. For example two developers have made roughly the same methods in the businesses layer. Then you refactor this under the 3 month to be one more generic method. I hate 2 similar methods and then for a new developer it is like wtf witch should I choose. And also if a service method is called from several contexts it's more likely to be correct. to be continued. –  Farmor Jan 27 '12 at 10:29
Another refactoring could be change all change all JavaScript YUI code to JQuery where the customer won't get any new features. Refactor to make use of Java 7 synthetic sugar to make the code more nice. If your code base is really old remove all warnings and make use of generics in all places e.g chane List to List<String> –  Farmor Jan 27 '12 at 10:32
@Farmor, in theory this sounds good, in practice it will never work this way. Your first example can be prevented by developers communicating more about their implementation, doing code reviews, or pair programming. In general, I seriously doubt you could find any manager willing to sponsor 3 months of "development" without any demonstrable end result for users / stakeholders. "Making the code nicer" is not a business objective. "Making it more maintainable" may be - if you know at least something about planned future developments and new features to ensure you aren't wasting effort. –  Péter Török Jan 27 '12 at 11:21
@PéterTörök, "no demonstrable end result" is not the worst; by rewriting code e.g. to use new syntactic sugar, you run the risk of introducing bugs because of faulty understanding of either the old code - that's why you are rewriting it, to make it easier to understand, correct? - or the sugar you are applying - maybe it's actually honey rather than powdered sugar? Refactoring is a good thing most of the time, but it's best done as you go, not left to pile up at the end. The boy scout rule of programming: leave the code a little better than you found it. –  Michael Kjörling Jan 27 '12 at 12:20
show 1 more comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.