Austen.Ito.Blog

Over the past couple weeks, I was getting interviewed by Aaron. This was the first time I have been interviewed outside of a job setting. After going through the process, I think that interviews are a good way of thinking about where you are in your career, what you need to improve on, and what you should strive for. The interview process is a lot like revisiting your resume every six months(which I still have not gotten around to doing). Here are some observations I had about getting interviewed:

1. Having extra time to gather your thoughts for an answer is a great exercise. Every question that Aaron asked required me to stop and think about an answer that expressed how I feel. It also made re-evaluate my reasoning behind my answers. I was happy to find that I couldn't find answers to some of his questions because I now have a concrete starting point to think about where I want to go.
2. The interview questions should be focused on a certain area of be effective. In Aaron's interview, he asked me how I got started, what I like about developing software now, and where I want to do later. I liked how he made me think about several aspects in my career. If he didn't ask me the right questions, I wouldn't be thinking about the right things.
   
3. Using back-and-forth emails to interview a person is better than I thought. I originally thought it would be better to just send one email with a whole bunch of questions. After doing this interview, where I spent long periods of time just thinking of an answer, I was glad that each email only had one question. It felt like I was accomplishing something and I didn't half-ass the end portion of the interview.
4. Self-introspection is fun! You get to learn about yourself. It's interesting when you learn new things about someone you should know the best.
   

I definitely recommend getting interviewed. It was a great experience that I want to have again in the near future. It is actually very easy to get interviewed. Just ask a friend, neighbor, colleague to think of themselves at a bar having a few drinks with you. After everyone is feeling good, fire away with the questions. Its a relaxed atmosphere with absolutely no pressure. All upside, no downside. Anyone want to get interviewed by me?

Tonight I tried a little experiment that involved a martini and some code. I have read and heard about the glorious effects of alcohol on the ability to think differently while hacking. Alcohol supposedly can provide you with some "liquid creativity". Much like the "liquid confidence" we are all familiar with, especially at those late night karaoke parties. Thinking outside the box can be yours when you grab some booze and start hacking. All ready to be ultra productive, I had some of my drink and started coding. Here is what I thought would happen:

"Hey I see what this code is doing! Let's try something new. Why not. What else do I have to lose. Code code code hack hack hack. This is great! I should drink and code at work!"

Here is what really happened:

"Oh god I just deleted all of the class again. CTRL + Z. Grrrr why can't I type correctly. Why doesn't this work???? I totally wrote a unit test and now its failing. I didn't type anything. CTRL + Z AGAIN. What was that class called again? Search search search fix typo fix typo backspace backspeace aldkasjfasdlfjlasdfsf"

This was after half a martini. I'm a lightweight drinker, but this was ridiculous. My motor skills were not kicking in tonight when I was trying to code. Even when I had to figure out why something was working, I felt no difference in my ability to debug. I actually got more frustrated cause it didn't make sense. My thinking was just clouded from the alcohol.

Worst hacking experience. ever.

