Seeking Engineer For My Questionable Startup Idea

“Seeking an iOS engineer to build an MVP for my startup.  Applicant needs to have 3 years of experience.  Role is a paid part-time job”

I see posts like this on a weekly basis.  I appreciate the fact that people would like to get their alpha app built.  The problem is that building anything functional, pretty, and usable isn’t easy.  Even with an MVP where you can cut corners it still is complicated and time consuming to build an application, especially a mobile one. And people who are skilled at building mobile apps aren’t just chilling neckid on their couch waiting for the next opportunity (except for me). iOS developers are in high demand and good ones tend to have jobs making good money.

So what DO you do if you want to build an MVP?  Here are you choices

  1. Hire a freelancer from a freelancer site – You can hire a freelancer from one of these sites.  Your mileage will vary greatly.  Probably your cheapest route, but you get what you pay for.  Chances are you will get a piece of crap.
  2. Hire a local design firm – These companies specialize in building apps.  It’s easier to get a better product by using a firm than a random freelancer.  You can do research on their portfolio, have live meetings with them, etc…  And if they screw up you can hunt them down and smack them (just because they are local doesn’t mean they are good at what they do).
  3. Hire an outsourced design firm – This is a company somewhere outside of the US that specializes in building apps.  It will be harder to guarantee quality like you can with a local firm, but an outsourced one will probably be cheaper.
  4. Learn to build yourself – If you have the time it is worth it.  You know, to actually understand the ins and outs of your product.  But most people don’t have the time and learning can be tough.
  5. Build a disposable mobile web app – It’s a lot easier to build a web app that kind of works mobile than it is to build a native app.  There are a lot of responsive ui frameworks and templates to get you going.
  6. Find a tech lead that believes in the product – This might be tough because your product is probably dumb.  But finding a tech lead will be a long term investment that will help you go from MVP to real product to $$$

Good Luck,


Long-term Ownership Problems

Long-term ownership problems can plague startups and tech companies trying to move fast and build a lot.  By “long-term ownership” I mean the ownership of a product, application, service, feature, etc… after it is live in production for some time.  This ownership exists both on the product and engineering side.  Long-term ownership involves the ability to maintain, debug, fix, understand, and add features to an existing application.  Problems that arise include:

  1. Poor Documentation -Often engineers don’t document their code perfectly.  Product managers may not write the most detailed product specs.  It can be very hard to revisit a system without thorough documentation.
  2. Forgetting –  The longer it has been since a product was built the harder it will be to remember the nuances of a product.  Engineers and product managers may have worked on other projects in the mean time.  Even in the best case scenario there are good product and tech specs along with code documentation (which is super rare),  people will have to relearn a system.  This will take time and be error prone.
  3. Attrition – When employees leave for whatever reason they probably will not be able to hand over all of their knowledge to someone else.  System knowledge will get lost as people depart a company.
  4. Resource Allocation – As a company builds more and more features, it is hard to staff ownership.  A single person can only understand, remember, and work on so many products at once.

I feel that as time goes on, a lot of these problems silently happen.  This leaves a lot of products running in production in a very precarious position.  People have to scramble to fix or add to these products.  In a later blog post I will write some ideas on how to prevent these problems.

Good Luck,

Circuit Training

It is important to get cardio exercise in with strength training.  I try to run 1-3 miles 1-3 times a week, but sometimes it is hard to run.  Often I am tired from a previous run or I just don’t feel like running.  One of my big barriers to running is that it can be pretty boring, especially when running on a treadmill.

Circuit training is an excellent cardio exercise alternative to running.  This  training is basically a bunch of full body exercises, using body weight or some sort of added resistance, that are done in high-intensity.  You do a lot of different exercises at high repetition with little pause time between the exercises.  There are a lot of classes and fads that fall into this category, like boot camps, p90x, insanity, etc…  It is considered high intensity interval training.

There are a lot of great reasons to do circuit training.  Since you are mixing up various exercises together, it is not boring or monotonous like other cardio exercise routines.  You can strengthen various muscle groups while getting your cardio in.  To me it feels more effective/tiring than typical exercises like running, cycling, etc…  I am not sure if it actually is any better than typical cardio, but I’ve been told that since it uses multiple muscle groups it burns more calories.

Creating a circuit routine is pretty simple.  You can take a bootcamp class at your local gym and recreate the steps, or google for a routine.  Typically a circuit routine it is 3-7 exercises that work different muscle groups where you do high reps of each exercise (something like 12-20).  Usually you do a circuit and then rest.  You repeat this twice (so do the circuit 3 times total) and then move onto the next circuit.  I typically do about 3 circuit groups.  Make sure you are doing an intensity that actually causes your heart rate to go up and for you to get a burn.

Good luck,

Bathroom Chumps

Yesterday my friend Shama requested a post about Luna the kitty or bowel movements.  So I decided to write a post about bathroom etiquette.  Here are weird activities I’ve noticed at office bathrooms that should not happen.

