Good work Google!

Google I/O website looks way cooler than I expected. Every year they do something new and interesting on the page and this time its not different.

I guess the page takes you on a tour from subatomics particles world to the solar system and universe. Stunning work!

And this is what happens when you have huge amount of resources (cash + employees) and you don’t have any idea where to get them focused at work. And you start giving away things for free (just like how Leonardo throws away money in the dustbin in Wolf of Wall Street movie).

I would appreciate them the same way if the things to be released in Google I/O is as cool as the website sounds.

Good work Google!

The Creation/Consumption Myth

Lots of people think that Content creation happens on the desktop and Consumption happens on the devices like iPhone and iPad. These are short sighted opinions. 

You touch and move, the object moves under your finger. Devices enabling such direct interactions are the ideal platforms for creation. We just don’t have enough tools in the app store to expose all the power to users.

In fact, the devices can open up completely new class of software and usage patterns. Only a few apps stand out really well - StoreHouse and Fifty three’s Paper. 

I wish my fellow iOS developers wake up to the reality, stop creating the same old NewsReader like consumption apps. And start producing more content creation apps. 

Secret to Bug Free Software

Disclaimer - This post is written for programmers who think that writing code is not just a job but is also a craft that not many are gifted to do well. IF you are not one of them, please spend your time in that sick Social Network. or the Youtube. or Whatever.

Errors as they state in classic software engineering books can be classified into 2 groups.

1. Syntax errors
2. Logical errors

Im not going to talk about syntax errors. It is the duty of your favourite editor to stop you from making them in the first place.

I’m going to talk about logical errors which causes big to huge losses in software business. Well, a bug in a todo list software does not have the same impact as a bug in an eCommerce system.

It is frustrating to see a bug creeping through the software destroying the whole reputation of your clean good code. And over time it has a good amount of impact on the way others treat you in a team. So it is worth taking the time to learn how to write bug free code.

I have worked on good number of software products for the past 3-4 years in a team and individually. So I believe I can talk about this subject.

The secret is in you.

It all comes down to you, the programmer who has been assigned a task to be completed before a specific date.

How you take up the task, what methods you follow to approach it and finish it on time is where all the secret exist.

First step is to understand that the fact that your job is all about writing components. Components that are going to play well with other components of the software. Be it a bug fix or a new feature. It is a software component.

The second step is to spend considerable amount of time in studying the system around before writing those if’s and for’s. When and where is your code going to run. What are the conditions under which your code is going to be called. And what is the time frame in which your component has to complete its task.

The third step is to actually write the code. In a clean way. I wrote a post before on how to do this well. Read it if you are interested. 

The ideal characteristics that you have to target while writing the component is that, any explosion outside shouldn’t affect the working of your component and any critical bug inside your component should be an implosion and shouldn’t affect the workings of other components around.

The reality is “Ideal cases” never exist. It never exited before and its not going to come into existence in the future. Having said that, the understanding you have about the system around your component matters. Even if you don’t achieve the ideal case, efforts can be put in to get closer to it.

Software engineering has dealt with “Writing bug free software” in many different ways.

Agile development has been one such practice and it has worked. Their bottom line is “we do ship software with bugs in every release. But they will be fixed in future iterations”. I totally buy this idea.

But when you take the right steps to write your code bug free in the first step, it would take less number of iterations to achieve the idea state.

It takes time to do all this. It is ok. Spend it.

After all, we live to receive that happy thank you email from the customer who appreciates the value of your software in his life.

Im not a native english speaker. So please don’t be a grammar nazi and ping me for errors in the post. Im working on this part.  If you have understood the things I wrote above, I’d consider that the Job is Done.

If you have different thoughts on this, share them below in comments section. I’d love to learn from you.

Happy and Productive Engineer

We are Knowledge workers.

Software industry demands us to be creative in picking up good solutions all the time. We need to be committed at what we do continuously for years to come.

So our Mind is the most important asset. There is an absolute necessity to take good care of it.

Our to-do list is always full. We  always throw those extra hours at it coz we love doing it. We  say YES to everything. And we always take those weekends granted for something that can be done on the following monday.

But when the work we produce come out lousy, it starts to show up. Thats the result of a tired mind. The sooner we realise this point, the better it is.

Allocate good number of hours to whatever you work on. And focus on it completely when you are inside of it. But never work on it outside of those hours.

When we set our work patterns like this,

It makes it visible the line between what you can do and what you cannot do.

When we don’t know this line, we don’t know what to expect from ourselves. Thats when stress arrives in and in some worst cases - Burn out.

