Frankenstein coding

These days, you can program and create real life applications via a Frankenstein approach.

1. Start with a tutorial that creates a basic "Hello World" application.
2. Think of a feature to add. 
3. Google "How do I do 'X' in 'Y'?
4. Cut and paste found code into your app.

Over time, you will eventually assemble an unique application that is a collection of copied bits.

Is it wrong to program like this? I don't know. I do feel that it is ugly, smelly and hacky (in a bad way). 

This is unfortunately how I have been programming my latest web app. HTML and CSS are new to me, yet they are both very human-readable. So I've gotten by, by just searching for what I think I want (give me a table or a new section) and then Frankenstein'ing it into my app. 

I am not proud of my Frankenstein-ing behavior. To stop it, I have started learning HTML and CSS with codecademy. 

After I've learned HTML and CSS, I will probably look back and think that I was a lousy programmer for cutting and pasting so much. I hope that my future self is a vastly superior programmer to my present day self. 

Yet, it's important to recognize that cutting and pasting is an important part of programming. Sometimes, you need to copy something in order to get something to work. You can go back and try to grok it fully later. 

Disclaimer: I'm not sure where plagiarism starts and ends when talking about code. I do not support passing off someone else's work as your own, but learning from others is ok. I think this is another separate debate. In the grey areas, to be safe, you should at least do these things: 1. ask for permission from the original author, 2. give proper attribution. 

Am I a spy?

In a recent blog post, Scott Hanselman denounces "Adware, Malware, Spyware, Crapware" as pure evil. I totally agreed with him, or so I thought.

Recently, I updated one of my apps, and one of the reviewers said that the app now contained SPYWARE. Hmm, since I don't think I'm writing spware, maybe the issue isn't so black and white.

I can go into the my specific details, but I'll discuss a more well known example.

Google Now is an Android App that delivers personalized 'cards'. The cards give me information on the local weather near me, websites (that I read) that that have new blog posts, the latest sports scores of my favorite teams, and they even used to show how many steps I walked in the recent past.

Google Now was creating this content by reading my email, tracking my browsing history, and more or less spying on my life. The app is doing things that I don't know about and that I may or may not want. I think it's fair to say that Google Now is a type of spyware; yet, I think Google Now is a pretty great app.

Name-calling seems to always trivialize things, so I shouldn't get too hung up on whether someone calls me a spy or not. Even if they do, maybe it's not so bad.

Commenter's Block

I have been thinking about comments today (the kind that you add to code, not to blogs). Adding comments to code is one of the first things we are taught to do, but I realized that it isn't that simple to do well.

I recently asked a co-worker to review a change I made. He replied,
"Each individual change looks fine, but there's a lot about the code that I don't really understand. Can you add some comments?"

I replied,
"Sure, the code is a bit gnarly and complex. Instead of me guessing what you think is unclear, can you quickly point out what spots need comments?" We use a nice tool for code reviews that makes asking for updates really easy.

He replied,
"You know what, I'll just accept your change for now. It's too hard for me to figure out what really requires a comment and what doesn't. Maybe we should chat about it later."

So, I've checked in the code and started rolling it out, without additional comments, but I wish I had a better idea of what's the BEST practice for adding comments? I don't have a complete guide in my head, but here are some random thoughts on the subject.

/* @author = Me, 
    @name=file.h */
I don't understand these types of comments. The author will change over time and there may be multiple ones with different levels of contributions. The file name is often obvious.

/* 
 * 
 * This is the start of the next section.
 *  
 */
When you are dealing with big files, this sort of comment can be pretty helpful for the sake of readability.

/* WARNING - This part of the code may not work during day-light savings */
This warning type of comment is pretty useful. If you see a bug, it should help you figure out what part of the code needs changing. I also feel more comfortable changing code that I know is already buggy and hacky. It's already broken, so there's nothing to lose!

/* TODO: Update this code after database change is made. */
In the interest of always be shipping, I often add this type of comment. Similar to the warning type of comment, this one tells you what part of the code should probably be updated next.

git log
I've started using git more and more, and I think the comments that exist as commit messages are often the most useful. They often tell you why a change was made, which is nice. A more powerful feature is that commit messages are dated, and if you know when your bug first appeared this can help.

/* TODO: add more good and bad types of comments to this post. */

Debugging

One of my favorite things about computer programming is debugging. For what it's worth, I also like vacuuming my apartment.

To be clear, debugging can be painful, annoying and stressful. But when you make a breakthrough and have that Aha moment, debugging a problem is very gratifying. I used to think of myself as a scientist. Maybe I was a bad one, but debugging programs has given me a lot more "Eureka! Oh, I see" moments than I ever had during my years as a scientist.

Another cool thing about debugging is the clear end-point. You start with a broken program or feature, and then you are done when the bug is fixed. I like ending the day certain that I did something worthwhile. I think this is one of the reasons why test-driven development is popular. You create the bug first, and then develop something that squashes those bugs.

When you debug, you learn. When I'm writing new code, I'm mostly trying to organize my own thoughts in a way that agrees with the compiler. When I'm debugging my code, I have to think hard about something I probably didn't understand before. If I'm debugging someone else's code (or some old code of my own), I have to understand what someone else was thinking.

For some people, they only want to work on building something from the ground up that is completely new. I like improving something now and knowing that I can keep on improving it later.