Answering your phone – Don’t answer your phone in the bathroom.  The person on the other end of the call doesn’t want to hear bathroom noises and people in the bathroom don’t want to hear your conversation.
Phone sound effects – Sure your phone’s default is to make a noise very time you press a key.  But do you need it?  All those noises disturb people in the bathroom.  Put your phone on silent.
Whistling –  Same idea as above, people don’t need to hear you whistle in the bathroom.
Multitasking – We are all in a rush, but you don’t need to brush your teeth while you use a urinal.  It’s just weird.
Open your pants at the urinal – This seems to be a new fad.  Don’t undo your belt and pants at the urinal.  Nobody wants to see your butt and undies.  Your pants have a fly, use it, you aren’t 4 years old.


Good luck,

Know-It-All Nerd

In my last blog post I mentioned the “know-it-all nerd” and how he ruined my hackathon experience.  I got a little heated reminiscing about the hackathon so I figured I would write a blog post about the archetype.   You probably know the type of person I am talking about.  He or she is always correcting everyone, whether it is the pronunciation of Nicaragua or the “proper” definition of a monad.  He or she is uncompromising and always has to win every argument.  It doesn’t matter if this person is correct, they need to appear correct and better than others.

I am not sure why people act like this.  I guess it is some sort of superiority complex.  Maybe it is because they weren’t good at sports as a child and decide that life should be competitive.  Maybe their dying father said “always be right no matter what.”  Who knows.

If this sounds like you, please stop acting like a know-it-all.  There is a funny Simpsons quote where homer tells Lisa “I’m really glad you corrected me, Lisa. People are always really glad when they’re corrected.”  Make it a new years resolution to stop alienating yourself from your friends and co-workers.  Someone (me) might smack you if you don’t stop.  And if you must must must correct people, at least be CORRECT YOURSELF.

Good Luck,

Hackathons Are A Pain

Hackathons are these competitions where a group or individual builds some application in a short timeframe.  I suppose it is a marathon of “hacking.”  There are typically two kinds of hackathons, public or internal to companies.  While there is something special and exhilarating about staying up all night and building a functioning application to present, more often than not it is completely not worth it.  Let me share some examples from my life to help you decide if you should participate in one.

Lame Team Members
I participated in the hackathon with a friend and some other guy.  I was building the iOS app, my friend was doing design work, and the third guy (I will call him ‘J’) was making the landing page and doing some backend work.  There were a lot of problems with the team, but the biggest problem was with ‘J’.  He was supposed to parse some public dataset into a SQLLite database to load into the app.  SQLLite doesn’t have a date type, so I asked him to parse out the time pieces so I can sort and filter better.  His “know-it-all-nerd” friend told him not to do it because he figured I could do some transformations on the date or something idiotic.  I had told him this wasn’t performant, but he seemed to not care.  I was doing the majority of the work for the project, and then I had to also take on another teammate’s work.  Thanks know-it-all-nerd guy.

Judging Criteria
In another hackathon, I was again building an iOS app.  I admit I wasn’t the greatest teammate, but we had a working demo by the end.  To my surprise a lot of teams didn’t have working demos and just had powerpoint presentations.  In the end, a lot of teams that won awards were merely powerpoint presentations without any working code.  It seems the ‘hack’ part of the ‘hackathon’ was a suggestion.

Empty Promises
There was a hackathon at my company that my buddy participated in.  The promise was that the winning team of the hackathon would get time and resources to get their project into production.  My friend’s team won but unsurprisingly the project was never prioritized and never made it to production.  I’ve actually heard this happen at a lot of companies.  Though to be honest, sometimes the projects do make it out into production.  It can be hit or miss.

Hopefully these anecdotes can help you make a better decision on whether or not to join a hackathon.  In the end it is your time and sleep so do as you please.

Good Luck,

365 Day Challenge Isn’t Great

Recently a friend of mine challenged a bunch of us to the 365 day challenge.  For those of you unaware, this is a challenge started by Zuckerberg (good ole zucky) to run 365 miles in a year.  The goal is to get people more active and to live a healthier lifestyle.  But this specific challenge irks me.  I truly do not think it is for everyone and I think it can do some harm.

  1. Running is a high impact exercise – It can lead to injuries of the knee, leg, neck, etc…
  2. Pushing yourself too hard leads to bad form – You fall behind on your schedule so you push yourself harder.  Bad form leads to injuries.
  3.  I don’t get a runners high –  Maybe 1 / 20 times AFTER running i feel energized.
  4.  I hate running – I currently run 1-3 miles 1-3 times a week and I hate almost every minute of it.  If I were to run 365 miles at 6.5 mph, that’s roughly 56 hours of running.  Why would I want to spend 56 hours of my year miserable?
  5. Running so much takes away from other exercises – After I run I am pretty exhausted.  I cannot lift as much, play a sport like boxing, or do circuit training.
  6. Strength training is important – Muscle has countless benefits from burning more calories (than fat) to making it easier to move something heavy in your home.  Only running ignores most of your body.

This challenge just seems like setting yourself up for failure.  I know some of my points are specific to myself, but they apply to many people.  I think a better challenge would be to exercise 365 times.  Run, walk, lift, play soccer, whatever it is as long as it is a unit of exercise (probably minimum of 30 minutes).  This way you can align your exercises with the body goals you have.  Also, allowing different exercises can make the challenge easier for out of shape people to commit to.  A person walking and lifting weights 365 times in a year is better than someone running a 10 times and giving up.

