About

I'm Sunil Shenoy: a programmer, UI designer and a movie buff. I currently live in Mumbai,India.

Namaste. Be Good.

Projects
/now
Code Snippets
Social
Travel

ADVERTISEMENT

DigitalOcean Affiliate Banner

It just works

Apple made these words popular. Every time they spoke about their hardware product Mac, it just works were words they kept repeating. Focusing on making a product which just works is so very important.

It feels good when you are using a product which just works. You feel in control and overall happy when you get the software / hardware to do what you want to do.

It’s easier to down play the importance of well written software or even hardware products. Why don’t you just create something, put it out there and see how people react to it being an advice we have heard far too many times. But I hope you are not giving this advice a lot of importance. Yes, it is important to launch, but it is equally important to make sure you think through the whole user flow before releasing it.

When the user feels less in control, they leave. Only a few users will take the time to send you feedback.

::

Whats your tech stack?

I am obsessed with trying to find out the tech stack behind popular web services. What tools do tech companies uses to run their startup?

Stackshare.io has been my goto place to peek behind the curtain of popular tech startups.

Its easy to overthink your own tech stack, when planning for the next web project. Should you choose AWS or Google Cloud? Redis or Memcached? Logentries or LogDNA? PHP or Ruby? There are so many options to choose from and its easy to spend a lot of time reading / comparing all the options.

Its equally important to commit to one and start. The stack would matter much if you never start and learn how the particular tool you chose performs. Outgrowing the tool and moving on is a decision to be made later.

PHP, MySQL on Amazon RDS, Heroku, LogDNA for logging and Redislabs are the tools I am starting with.

::

UX Designer

What does a UX designer do? I have been thinking about this since yesterday.

Whether you land a job at a startup or a larger corporation, your role as UX designer will be directly involved in the process to make a product useful, usable and delightful for that company’s intended target user group.

A UX Designer should be concerned with the whole design process, rather than just one part.

The Differing Roles of the UX Designer | UX Magazine

User research and usability testing have been topics of interest to me since more than 7 years. Would I consider myself a UX designer? As of now, no. You become good at doing something when you are put into practise what you have learnt.

I should start dedicating more time to writing, reading and improving user experience of softwares that I work on.

::

Prototype

I have never had this be part of my software development approach before. Prototyping the entire app.

Last month I got to see an app which was full prototyped. The sign up flow, the login screen, the dashboard along with every app interaction. An excellent change to software development cycle.

My approach to software development was Idea > Research > Design > Frontend development > API’s integration with mock response > Test(and fix issues) > Tweak UI / Design / UX > API development > Test(and fix issues) > Release.

After having tried the prototype, I am now going to update the approach to be Idea > Research > Design > Prototype > Tweak UI / Design / UX > Frontend Development > API development > Test(and fix issues) > Release.

Prototyping the app helps you think about every user interaction even before you start building the app. Using the prototype for a couple of days would help you get to the missing features earlier in the software development cycle. It’s also makes it easier / faster to share the final vision of the app with the client / team and get their feedback.

::

Right amount of time to create an app

How long should you spend on the initial version of the app? In my opinion, 4 months is the right amount of time. This considering that you are building an iOS / Android app on a cross platform tool like React Native for which the API also needs to developed.

Anything less than 4 months and you start to cut corner and rush features. 4 months should give you enough time to build the list of features and ensure that it works on both platforms.

Any longer than 4 months and you start to feel like you have been working on the project for too long without getting any feedback from the user. It’s important to get feedback as soon as possible.

::

React Native Packages

Some of the packages I have found to be really helpful in apps I have been working on.

Vector Icons
Customizable Icons for React Native with support for NavBar/TabBar/ToolbarAndroid, image source and full styling.

Bugsnag
My favourite tool for recording bugs. Error monitoring and reporting for native exceptions and JS errors in React Native apps

DatePicker

Image Progress
Progress indicator for networked images in React Native