Prioritisation is an important step in any list we compose. That’s when our decisions start to become sharp and logical. Actions will become quick and confident. And thoughts will be so much more clear.

I believe that you always have to give up something to get something else. It is OK to accept that you can’t do/build everything. You would have to give up some of your secondary items in the list and choose the top most item for better results.

Sketch is awesome.

 image

If you are in any way associated with building software, you must get sketch app and play around. Designing software components in it is super fast. 

Here is why I think it is better than Photoshop.

1. 100% vector. I can zoom 300% into a component and design it to the very detail i want. 

2. Exporting/Slicing is freaking fast and easy.

3. The whole software is less than 20MB. 

Get it here.

Kicker - The creators have put together a neat website to list all the templates for web and mobile design. Checkout sketchappsources.com

Make it work. Make it right. Make it fast.

Be it a new product or a new feature or an enhancement or a bug fix, I follow this quite religiously.

1. Make it Work
2. Make it Right
3. Make it Fast

This is not new. Most programmers I follow do this. 

Make it work - first make the product do what you wanted it to do.

Make it right - Refactor it. Cut the duplication and make sure your code is easy to read and understand. It then becomes simple to maintain it.

Make it fast - if your product is slow, you suck. Big time. Measure the code and fix the bottlenecks. You can delight your users only when you finish this step.

Code review is almost always about the last two steps. If your team mate can’t do the first step, your shouldn’t have hired him in the first place. If he cannot do the last two steps - that’s ok. These skills can be acquired. Luckily, I work with good programmers. 

Don’t commit your code until you finish the third thing. You will have a better product if most of your team is convinced about all this.

I moved from Android to iOS

I wouldn’t have said this better than him.

Developers are not fools. They choose to develop for a platform if

1. They use it.
2. A lot of others use it.
3. They can make a living out of it.

Nexus was my first smartphone. The reason why I stopped using Android and went to iOS is because Android is incomplete. And iOS nails all the above points. Happy ever since I made the move.

Specs comparison is irrelevant

I’ve been seeing many specs comparisons like this - http://www.cultofmac.com/238464/moto-xs-specs-compared-to-the-iphone-5-and-galaxy-s4/ and I think it’s absolutely irrelevant for users.

Apple devices by trend live without problems for 2 years. During the same period they receive first class support in software updates. There is usually one iOS release per year and so in two years, the device can run two OS releases.

Since the device can run all the software without any problem during its life time, I feel the specs comparisons are just confusing and misleading users.

If you want to purchase a Windows computer, specs comparison between a DELL computer and HP computer makes sense. If you compare two android devices, it makes sense. And if you compare two apple devices it makes sense. Software running on each of the devices is same in such comparisons and specs affect how fast you can run it.

What journalists do is they take an apple device and android device for comparison. Which is totally wrong way of doing it. Because the software is different in each of them.

Poor non-techie people use such articles to take decisions. As if that single GB RAM is gonna help them launch a space ship next day.

As long as my device can run that latest game on App Store, the specs doesn’t matter.

Its not over.

iOS 7 redesign is not yet done. 

What was revealed in WWDC is just the start. They set the tone of the entire system. And in every beta, Apple is refining the details one by one. 

So any blogger who writes review about iOS7 should know about this. Many think that what they see in beta is final. There is a reason why they call it iOS7 beta.

Apple can’t change the entire design overnight. First they have to come up with the feel of the whole system and they have to gather feedback before finalising the design. That’s what they are doing now.

Only developers are given a chance to use the beta. Thats purely for the purpose of getting their apps ready for the new system.

If a journalist gets hold of it and starts to write review now itself, its like eating a half-baked cake and judging the taste of it. 

Lets wait and see. The problem is, people from the other world are starting to go hoo-haa about the negative reviews. They don’t know what they are talking about.

Rails 4 is Awesome

I have not been following Rails for a long time. WWDC and few other things occupied my time. 

Its been a month since ✨Rails 4 got released✨. And the changes are pretty good. Committers are so bold and fast in adopting new stuff on the web. I think it is one of the things that separates Rails from other web frameworks.

Removal of Active Resource for example. Frankly speaking I’ve never used ActiveResource. I’m sure its the same case with many other developers. Anyways - i feel its a good move to remove it from the framework. 

And adding support for Postgres HStore in ActiveRecord is my favourite part. There is always a need for such a data type in my work.

I was camping on the other side (Python/Django) for a while and I realised many times that Rails is a perfect framework to build things.

Happy to be back on board. 🍻

Top