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?

  • 4
    TBH this sounds like a management / marketing buzzword as opposed to an actual technical meme.
    – mcfinnigan
    Jan 27, 2012 at 9:20
  • Can you provide a quote or context? Without more information, we're mostly only able to guess.
    – S.Lott
    Jan 27, 2012 at 10:44
  • 1
    Are you sure you're not confusing "efficient" with "effective"? Jan 27, 2012 at 10:50
  • 1
    The most efficient Java Programmer would be one who understands where and how Java shouldn't be used :)
    – duros
    Jan 27, 2012 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, 2012 at 12:53

2 Answers 2


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...
  • 1
    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! Jan 27, 2012 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, 2014 at 14:10

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.
  • 1
    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.
    – user
    Jan 27, 2012 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.
    – user36524
    Jan 27, 2012 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>
    – user36524
    Jan 27, 2012 at 10:32
  • 1
    @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. Jan 27, 2012 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.
    – user
    Jan 27, 2012 at 12:20

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