To be ultra useful, add a "copy to clipboard" link, more spacing between the generated url and the search box, maybe wrap the generated url in a textbox, bigger font and more centered.

Another: add password protection. Say I want to share my daughter's birthday photos with my friends, I can have a url like fry.io/{hername} and also have it password protected. That will add value over bitly or goo.gl.

Just my $0.02.

Spot on insights, couldn't agree more. It takes a great deal of self discipline to shut up and really listen, but it definitely pays off in long term relationship and reputation.

1. People usually start a side project because they are unhappy at work. If they are unhappy, they are unlikely already giving their best

2. On another note, a side project often gives your a great deal of satisfaction, accomplishment, control and responsibilities that you wouldn't get in your daily job. This balances your morale and will make you perform better both at your daily job and at your side project

3. I worked on a number of side projects in the past. Some successful, some not. But in ALL of them the learning was priceless. I didn't start side projects because I wanted to start a business and go all-in. I did start them because I wanted to learn things that spaced beyond my daily tasks at work. And it worked brilliantly.

Also, if you've a mortgage to pay and a family to maintain, you have some responsibilities that make the "go all in" move quite a big risk. And I do believe it is possible to start a business starting as a side project first - it just takes much more time and energy and, most of all, patience.

People with real families and real responsibilities normally can't quit. Doesn't matter how much they want to.

Agree on your second point - it should be called a side project. It's a startup / business from the day it actually _does become_ a business.

Sounds exactly like the person who plows every cent of otherwise disposable income into a startup, while risking their employment by reserving a portion of their mental/creative energy for their own thing, instead of whatever shitty product their employer is churning out.

You decided to get out of your comfort zone, at your own expenses - not many people are that brave, and this will always pay out. Even if it doesn't work out for your startup, you know you tried, and you did your best. If you didn't even try, you would have spent your life wondering what would have happened if you did.

This will be a huge learning experience for you that at the worst may land you a highly paid job in some company looking for techies with horizontal knowledge that spaces on growth, marketing, business development, product, etc... - it is very difficult to acquire all these skills while working as employee.

Persistence is key: keep getting feedback (from customers, entrepreneurs, competitors' study, ...), keep improving the product and don't waste your time thinking about failures, depression etc... - they are just energy drainers. Whenever your brain starts sidelining on these sad topics, just think "what can I get done in the next five minutes?" - it may be answering a support ticket, fixing a bug, changing copy, implementing a new A/B test, etc... ANYTHING is still better than thinking about failures. You are failing when you think too much about it and do nothing to get back on track. And you DO have the energy to go ahead, so just go! You'll realize that very likely these 5 minutes will become 10, then 60, etc... and at the end of the day you'll feel a great sense of accomplishment.

You will be rejected a number of times. Your work and skills will be understated. A LOT. Entrepreneurship is a great toughening experience. Be a winner, believe in yourself and always work to proof people wrong.

Also, if you need more customers - would you be able to provide a free account to some early members, in exchange of some valuable feedback? This is one of the best product growth hack.

One advice though: if you don't need to, don't search for funding. Build a MVP that works, that customers love and make it profitable. Even if you have a very small set of customers. You may need funding when you decide to scale it - but that's a much better situation to be in (and your startup evaluation will be way higher).

Now, think about what you can do your next five minutes to improve your product - and do it :)!

Best of luck!

Whenever something gets really tough - you should be thankful, because if means that you stumbled upon a situation that only few people overcome (for entrepreneurs, many times this situation is depression), and now it's your chance to finally distinguish yourself as a winner.

FYI: http://1humor.com/img/upload/25062012104430-zone.jpg

I disagree. RDBMS are highly optimized for this kind of operations (including MS SQL in here as well) and you’d better off retrieve in the application layer only what you actually need to work on. Think about paging: why would you want to retrieve millions of records in the application layer when you just need a few hundreds to work on? You’re going to waste SELECT time, connection time, application layer processing time (as I believe you’re logic won’t be as optimized as the one that resides in a well optimized RDBMS)

2. Concurrency, avoid it if you can. If not, then remember that with great power comes great responsibility Avoid working directly with threads if you can. Work at a higher level of abstraction if possible. In iOS, for example: GCD, dispatch and operation queues are your friends. The human mind was not designed to reason about infinite temporal state—I get nauseous thinking about how I learned all this first hand.

