“Wanted Java Developer” could you be a little more ambiguous?

I have a bone to pick with the industry I associate with. The tech industry struggles to clearly define the expectations of whatever is desired. This is pretty much a universal issue with the industry. There are always hidden requirements. Job listings are no different.

The bone I have to pick is with the titles/job requirements. One of the worst offenders of this is for a Java Software Engineer. Based on the availability of frameworks, and meta-frameworks, asking for a Java engineer is quite ambiguous. This could ask for a graphics developer, API designer, web developer, Computer vision expert [CV in java is possible with native libraries, trust me!], core libraries developer, or even a micro-JVM developer. The amount of variability with the language makes a generic “Java developer” title frustrating.

As a potential candidate, it is incredibly frustrating to see the “Java Developer” title. Some titles ask for experience in Spring, Hibernate, Solr, Lucene, JAI, J2EE, etc. It’s incredibly frustrating to go into an interview, where the listing asked for all of these and then only be grilled on the minute [rarely used] inner workings of Spring RMI. Just the Spring framework alone asks for a lot. Of all of the potential avenues of spring that one could master are: Message queuing, Web services, Roo, Security, Integration, Web flow, MVC, BlazeDS, Batch, Social, and mobile. That’s not even accounting for the frameworks that you can substitute between the pathways for Spring. I’ve worked with a late Spring 2.x and early 3.0, I was not even aware of the new BlazeDS, Batch, social, or even mobile options for the framework. Things change quite quickly.

Besides ranting, what is the purpose of this article? I believe that the Java title should be a bit more specific. If you want a Java developer that knows a lot of frameworks, still label it as a Java developer position. However, don’t expect him or her to know all of the inner workings: that is just silly. If your business involves multimedia display, request a developer that knows the Java 2D and 3D graphics, and maybe the JAI libraries. There is a lot there for practically any task you want to throw at Java, given you know which library to use.

Scientific or mathematical tasks, ask for a Scientific Java Developer. What libraries should they know? Colt, EJML, JAMA, etc.

Writing a Java API? Ask for a Java API Designer. Expect for them to list their favorite APIs, what works, what doesn’t, and why.

Web applications? Ask for a Java Web Developer. Maybe they should have experience with a SOAP framework, MVC framework, Play, GWT, basic Web skills, and maybe even a non-SOAP based webservice library [REST, Hessian/Binary]. Please don’t use the enterprise title unless you need someone who knows EJB, and/or ESB frameworks.

Moreover as an employer, be more specific the first interview/inquiry on what the job is asking for. If an job application asks for the common ORM Hibernate, how much should one know about it before applying for the position? Should they be able to know how to wire up beans to their DB analog? Should they know how write their own dialect for a new data source? With JUnit, should the applicant be expected to transition your current development methodology to TDD? Should they know how to extend the JUnit framework?

At this point, you should be getting the picture. Different tasks demand different skills. Specify what you’re looking for. Find people that can learn new skills and that are interested in the same problems you are. People who have an active interest can learn what is needed to get up to speed. If you go to a butcher and ask for meat, you’re always going to get what you asked for, but not what you were craving.

Addendum: This can apply to an Erlang, C++, Python, and most other developers. The role of Java currently has such a great demand, and such an ambiguous title, making this article a little easier to communicate.

“10 Ten Reasons why You’re Programming Wrong” — How to bore/annoy your audience

After watching the video “The Web Will Die When OOPs dies” and reading a few hip articles, on “how to improve your code,” gave me an idea. If someone is writing to give advice on improvements they should provide real world examples to why their suggestions/fixes to a language/framework are necessary.

Instead of articles of “Top 10 ways to improve your code;” I’d rather see an article about how something was improved. Take small segments from your own application or an open source project and write up a small report on how your suggestion[s] improved it. If you’re writing an article for developers, we’re interested in the proof and technical content. If your suggestions didn’t work out, we’re still interested in the story about the journey, or the technical observations that you found. Making vague suggestions and recommendations (without evidence) bore a technical audience. When you make vague suggestions to someone, you’re making an statement that you know more about their work or problem than they do. Your audience should be intelligent, if not then still write for an intelligent audience. Vague statements don’t address interesting problems, or new approaches.

