Sunday, June 13, 2010

i want to care, but i don't

I'm back to "why bother" mode at work. I'm finding it difficult to get into work by 9, and to convince myself to stay beyond 5. And it's not like I have anything compelling to distract me. Before heading to work, I'll be surfing the internet, maybe reading blogs or discussion boards. When I get home, I'll do some exercise, surf the internet, catch some Netflix.

A few months ago, there were a few precious days when I was working on an issue which had strongly grabbed my attention. I was so obsessed that I came back to work after leaving for the day, and stayed till after midnight to work on it. I hadn't felt so good since I was in grad school. At that time, every minute of every day felt like effort I was expending on myself, on something that was important to me, personally.

This meshes up with an RSA Animate video that I viewed recently. The animation was made to accompany a talk by Dan Pink about how (according to some study) money is an insufficient motivator, except for workers doing very mechanical, non-creative tasks (I'm glossing over the details, but that's the gist of it).

Yeah, I get that. I still need to work for a living, and in a job hunt, I'm going to pick the highest paid job I can find, so money motivates to a certain extent. But will I do the best I possibly can at that job, giving it my heart and soul, like I did when I was a grad student? Most of the time, the answer is no. Because I fundamentally don't care about what I'm doing. I know that companies buy the software that I'm working on, so it's obviously valuable to them. But I see no value in the product (in fact I kind of hate it).

In addition to that, I've lost the feeling of "tribe" that I felt I had in grad school. At that time, I felt like I was part of a cohort with similar lofty goals: contributing to science, discovering new things. I'm a cohort of one where I work now. There isn't a sense of trust. People look at you sideways if you say the wrong thing, and you never know exactly what will sound wrong, so you don't say much at all. Ask for help? If you do that, you're "bothering" people, acting like some junior newbie.

And despite all that, my current job is really not so bad. My coworkers are fine people. There's just something missing. I should probably leave, to look for that sense of team elsewhere. But I kind of wonder if it exists. If it does, it's probably so rare that it would be very difficult to find. Maybe my best bet is to just keep saving till I can be done with working for a living.

Friday, May 7, 2010

java is verbose

a mountain of code is the worst thing that can befall a person, a team, a company - Steve Yegge
So, is Java verbose? I hadn't considered it before reading Steve Yegge's post. And I didn't really get it, initially. But I've been looking at my code differently since then. Recently I ran across another example.

I wanted to write a switch-case statement for about 10 different String possibilities. Last time I checked, you couldn't do this, but I hunted around to be sure. It turns out that you will be able to do this in Java 7. But I couldn't do it now.

One alternative is to use numerous if-then-else lines to sort through the possibilities. I much prefer switch-case; I find it cleaner and easier to read.

If I wanted to stick with switch-case for this example, I could go with one of several workarounds, all of which produce excessive code which ideally should be hidden from view. Probably the most "proper" way of doing this would be to create an enum listing all the constants. Talk about extra code just to make a decision based on a String value!

In the end I went with if-then-else. Ho-hum.

Thursday, April 29, 2010

do women get paid less because they're nicer?

That's what Nancy Folbre wonders in a recent NY Times blog post about supersized executive compensation. She says:
Some personality traits — like conscientiousness — are likely to increase productivity. But other traits, including Machiavellianism and aggressiveness, can increase earnings via a more direct route. They can increase both efforts to demand higher pay and propensity to lie, cheat and steal.

Men score significantly higher than women on Machiavellianism and aggressiveness, which may help explain why 15 times as many men as women were in prison in 2008.
I've wondered if women tend to get paid less because, on average, they're less self-centered, egotistical, and more realistic, than men. If you look at your salary and always think you're underpaid, you'll constantly engage in behaviors that seek to raise your pay, and some of those will be successful, whether or not you "deserve" it. I think men tend to do that more than women. I emphasize that I'm talking about averages. If only a small fraction of men behave this way more than women do, it could skew salaries in favor of men quite a lot. To be fair, I've known men who, to my knowledge, took no active steps to increase their salary, since they felt like they were paid plenty as is.

I suspect a lot of this has to do with the way that men in our society are still expected to be the main breadwinners in a family. A man with a family to support is probably more driven to get higher pay than a women who brings in secondary income. Also, I suspect that bosses are more likely to give male heads of households higher salaries because, in the back of their minds, they think that he "needs" it more. I wish I had some statistics to compare the salaries of single men with married men.

