Developer efficiency myths and truths

If you read the ads in development-related magazines or on Web sites, you would think that solving development inefficiency is a great path to making big bucks — and I believe that it is. There are tons of products on the market that claim to improve developer efficiency, from different languages to IDEs, automated build tools to automated build environments. I will try to bust some myths, bring to light a few truths, and show some partial truths regarding developer efficiency.

Myths about what leads to developer efficiency

#1: Drag ‘n Drop IDEs are the be-all and end-all.

Drag ‘n Drop IDEs are great… for building UIs. Outside of using a Drag ‘n Drop IDE as a graphical code generator for UI-specific tasks, they universally stink. Unless you are writing an application so basic that the IDE’s assumptions about how code should be written won’t hurt things, chances are you will rip out at least half of the code that the Drag ‘n Drop IDE put there for you. Go ahead, use Visual Studio or Eclipse — they are great IDEs. But be wary of trying to drag ‘n drop your way to a complete application.

#2: Slumber parties at the office equal more quality work completed.

I call a workaholic programmer who regularly pulls all-nighters The Martyr. It is tempting to think that putting in more hours equals more work, but most developers are spun out by 5:00 PM. Development is brain-taxing work, and you cannot do it when you’re tired or improperly nourished. A late night here and there may pay off, but chances are, the quality of the work done past 6:00 PM or 7:00 PM is low, and the next day your efficiency will be in the toilet. Avoid the late night work whenever possible — you are not nearly as efficient as you’d like to think.

#3: Caffeine, nicotine, and sugar are your friends.

Caffeine, cigarettes, and sugary beverages contain chemicals that might provide a temporary boost in awareness, alertness, and concentration. But the 30-minute jolt that a can of Mountain Dew might give you is followed by a much longer crash that dulls your senses and fatigues your body. This is why you see people with trash cans full of soda bottles, cigarette packs, and coffee cups; they need to continually ingest the chemical(s) of their choice to find a balance. Trust me, I have been there myself (regrettably, I started drinking coffee again a month ago, but I am still cigarette and sugar free). Try to replace the coffee with water, the sugar with fruit, and find a way to quit smoking. Not only will you stop feeling the nasty side effects of coming down, but you will also have much fewer interruptions when you do not need to leave your desk constantly.

Truths about what leads to developer efficiency

#1: Environment matters

No, I am not talking about Al Gore or Greenpeace. If you are in an office, I bet good money that there is a standard fluorescent light bulb over your head. It probably cost the builder $45 or less to install; meanwhile, full-spectrum task lights can easily cost over $100.

Ever notice how many IT pros turn the lights out in the office? It is because fluorescent lights are horrible on your eyes when you’re using a PC; turning the lights off reduces the immediate stress on your eyes that causes the 2:00 PM headache. The problem is that your eyes dilate even more when you turn the lights off, letting even more of the eyeball killing monitor light damage them. In other words, the short term “fix” does long term damage. Go ahead, buy the $100 task lamp; it is cheaper than a new pair of glasses or contacts, and it will improve your efficiency significantly since you won’t be in pain by mid-afternoon.

#2: Practice makes perfect

A lot of developers think that warming a chair for 10 years makes them a better programmer. The fact is that someone who spends time reading about new ideas and trying them out on their own time is going to learn valuable lessons that they can apply in their day-to-day work. If you want to become more efficient, I suggest spending time working on a project (at home or set aside an hour or two a week at the office) that is related to work but that uses techniques that are new to you. You will discover that learning new techniques always pays a huge dividend.

#3: Limit interruptions

Your manager is making you less efficient. Every time he or she stops at your desk for a quick status update or e-mails you a memo reminding the team of the dress code policy, your concentration is broken. Even a slight distraction of a minute or two can take many more minutes to recover from and get back in “the zone.” Add that up over the course of a day, and you could be losing up to an hour’s worth of time where you are fully “in the problem” due to your manager or a coworker interrupting your thought process.

Close the door (if you have one), put blinders on so people near you don’t bother you, and close your e-mail and IM clients. Limit opening your communications software to a few times a day (after a meal, a restroom break, or other similar time is perfect, since you have already lost your train of thought anyway). If it is really important, they can pick up the phone and call you.