So going back to the video I mentioned earlier. I like his tactless approach. He’s taken a good deal of experience from web development and he is presenting his argument. He doesn’t attempt to ask for others for opinion, nor does he attempt to tell his audience how to do their job. He just merely presents issues that he found, and his way of trying to solve those. The last thing that I loved about his talk is that he never once tried to push the latest hip language or framework. He mentioned a few frameworks, and then made a critism.

Review: “Test-Driven Development” by Kent Beck [The creator of JUnit]

It is always interesting to read a book about a technical topic from its creator. They tend to better identify the motivating factors and history that went into creating the product than other authors could possibly try. Kent Beck is the creator of JUnit, and happens to be the author of this book. The book is designed for people who are new to unit testing and Test-Driven Development. For anyone in the current software development industry, this is very few people.

The book is divided into three separate sections. The first being a walk-through with JUnit (by example), xUnit, and then a “best practices guide.” The JUnit section, the majority of the content of this book, is focused on developing a currency class. While there were some interesting design decisions, this part irritated me the most. The first section produced blatant errors, just to create a test that would fail. I would have preferred if these errors had been described rather than presented to the reader. The currency example was a good example, however adding another example would have been better. The xUnit section of the book focused on creating a test environment for Python. I am not a Python developer, but I have written a very small amount of code. I was not a fan of this section. However, I was pleased with the best practices section. The only issue I had with the last section is that I do not recall that the best practices section went into why the recommendations are better than what they replace. If my memory serves me correctly, it did not.

This is a great resource for developers who have never heard of TDD. It may even be a great book for students that have just completed half of a class in Java. However, it is not such a great book for people who have worked with Test Driven Development.  For those who have already worked with TDD, a Manning Press’s “In Action” series may be more suitable. Although their resource on JUnit looks to be a bit dated. Manning Press’s dated JUnit book includes information on integrations with other frameworks, which are slightly harder to test against [J2EE, XML, Servlets, EJB, DBs….].

In summary, I was probably looking for another book similar to “Pragmatic Unit Testing in Java with JUnit” (Hunt and Davis). Their approach was more focused on how to try to find trouble spots, and improve existing code.

Given that this was written in 2002, the following is not exactly fair criticism, but it should be mentioned by anyone that is claiming that TDD is beneficial. I would have liked to see more support [research/studies] on why Test Driven Development is beneficial. Every TDD-related article/publication/book that I have read always attempts to convince the reader that it’s necessarily with marketing-speak. The claim is that it is good for “high stress environments,” or it reduces defects. However, I have never seen evidence supporting the claim mentioned. I, personally, have found that TDD to be a significant improvement in development. However, I have never been able to quantify how much of an improvement it has made. What is the amount of time saved by TDD? Has it made today’s software more reliable than before? Has it affected the developer job market? [Increased/Decreased] Has it made the users of the products using TDD happier? Most importantly, has test-driven development reduced the stress of software development?

A Tool That Would Be Rather Nice To Have

There is one tool that I haven’t found an open source project for or a commercial product. I think that it would be quite useful in creating dependable software. I would like to see for evaluating unit tests. It would be something like a Lint or Static analysis tool – but for the tests themselves.

Some of the features that I would imagine that would make this tool useful in evaluating tests for the particular cases:

  • Seek out infinite loop cases
  • Check bounds on parameters
  • Duplicate test cases [are there redundant test cases]
  • If exceptional cases are tested
  • Evaluate for bad parameters
  • Evaluate potential recursion issues.

This would differ from a code coverage tool, because a coverage tool is only effective for evaluating what isn’t covered by tests. The tool I’m suggesting would be responsible for making sure that the tests are effective, and would handle potential pitfalls in input and common programmatic areas.

My question to the reader: Does this already exist? Are there any new open source projects starting up that are designed to tackle this problem?

If not – how hard would it be to adapt existing analysis tools/testing frameworks, and where would you approach starting the development?

Computer Science Classes I Would Like To See Offered