Queue patterns are cool, but concurrency sometime gives you a great deal of performance improvement. Sure, it’s dangerous, fragile and can mess things up real quick. But I wouldn’t just exclude it because of this. From great developers _is expected_ great responsibility.

3. Minimize state as much as possible, and keep it as localized as possible. The functionalists were/are onto something.

Good point, without exaggeration.

4. Short composable methods are your friend.

Agree, as long as you don’t end up in a compulsing-composive behavior where you abstract and split every method into meaningless individual parts. I’ve seen pojects containing 50 folders, each of them with one file and one method, from people trying to follow this pattern.

5. Comments are dangerous since they can get out of date and mislead, but so is not having them. Don’t comment the trivial, but strategically write paragraphs if needed in specific sections. Your memory will fail you, as soon as tomorrow morning, even after coffee

Code should be self readable, and if you get to the point where it isn’t, then you may have to rewrite few bits. This is not always possible though, especially for temporary hotfixes or hacks. In this case, comments are a must.

6. If you feel one use-case scenario will “probably be ok”, that’s the one that’s going to lead to catastrophic failure a month in production. Trust your paranoid gut, test and verify.

I tend to be more concerned about the scenario you feel 100% confident about. In case of major failures, you’re going to be looking at the dubious parts of your system (scenarios, code, patterns) – making it more difficult to spot the issue, if it’s hidden inside a “safe” part.

7. When in doubt, over communicate all concerns with your team.

Communicate and discuss all concerns as well as proposed solutions.

8. Do the right thing—you usually know what that thing is.

Couldn’t agree more. This is very difficult to explain, but you may find yourself sometime writing code and you know that the right thing takes few hours more and requires more effort… don’t keep doing what you are doing just because “maybe you won’t need it”. Always go for the right thing. If you don’t, it is likely going to bit you back.

9. Your users aren’t stupid, they just don’t have the patience for your cut corners.

Or simply they don’t get your UX. User testing is key to success.

10. If an engineer is not tasked with the long term maintenance of the systems they build, view them with suspicion. 80% of the blood, sweat, and tears of software occurs after its been released—that’s when you become a world weary, but wiser “professional.”

I would expect every engineer in my team to write self readable, well planned, “long term” code. Even if it is for the stupidest internal tool that nobody else is ever going to upgrade. And most of the times this does not slow down development (short and long term). It just becomes automatic.

11. Checklists are your friends.

Kanban boards, checklists, basecamp, whatever helps your team to track stuff and get things done.

12. Take initiative to purposeful enjoy your work, sometimes this will take effort.

True, although sometime you have to do the boring parts as well – you’ll have to do things who sucks, to make sure your customers won’t.

13. Silent failures, I still have nightmares. Monitor, log, alert. But be wary of false positives and the inevitable desensitization it leads to. Keep your system senses clear and alert.

Spot on. Don’t end up with a notification system that sends you thousands of exceptions to your mailbox everyday. You’ll start to ignore them and it’ll be difficult to find out real issues. Keep your monitoring clean. Fix issues, or deprioritize them.

14. At the end of the day, we’re paid to manage complexity. Work accordingly.

…and make complexity simpler for our users.

  > Code should be self readable, and if you get
  > to the point where it isn’t, then you may have
  > to rewrite few bits. This is not always
  > possible though, especially for temporary
  > hotfixes or hacks. In this case, comments are
  > a must.

* The code might tell you what it's doing, but not necessarily why it's doing it.

* You may be making use of legacy components that you are unable to rewrite. It may make sense to comment on their use within newer code that interfaces with them, making it possible for people to bugfix the interface without needing to delve all the way into the legacy component.

Your others points are really informative thanks.

I'm also a big fan of building transactional updates in "service-space" and using transactional coordination to ensure ACID, rather than making bulky stored procedures to churn over bits of procedural data.

There is no space in the market for drama queens. If you can't give negative feedback now because of their feelings, how do you expect to give it to them when their company doesn't meet targets & expectations?

Negative feedback is priceless. It's toughening, it points people in the right direction and, sometimes, it helps to laser-focus (especially when it's pointless - eg remember when people asked for GANTT charts on Basecamp?).