Friday, March 26, 2010

anonymous blogging is difficult

I started this blog because I had a bunch of things to talk about, and also things that I wanted to read about, which I couldn't find out there.

However, I'm finding it hard to blog. I keep getting the feeling that if I mention some specific incident, somehow, someone at work will read the post and recognize me. I know it's unlikely, but it's still an uneasy feeling.

Tuesday, December 22, 2009

Java inner class peculiarity

I recently ran across an obscure Java factoid that will probably never come in handy. I found it when researching PMD rules.

Suppose I have an inner class as follows:

1 package com.examples;

3 public class Outer {

5   public void test() {
6     Inner ic = new Inner();
7   }

9   public class Inner {
10     private Inner() {
11     }
12   }
13 }


Even though the constructor for the inner class Inner is private, a package-access constructor is created by the compiler as a side-effect when you call the private constructor at line 6 in the test method.

There are a couple of ways to verify this. First, you can just look at the generated class file Outer$Inner.class. You'll find two lines, one for the private constructor that you have written, and another which is a "synthetic"* constructor:

..
private Outer$Inner(com.examples.Outer arg0);
..
synthetic Outer$Inner(com.examples.Outer arg0, com.examples.Outer.Inner arg1);


If you are not convinced, you can run through the constructors using reflection, as shown in this example class:

1 package com.examples;
2 import java.lang.reflect.*;

4 public class InnerTester {
5   public static void main(String[] args) throws ClassNotFoundException {
6     InnerTester.printConstructors("com.examples.Outer$Inner");
7   }
8   public static void printConstructors(String str) throws ClassNotFoundException {
9      Class c = Class.forName(str);
10     Constructor[] cs = c.getDeclaredConstructors();
11     for (int i = 0; i < cs.length; i++) {
12       System.out.println(cs[i].toString());
13     }
14   }
15}

Running this program produces two lines of output:

com.examples.Outer$Inner(com.examples.Outer,com.examples.Outer$Inner)
private com.examples.Outer$Inner(com.examples.Outer)


If you comment out line 6 in Outer.java and recompile it, the output of this program is just one line:

private com.examples.Outer$Inner(com.examples.Outer)


You can look at the class file, Outer$Inner.class, and check that the package access constructor is gone, there, too.

There's a rule warning against calling a private constructor of an inner class like this, because the constructor is effectively given package access. PMD suggests using a factory method instead of creating the instance directly in the outer class, or just making the constructor public, to solve the problem.

I can't imagine any situation in which this would be a problem unless you're using reflection to call constructors.


* The Sun tutorial on Java reflection has a brief discussion of synthetic (compiler-generated) constructors.

Sunday, December 20, 2009

classes that override equals should override hashCode

I was talking to a developer the other day who admitted to me that he had only recently found out that in Java, if you override the Object equals method, you should override the hashCode method also. He had been introduced to this practice by a checkstyle rule.

This surprised me for a couple of reasons. This developer is not a newcomer to Java, and it's the kind of thing I'd expect an experienced developer to know. I know about it myself from my first forays into Java. It's documented in the API for Object:
Note that it is generally necessary to override the hashCode method whenever this method [equals] is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

But I suppose it's the kind of thing you might miss learning if you come into Java from another object-oriented language, and don't do a thorough job of learning the peculiarities of Java.

The other thing that surprised me was the fact that he admitted it at all. Developers rarely confess to ignorance. I guess that admitting a weakness is just too dangerous in this highly competitive field. I tend to be pretty open about my own gaps in knowledge, but I suspect it doesn't help me any, and in some cases it may hurt. Have you ever said "gee I didn't know X" and gotten a snooty look down the nose from someone? Not the kind of experience you want to repeat!

Friday, December 11, 2009

debugging tools

I recently talked to a developer who admitted that he preferred using print statements to debug than any of the newer debugging tools, like what's available in Eclipse. This is the kind of statement that would probably knock my socks off if it weren't for the fact that almost nothing surprises me anymore!

I disagreed, but didn't argue it with him. Print statements are the worst, last option, in my world. There are just a few times when they are appropriate - for example, if you want to grep through values in a large loop. And of course in some cases print statements are the only option (on a production machine, for example).

But really, who doesn't just love a debugger? It's useful for 99% of the problems I have to solve.