My friend Warren recently expressed a very “scorched earth” opinion of the standard Computer Science curriculum. He suggested that given the available of free CS courses (OpenCourseWare and the like) and experts at your fingertips (Blogs and Stackoverflow); wheres the value of a formal CS degree?  That lead me to think …. What are some classes that would be very interesting to take: [Even as an alumni of 2 CS programs, I would be interested]

  • Software Development Tools: A lot of classes mention tools, but not how to actually use and extend them. [Build systems, version control systems, formatters, emulators/virtualization]
  • Debugging: The goal of this class is to teach basic skills and then go through labs of finding/fixing bugs. Later, to write unit tests to verify the bugs.
  • Testing software: This would be a hands-on class to teach students how to write unit tests, implement mocks, test black box software, and write up reports on testing procedures. This would also the involve testing of embedded hardware and software, black box systems, functional languages, network services, concurrent software, and even components that lack a stable test environment.
  • Computer Vision: It’s just interesting, and visual, often you don’t hit this class until graduate school.
  • How to design an API/Surveying APIs: Let’s get rid of bad APIs. This would also be responsible for demonstrating the differences [good and bad] of available APIs.
  • Open Source: Not really a history of open source. But this is to take an open source project, and extend it. The goal of this project is to get students involved with working with one project, and demonstrating improvement to the project.
  • Marketing: How to market your work, or someone else’s software. This isn’t designed to replace developers with marketers, but it just helps the developer understand how their work is sold.
  • Automation: How to automate manual tasks with software. This could be with build scripts, batch scripts, testing automation software, or even simple system scheduling.
  • From hardware to software: The goal of this class would be 2 things. To create a small embedded device, and then go all the way up the chain to a working software client. This would involve writing a device driver, interfacing with hardware ports, and using the driver. The second part of this class would involve creating a simple processor either as a circuit or a manual build. http://blog.makezine.com/2009/10/03/building-a-cpu-from-scratch/
  • How Computer Science relates to [Field x, y or z]: This is more of an open ended suggestion. For example: Offer a class on Bioinformatics [It’s a class that combines biology, and computer science], combine a class on art and computer science (that’s more of visualizations though), history and CS [examine potential DSLs involved with history research], or even math and CS [shows the tools, and libraries that one can use in their application].
  • How to crack software/re-engineer a binary: [Probably with the permission of the publisher] Crack a copy protection system. Many students know about software cracks, but very few actually know how to create them or how they work. The goal of this class would to familiarize the student with how software is compiled, and can be reworked after compilation. Also, this would demonstrate how to protect their application as well.
  • Alternative Language Survey: Yes, this is technically a standard class. But I’d like to see one on functional languages, Groovy, BF, or even creating your own domain specific languages be taught.
  • Community Service: This really isn’t as altruistic as the title may imply. This is more of a class to create a software component [as a large group] for a member of a local community. This could be a small interesting game [example I worked with a group for a class], or working with a small company or individual to improve or sofware-ize their product. Elon’s CS department did this a while back with the game deflection. even taking an existing board game [with the original creator] and making  a software version. The goal of this class is to research market need, create something usable and getting their fellow peers involved in using it. This would help communicate to the rest of the students about some of the cool things that CS can produce.
  • Author selected: Get an author of a quality software related book to teach a class. Have John Skeet teach a C# class. Paul Graham teach a class on LISP. Brian Goetz to teach a class on Concurrency.
  • Hands on Software Optimization class: Take an open source system, and optimize it. This class would teach formal procedures on how to optimize an existing application to perform as quickly as possible, monitor, and document the improvements.

Last of all, these classes should be fun and engaging. If you’re not actively involving the student, don’t even bother trying these suggestions.

I’m a student, what [language, framework, API, concept] should I learn?

Part one of a continuing series.

There are two ways to learn something. The first way is to learn from another’s advice [the easy way], and then there is the hard way [through experience and making mistakes]. When starting out in a Computer Science degree, learning the material and concepts will require a lot of effort. [the hard way] It’s not a wrong way to go about it. The hard route helps to reinforce the material. However, not everything in your journey to become a software developer has to be difficult.

