I am not a Computer Science Engineer and neither am I from any of the IITs. I have never for once had a formal training on any technology. I just have had a long term committed relationship with technology.I love it and it loves me back.I have learnt almost everything on my own ; from the web, from my peers, from my mentors and endless errors which called out “Object reference not set to an instance of object”. I still learn from them.
This piece is about my journey of founding technology at a start-up. The challenges, the solutions, the skills and most importantly, the delight. It will not go into core technical details or specifications.
Here is a list of 7 things that in my opinion, are most important.
1.) Find a mentor.
You need someone to look up to and put things in perspective for you. Building a product is not just about the hardcore technology , it goes beyond that, like timing, sourcing, hiring, people management etc. This stuff can only be tackled with a combination of knowledge and experience. While you might have the former, it definitely adds a lot to get more of the latter.
2.) Be pragmatic and understand trade-off.
Some teams are exceptionally talented, some lucky, others have coded their luck. If you are in the last bucket and are bootstrapping technology, you will end up making a lot of choices. Time, money, knowledge — everything has a limited supply and you just hope to cling on till that supply increases.
You will be forced to choose between writing the most scalable code vs just posting the form and pulling the data; between getting a UX guy or buying the template off the net; between outsourcing or getting an intern or hiring that guy full time.
There is no right answer, you have to be pragmatic and understand trade-offs of NOT your product but your business.
3.) Open Technology stack — source and code.
I have seen and lot of people debate over the “best” programming language. Ohh.. PHP is not scalable, .NET is expensive and closed, Python is marriage material etc.
Its all about a personal choice actually. If your product will stretch languages to extremes of computational abilities then its a different case. If not, then anything that gets the job done , that you are comfortable with , that has a community of at-least 5000 people is best suitable for you.
Scalability is a software/infra design attribute which you try to balance out with fx(ability,infrastructure, time) →costs. If I write a program that takes 200 Mb of RAM per thread and back it up with servers provided by aliens, it would be scalable.
4.) Don’t hire the cliched rockstars.
Coding is about aptitude and attitude. If you get these things in a person that aligns to yours, you take them on-board and let them learn and perform. A “rockstar” engineer would be a technology loyalist, but you need people who are product loyalists first.
Aptitude does not change with time but attitude does. That is something very critical to look out for.
5.) Process orientation.
Learning and un-learning go hand in hand in the tech space. There are always new methods and approaches to same problems that keep on coming up with time.
Creating and adhering to certain processes increases confidence both with the tech team and business stake holders. Lack of processes lead to short-cuts which creates leaks in your system. You need to put processes into requirement gathering, scheduling, development methodologies, release management and deployment etc.
Its difficult at most times but every member of the team MUST be cognizant of the fact that processes are important and need to be there.
6.) Leverage services on the cloud.
There are some awesome services on the cloud which come under the umbrella of *aaS . AWS, Bitbucket, Teambox, Cloud9, Pluralsight,JIRA — these find their use-cases in most stacks. Pay for these services, just pay. You will save on a lot of sleep.
7.) Take risks.
Takings risks is a power that you have, you take it or not depends on you. Never ever be afraid to try out the new stack, the new technology , the new process, the new approach. You can never learn new things without taking risks and being comfortable.
We made a choice to develop one of our new tools on the MEAN stack. We could have gone with our existing expertise on the current LAMP stack. The tool did not exclusively call out for a MEAN implementation but we went ahead and did it. We ended up saving our development time instead. You need to keep on taking these risks.
This is my experience and its getting better by the day. Hello World — once again.