Good Luck,

Good Feedback is Hard

I am sitting in a local coffee shop as two gentlemen discuss a startup that one of them is working on.  Their conversation reminds me how hard it is to both give and receive useful feedback.  I do not profess to be a product manager so some of these ideas might be obvious to you, but I feel like bad feedback can fall into the following categories:

On The Giving End
1.  Circle Jerk.  Sorry for the crude term, I acquired it from my friend Francis.  Basically, this is when people try to get each other off.  It’s when the person giving feedback just blindly approves and pumps the other person up.  We all need a good pump up every now and then, but we don’t want a “yes man”.
The two men at the coffee shop were discussing some silly app idea regarding coffee that had me questioning the premise.  But his friend was all in, pumping the entrepreneur up, creating silly scenarios to validate the idea, etc…  The man said “that’s awesome” about ten times.  It’s awesome that the entrepreneur was trying to do something on his own, but the idea was definitely not awesome.
2.  Fixer.  On the other end of the spectrum, this person feels compelled to give some sort of constructive feedback.  He or she is trying to be helpful, but the feedback is not often not quality feedback.  Often, it is a very personal opinion that will have almost no affect on the adoption of your product or the satisfaction of the users.
3.  Your Aunt.  This is a person that isn’t part of your user base.  He or she doesn’t get what you are doing and will probably suggest something totally arbitrary.  If someone that is not in your target user base doesn’t want the product, that is not a big deal.

On The Receiving End
1.  Ignoring Quality Feedback.  Sometimes we will say “what does he know” or “she doesn’t know what she is talking about, she is just one person”.  But if that person is smart, experienced, and part of your target user base then you shouldn’t shrug off feedback so easily.
2.  Taking all Feedback To Heart.  Every user is special and will have one or two things that only apply to them.  Don’t drive yourself crazy trying to make everyone 100% happy.  Time is precious and you also don’t want to cloud your product.

I am probably preaching to the choir here, but thought I’d state some observations.

Good luck,

Prioritizing and Cost

Product prioritization is very complicated.  There are many variables that need to be taken into account to figure out what to build and in what order.  Unfortunately, it seems that cost isn’t taken into account often enough.  Perhaps at most the superficial cost is considered, but cost can be a deep and complicated concept.

Types of Cost
Direct “Bottom Line”

  • Salaries of engineers * time – This is the superficial cost.  Pretty easy to calculate
  • Hardware cost – An increase in load might require more hardware to handle more requests.  Implementing an open source system like ElasticSearch, Hadoop, Redis, etc.. requires extra hardware to run on its own.  “Big Data” processes tend to require a lot of hardware.  Complicated algorithms can take a lot of CPU time and might require more hardware.

Indirect “Blood and Sweat”

  • Opportunity cost – Your engineering resources can be building other things.  While this seems obvious, at a larger company an engineer can be working on almost ANYTHING on ANY team.  Product owners tend to only prioritize within their team, but a resource could be used on another team to build something else.
  • Technical debt – Almost anything that is built (especially in a rush) will have some technical debt around it.  As time goes on, the debt gets worse and everything gets harder to build on and maintain.
  • Pager pain – You rushed a system out the door.  It works, but it is held together with scotch tape.  That system breaks every other night at 3 am and causes pager alerts.  Clients don’t notice, but the engineering team sure does.
  • Engineer sadness – Building annoying features can add up on engineers.  You keep dumping on them, they will leave.

While the “bottom line” cost is fairly direct and measurable, the “blood and sweat” cost will cause engineering quality to go down over time and lead to engineers leaving.  This indirect cost in the long run can be more expensive than the direct cost.  Please think about these costs the next time you are doing product prioritization!

Good Luck,

Compromising vs Yielding

I find it funny how people confuse the concepts of “compromising” and “yielding” .  When you google the word compromise, the definition that comes back is “an agreement or a settlement of a dispute that is reached by each side making concessions.”  A lot of times in a work setting if there is a dispute or disagreement where there is no clear correct answer, management folks will tell the parties to compromise.  But often people will call the settlement a compromise when in fact it is nothing of the sort.  Here is an example of a compromise and a yielding.

During scrum planning, an engineer wants to spend some extra cycles refactoring some code.  The product owner wants to spend those extra cycles building a feature that has been promised to clients for a while. Solution
The product feature gets prioritized this sprint but next sprint double the amount of time is allocated towards refactoring pushing off other product features.
Time was allocated to build user libraries for an app.  An engineer wants to build the first library in python since most clients use python.  An internal team would like the engineer to build the first client in Java because they use java.
The java library is built to gain favor with the internal team.

Do you see the difference?  There is nothing wrong with settling an argument with yielding.  Sometimes someone has to make an executive decision, there is political pressure, or there is just a best choice.  However, I see no good reason to call it a compromise.  I guess saying something is a compromise makes the party yielding feel better about themselves.  But to me that misuse of the term is just insulting a person’s intelligence.  Transparency and honesty will make people feel better than trying to play a mind trick with them.

Good Luck,