Thursday, December 3, 2015

5 Productivity Tips for Working Professionals

There is a quote from Late APJ Abdul Kalam, which working professionals seems to use and put in practise too often, "Always leave office on time." That goes on to say, 

"A person who stays late at the office is not a hardworking person. Instead he/she is a fool who does not know how to manage work within the stipulated time. He/She is inefficient and incompetent in his work."

Here are my two cents if you had wish to follow his saying and still be productive. 

1. Make A List

Agile is good, WBS are good, but on your personal level you should always have a list. A simple bulleted list, you make on your notebook, apps or NotePad.exe. But always write it down, no matter how better you think your brain is. And... put a tick, or cross it out when it is marked down. Let it be there for sometime before you trash it - it somehow motivates you to follow on.

Recommended App: Google Tasks

2. Put Your Devices In Sync

So you got this desktop where you do your work, and then you got the Macbook to carry around and that shiny Nexus in your pocket. And just add an iPad for the sake of it. Add the no. of devices and see productivity that is suppose to increase, get out of the window.

The best way to cope with this is to keep the devices in sync, at the best you would want to sync your emails, contacts, documents, notes and code?

I use Google Apps, DropBox, Evernote, SVN and iCloud and it really keeps thing sane. 

3. Make Your Phone Sleep

Damn the notifications! So you are writing your code, or feeding your baby and ding, and there turns your neck, and there you clicked on Reply, and there you are typing your heart out. Ok, so now, what was I writing in the code?

Make your phone in Sleep Mode, and put it down face first on the table. You can may be pick it up every 2hours and check what you had missed, but keeping it on and in front, or keep it in your pocket to tickle you every now-and-then will definitely take away the productivity, not add to it.

4. Put Everything in Place before You Begin

Getting everything in order before you even begin is work half-done. It could be as simple as keeping your coffee and water on desk, to making sure your graphics, designs, icons, web services documents and so on are in place and in one easy folder. Waiting for your design asset to download from company server or looking around in your files to see where is that SQLite structure will corrupt your work-flow and set you back.

Also, open the URLs which help you with work in your browser, and even the software that you occasionally use to get the work done. For me it could be Terminal, MySQL admin, Blasamiq, a Passwords file and so on. They are as close as Command-Tab (or Alt-Tab).

5. Procrastinate

Having a To-Do is good only if you also have the ability to add the tasks you jump into, into it first. Now, here you are designing your ERD and there you have a request from your HR to fill your employee information sheet. Basically leaving your task and jumping to another will put you in the Never Ending Work club, so whenever you get a new task while you are already working on one, and which is not extremely life-and-death situation, add it to your To Do list. And continue with what you were already doing.

So if you follow the above tips you can always leave your office on time and not feel guilty about it at the same time.

Tuesday, August 25, 2015

The Outdated Programmer

Suppose like Predestination, I have travelled back 10 years and met myself. Seriously, haven't you seen the movie? So I meet myself, and advise him, errr, me, "Dude, Learn Java!". But I say, "No, I love compilers. And how the hack do you create Windows app with Java (that people buy)?". And then I say, "Dude, drop your Windows." And then I say,  "Are you serious? What should I code for then, Nokia?" And I give up, there is no arguing with the younger me.

Now hypothetically, assume another me, the future me, comes and meet me now. See me coding Objective-C and running on iPhone 6 Plus, and says, "Dude, Learn Swift. The Apple Micro-oven doesn't support Obj-C anymore."

So what can we get from this, either Predestination got into my head or I am trying to make a point. What is the point? If you make no mistake in your life, you are stupid. If you make the same mistake twice, you are fool.

The other point I am trying to make is, embrace the technology as it comes. I have personally witnessed the upcoming of Windows, Java, .NET, iPhone, Android, each one taking over the predecessor technology and moving forward. For sure, the first version has always been crappy, and the already established VB6 can do so much, and make an OLE connection, which the new one can't. But guess what, the new one gonna get better while the old one get stuck where it is now. And then you are moving with the time, and your tool is not. This is certainly not a situation you want yourself to find yourself into. Keep your ears open to the upcoming drumbeat of the newest disruptive tech, and be ready to learn it as quickly as possible.

Keep calm and learn on.

Saturday, November 30, 2013

Emergency landing.

Recently I was flying on IndiGo. The pilot announced, "We are expecting to land before schedule, thank you for flying with IndiGo". Somebody had a heart-attack! The air-hostesses started running around with Oxyzen cylinders and First-aids, the pilot again announced, "If there is any Doctor please let us know." I was thankful I was not a Doctor.

Then the dreaded, "We need to make an emergency landing at Lucknow to deboard the patient." Ah, there, we were expecting to land before time and now it would be delayed by like 10 minutes. Land, deboard, fly again. Yes, right?