(You Hackystat hackers out there know I tried doing this the day before our we get ready for the public release. It's ok. Unit tests pass. Woohoo!)

After a week long hiatus, I finally got back into Hackystat hacking. I re-started my work on the Commit Daily Project Data Analysis Service. After some initial startup lag (getting a drink, listening to some easy hacking music radio, etc) I was ready to whip out some code and get it done. Or so I thought. I had no idea where to begin. I only had 3 classes, but I still was lost. What was I working on a week ago? Does everything work or do I need to debug? Oh man this is going to be a long night...

Then I remembered that I wrote unit tests as I was coding. I did a quick ALT+SHIFT+X+T and saw the little green bar appear in eclipse. (I'm running unit tests with a keyboard shortcut for those of you who don't use eclipse) Hooray, it seems that everything I did in that class is functional. I did this for the remaining two classes and was able to figure out relatively quickly what I completed the previous week.

Writing unit tests while coding continues to amaze me with it's usefulness. I can add "restarting long forgotten work" to the existing list of unit test uses such as "debugging while I code" and "ensuring the correctness of my logic". I remember long ago that someone told me that unit tests help developers learn about the intent of someone's code. I guess this is a prime example of showing someone (me!) what the hell I did last week.

A while back Randy Cox made a comment on his blog about his teammate disliking JAXB:

"Another aspect of our differences is Brian's drive to build a high quality system from the start, while I tend to like to start with the basics and increase scope incrementally. Brian's strong dislike of JaxB, resulted in a lot of work on the Model to mitigate the JaxB limitations."


Curious about what the limitations of JAXB were, I made a comment on his blog. Sadly I was left out to dry on the matter and forgot about it for a month. This past week at work I revisited my JAXB code and figured out one JAXB limitation.

There is no easy to abstract JAXB auto-generated classes.

So what normally happens with JAXB is:

1. Create an XML schema
2. Run the XJC compiler, which creates the JAXB auto-generated classes.
3. Write the java code using the JAXB classes to marshall and unmarshall data.

The problem occurs when you have 2 JAXB objects that do similar things:

Apple Object Interface:
setName()
setColor()

Orange Object Interface:
setName()
setColor()

So now you have 2 classes that perform the same operations. You end having to write code specific to each object:

Apple apple = new Apple();
apple.setName("Ringo");
apple.setColor("Red");

Orange orange = new Orange();
orange.setName("Japanese name for an orange");
orange.setColor("Orange");

This is an excellent time to abstract their behaviors to enforce the DRY principle. Why don't we go ahead and create a 'Fruit' interface that abstracts the behavior of each object? Technically you can, but because the Apple and Orange classes are auto-generated, it isn't such a good idea to edit them directly. If you ever decide to change the XML schema, you will have to re-run the XJC compiler, which in turn will overwrite your changes. Another alternative is to wrap the JAXB objects in a wrapper class to provide a common interface. If the schema changes, the auto-generated class changes will be transparent to the wrapper's clients.

Although it is possible to provide common interfaces between the JAXB objects, there is no clean way to do it. Maybe there should be a way to specify behaviors of objects to the XJC compiler. That would remove the round-about way of abstracting the JAXB classes.

I'm sure that there even more limitations to the JAXB package, but currently it's benefits outweigh the drawbacks. XML parsing is fun again! (Well, more fun than manipulating the XML DOM tree directly)

Your resume, like your objective, should give me a sense of you and where you're going. I want to see a little ego and I want to see your character because I'm not hiring a flat piece of paper, I'm hiring a person.
- Rands in Repose, A Brief Glimpse


After reading Rands' article on how to write a good resume objective, I decided to take a look at my old resume. What I found is a crappy objective statement:

To bring my knowledge and experience from research on software engineering processes to the real world; to develop software for a world class software development company.

Wow. So I want to bring it to the real world huh? And a world class software development company aye? Would it make sense to put, "to develop software for a decent company." No wonder employer's eyes glaze over when they hit the first part of potential candidate’s resumes.

After some brainstorming, I worked out a preliminary objective:

I need to work in an environment that values developers over products. When this happens I can write software that is useful and will make a difference. As a software engineer, I work hard to write quality software.

This objective says that I want to work somewhere that doesn't impose crazy deadlines and micro-management to get software out the door. It says that I want to be someplace that gives software engineers interesting problems and turns them loose. If you want quality software, give me a problem and get out of my way. This statement definitely needs work, but I think it's a good start. I think it fits the situation of "sitting at a bar, having a couple drinks, talking about software with a friend."

I also took a look at the rest of my old resume. I think it's time to wipe the dust off and update it (Stay tuned for an update in another blog). I need to know where I am now, and where I want to go.

No direction + No Awareness = Career Death.

The ability to accept feedback from *anybody*. I find the best feedback comes in the "customer is always right" sense, where the intern is a "customer" of your design. If they feel like something is more complicated than it ought to be, there's a reasonable chance they are right, even though their identification of the "root problem" may be laughably wrong. And even if they are completely wrong and it really does have to be that complex, a humble designer should not immediately resort to "Because I said so", but should at least try to explain why.

- http://www.codinghorror.com/blog/archives/000051.html

With a new member on my team at work, I gave him a task to implement a new feature for an upcoming milestone. He was to use code that I wrote to implement a new feature. After spending some time learning how the code works, he came up to me and said, “Austen, isn’t there an easier way to do this?” After explaining to him the reason why things are they way they are, he trodded off and churn out more code. Once again he came back to me a bit later saying, “I’ve been using your API and here are the areas that I am having a problem with.” I wondered what was wrong. I had no problems using my own code. Once again I worked through the code with him and explained it in even more detailed. A bit frustrated, he went off to hack. We ended up talking about the code a short while later.

Looking back, I learned something valuable. I learned that I should be humble, rather than handling the situation by saying:

Stop bugging me. Use my API. It’s awesome.

After the second time he came confused, I should’ve stopped and said:

Hrm. I see you are back again. Is my code too complicated to be used by others? Let’s talk about why you are having problems.

The new member on my team because a “customer” of my design. He brought to light very large flaws in my original design. My code ended up being a lot more complex that it should have been. This was evident in the large amount of crazy complicated code required to implement the upcoming feature.

I believe that you don’t write code for yourself, you write it for others. After all, you should know the in’s and outs of your code since you wrote it. If you belonged to a one-person team, cowboyed it up, and wrote the next Mac OS, then you don't need to be clear about what you are doing. But if you are like the rest of the software world, your code will be read by your team. If you hide the intent of your code or don’t document what’s expected, your team will be confused. It's great that you know if you pass in a value of ‘42’ to your method, you find out the answer to the meaning of life. But if you don’t make it obvious, someone who has never read The Hitchhikers Guide to the Galaxy isn’t going to know what the hell you are talking about. If someone tells you “Hey your API sucks.” Maybe it does suck and you should stop and investigate. They are doing you a huge favor by helping you pin point the areas of suckiness. You should aim to please your customers. After all, they are always right.

On a side note, don’t be afraid to suck. Suck less every year.