David R. Heffelfinger

Software developers are in high demand nowadays. We get contacted on a daily basis by companies requesting we go work for them. We frequently get emails with the words "Great Opportunity!" and "Urgent Requirement". The thing is, not many of the projects we get contacted for offer compelling reasons for us to make the change. I decided to make a list of things that would make us as software developers consider the possibility of moving on to another project.

1. Working on a brand new project

Most of the projects out there are maintenance of an existing application, brand new projects built from the ground up are few and far in between. If you have a brand new project, then you have a leg up over all the other companies looking to hire software development talent.

2. Quiet working spaces

Software development requires concentration, this concentration is hard to obtain in the modern cubicle farm, with all the interruptions around (conversations, phones ringing etc). Offer your developers quiet working spaces and you have a perk that most employers around can't offer. Ideally, give each developer their own private office, now you really have a perk that puts you head and shoulders above the competition. If you can offer private offices, at least offer cubicles with doors, which provide a bit more privacy than the usual open cubicles.

3. The ability to work remotely

Nowadays high speed internet is so common, that there really is no reason for most people to actually drive to an office. A lot of companies want to see "butts in chairs", this is really not necessary, you should know if the work is getting done, your development team does not have to physically be at your location. This is one very rare perk, offering this will certainly make your company an attractive place to work for software developers. This also has the side effect of increasing the available talent pool, since members of the development team does not have to live in the same geographical area as your company.

4. Allow the development team to use their own equipment

To this day, many companies are shy about allowing non-company laptops into their network. The development team has to use company approved hardware. Many software developers would prefer to work using their own laptops, it shouldn't be a big deal to allow them to do so. As a bonus, when working with a programming language that is platform independent, such as Java, it doesn't matter if the developer is using a Mac, Windows or Linux, therefore developers can work with their preferred platform, as opposed to being tied to whatever the company standard is.

5. Keep meetings to a minimum

In my experience, in most cases, most people attending a meeting have no real business being there. They could be doing productive work instead. Meetings interrupt the workflow of software developers and in most cases are a massive waste of time. I'd recommend not more than a 1 hour meeting a week. If you need daily status reports, an email works better than a daily meeting, that way the developers can do it at their leisure, not at a set time, and they don't have to sit through and listen to the status of all the other team members, which more than likely has no impact whatsoever in whatever they may be working on.

I am fortunate enough to work in a field for which there is a lot of demand out there. I get multiple emails every day from companies asking for help with their server side Java projects. Java developers such as myself

1. Don't call your position "an opportunity"
Like I mentined in the intro, I get tons of "opportunities" every day via email or LinkedIn messages. Java projects are a dime a dozen, chances are your project is not a "great opportunity" for me. You know and I know that Java developers are hard to find, if anything, me agreeing to work on your project is an opportunity for you, and not for me.

2. Don't say you have an "urgent requirement"
You may urgently need a Java developer, and I'm here drowning in emails from recruiters that also need Java developers. It may be urgent for you to fill that position, but it is not urgent for me to accept it. While we are on the topic, don't say the requirement is urgent if you are not willing to be flexible. One perk that would certainly catch my attention would be the ability to work remotely, but very few customers are open to the possiblity. If your requirement is so urgent, shouldn't you be a bit more flexible? Oh, and by the way, no, I am not willing to relocate just so that I can work on a 6 month project.

3. I don't stay on the market too long.
I work as a consultant on a C2C basis, therefore I switch projects every few months. Every time I post my resume on one of the job boards, I get bombarded with calls and emails from recruiters (even more so than when I'm not actively looking).
If you are interested in my services, you have to move fast, chances are that in a week or less I won't be in the market anymore.

4. Don't make me jump through hoops
I've written several books on Java, taught Java classes and been a speaker at Java conferences, as well as having about 18 years of experience. I think my experience speaks for itself. Please don't make me go through several rounds of interviews or take a silly test just so that I can work on your project. Just by talking to one of your developers he or she will be able to tell that I know what I'm talking about.

5. If I accept/am about to accept another project, don't ask me to "wait a few days"
As much as I get contacted by recruiters for several different positions, it is mentally exhausting and draining to talk to several potential clients, send resumes, etc. I just want to get it over with, so as soon as I get an offer, I'm taking it.

I just came back from teaching a Java EE class in San Francisco.

The course lasted two days, and it covered the most commonly used Java EE technologies and API's such as JavaServer Faces (JSF), Contexts and Dependency Injection (CDI), Enterprise JavaBeans (EJB), the Java Persistence API and the Java Message Service(JMS). The course also touched on Bean Validation and the Java API for RESTful Web Services (JAX-RS).

The students were veteran Java developers and architects, ranging from around 5 to 18 years of experience. There were a few students that had use EJB's back in the J2EE era, some that had used earlier versions of JSF (1.x) and some that had been focusing on Spring for their server side Java development.

None of the students had use modern versions of EJB or JSF, they were very impressed on how much easier modern versions of these frameworks are compared to their Java EE counterparts.

Since we had only two days, we only covered the basics of each technology, such as Facelets markup for JSF. For CDI, we covered context (scope) annotations and dependency injection for CDI. We mentioned additional CDI features such as qualifiers, stereotypes and interceptor binding types.

The different Bean Validation annotations were covered, pointing out how simple it is to do validation using just a few simple annotations. As far as EJB's go, I covered the different type of session beans, such as Stateless, Stateful, and Singleton session beans; as well as Message driven beans. For EJB's we went a bit deeper, covering things such as transaction management, interceptors for Aspect Oriented Programming (AOP) and the EJB timer service.

When talking about JPA, the class covered basic JPA annotations such as @Table and @Column, as well as one-to-many, many-to-one, many-to-many and one-to-one entity relationships. We also covered eager vs lazy fetching, and the advantages and disadvantages of each approach. We ended the JPA topic with a discussion of the Java Persistence Query Language (JPQL) and the JPA Criteria API.

I overheard some comments from the students, for example, one mentioned "EJB's are cool", which I completely agree. Another student noted that there isn't anything in Java EE that he cannot accomplish with Spring, which, while it may be true that the end result is the same, fails to take into account that the amount of work to get this end result tends to be a lot less with Java EE.

There were hands-on labs for the students to practice the concepts taught in class. I chose NetBeans as the IDE for the exercises, since it comes bundled out of the box with everything needed to build complete applications, such as a Java EE compliant application server (GlassFish), and a fully functional RDBMS (JavaDB). Not many of the students had previous NetBeans experience, however most of them were able to finish the exercises (which were simple, but complete Java EE applications) in about 30 minutes or so.

While discussing the hands-on labs, I provided some NetBeans tips, such as the ability to generate boilerplate code (Alt-Ins), generate JPA entities from an existing database, and the NetBeans JPQL editor, which provides code completion when developing JPQL queries.

All in all, a great experience. I don't get to teach as often as I'd like, it is a nice change of pace from my day to day job developing real-life Java EE applications.