Monday, February 25, 2013

On my own

I have been working for a fairly large software company for the last 3 years.  During these years, I have been paid fairly well, learned a lot about software development, and have worked on a few interesting projects.  The experience has been good and I expect it to continue to be good.

Despite a positive work experience at my present company, I still day-dream about working on my own.  I would have my own home office.  I'd build software.  I'd make money.  In my day-dreams at least, it is so appealing.

Working for the 'man' is basically a fair deal.  They pay me fairly well, and they also handle all of the marketing, selling, lawyer-ing and whatever else is involved in running a company.  I know that my code is worth more in their hands than mine.  Without their infrastructure, my code would be close to worthless.  

Yet, the biggest issue I have with working for a company is that all of the software that I produce is owned by someone else.  If I quit my job or get fired tomorrow, my company can continue to use the code I wrote to make money.  It would be nice to actually 'own' or benefit from the code that I wrote as long as it is being used, even if I left the company.  

I don't know if this desire to be own my own will ever manifest into any kind of action, but the thought has been bouncing around in my head for so long, I couldn't help but web-log it.

Monday, February 18, 2013

This Developer's Life

I have been on the search for a podcast about programming / coding, and I have just started listening to This Developer's Life.  It is a podcast, modeled after the This American Life podcast.  Similar to This American Life, this developer's life is of super high audio and content quality.

I have listened to the first 7 episodes, and I have enjoyed them all.  The focus of the podcast isn't on the code or the developed software; rather, it centers on the developer.  This podcast will give you insight into the psyche of a software developer.

For one, what makes a developer tick?  Is it a need to build things or fix bugs?  Do developers want to be famous?  Or, maybe they just want to understand everything (from semiconductors to mobile apps).  It's probably a mix of all things, at least it is for me.

The other big aspect of  this developer's life, both in the podcast and in my life, is the developer community.  There has been discussion on how we treat other developers.

This podcast began in 2010 and there has been about about 1 episode per month, so there is a lot of content for me to catch up on.  At this point, I am a big fan.

Sunday, February 10, 2013

Finding the pain

As of today, I have two things in my personal portfolio.  
The motivation for building each of these applications was to learn: to learn about mobile development in the first case and about building Google App Engine web applications in the second case.  Secondary reasons for building each of these apps is that I thought some people will find them amusing/useful and that no-preexisting app provided the same functionality.  

As I come closer to finishing up my doodlesforum project, I heard about Jeff Atwood's newest project, Discourse.  Discourse is software that will help discussions on the internet, aka forum software.  I don't know how popular this software will become, but I am pretty impressed that he chose to tackle this question.  

I think choosing the right software project to work on next is difficult.  I don't know if I'll ever work on a project that has such simple yet profound goals such as:
  • Let's build a good internet search engine (Google) 
  • Let's build a good Q&A site (Stack overflow)
  • ...
  • Let's build good forum software (Discourse?)
I think a good way to choose projects is to find the pain, and then build something that solves that pain.  I'm not sure what pain I'll look to solve for my next project, but it's something I'll keep in mind.

Thursday, February 7, 2013

Thoughts on Performance Enhancing Drugs

I just listened to a podcast where Bill Simmons and Chuck Klosterman discussed the sport's guys recent article on performance enhancing drugs (PEDs).  I recommend you listen to the podcast.

Here are my initial thoughts on the subject.

Everything is a PED.
Steriods, Human growth hormone (HGH), and blood doping are things that give athletes the ability to perform better.  The same goes for good food, lots of sleep, and practice.  So why are the items in the first list illegal (in some sports) and not the items in the second list?

You might argue that steroids and other PEDs are illegal because they have some bad side effects.  This is true.  Of course, the side effects might be worth it - especially if being a professional athlete is your only marketable job skill.  Taking steriods may allow an athlete to earn enough money to have insurance for the rest of his life, which would be good for your health.

And really, if side effects are your only concern, one day someone will invent drugs that enhance your performance without any known side effect.  Will that be OK?

Testing does not work.
The problem with testing is that some people will be intimidated by the testing and will stop taking PEDs, while others will continue taking PEDs, trick the tests and pass.  This is what happened with Lance Armstrong.  Despite being tested, Lance continued to take drugs while his peers stopped taking drugs.  The tests enabled him to get an unfair advantage.  If there weren't any tests, presumably all the competitors would take PEDS, and that would be fair.  All tests are imperfect.  There will always be loopholes and someone will always get away with cheating.

