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.
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!
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.
I remember when I first started out as a software engineer in 2006 I had to “earn my stripes.” I did as I was told, learned from my elders, and tried to make suggestions here and there. If my ideas weren’t good I was told why and would either go back to the drawing board or move on.
Something has changed with the paradigm of management and engineers. It seems management is afraid to offend or bother engineers. Nobody wants to say “no” to an engineer anymore.
We allow engineers (generally junior ones) to
- Design overly complex systems
- Use random languages or frameworks
- Go against team agreements
- Merge code without reviews
- Be rude to their fellow employees
- Make inappropriate and sexist jokes
- Become “brilliant jerks”
Why are we afraid to stand up? I guess engineering talent is at such a premium that we don’t want to lose engineers. But guess what? A bad seed will make other engineers leave. Not only that, the bad seed will probably leave at some point anyway and someone will be left with the mess.
Be logical. Sometimes you will agree, sometimes you will disagree. Sometimes your opinion will be swayed by a good argument. But don’t be afraid to say no. You’re running a team, organization, or company and not a hippy commune.
A good chunk of America stuffs their face from Thanksgiving until the end of December. Some large percent of these chubbers decide to make a New Years resolution to go to the gym more, lose weight, get into better shape, etc… This yearly ritual makes January the busiest and most annoying time at the gym. Here is some advice for the resolutioners to be less annoying to everyone and possibly be more successful.
- Plan a routine and schedule. Go to the gym for an hour for three days, then take a day off, then repeat. Go at the same time each day. It will become a habbit
- Use weights and do cardio. Whatever your goal is, both weights and cardio will help you be healthier.
- Start simple. Blogs, message boards, and your idiot cross fit friends will tell you how you have to squat and jerk and clean and back flip. While those lifts are great, you are just starting out. Do simple stuff that you recognize. Use machines at first and slowly work in some free weights.
- Don’t hog anything. A gym only has so many free weights, so many treadmills, and so many benches. Do your exercise and move on.
- BENCHES ARE FOR BODIES. Don’t be that guy or gal that leaves a cell phone on a bench just to stand next to it. I don’t care if you are exercising next to the bench, unless your body needs the bench for an exercise let someone else use it
- Fancy outfits don’t help. Maybe get a good pair of sneakers. Your $500 lululime pants won’t make you run better or give you more strength. It will just make you look like snobby. Just get something you can sweat into.
- Toe shoes are useless
- Don’t do weird stuff. Yes the treadmill goes to 10 mph. Yes you can tie a weight to your waist while you do exercises. Yes you can add a free weight to a machine rack. Yes you can hang from the chin-up bar and do crunches. But WHY WOULD YOU? STOP BEING WEIRD. YOU WILL HURT YOURSELF
- Stop staring in the mirror. Yes, right after you lift your muscles look bigger. You own a mirror at home. Nobody wants to see your belly no matter how ripped you are.
- Eat better. Diet plays a large factor in gaining muscle and losing weight.
- Keep at it. Just keep going to the gym. Things get easier and feel more natural.
Good luck and stay away from my boxing bags