Oleg Dulin

Helping you help me help you help me

I am not particularly religious, but I do believe in the constant amount of good in the universe.

In 2000 I got a job at a Web services consulting firm straight out of college and about 3-4 months into it realized that I am in the wrong place at the wrong time. I was working 12 hour days. My manager quit. The new manager didn't know what to do with me. It was a disaster.

One crisp October day I decided to go for a walk and in the elevator of my building I bumped into a college classmate of mine whom I haven't seen in years because he transferred out during his sophomore year. He told me he was working for an EAI startup and that they were hiring Java developers. He referred me to his manager and within days I had a new more exciting and higher paying job.

Perhaps that experience was normal, but I was so impressed with my friend's generosity that I decided that the universe must remain in balance and I have to help someone else. In 2000 a lot of my friends were having difficulties finding jobs and as soon as a position opened up in my startup I referred one.

When my dot-com closed its shutters in 2001 I got in touch with someone I worked with before who referred me to a consulting gig at a large bank. Within a month I helped my dot-com coworkers come work for this bank as well.

To make the long story short, in the 12-14 years of my career I was never hired through a recruiter. It was always through referals. I don't ask for referal fees because I don't like closing the transaction -- I value networking more than the referal fee. I was refered to jobs and I refered friends to jobs. Most of the time it worked to my advantage. I still refer and would do it again.

If there is one thing that I learned from the past 10 years it is that things you do come back to bite you or help you. If you help others in times of need they are more likely to help you in the future. It is all about give and take. If all you do is take then next time there will be nobody to help you.

Do AWT threads exist in a headless application ?

Consider this simple program:

public class ThreadTest
{
    public static void main(String[] args)
    {
       while(true)
      {
         try
        {
            Thread.sleep(10000);
        }
         catch (InterruptedException e)
        {
        }
     }
   }
}

What is the number of threads when this application starts ? In particular, is the Swing thread available at all times ? To find out I placed a breakpoint on the sleep line and ran it inside of the Eclipse debugger. There were 5 threads:

ThreadTest at localhost:3078	
	Daemon System Thread [Attach Listener] (Running)	
	Daemon System Thread [Signal Dispatcher] (Running)	
	Daemon System Thread [Finalizer] (Running)	
	Daemon System Thread [Reference Handler] (Running)	
	Thread [main] (Suspended (breakpoint at line 15 in ThreadTest))	
		ThreadTest.main(java.lang.String[]) line: 15	

To confirm this I ran it outside of the debugger and attached to the process with a jconsole. I observed the same plus a couple of JMX threads due to the jconsole connection. The key here is that there is no GUI thread at all. Now, lets try this code:

public static void main(String[] args)
	{
		while(true)
		{
			try
			{
				SwingUtilities.invokeLater(new Runnable()
				{
					public void run()
					{
						System.out.println("Hello");
					}
				});
				Thread.sleep(1000);
			}
			catch (InterruptedException e)
			{
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
			
		}

	}

In this case there are at least 8 threads:

ThreadTest at localhost:3144	
	Daemon System Thread [Attach Listener] (Running)	
	Daemon System Thread [Signal Dispatcher] (Running)	
	Daemon System Thread [Finalizer] (Running)	
	Daemon System Thread [Reference Handler] (Running)	
	Thread [main] (Running)	
	Daemon System Thread [Java2D Disposer] (Running)	
	Daemon Thread [AWT-Windows] (Running)	
	Thread [AWT-Shutdown] (Running)	

Conclusion: Swing threads are only created when you use Swing.

Simple ANT interview question

Consider the following ANT script:

<project default="all">
    <target name="C">
        <echo message="C" />
    </target>   
    <target name="A" depends="C">
        <echo message="A" />
    </target>
    <target name="B" depends="A,C">
           <echo message="B" />
        </target>
    <target name="all" depends="A,B,C" />
</project>

What is the order of messages echoed to the console ?

Joel Spolsky: Why great developers are never on the market

I disagree with Joel Spolsky. In his post on why great people are never on the job market he states:

The corollary of that rule—the rule that the great people are never on the market—is that the bad people—the seriously unqualified—are on the market quite a lot. They get fired all the time, because they can’t do their job. Their companies fail—sometimes because any company that would hire them would probably also hire a lot of unqualified programmers, so it all adds up to failure—but sometimes because they actually are so unqualified that they ruined the company. Yep, it happens.

It is true that organizations that fail do so largely because they keep hiring incompetent buffoons. However, calling developers incompetent because they were unfortunate enough to end up in a mismanaged company puts way too much responsibility on the technologists.

A bright developer may get lured into a mismanaged company by an interesting project just to find that project canceled a few months later and the whole team laid off. A bright developer may choose to work with his friends on a startup, then sell the company and move on to other things. He may also choose to work in consulting and go from a gig to a gig every few months.

Joel statement applies more to managers than it does to developers. Great managers are never on the market. They manage their projects well and their companies are profitable and successful. Bad managers don't manage their projects well and end up driving their teams into the ground. Developers are just engineers and that's that. Most of them do what they are required to do to meet a perceived need, and most developers do it well. It is managers that fail.

As a general rule assume a multi-threaded environment

I suspect this post is going to be one of the first in a series of my criticisms of the Java interview book by K. Arulkumaran.

In the Java Fundamentals Question 15 he asks about the difference between ArrayList and a Vector, and HashMap and Hashtable, and stack and a queue. He then proceeds to ask which is better -- the thread safe version or not thread safe version.

Mr. Arulkumaran then offers an answer that would make the candidate fail an interview with me:

As a general rule, prefer ArrayList/HashMap to Vector/Hashtable. If your application is a multithreaded application and at least one of the threads either adds or deletes an entry into the collection then use new Java collections API's external synchronization facilitity [ed: Collections.synchronized* methods] to temporarily synchronize your collections as needed.

When I saw this I felt like calling up the author and saying "Wrong!"

Here is why. What makes the author so smart as to know that as a general rule his application won't be multithreaded ? What does it even mean to "temporarily synchronize" ? In the same book he talks about servlets, EJBs, RMI, messaging, etc. Application servers can take your presumably single threaded application and load-balance the heck out of it -- your single-threaded application may end up running across different CPUs, different network nodes, you name it.

My answer would be this -- as a general rule do not assume that your application will be single-threaded. In modern JVMs obtaining locks is so cheap that it makes it insignificant. Assuming single-threaded execution is dangerous and will make it extremely difficult to scale your application. Most developers have such a mediocre grasp of the overall big picture of the system that giving them the freedom to default to unsynchronized code is just plainly irresponsible.

This is just one of the many inconsistencies in this book. Good book if you want something to yell about on your blog -- bad book if you want to use it as a guide to get a job or to hire a candidate.

"Java Concurrency in Practice" by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea

I read this book cover to cover and consider it an essential part of a Wall St. software engineer's library. In an environment where transactions need to happen in nanoseconds with 100% reliability proper understanding of concurrency is a must.

Amazon.com: Java Concurrency in Practice: Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea: Books.

"Java/J2EE Job Interview Companion - 400+ Questions & Answers" by Arulkumaran Kumaraswamipillai, Sivayini Arulkumaran

You don't necessarily have to be looking for a new job to find this book valuable. Even in your present job it will help you find out what you need to brush up on to stay ahead of the game. It does cover a lot of material and is a good book to keep handy.

I do have two issues with it though -- one is that many of the answers are written in a way that the author would respond if asked, not necessarily what is an accepted industry standard (* As I read this book I am going to post specific examples one at a time). Second is that it is pretty clear from this self-published Lulu book that English is not the authors' first language.

Otherwise, this is the only book out there of this kind that covers this much material.

Java/J2EE Job Interview Companion - 400+ Questions & Answers by Arulkumaran Kumaraswamipillai, Sivayini Arulkumaran (Book) in Computers & Internet.

UPDATE1: The more I read it the more I have to warn you -- do not rely on this book as your sole source of interview preparation material! There are nuances you may be asked that are not covered in the book which is going to make you look like a fool. This book is only useful as a rough guide of what to expect.

UPDATE2: This guide is not going to get you a management or a chief architect job. At best it is a good guide to get you through your first 5 years out of college.

Fixes are more important than problems

"The Accidental IT Leader" blog writes that it is a response to a mistake that's important, not the mistake itself. I made my share of serious errors while working on mission-critical projects. However, I've done the following:

• Immediately took responsibility for my actions and stepped up to the plate
• Identified the reason the errors were made and came up with an action plan
• Developed a solution to drive manual errors down to zero

The lessons I learned from my past mistakes are:

• The more mission critical work you do the more likely you are to screw up
• If you never screw up then you probably aren't doing anything important
• It is one's response to the screw up that matters

IT Employee Motivation: Fixes Are More Important Than Problems | The Accidental IT Leader.

Design patterns and theoretical models are not meant to be taken literally

Last time (not recently, I am happilly employed now) I was looking for a new job I was asked this question at an interview:

What is better - a singleton or a class with static methods and why ?

A singleton with a controlled access to its constructor and a static getInstance() method is the way to go unless you are writing a one-off utility class that you know 100% will never need to be extended.

The reason for this is that "static" in Java prevents you from taking advantage of inheritance and just about any other object-oriented features of the language. A singleton with a controlled factory method for obtaining its instance (getInstance typically) lets you extend the component in the future. For example:

• Turning singleton into a managed pool of objects
• Converting a local component into a remote service

And here is the sticking point that I mentioned to the interviewer just for the sake of argument -- I don't buy the viewpoint that there has to be a strictly one instance of a singleton. Yes, singleton by definition only has one instance. However, if you are going to argue that a singleton has to only have one instance of itself then why not try and argue that all computers should have an infinite tape with a reader head that moves left and right reading one character at a time ?

There are plenty of singletons in Java that are logically one instance but the container may manage multiple instances of them. For example, Java servlets, stateless session EJBs, remote RMI objects, etc. -- these are all technically singletons but may exist as multiple instances. Why ? Well, in a client-server environment you may have a cluster of servers each having an instance of the EJB. Even on an SMP box it may be more efficient to have one instance of a singleton per each thread instead of just a single one.

When I described this viewpoint to the interviewer he appeared shocked and told my recruiter that I am not "technical" enough. The interviewer told the recruiter that I don't know how computers work because I thought that they have a tape for memory and reader head for the CPU and that I don't know what a singleton is. That was for the better, because I was shocked at the lack of inquisitiveness and independent thought on his behalf. On my part, I told the recruiter that I didn't find the environment at this company intellectually stimulating enough for me.

There are two morals to this story.

One is that design patterns are not necessarily hard rules to follow. Sometimes you need to express some independent thought and stop being a code monkey.

The second moral is that if push comes to shove and I am desperate to find a new job I may have to swallow my pride and play along with the office drone on the side of the desk during an interview. Sometimes people are just too literal with theoretical models.

P.S.: If you don't know the reference I made when I described the infinite tape and a reader head here is a tip --  Google for "turing machine." If you are a software engineer and you don't know theoretical models of computation you probably should go back to school or get out of the field completely.

What motivates me

I am off for a week to spend Passover with my family. While my wife is buying groceries this morning I spent a couple of hours outside watching our 2.5 year old daughter playing with her play set in our backyard. That got me thinking of what motivates me to succeed in my career:

• My family. Doing my best to secure opportunities to our American-born daughter that our immigrant parents couldn't offer to us. Teaching her the freedoms and responsibilities that come with living in a free society and making sure she doesn't forget her roots.
• A job where I get to own and take responsibility of a chunk of the product. 
• Being recognized at work for my talent, passion for technology and experience.
• Working hard each day to finish my work on time and with quality so I don't miss our family dinner and my daughter's bed time.
• An opportunity to make my project better.
• Feeling that I have contributed something useful to my employer or customer.