Saturday, January 1, 2011

A smart plan

Just when I thought my goals for 2011 were set, I listened to the Smart Passive Income podcast. Pat Flynn talked about having SMART goals, that is specific, measurable, attainable, relevant, and time bound goals. After taking a look at what I wrote in my goals for 2011, I realize that I didn't really think though what I want to accomplish.

Learn Django
Learning Django is some vague goal that I might get done. Who knows when and how well I'll get I'll do it. So to make a realistic goal, I'll change my goal to run through the entire Writing your first Django app tutorial. If I want to continue along Django, I can add another goal to this list.

Improve my online presence
Vague goal #2. What? How am I going to improve my online presence? I just did a quick search on "Improving my online presence" and I see the same things:
  • write a blog
  • contribute to open source projects
  • participate in online help forums, i.e. Stack Overflow
I already have some technical goals in regards to open source projects and hacking, but blogging is once again a weak point. So how about I quantify my blogging? I want to have 18 posts by the end of this year not including this post. That's 1.5 posts a month. That's sounds like such a small number of posts, but I bet by the end of year I'll be struggling to get this goal in. A nice timely, achievable goal.

Personal Finance
Using cash only for non-recurring purchases is a great goal. I like that goal a lot. I'm already on my way to saving. I also wanted to quantify my savings goals. I need to put a monetary number on how much I want to save. My emergency fund is a weak point I need to address. I want to have $5000 by the end of 2011. With what I have saved, that turns out to be $400 a month. Ouch. A lofty goal, but I worked it out and I can get it done. Totally attainable.


I also have an addendum to my goals. These are things that I've thought of in the past week.

Do the marathon
I'm going to be in the 1% that does the marathon in their lifetime. Training starts at the end of January!


Sky Diving on my birthday
I'm going to make it happen!

iPhone Hacking
I've spent some time working on an iphone application that's really fun. My brain hurts, but I'm going to continue working on it. This part is measurable with the next item.

Average 7 hours a week on something I'm passionate about
Whether it be iPhone hacking or blogging, I want to average 7 hours a week doing something I love. 7 hours a week isn't that much. It's one hour a night. Totally achievable. I'm going to keep a log on google docs that keeps track of what I'm doing and when. Reading blogs and things online doesn't count because I'm only consuming information. I want to be a producer, one night at a time.

Phew. Now that sounds like a goal list. Time to get to work!


Sunday, December 12, 2010

Personal Update: The end of 2010

One of the great things about having a blog is being able to look back at what you decided to do about your life and and measure how far you've come.  I dusted off my previous update,  2010 Things to Get Done to determine if I executed on my action item list.  And with that, here is how I did.


Financial Goals - Total, complete, epic fail.  Well almost.  I didn't stick to my budget, but I did manage to save for a couple of vacations.

Paying Myself First - Going to the gym in the morning before work lasted for about 4 months.  Then I had a week of going to sleep late and that killed the early morning gym fests.  I still go to the gym 5 times a week, but they are at the end of my day instead of the start.

Read One Library Book A Month - Sigh.  Fail again.

Play with Python - Nailed it.  I learned a bunch of Python by playing with the YouTube Rest API and the last.fm API.

Complete 2 Resume Updates - Half credit.  I did one.

Increase StackOverflow Reputation to 1000 - Fail.  I got to 172. I also stopped frequenting SO unless I needed a question answered.

Rails Development - Failed.  I did some Rails hacking this year, but I didn't deploy my app.  I also canceled the domain I bought to deploy the app.

How depressing.  My action item score is:

Completed: 1
Half Credit: 2
Failed: 4

On the surface, it appears that I had a horrible year.  I only completed one thing that I set out to do, made some progress on others, and totally dropped the ball on the rest.  But to prepare for this post, I did a resume update and found that the majority of my time was dedicated to work:

  • Worked on a bunch of interesting things like: GWT, Client/Server architectures,  Performance improvements.
  • Mentored an intern during the summer.  I learned a lot from him and I hopefully taught him a bunch of stuff.
  • Used a bunch of frameworks, technologies and tools like: ActiveMQ, Camel, JMS, Tomcat, Derby, Git, Mercurial
Some things that I've learned and along the way, but aren't resume material are:
  • Making a conscious effort to listening to my team's suggestions and recommendations
  • Revisiting my software design and ideas the next day to double-check if it was actually a good idea
  • Being more open to new ways of accomplishing tasks
  • Read world news in the NY Times in addition to reading a lot of personal improvement, finance, and technology blogs.
  • I've become an avid yelper at aus.yelp.com
So maybe I didn't do so bad this year.  I may not have accomplished my action items I set at the beginning of the year, but I definitely didn't stagnate.  I feel like I should have done more, but at least I made some progress.

So where do I go from here?