One of the most frustrating things for a student, when in a Computer Science program, is producing a deliverable to submit. Many students, outside of the introductory course, quickly find out that a few quick hacks won’t get the highest grade available. Many professors require documentation, specific file layouts, compliable code, funky submission instructions, build instructions, shout-outs in the comments (1), or even coding conventions. These extra/non-technical requirements add to more complexity and make assignments more difficult. However, they do have merit and “build” the student’s technical character. In academia, there are very few courses in the US that will teach the tools of the trade, this is something that the student is left to learn on his or her own.

So what does this have to do with answering the question: What should I [as a current Computer Science student] learn? Build systems. Learning how to consume a web service to Facebook or writing the next twitter client is great, however learning how to use a build system will make your professor’s, and your life much easier. A build system is an external tool [usually separated from an IDE] that defines the instructions on how to build an application. In addition, it makes your life easier when questioning if your attempt was worthy enough to submit. Did the build system pass and produce a deliverable? If you have all of the rules and unit tests configured to run, the answer is easy… Yes! Once you are confident that the assignment was completed to satisfaction, you can go party err study ‘social algorithms.’

So let’s imagine that you have the following requirements from a professor:

  • Build a chat system [One client, and one server]
  • Include unit tests for every method used
  • Include Java Doc
  • Email to: professor@university.com
  • FTP The resulting zip file to: ftp server.
  • Create a readme at the base, and include your name and the word “Screaming Monkeys” within the readme file.
  • Include instructions on how to build your software
  • Use the following file format:
    • /
    • Readme
    • BuildDoc
    • Doc/
    • Source/Client/*….
    • Source/Server/*…
    • Binary/*…

Building a working chat client and server solution may be difficult for someone that has just learned about sockets and lacks experience. The non-technical requirements could become overwhelming. However the assignment never required all of the non-technical instructions to be performed manually. I have NEVER heard of a professor that will take points off for using these tools. If anything, using a build tool will improve your grade. It allows for you to plan for these requirements ahead of time, and let software handle the rest for you.

“But hey! That looks like a lot of work to do a few simple steps!” You’re right; all of those steps can be performed manually and probably quicker. However, if you screw up part of your final deliverable , you’ll have to perform all of those menial tasks all over again. With all of those tasks, Ant can perform those automatically by just typing in “ant.” You can configure ant to build the software, run all of the unit tests [and stop the build if one fails], configure the output of the java doc, run utilities [to confirm that your name is there, and the “special word”], perform all of the file manipulation and deliverable locations, and even submit the result [ftp, email, source control]. If there is an ant task for the action, you can use ant to do it.  Another benefit is that it can even run the source code through a “coding convention” checker. Have a professor that requires you to use the K&R coding convention? No problem, just add a check or reformator in the build environment. Problem solved.

In summary, assignments in computer science are difficult with the shear amount of demands. Reduce the potential for mistakes by automating the tedious tasks. Learn a build system early in your education. It will help ensure consistency in your code, get rid of annoying non-technical requirements, and make your work a lot simpler.

Need another reason? Do it for getting a job after you get out of school. There are very few students that have even used a build system prior to entering the work world. Most students entering the work world have to learn at least one build system as soon as they start their first job. The software industry thrives on build systems. If they aren’t working, the developers are unable to progress. Hey, worst case scenario: Let’s assume that you’re not a very good CS student, and you barely pass with your CS degree. If you know a build system extremely well, you can still proceed with a career of being a “Build Systems engineer.” Those guys can still make quite a lot of money. [Indeed claims that a build engineer starts at $50k and has a sizable amount of jobs that will earn $130k+ a year]

Some of the build systems that are currently in use:

  • Ant [Good for nearly every language out there]
  • MSBuild [Good for the MS supported language (VC++, VB?, anything .NET)]
  • Maven
  • Gradle
  • Make [Good for C++, and bash]
  • Apache Ivy

(1)    In my prior work as a teaching assistant I am guilty for supporting the shout-outs rule. The requirement was for the student to include his or her name in the top of the file. This was mentioned on the grading rubric (included in the assignment writeup/specs).  It’s a simple request to complete, and it makes the grader/professor’s life a lot easier. It’s akin to asking elementary school children to write their name on top of the assignment. A lot of new students don’t add their name to their code.