What can we do?
So far, the strategy for combating PEDs is with black-lists.  The rules in a given sport state: You cannot take steroids, cannot use HGH, cannot dope your blood, etc ... This type of list will always be incomplete.  You can never include every drug that can possibly give someone an unfair advantage.  Someone will always be ahead of the times and will figure out a new way to get stronger or faster.  Eventually, everyone else will also do it, or it will be banned later.  During the interim, someone had an unfair edge.

The better strategy should be to create a white list.  Athletes can only eat apples, bread, chicken, etc ... and these are all supplied by the NBA or NFL or whoever.  You can also only take advil, pepto bismol and a handful of pre-determined drugs.  If you do anything more, say take powerful pain killers, you will be suspended or expelled from the league.

Can a white-list of approved foods and drugs work?
Not really. There's no way we could regulate the intake of food of all athletes in the world.  I think the only way this could work is if all athletes in a league were forced to live in some bubble.  We'd tape them 24 hours a day to ensure that they aren't cheating.

Professional sports would become something akin to survivor.  Sports, like any reality show, is a game with a predefined set of rules.  Maybe the line between professional sports and reality shows like survivor will disappear.  Dare I say, can survivor be the sport of the future?

The problem with my idea.
The problem with putting all athletes in a bubble is that we wouldn't know who gets to go into the bubble.  We can't just put the best athletes in, because we don't know if they've been taking PEDs or not.  

Monday, February 4, 2013

How does a brogrammer become a programmer

A brogrammer is a type of programmer known for his sexist comments, macho brashness and frat-boy attitude.  A brogrammer is sort of the opposite of a nerd, in a bad way.

I am part-brogrammer 
While some would say that brogrammers aren't real, I see a little bit of brogrammer in me.  While I don't normally drink booze while I code nor do I make many sexist coments (as far as I know), I am guilty of suffering from one part of the brogrammer stereotype.  And worse yet, I think I picked up one of the worst brogrammer characteristics.  My attitude towards writing code is way too macho.  I think this is one of the worst brogrammer traits, because it will eventually make your final product worse.

Macho brogramming leads to bad software
So why is macho programming bad?   It leads to an over-estimation in a coder's ability.  I often promise to deliver something, and find myself short on time.  In order to finish on time, I'll have to work late and/or push out rushed code, which leads to buggy code.

Beyond the code you actually write, macho brogrammers like myself spend way too little time not writing code.  I have come to realize that good software developers spend a lot of time reading, asking questions and planning.  Writing code should come at the end of a lot of thought.  If you begin writing too early, chances are you haven't found the ideal design and you will either have to re-write code or live with poor design choices.

Putting the Pro back into Programmer
I think the way to stop being a macho brogrammer is pretty simple.  Here's what I came up with.
  1. Think first. Code later.
  2. Ask lots of questions.  

Saturday, February 2, 2013

Tips for using Google Web Toolkit

This post will be a set of notes with UI improvements.

Loading Image ...
If you are loading an image that may take some time to load, it would be nice to tell the user that something will appear.  One way to do this is to put some text into a panel first, and when the image is ready, display it to the user.
// Fill in the panel with some text.
Label loadingImgLabel = new Label("Image loading ...");
private VerticalPanel imagePanel = new VerticalPanel();
imagePanel.setHeight( "250px" );
imagePanel.add( loadingImgLabel );

// Make a async call to get the image you want
// When it is ready, replace the text with an image.
Image image = new Image();
image.setUrl( "location/of/img" );

imagePanel.clear( );
imagePanel.add( image );

Setting the width of the panel
If you want your widgets to fill up the page, set widths like this:
private VerticalPanel aPanel = new VerticalPanel();
aPanel.setWidth( "100%" );

How to write to and clear a Flextable
I was trying to clear rows from a flextable in the following way:
FlexTable flexTable = new FlexTable();
flexTable.setText( 0, 0, "some text to add in row 1, column 1" );

// This clear statement didn't remove the text from the table
flexTable.clear();
I realized that the clear command will only clear widgets.  Thus, in order to add and remove flextable rows, you need to do the following.
FlexTable flexTable = new FlexTable();
flexTable.setWidget( 0, 0 ,
new Label( "some text to add in row 1, column 1" ));
// Now, the text as widgets will be removed, as expected
flexTable.clear();
// Just to be extra safe, you can also do
flexTable.removeAllRows();

More to come later ...