This year I'm going to try something new.  I'm going to create two lists, an "Action item" list and a "Maybe do it this year" list.


Action Items

Learn Django - To continue my software learning, I want to learn some Django.  I've done some Python work so now it's time to move my learning to the web.  I'm thinking of looking for an OSS Python web based project to contribute to.

Improve my online presence - My online image needs to improve.  I need to contribute to online technology forums, work on my linked in profile, and anything else that will increase my visibility.

Personal Finance - My yearly struggle with sticking to budget has made the action item list once again. This time I'm going to try paying with cash for everything except for gas and my monthly bills that are automatically charged.  It's sort of like the Envelope System, but I'm not going to bother with sorting my cash into physical envelopes.

Read More Books - I really love reading.  I just need to get off my butt and use the library more.

Visit Japan - I need to get to the homeland.  In order to go, I'm going to have to save, save, save.

The Maybe List

Take a side job - I really want to try working a part-time job on the side for fun.  Something like working at Starbucks or at a wine store.  I'm not sure it fits into my work schedule, but I have been toying with the idea.

Andddd go!

Friday, April 2, 2010

Checkstyle: It's Important

People have a love/hate relationship with Checkstyle.  Some people, myself included, are in the love camp.  We include it in our development process.  We strive for 0 checkstyle warnings.  We fear committing Checkstyle warnings because of the ensuing shame resulting from Hudson unstable build emails.  Other people tend to hate checkstyle.  They think that checkstyle piles on work on the already piled on work stack.

Here's why that's the wrong mindset to have.

Checkstyle enforces your team's agreed upon code style guidelines

Code style is very religious subject.  Very Religious.  It creates just as many holy wars as the "My IDE is better than yours" argument.  But I think everyone can agree that having code style guidelines is a good thing.  It aids teams by keeping code uniform and easy to read.  Reading code is hard enough without having to weed through 20 different ways types of if-statements and for-loops.

This one is easy.  You have style guidelines, let's make sure that everyone is following them.  It doesn't take much work to integrate Checkstyle into the daily build.  Enforcing code style is a good thing.  It really doesn't matter what the style is.  What matters is that everyone follows what rules the team has agreed upon.

Checkstyle forces you to write documentation

Developers hate writing documentation.  If you love writing code comments then you are a sick, sick person and you probably already love Checkstyle.  Feel free to stop reading.  Now for the rest of us, we often have a personal two-way connection to our source.  We know what it does.  At least we know what it does right now.  What about two weeks from now?  One month?  One year?

Integrating Checkstyle into your development process forces you to stop and think.  It makes you question what your code does.  It can help validate your design.  Often times I find myself asking questions like:
What exactly does this method do?  
What are it's invariants?  
Are their any special cases? 
Can I pass bogus values?  
What does this algorithm accomplish?  
The intricacies of your code exist in your head at this very moment.  Why not write it down?  Checkstyle makes it so.

The argument against forcing developers to write documentation is that they will write useless comments.  This isn't a fault of Checkstyle, it's a fault of the developer.  Why aren't they writing good documentation?  Why aren't other developers getting on the bad documenter's case?  Is anyone else reviewing their code to make sure they aren't being sloppy?  Checkstyle doesn't do any of that.  Your team does.

Checkstyle isn't for you, it's for everyone else

I believe we all can agree that clear, concise, and well documented code helps other developers.  There is  a feeling of pure joy when you use a well-documented third party library.  Since all code you write will be used by other developers, shouldn't you impose the same documentation standards on yourself that you wish everyone else would follow?

What about the argument of "Why should I care about checkstyle?  I know how to document".  Even if it were true that you always wrote great documentation, 99.9% of us aren't like you.  We need help verifying that we are indeed following code style standards.  Checkstyle keeps us honest.  After all, we are developers and developers are lazy.  Sometimes we need a little prodding to keep ourselves disciplined.

Checkstyle is just a tool.  If you don't use the tool correctly, then of course it's going to suck.  Used in the right way it's extremely powerful, even for something as seemingly trivial as code style.

Saturday, March 27, 2010

Developer Responsibilities

I think Eric Sink got it right.

We Need Developers, Not Programmers.

In the article, he writes about needing developers who know how to be flexible and understand the software lifecycle instead of coders that are one trick ponies.  You know who I'm talking about.  Those programmers who know how to write some source and nothing else.  Improve the build environment? Work on continuos integration?  Unit test?  Write wikis to help the team? Mentor?  Contribute to the awesome company culture? Forget about it.

Working for a small company, I completely agree with that statement.  I'm glad that I work at a company that allows me to have a hand in everything.  My tasks during the week range from development environment scripting to application deployment to middleware hacking to pretty front end stuff to ensuring code quality to maintaining our build server.  Then I get to write down what I've done to help out the rest of the team on our company wiki.  My hard work is rewarded with my #1 status on the Continuos Integration Game leaderboard.  Having my hand in everything is awesome because