No. After the patient was deboarded,  a set of process started. The engineers inspected the plane with their usual colorful forms, the agents checked every hand baggage to check whose who, the air hostesses made a detail report over the patient heart-attack and steps taken. I think even the air-plane was wiped clean and refreshments were quality checked. After 1 hour of impatience waiting of the customers, finally the pilot announced, "We are clear to take-off."

The point? A business is not run by couple of competent employees or sharp decision makers. The business runs on a "systemetic process". If you don't have every step of your business operation and process documented and transparent, you are running a hobby not a business. The number one rule of growing your business is to have a process and follow it. No matter how inconvenience it is to your employees or the customers, or yourself. Following the steps while minute to minute product versions or "patched" builds are given to end users, will ensure a turbulence free flying of your business.

Sunday, June 16, 2013

5 Commandments for Programmers

If you are in the business of software, under layers and layers of encapsulation you are selling a program. A program that couple of programmers has made for you, the brightest of your sales people can only get the program into your customers computer, and make them pay for it. But what if the customer says, my computer is in kitchen and the heat is making your software not work. Your sales people blanks out, and you start looking inside the contract you made with the programmers who coded it - did you take care of this situation?

Programmers are smart and sharp people, they think logically and king at solving problems. Here is the deal, everyday they are not the right smart, sharp, logical or in the mood to solve the problem correctly. They would use the above four qualities to make the program pass quality control. If you are betting your business and hence your life in the programs made, spend a little time ensuring your programmers are not sinners and following following commandments:

Thougshalt write secure programs

This world is divided between two categories of people, good people and bad people. Bad people make sh*t happen to good people. They make illegal copies of your software, break into your databases, causes havoc on your web applications and just for the fun of it.

Programmers can at least make the job a little difficult and hence less fun for them to crack into. Not only can your prevent illegal distribution of your software, you can prevent the sensitive data of your users from leaking online.

Web applications are the most easy to hack, look over XSS, SQL Injection, XSRF, Phishing, Web servers/MySQL security holes and more.

Software reengineering gives your competitors advantage to look in to your programming logic to copy the features more easily, specially if you are using languages like C# or Java. Look for tools that can make that difficult.

Thoughshalt design better

Design your architecture, and then design again. And then go back and design it yet again, and once you are coding everything and done everything. Dump it and do it once more. Don't rely on the programmers experience, rely on the Design Patterns. Programmers are going to write the software that makes it run on your test devices, and run perfectly. But a year down the line, you can't sell the same software, your cheapest competitors has the same features. You need to add and modify things, and you open the dusted svn repository, and voila not even the same coder can figure out whats going on.

Here is the good part, programming practice is here for almost three decades. The knowledge has been passed from generation to next, and only for the fact that programmers don't have this knowledge doesn't make it obsolete.

Learn what are the design principles and follow them.

Thoughshalt test

No matter how much truthful the statement is that every line of code need to be tested as soon as its compiled, I can't end up seeing coders who don't test. Where and how they get the notion that programmers write code. No! Listen, programmers test their programs as well.

Programmers test their programs.

Got it? You need to write code to test code, simulate and call the methods that you have just written. Just because it has compiled doesn't end your job. Don't punch the attendance now. Wait, run it, see the log output - you are doing debug.print, aren't you? Your testers don't have the privileges to dry run your code, set breakpoints, see these logs or use your IDE's swords. You do. Use it. Cut some bugs before it passes to people who are handicapped with just your program and a test environment. Start testing or leave programming.

Thoughshalt communicate

Great software are not made in solitude. No Mark Zuckerberg didn't coded Facebook from start to end, sooner he had Dustin Moskovitz, followed by many interns. And then a whole group once Peter Thiel invested in FB. The idea is simple, you need to discuss over the design issues you face, code that you write, the algorithm you implement. Technical discussion over the implementation details is not a waste of time, its savior for the later maintenance issues. 

Thoughshalt handle exceptions

There is an interesting method called assert(), it ensures the condition passed is correct and abort there if it fails. The assumption made with assert() need to be correct for your program to work correctly. But guess what, its a debug tool. Your help guide is not coming with a print of your assert statements, (which are already removed if you have defined NDEBUG). The file which is suppose to be there, is not there on that computer. Usernames can have ', users have meaning to e, ē, ĕ, or ė. Network connections can't be relied, users behavior can't be relied. Please do not let your program crash, with technical jargon printed over the screen. Think whats the best you can do in the exception block other than printing an error.

There's the rules I can think from the top of my head, don't end here. There are many good books to look into, check out:

97 things, pragmatic programmer, code complete, hf oops.