Partial truths about what leads to developer efficiency

#1: Code generators may lead to more work on your end.

If you are doing a ton of rote tasks, like creating the accessors for a class that represents a 200 element XML schema, code generators are great. Drag ‘n Drop IDEs make short work of generating UI code, but unless your task is extremely generic, you will probably spend more time tweaking the generated code than it would have taken you to just write it yourself. For specialized tasks, sometimes a text editor that supports regex find/replace or a spreadsheet program like Excel can do a task in a few moments where pricey code generators fall flat.

#2: Language matters some of the time.

Sometimes language matters, and sometimes it doesn’t — it is completely situational. For example, many of the languages that can be written extremely quickly thanks to type inference or syntactic tricks are often difficult to follow when they are maintained. The two minutes worth of typing saved can cause an hour of wasted time down the road. The current mainstream languages (Java, VB.NET, and C#) are all so similar (VB.NET is slightly more verbose) that none of them are particularly more efficient to work with. Some languages do have unique properties and advantages that can significantly impact development time. For instance, try writing something that is as pure logic (or math) as a weather forecasting system in C#, and you’ll be sorry. On the flip side, a typical Windows desktop application written in Fortran will probably take forever. Library support matters too; some languages, despite being weaker, in and of themselves, have library support that makes up for it.

#3: Personal life

Developers who get phone calls from friends and family for a total of two hours a day are probably not going to get much done. However, locking people down is not going to fix the issue of personal calls either. For many people (particularly those with children), a five minute phone call might save a trip home. In an ideal world, developers would not let their personal life and issues affect their work. In the real world, an argument with a spouse, money worries, the kids’ grades, and so on can and will spillover into someone’s work time.

So, for all you managers out there, while personal telephone calls represent an obvious inefficiency, it’s fairly useless to have a programmer in the office who has something heavy on his or her mind. They won’t be able to concentrate anyway, so go ahead and let them do what they need to do within reason.

Are you a developer??? cheers Aurobindo

Explore JAR files' countless possibilities

All Java developers know that JAR files are just ZIP files that contain the tree of Java classes. However, not everyone (including experienced developers) knows about the additional benefits you can get from this file format. In this article, I briefly review the JAR file format and describe the possibilities that you can enable by using it.

The ABCs of JAR files

A JAR file is based on the popular binary ZIP file format and is used for aggregating many files into one. It can also contain an optional directory called META-INF located in the root of file contents.

There are two ways that you can create JAR files: by the command-line tool jar or programmatically by using the java.util.jar API in the Java application. JAR files contain Java classes and/or resources that can be run, used, and loaded by class loaders—if the JAR files are included into the Java classpath in order to be visible for JVM.

In many cases, JAR files are not just simple archives of Java classes files and/or resources; they are used as building blocks for applications and extensions. The META-INF directory (if it exists) is used to store package and extension configuration data, including security, versioning, extension, and services.

The magic of the META-INF directory

The following files and directory in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders, and services:

• MANIFEST.MF: The manifest file that is used to define extension and package-related data.
• INDEX.LIST: This file is generated by the new "-i" option of the JAR tool, which contains location information for packages defined in an application or extension. It is part of the JarIndex implementation and used by class loaders to speed up the class loading process.
• x.SF: The signature file for the JAR file. 'x' stands for the base file name.
• x.DSA: The signature block file associated with the signature file with the same base file name. This file stores the digital signature of the corresponding signature file.
• services/: This directory stores all the service provider configuration files.

Let's go through each possible component.

Manifest file

The manifest file consists of "AttributeName: Value" pairs separated by a newline split into two sections: main and individual. The sections are divided by an additional newline symbol.

• Main: This section contains security and configuration information about the JAR file itself, as well as the application or extension that this JAR file is a part of. It also defines main attributes that apply to each individual manifest entry. No attribute in this section can have its name equal to "Name." This section is terminated by an empty line.
• Individual: This section defines various attributes for packages or files contained in this JAR file. Not all files in the JAR file need to be listed in the manifest as entries, but all files that are to be signed must be listed. The manifest file itself must not be listed. Each section must start with an attribute with the name as "Name," and the value must be a relative path to the file or an absolute URL referencing data outside the archive. (I discuss JAR signing later in the article.)

The following are the most important attributes of the manifest file:

• Manifest-Version: Defines the manifest file version. The value is a legitimate version number as described in the above spec.
• Created-By: Defines the version and the vendor of the Java implementation on top of which this manifest file is generated. This attribute is generated by the JAR tool.
• Signature-Version: Defines the signature version of the JAR file. The value should be a valid version number string.
• Class-Path: The value of this attribute specifies the relative URLs of the extensions or libraries that this application or extension needs. URLs are separated by one or more spaces. The application or extension class loader uses the value of this attribute to construct its internal search path.
• Main-Class: This is used for stand-alone applications. The value of this attribute defines the relative path of the main application class, which the launcher will load at startup time. The value must not have the .class extension appended to the class name. If you have specified this attribute, the JAR file becomes executable, and an application will be automatically launched by the command java -jar x.jar.
• Sealed: This attribute defines whether this JAR file is sealed. The value can be either true or false and case is ignored. When the JAR file is sealed, an optional package can enforce consistency within a particular version. A package sealed within a JAR specifies that all classes defined in that package must originate from the same JAR; otherwise, a SecurityException is thrown. For example, this code:

Name: javax/servlet/internal/

Sealed: true

specifies that the javax.servlet.internal package is sealed and that all classes in that package must be loaded from the same JAR file. To find out about optional packages, look at the extension mechanism.

Signed JAR file

Any JAR file can be signed by using the command line jarsigner tool or directly through the java.security API. By signing the file, you can ensure that nobody has changed the contents of a JAR and that you are using the JAR file from a well-known producer. Every file entry, including non-signature related files in the META-INF directory, will be signed if the JAR file is signed by the jarsigner tool. The signature-related files are:

• META-INF/MANIFEST.MF
• META-INF/*.SF
• META-INF/*.DSA
• META-INF/*.RSA
• META-INF/SIG-*

Each signer is represented by a signature file with extension .SF. The major part of the file is similar to the manifest file. It consists of a main section, which includes information supplied by the signer but not specific to any particular JAR file entry. The main section entry, x-Digest-Manifest-Main-Attributes (where x is a digest algorithm), contains the digest value for the main attributes of the manifest.

To validate a file, a digest value in the signature file is compared against a digest calculated against the corresponding entry in the manifest file. Then, a digest value in the manifest file is compared against a digest calculated against the actual data referenced in the "Name:" attribute, which specifies either a relative file path or URL.

For example, this is a manifest file for a signed JAR:

Manifest-Version: 1.0

Created-By: 1.3 (Sun Microsystems, Inc)


Name: common/class1.class

MD5-Digest: (base64 representation of MD5 digest)


Name: common/class2.class

MD5-Digest: (base64 representation of MD5 digest)

SHA-Digest: (base64 representation of SHA digest)

This is the corresponding signature:

Signature-Version: 1.0

MD5-Digest-Manifest-Main-Attributes: (base64 representation of MD5 digest)


Name: common/class1.class

MD5-Digest: (base64 representation of MD5 digest)


Name: common/class2.class

MD5-Digest: (base64 representation of MD5 digest)

A digital signature is a signed version of the .SF signature file. These are binary files that are not intended to be interpreted by humans. Digital signature files have the same filenames as the .SF files but different extensions. The extension varies depending on the type of digital signature and is generally either RSA or DSA.

JAR Index

JAR Index (often referred to as the JarIndex mechanism) was introduced to optimize the class searching process of class loaders for network applications, especially applets. The JarIndex mechanism collects the contents of all the JAR files defined in an applet and stores the information in an index file in the first JAR file on the applet's class path. After the first JAR file is downloaded, the applet class loader will use the collected content information for efficient downloading of JAR files.

The existing JAR tool is enhanced to be able to examine a list of JAR files and generate directory information as to which classes and resources reside in which JAR file. This directory information is stored in a simple text file named INDEX.LIST in the META-INF directory of the root JAR file. When the classloader loads the root JAR file, it reads the INDEX.LIST file and uses it to construct a hash table of mappings from file and package names to lists of JAR file names. In order to find a class or a resource, the class loader queries the hashtable to find the proper JAR file and then downloads it if necessary.

Service providing

Files in the META-INF/services directory are service provider configuration files. A service is a well-known set of interfaces and (usually abstract) classes. A service provider is a specific implementation of a service. The classes in a provider typically implement the interfaces and inherit the classes defined in the service itself.

A service provider identifies itself by placing a provider-configuration file in the resource directory META-INF/services. The file's name should consist of the fully-qualified name of the abstract service class.

Using the features

Now that you see what you can do with the features of the JAR files, it's up to you to put them to practical and creative uses in your development work. If you have used JAR files in some interesting ways, please share your experiences in the article discussion.

Write a resume that will land you a programming job..PART 3

Watch your formatting

While technical pros’ resumes do not need to be pretty, formatting can make a huge difference in a resume’s readability. If you cannot put three pages of text in front of me in a readable form, do I really want you touching the UI or writing code that someone else might have to maintain?

I recommend that you stick to a larger font size (e.g., 10 - 12 pt.) in a font that reads well onscreen and in print (e.g., Verdana, Arial, Tahoma, Calibri, Helvetica). If you want a slightly fancier font, use it only for section headers. Also, do not mix Serif and Sans Serif fonts — that is just ugly. Do not use “Comic Sans” anywhere, especially in hot pink or baby blue (and yes, unfortunately, this needs to be stated). Keep your margins and space between paragraphs large enough to provide the reader some “breathing room.”

Employment history

I give applicants some slack on employment history. For instance, five year stints are fairly rare in IT, and I give anyone a lot of leeway if their history includes anything that occurred during the dot com boom/bust.

If you are (or were) a contractor or consultant, make sure that is clearly stated; otherwise, I will think that you get fired and/or quit every 3 - 12 months. If you were not a contractor or a consultant, and it looks like you have a hard time staying at a job, I am going to be very cautious. If I see an increasing progression of job titles, “mercenary” pops into my head. Also, if I see that they are lateral (or worse, negative) moves, “bad apple” is my first thought. Of course, sometimes you get hit with a string of employers that go under or get acquired — it happens to the best of us. If that is the case, find a way to convey that information so I don’t think you are unemployable.

Spelling and grammar

It is critical that the spelling and grammar in your resume is flawless. I have seen applicants misspell the name of their state and the name of their school. If grammar and spelling are not your forte, ask someone to look over your resume for you. While I understand that many IT pros are not native English language speakers (or are English language speakers who paid little attention to those subjects in school), you should still ask someone for help. In fact, knowing when to ask for help is a hallmark of the best developers. If I interview you and realize from your speech that you had the sense and humility to ask someone for help on your resume, I am going to be truly impressed. (For examples of what not to do, check out this list of real-life resume blunders.)

Stay out of EEO (Equal Employment Opportunity) territory

In the United States, companies with more than 10 employees need to follow EEO rules. These rules state that an employer cannot discriminate against or show preference for an employee based on certain group membership items or personal lifestyle issues, such as gender, age, ethnicity, nation of origin, religion, sexual orientation, and so on. So, do me a favor and try to not expose any EEO-related information to me on the resume. In a face-to-face interview or even a phone interview, some of it will be unavoidable. But I will never solicit that information. Not only do I want to keep my employer and myself out of trouble, but I personally feel that EEO is important. I can understand that many names (or even college attended) are strongly correlated with ethnicity, religion, or nation (or at least general geographic region) of origin, and college graduation or attendance dates give some age clues. Minimize this as much as possible. Please do not tell me about your church, your family situation, your home life, your parents, and so on. It is not that I am not interested — I would probably love to learn these things about you if we hire you — but I do not need or want to know them before that you come on board.

Outside interests, hobbies, achievements, and activities

I like to see these, but only if they are relevant. I really do not need to know about how big of a fan you are of the New York Knicks; but if you wrote a piece of software that can do something nifty with the team’s statistics for fun, I would love to know about it. People who contribute to open source projects get a huge gold star in my book, but only if I feel like they would be comfortable working on proprietary software with proprietary tools, and not bringing anything GPL’ed into my codebase. That is a small caveat there. “Contributed to project XYZ in the areas of ABC and DEF” is enough to whet my appetite. Show me some outside learning too — don’t let me think that you get home at 6;00 and shut off your brain. If this work is not interesting enough for you to read about or experiment with on your own time, why would I think that you will be engaged or even interested in the job we would hire you for?

Gracefully show your inner geek

Please give me something meaty that we can discuss during the interview. So, where it is relevant, try to show me how much of a nerd you are.

For instance, try to mention the hovercraft you made from an inner tube and a lawn mower engine. Make note of the iterative, evolutionary game theory system you coded in Lisp that proves that Nash’s equilibrium is dead wrong. Tell me something about your three chess championship victories. I do not want to know that you memorized UHF or that you have a pocket protectors collection that have logos of now defunct minicomputer vendors.

I know most of this falls under the previous section, but it is relevant. I love to work with programmers who love technology and logic and using their brains. People like that are simply better programmers. Why would I want to hire someone who is intellectually lazy for an intellectually challenging job?

Obscure or nonmainstream technologies

I am not hiring Lisp, Prolog, Erlang, APL, Scheme, Clipper, PowerBuilder, Delphi, Pascal, Perl, Ruby, Python (forgive me for including those four in this list), Fortran, Ada, Algol, PL/1, OCaml, F#, Spec#, Smalltalk, Logo, StarLogo, Haskell, ML, D, Cobra, B, or even COBOL (which is fairly mainstream) developers. If you show these on your resume, I will want to interview you just for the sake of slipping in a few questions about these items. I am serious. As part of my secret geekiness, I am really into obscure and almost obscure languages and technologies. I know that a lot of those items take better-than-industry-average intellect and experience to do; they also provide a set of experiences that gives their practitioners a great angle on problems. While you will never directly use those skills in my shop, you will be using those ways of thinking, and it will give us something to talk about on your first day.

(Aside: A coworker was shocked to learn that I played Half Life. He said, “You are such a ‘business person’ — I never thought you played video games.” I guess I’m camouflaging my secret geekiness too well!)

Good luck

I’ve given away crown jewels here. In my perspective, these tips will help any programmer write a perfect resume and get them an interview.

What do you think gets applicants an interview? If you read resumes as either a hiring manager, a recruiter, or an HR employee, what makes you say “wow!” or “ugh!” when you see it on paper?

source @TechRepublic

Write a resume that will land you a programming job..PART 2

Show me that you are different

Even if my project is a run-of-the-mill Web-based, data driven application (which it is not), I still want to see that you are more than someone with 10 years of experience writing run-of-the-mill Web-based, data driven applications. For example, compare these two items:

BORING!
East Coast Power - Programmer 1999 - 2005

* Wrote VB applications to control machinery. The hardware interface was handled in a COM library that was written by another team. Application was robust and reliable.
* Wrote Web-based tool to track system faults.
* Created Web service to allow partners to consume portions of the database.

WOW!
East Coast Power - Programmer 1999 - 2005

* Wrote VB applications to control nuclear reactor. Real-time control and monitoring of systems handling 10,000 unique data inputs per second.
* Wrote advanced algorithms in C# to detect imminent system failure, which were used within a Web-based application.
* Created Web service in C# to allow partners to access data in a secure, reliable, and responsive manner; typical data set was 1,000,000 rows and concurrency challenges needed to be overcome at the database and application layers.

See the difference? Control machinery does not help me much – you could have been working on the elevator system for all I know. Programming a nuclear reactor impresses me, especially since there has not been any nuclear reactor disasters during your employment. Writing advanced algorithms in C# touches my engineer’s heart; whereas writing a mere Web-based tool is ho hum. And, while writing a Web service is fairly simple, particularly in ASP.Net, it’s not so easy to write one that is “secure, reliable, and responsive” with that size of a data set. It’s also not easy to deal with concurrency issues at two different levels.

I am not saying that it needs to be wordy or full of minute details, but if you are doing work beyond what a summer intern could do, I need to know about it. Every developer has written a Web-based, data driven application. Show me more.

Make sure that your experience highlights your skills

I don’t expect your employment history to include a list of all your skills. But if you are looking for work as a .Net developer, show me that you have done some .Net work. If you do not list that experience, I am going to assume that you have little or no experience with it — even if it is on your skill list. If you have large amounts of experience outside of the workforce, find a way to show that on your resume.

Keep your resume between two to four pages long

I have struggled through seven-page resumes filled with jargon and boring details that made me want to cry. An overly long resume doesn’t necessarily make me rule out a candidate, but why make it hard on me?

On the other hand, a resume that tries to stick to the one page rule is not going to cut it for a technical person unless they are new to the field. In my experience, two to four pages is just right. Also, please use some whitespace, so I do not feel like I am drowning.
continued...

Write a resume that will land you a programming job..PART 1

I usually read 5 - 20 resumes each week. Both my boss and I are extremely busy, so it’s important that a programmer’s resume grab our attention quickly by providing the right mix of necessary information with something that makes that person stand out from the pack.

I’ve been involved with our hiring process for more than six months, so I feel fairly confident that I can distill what it takes for a programming resume to get me to say, “Let’s arrange an interview.” Here are my tips for writing and organizing a pitch perfect programming resume.

Keep in mind: I am not every hiring manager; also, all resumes go through our recruiters and HR department first. Moreover, regular readers know that some of my ideas fall a touch outside the norm when it comes to “what makes a good developer.”

Put your skills front and center

Reading the in-depth details of how you used mainstream skill XYZ to accomplish typical task ABC is not at the top of my agenda. I want to see your skills up front, so I don’t need to go trolling through your resume to see if you meet my minimum needs.

Skip the summary and maybe even the objective

Those summaries are a waste of my time. It is going to say something like “seasoned IT pro with great communication skills” or “proven veteran with 10 years of programming experience.” How do I know this? Because they all say this. Skip it, please.

The objective is a slightly different story; it is useful only if it informs the interviewer about something that the skills and experience does not. The objective’s relevance to me is largely a function of whether you wish to keep doing what you have been doing. If I see you have been programming — particularly at the data access layer and the business object layer — and there is no objective, I am going to assume that you are looking for more of the same with a different employer or location. If you want to do more of that work and put an objective, you are wasting space. If you are looking for a change of pace — like getting more into the presentation layer or heading towards a management track — it’s important to state that in your resume. Otherwise, we may discover during the interview that you are not interested in what we have to offer.

List your education last

Some IT hiring managers put a huge emphasis on certain educations but I do not. I always want you to list your school and your major, but I will only ask you about your education if there is something unusual or intriguing.

For instance, a candidate with a Computer Science degree from MIT or with a PhD in Organic Chemistry will draw my eye because these degrees show a level of high intelligence. On the flipside, an AA in basket weaving or a lack of a degree will not count against you.

In most cases, I am not even curious about your education until I have already made up my mind. This includes certifications — MCSEs and CCNAs do not impress me that much at this point. They matter to some folks, and they do not hurt you in my opinion, but I will only take that certification into account if all else is equal.

continued...

Sun says farewell to mobile Java

According to James Gosling, often called the father of Java, the Java Micro Edition (ME) will gradually supplanted by the Java Standard Edition (SE). He said, “We’re trying to converge everything to the Java SE specification. Cell phones and TV set-top boxes are growing up.”

The idea is that mobile devices are packing ever increasing amount of processing power - enough to handle all the demands of full-featured Java.

Excerpt from News.com:

Sun’s Java expectation dovetails with recent trends, most notably Apple’s iPhone, which architecturally is much more an Apple computer writ small than a mobile phone writ large. In particular, Apple uses a version of its regular Safari Web browser so users will have as much of the desktop Internet experience as possible.

To be clear, the move to Java SE won’t be happening overnight. Smart phones using various pared-down versions of Java is expected to stay in the market for at least a decade. But the shift is already under way.

courtesy @TechRepublic