I'm learning tons everyday!

As a developer, that's something to strive for. Especially if you're a developer that's fresh out of school.  When you get out of college, you want to absorb as much as possible.  Can you do that at a big company?  Maybe.  Is it easier at a smaller company?  Totally.

As a developer, you have a mound of responsibilities other than whipping out lines of source.  Specializing in something is great, but being an agile developer is much more useful to your peers.  If you understand the different aspects of software, you can apply your knowledge to challenges you face in every facet of development.  I've learned over the years that just being familiar with what people are talking is HUGE.  It gives you a basis when you start learning new stuff on The Google.  The only way to get to that nice and comfy "I've heard of that before" place is to dive into as many new things as possible.

Staying agile is important and a small company helps you do that.  It helps you and your team get things done.

And isn't that what it's all about?

Solving problems, improving customers lives, and rocking out to an awesome product.


Thursday, March 4, 2010

Hotkeys. More productivity, More Awesome.

At a recent career fair, Aaron Kagawa asked students the question,

"What is your favorite hotkey in Eclipse?"

Sadly, not very many students had an answer.  Joel Lazaro, a student in Dr. Philip Johnson's 414 class, is on the right track and posted a useful link on Eclipse shortcuts.

Being a productive developer means you trim the number of steps do your hacker tasks.  Why is this important?  Let's take a look at an extreme example, a daily task in Eclipse with and without hotkeys:

A simple task with hotkeys
  1. Ctrl-Shift-T to open Foo Class
  2. Ctrl-O to find and move to another method
  3. Write some code
  4. Ctrl-Shift-Up/Down to move to the next method
  5. Ctrl-D to delete a line
  6. Control-F11 to run the code
Now the same task without Hotkeys
  1. Grab the mouse
  2. Open the package navigator and search for the package where Foo Class exists
  3. Double-click to open the Foo Class
  4. Scroll with the mouse to find the method to edit
  5. Write some code
  6. Grab the mouse
  7. Move to the next method
  8. Using the mouse, highlight the entire line to delete
  9. Move the mouse to the 'Run Application' Button
  10. Run the code
The main tasks to notice in the 'Without Hotkeys' example is the time spent searching and moving your hand to the mouse.  When a developer skips out on the hotkeys, productivity suffers.  Too much time is spent searching.  When the file to edit is located, more time is spent searching for the place to edit.  Once editing is done, it's back to the mouse to move someplace else.  Rinse and repeat.  *Yawn*

That isn't even the worst part.  The worst part is the productivity of the entire team suffers.  Less things get done because time is wasted.  When other developers try to help, even more of their time evaporates.  Let's take a pair programming example.  It could be a formal session or an impromptu 'walk-by' to help someone out.  The navigator stands their idling while the driver opens a class or finds a method using the mouse.  Now the productivity of two people has flatlined.  If you're the driver, you're job is to drive fast

To better explain why hotkeys are so important, I'll reference the age-old analogy of a carpenter and his tools.  Think of a carpenter's toolbelt.  Pure genius right? It's inventor thought, "I'll wrap a piece of leather around carpenter's waist so they can grab their tools quickly rather than waste their time going back to their tool box."  Productivity went through the roof.  Carpenters pick the right tool without moving or looking down.  Commence carpenter flow time.

Hotkeys help developers to get "in the zone".  When you stop to find a class or method, there are more opportunities to break your train of thought.  Moving your hands off the keyboard and onto the mouse is like switching contexts. Switching tasks is bad.

Are you ready to improve another skill in your toolset?  Take a look at Developers favorite Eclipse hotkeys or hit Ctrl-Shift-L in Eclipse to list the available hot keys.  If you use another IDE, take some time to learn about it's hotkeys, macros, and shortcuts.

Still don't believe me?  Think using the mouse is ok?

Steve Yegge says, "Non-touch-typists have to make sacrifices in order to sustain their productivity"

Death to the mouse!

Saturday, February 13, 2010

Getting Technically Started

Where do I begin? 

This question scared the crap out of me when I forayed into the job space straight out of the university. Everything was wild and unknown. I needed a tour guide yesterday.


As a new grad, I tried a lot of things. I read books and blogs. Listened to podcasts. Worked on open source projects like Hackystat and personal projects like an Open Microblogging Plaform and a ping pong score tracker. I tried a bunch of different approaches to improving my technical life. This blog's aim is to help you filter out the noise.  I'll write what worked for me with the hope that it can bootstrap your improvement outside of college.


First things first
There are two articles are forever part of my hacker livelihood. Having read these two articles in Philip Johnson's software engineering class helped me define who I am and to understand what I need to do to contribute. These two webpages.  Yes I said webpages not blogs.  It's crazy how old these articles are.  Notice the manual revision history at the top?  Crazy.  Nonetheless, the content is the stuff of legends.