Want to work where advocacy of beautiful coding is followed? Check us @ Retina Software 

Monday, March 18, 2013

Are we lazy programmers?

When we were young programmers, someone said they are learning programming HTML. Now, some might not understand it - but its the biggest LOL moment for anyone. Dude, HTML is not a programming language. Without much change in earth magnetic fields, the world is upside down now, HTML5 is now a mobile app development language. You can really make apps that sells in AppWorld for BlackBerry and other devices programmed in HTML programming language.

The other habit that we programmer have formed is of pressing the Run command almost as a nerve reflex, written a function, build&run. Added a blank class, build&run. Declared a variable, Build&Run. The habit to try to run the program and see fast results, is, well making us do do quick fixes than doing it right. Again, running compiling and running programs were just a lot harder in old days. And hence it was more welcoming to actually review the code with eyes and ensure of resolving bugs before doing a compile and link.

Getting to market was even more harder, required budget. When we used to write programs for Visual Basic, it created SETUP than spanned to multiple floppy drives (VB has an option in installer to support multi-disk spanning). The disks were labeled in order and shipped to customers and reviewers. Don't get me started on how many disk failed during transitions, even after putting Handle With Care on the envelopes. Now we have the AppMarket concept, just build a fart app and upload it online.

So are the new generation of programmers actually lazy?

Actually programmer is becoming a more broader word, we need to create new words. Like the way we differentiated coders and developers. A developer has to analyze a problem, design a solution, implement with code and test his work.

The question also depends on the Company you are employed in, if you are working in a company making "Flashlight" app you might do well being a lazy programmer. If you are in one requiring Tzinga every hour, your better off going more traditional.

"So do you want to be a lazy programmer all your life, or join us and change the world?"

No offense intended for HTML... programmers, ah cr*p.

Saturday, September 29, 2012

First Step to Learning Programming...

I had a terrible start. Around 17 years back I decided I will be a computer programmer. My first serious encounter with programming was "C". I was from ICSE board, and they had BASIC not even C as part of their academic. We had DOS those days, and had to remember the commands. Loosely talking there were BIOS calls to be made after setting various bits in the CPU registers to get things to work. There were no background process other than TSR programs. Achieving graphic result was accompanied with tons of secret codes, even some ASM.

We didn't have Internet. Damn, there were no mouse! It needed to be typed, there were very few books detailing the secret weapons. We were hearing from distance horizon of something called Java cooking up. We read, it runs inside a box and no system calls can be made. It wouldn't have been used either for serious UI based application nor for writing any background service. I don't worry what Java 6 or 10 has now, but that's how it was in 1996.

Things are changed now. Instead of calling interrupts, we call the APIs or damn me we call the "Framework"'s function. Things are encapsulated at such a detail that your compiler will even help you run your code in 32 or 64 bits computer with almost no effects.

So whats the point? When you drop Internet, when you drop your Superior High Level Language, and when you seat naked with your command line based compiler, then it makes you do one thing that you absolutely and essentially need to be a programmer. That is, Think!

Sunday, September 9, 2012

Where you work matters!

Private software companies have made quite a bad reputation. Once a government subsidiary bank manager visited me and during talk he said right of course you wouldn't have been placed that's why you're seating here. One of the employee's (who run away lately) mother came to visit me, and reasoned that there would be better prospect of finding a good girl if her boy was working in a public company.

In the Jungle of elancing, software companies main theme is do as many projects as possible with the lowest possible paid workers. Paid by Quantity not Quality. Before you start damning your employer, it is your equal fault to be working there. Nobody has fastened you to your seat but your paycheck, if you are working at a place which is no better than a sweet shop, it is time to break free.

Jerry McGuire woke up in the middle of the night and started writing a mission statement for his company, he copied it and passed it on to all his staffs at work. It said, `Fewer clients, less money.` A week later he was fired, because the mantra of success of service industry is `More clients, more money.` McGuire was not the founder of the company, he was an employee. But is it a curse for an employee to write the mission statement of its company if you were already giving your sweat and blood to it?

Software companies need to advocate a place of openness where free flow of idea can take place. It should not just be the products getting focus, but the process as well. The vision of the company need to be induced in each employee of the company. Attend the clients that bring value to the company. Do the projects which sharpen your portfolio, bring quality process and stick to good code design. Use private networking to increase openness. Focus on getting it done to getting it done right.

As an employee, rebel to the conspiracy. Bring change to the process. Go agile, use source code control, make UMLs and build user friendly scalable and maintainable software. Stand up to the politics, and don't be afraid to pass above your immediate supervisor if you wish to bring a good change. And above all be the change you wish to see in others.

Of course, if you wake up to write mission statement for Retina, promise you wont be fired for it.