Anand

I am totally in love with The Breakpoint series.

Check it out - http://www.youtube.com/playlist?list=PLVUliVBcvz1n_DOgB4lb06G_Dc5fQVRRv

Thanks Addy Osmani, Paul Irish and Google!

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. 

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.

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.

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

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’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.