Bugs increase your technical debt.
Embrace removing all bugs from your code so that you can be debt free.

Opportunities

If you build it, they will come. 
It's a classic line from Field of Dreams, and it happens to be true for software development.

I have a small app on Google Play Store. As of now, less than a 1000 people have even tried the app. Despite the humble statistics, I've begun to get more and more inquiries about the app.

They are coming. Who are they, you may ask. Well, here is what I've been seeing so far.

Clients. I've had some bad and some good feedback. Once, someone told me that the app was crashing and how to reproduce the crash. I immediately (well, in the next few days), worked on the fix and thanked them for the help. The best feedback is when I hear of new features to implement. It's great to know that you are building something that matters.

Promoters. (Scammers?) Since the moment of my initial publish, there have been people asking me if I'd like my app reviewed by them. They'd promote my app, and I'm not sure what I'd have to do for them. This always felt disingenuous to me. If you want to review my app, you certainly don't need my permission to do so. I'm not sure if all of these solicitations were actual scams, but it's best to be cautious with these sort of things, so I typically just didn't reply to these folks.

Developers. Other developers have asked me if they might build some new feature for me. This is cool. In true open-source fashion, the project takes a life of its own and is built by a community. But this is a project that I'd like to build. I fear that I give others access to the code to build on and bug fix, I'd end up maintaining more than building. I guess I haven't fully adopted the open source spirit.

It's pretty cool that I can work on something at home and then generate interest from people all over the world. It motivates me to keep building, as it accumulates to be something that can take a life of its own.

Gloomy programmer

Lately, I've been feeling depressed. I think it's about my work, but I'm not sure. Below are three somber stories that are in my head. I am hoping that blogging about it will help me clear it from my memory, and I can start thinking about other happier things.

The cartographer

(this is based on a short story I read about 10 years ago. I cannot find any reference to it). There was a man and his wife.  The man was a good man, and he loved his wife. He wanted to provide for his wife, and he found a job as a cartographer. In those days, a cartographer made maps by physically going to uncharted territories. In the beginning, he found the constant travel tiring and he missed his wife. He wrote letters to his wife and went home to visit as often as he could. Over time, without realizing how, he felt more and more comfortable away from home and his wife. Eventually, he wrote to his wife telling her that he would remain on the road and that he would never return home.

A pair of dogs

(this is based on something someone told me). There was a farmer. He had two dogs; a boy and a girl. The dogs would spend some of the day with the farmer, but would often go somewhere on their own. One day, the dogs returned from their adventure and the farmer saw that the dogs didn't have an appetite. This happened for two straight days, and the farmer became worried. The next morning, the farmer found one of the dogs dead. The next day, the other dog died.

A programmer

(this is my story) For the last year, I've been building and nurturing a project. It started as my own small seedling idea. I was overjoyed when I had a proof of concept to demo. It grew to be a major feature that everyone was excited about. Lots of people had opinions on what should be done next. There were so many discussions that everyone stopped working. The project is now suspended; pending UI reviews, business planning, etc... I am now working on some other project, and I have a hard time understanding why.

Always be shipping - onward and upward

It's been said before (by smarter people than me), and it'll be said again. In any case, I feel like blogging about it today, and so it's the subject of this post -- Always Be Shipping.

When I say 'Always Be Shipping', I mean that code should always be moving forward. Code can be in a lot of stages.

At the lowest stage, it's just an idea in my mind.
'I think our app should provide some calculations for the user'.

Then, it might just be a "TODO:" with pseudo code in the real code.  Example,
// TODO:
// loop through item list here
//   for each item hook up to new api 
// return new amazing data

The pseudo code eventually becomes real compiled/interpreted functioning code that you can test on your development machine.
Woohoo - it works on my machine!

If it's working on your machine, you should start rolling the code out. Even in my hobby projects, I have a few levels of roll out. For Android apps, I have:

• I start with the Emulator.
• Then I have a test android device.
• Next, is my actual phone that I use on a day to day basis. 
• Then I can enable for some alpha testers. 
• Then I can slowly roll out to some percentage of users. 
• Then I can roll out to all users. 

If you find yourself stalling at any point of this process, you should figure out why, and then push forward.

If you have lots of ideas and you never get around to coding them up, then you need to get focused and implement one idea.  A functioning piece of code is better than lots of theoretical brainstorming ideas. Every great product had a 0.1 version. Go ahead and write the 0.1 version so you can start on the 0.2 version sooner. Otherwise, you will find yourself at 0 for a while.

If you have a functioning version of your code, but haven't released it to the world, you should ask yourself why. Are you afraid of bad client feedback?  Get a friend to try out the change and get their opinion.

Are you afraid of performance issues? That's good, but don't just sit and worry. Figure out a way to quickly turn off your change if needed. If things go awry, you can get back to a steady state easily. Even if things go bad, at least you have identified a real problem that needs to be fixed. The alternative is that you are optimizing for doomsday scenarios that never occur. In the future, you can use this mechanism (of quickly turning off a change) so you aren't stalled in the future.

For most software development these days, shipping code is something you should do early and often. This is true for other things. For example, when blogging, I try to tell myself -- Always be publishing. It's easy for me to write half a blog post, get tired, and leave it unpublished as a draft. It would be nice if all our code and blog posts were perfect before shipping/publishing, but then we'd never ship anything.

So - stop reading and start shipping.