Defines who we are and how we get there.  We are hackers.  Be proud and proclaim it.

Asking dumb questions makes you dead weight. Hackers hate dead weight. We want to spend time having fun chatting about the latest tech news, making paper airplanes, having Nerf gun fights, and if it's in the project plan, write some code.  We don't have the time or patience to answer stupid questions.  Remember the "There is no such thing as a stupid question" line doesn't apply to our world.  There are stupid questions and it makes us angry.

With that said, we geeks get it.  No one knows the answer to everything.  It's not humanly possible.  Robots, ninjas and zombies can do it, but not us lowly humans.  Geeks genuinely want to help people.  They want to explain a topic they're familiar with not only flex their intellectual guns, but to help you out.

Ask a smart question, get a smart answer.  Respect +1.
Ask a dumb question, lose respect.  Respect -100 

Respect is king amongst the Geeky.


Blogs
Blogs are an excellent knowledge resource.  StackOverflow has a thread on the best programming and development blogs if you are interested, but here are the blogs that I've been following for quite some time:
I also follow the blogs of people I've met at the university or through work.  They are all interesting as well.

Reading Code
As a hacker you want to get into the nitty gritty.  You want to jump into that source and show it who's boss.  You're going to write millions of lines of unit tested, bug free, elegant code.  But wait. 

Do you enjoy reading other people's code?  No?  That's too bad because reading code is about 90% of your hacker life.  Maybe more.  There's API's, javadocs, code examples, and source digging among the countless other ways to read lines of code.  Rockstar programmers that perform 10x better than others rock at reading code.  For the rockstars, reading code should be like reading a book.  It needs to flow through your mind and paint a picture of what's happening.  It's said that you need to practice 10,000 hours to master something.  I think you'll need even more to master code reading because everyone writes their code differently and most of it is bad.  You'll need to be able to quickly pick up favored patterns and apply it to your overall understanding of the code structure and usage.

It might seem obvious, but you should get out there and read code.  It's actually really easy:

Step 1: Find an interesting project on SourceForge or Github.  
Step 2: Check out the source
Step 3: Read the source.

Voila.  You are on your way to code reading mastery.  You could even take a step in your code writing mastery hour allotment by contributing to the project.


Writing Code
I don't need to write much here.  Practice, practice, practice.  I would suggest immediately starting with a new language because it promotes new ways of thinking.  You'll realize the importance of learning new languages once you apply a language design pattern from one language to another.  

I started with Ruby on Rails because I was interested in web frameworks.  I've made a resolution to work with Python this year.  Pick something you find interesting and do some Code Kata or create yourself a side project.


Blogging
Blogging is an excellent tool.  I know that it's not for everyone, but I find that it continually improves my thinking and writing skills.  I brainstorm during my commute to work, the walk to Starbucks, the lonely period in the bathroom.  I think about interesting blog topics and if my readers (all 5 of them) would get it.  Blogging puts your thoughts into written form.  Sometimes it's hard to express what you mean until you try to explain it to someone else.

Another great thing about blogging is that it can help you with your Periodic Resume Updates.  You won't be able to remember what you've done over the past year, but having an activity log will help figure out what you should add to your resume or tell you that you aren't investing in yourself enough.


Hang out with Hackers
The last point I have to make isn't really a skill, but rather something to help build on your hackerism. Find smart hackers and hang out with them.  In person would be best, whether it be your coworkers or people at other software companies.  It could even be online. It's similar to pair programming without any coding. Either of you can drive, but both learn from each other. Most geeks like to talk about geeky things like the latest and greatest tools. Find people that are on the bleeding edge and attach yourself to them. The bleeding edge is where you always want to be.

Monday, February 1, 2010

Purpose. It's that little flame.



Purpose from the Broadway musical Avenue Q.  Awesome.

When I first started out writing this blog, I wanted it to be a place where I talked about the happenings in my technical life.  A good start I think.  Sometime this past week, three years into blogging on and off, I noticed something about the blogs that I read.  I'm so dense.  They all provide information that help me in some way.  Whether its explaining how I use a specific technique to improve my career, an interesting idea, or a novel concept, they all exist to lend a hand.

I noticed that a lot of my posts are a bunch of rants on what projects I'm working on, my love-hate relationship with certain technologies, or my personal improvement progress.  Maybe it's time to put a spin on what I blog.  Maybe I should write posts about how activities on projects flick on the lightbulb or create guides for tools I'm using.  Even reviews of tools and books would be helpful.

Maybe I shouldn't care what others think about my blog because part of the reason for taking the time to write things down is to get my thoughts out of my head.  If I really cared about increasing my readership, there are a lot of other things I could do.  Tons of people reading my blog isn't my purpose.

Helping others improve is a noble purpose.  It will be that little flame.