Every now and then I get a recruiting email talking about a “startup within a top bank” or “startup environment within a top financial institution.” If you are an engineer then you probably have received these emails too. This concept is completely ludicrous. I am not knocking working at a bank, just the selling point of a startup at a bank is a complete lie and bait and switch.
I am pretty sure big banks don’t even know what it means to be a startup or have a startup culture. The only things they know about startups is from what they read in FT (Financial Times) about game rooms at Google and what they see on the TV show Silicon Valley. I was once talking to a Managing Director at a bank and he was trying to understand why engineers were leaving. He said “I’ll put a damn Foosball table in the office.” Clearly he didn’t get how horrible it was to work in his group nor did he understand why engineers want to work at a startup. The old guard at banks sit on ivory towers and have no clue about how (many) engineers want to avoid politics, learn and use new technologies, make autonomous decisions, work in a relaxed environment, etc…
Even if there were some group within a bank that actually mimicked the startup environment, it is guaranteed to not last long. Banks are typically good with money and tend to have high turnover at the top. When a new big wig comes in he or she (probably he) will see this group as crazy, too big of a cost center, unprofessional, etc.. and will revert everything to whatever the bank standard is.
You can’t blame banks for acting like banks. You just have to be realistic with your expectations of what a “startup culture” within a bank will actually look like.
“I was supposed to go to the gym today but I think I will just go tomorrow”
“I will work on my side project tomorrow”
“I will update my resume tomorrow”
How often have you heard or said things like these quotes? How often have you pushed something off until tomorrow for no good reason? You say it with the best intentions and actually plan to do something tomorrow instead of today. But it seems that fate / bad luck doesn’t like this and something will come up tomorrow to ACTUALLY PREVENT you from doing what you want. Maybe you will wake up sick, the gym will be closed, you have to stay late at work, your laptop dies, etc…
Don’t push anything off without a good reason. Fate will smack you for doing it.
“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
- 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.
- 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).
- 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.
- 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.
- 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.
- 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 $$$
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:
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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.
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.
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.
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.
- Running is a high impact exercise – It can lead to injuries of the knee, leg, neck, etc…
- Pushing yourself too hard leads to bad form – You fall behind on your schedule so you push yourself harder. Bad form leads to injuries.
- I don’t get a runners high – Maybe 1 / 20 times AFTER running i feel energized.
- 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?
- 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.
- 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.
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.