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,
-Larry

Advertisements

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,
-Larry

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,
-Larry

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,
-Larry

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,
-Larry

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.

Compromise
Problem
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.
Yield
Problem
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.
Solution
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,
-Larry

Just Say No

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.

Good Luck,
-Larry