htmlview
A React Native component which renders HTML content as native views

Snackbar
Material-design "Snackbar" component for Android and iOS.

Storage
Local storage wrapper for both react-native and browser. Support size controlling, auto expiring, remote data auto syncing and getting batch data in one query.

Swipeout

React Navigation
Navigation for React Native done right.

::

When will it be launched?

This question being one of the trickiest questions to answer. Especially when its about software you are working on.

I have been working on a mobile app since about 6 months now. There is API to be built and also the UI of the app. Laravel and React Native being my tool of choice. This is the first time I am using these tools for such a large scale project.

I have been developing software since more than 10 years now. I have come to terms with scope of work being an ever changing document. As you start to use / build the software, you realise you missed adding that one feature or did not think about how the UI would handle X scenario.

Ever changing scope of work although does not help with setting a fixed launch date. More features mean more edge cases, bugs, UI updates you did not estimate for before.

It’s also easy to loose focus/motivation if the software is not launched within a month or two of you starting to work on it. Loosing interest in work also leads to features now taking longer than expected to finish.

It’s important to have a launch date. A milestone, you are working towards. When the scope of work changes, look at the list of work which remains to be done and remove items which are no longer as important as the new feature/ bug being considered.

With most software now being hosted on the web, its easier to add features / fix non critical bugs after the initial release.

Always have a launch date for the initial release. Helps you focus and it’s good for morale.

::

How Do You Focus?

Continued from yesterday...

Writing down tasks

I have ignored this advice since a long time now. Almost every Getting Things Done book I read recommends that its a good idea to write down tasks you need to work on. The brain can only remember so much and its easy to drop the ball on all the tasks you have juggling.

Ever since I have started to record all tasks I need to work on, my mind is more at peace. I now start the day by looking at all the tasks I need to work on and move them to the “Today” list.

The feeling of seeing the “Today” list empty at the end of the day. Priceless.

Night Mode

We all need un interrupted time to work on tasks. Being constantly distracted is no way to work.

I now have my phone in night mode from 2 PM-5:30 PM. No reason to look at the phone when the screen does not turn on.

Highly recommend this.

::

How Do You Focus?

A few people have now told me about this book, Deep work. In an ever so distracted world, it hard to get into the zone and focus on the task at hand.

Without deep work, it is hard to make progress on the task at hand. Cutting corners, not giving the task enough thought are all results of being constantly distracted.

Acknowledging that we are way more distracted than before is Step 1. Now that we know we are surrounded by distractions, we can take steps to tackle the distractions.

Saying no to app notifications was my first step towards tackling the distractions
Lets Talk About Notification

Having turned off most app notifications, I was paying less attention to my phone than before. Apps now got my attention when I was ready to give it my attention and not the other way around.

Tracking screen time

I started to set fixed time to when I would start / stop working on a task. Instead of work day being 7 am till whenever I felt I sleeping, work day was now 7 AM till 6 PM. Having a boxed time, ensured that I was working on focused tasks.

More in the next post tomorrow…

::

Imposter’s syndrome

I have had this blog post in my unread tab since about a week now.

I haven’t experienced imposter syndrome, and maybe you haven’t either

I got around to reading the post today and could not help but relate to starting few words of the post

"In the course of my day at work I will often wonder if the next bug is the bug that will finish me.”

As a developer and a person who looks after servers (is this called DevOps?) I always feel like the knowledge I have is not good enough. It’s not that I am not capable of creating good UI or that I can't develop software which works well and help users. Its just that, when I look at other people’s codebase which has a better UI, better logic on how they approached the problem, I feel like I am lucky to be paid to do what I do for a living.

Last week I took part in a code review process and while explaining part of the code to the developer from other team, he asked why I had not tried “X” to resolve the issue I had experienced and spent considerable time working on my logic. X clearly was a better solution, but I had never heard of it.

I have started to accept that there is always going to be a gap in my knowledge and learning something new is always the way forward.

::