Oct 10, 2013

day5 - beef jerky, culture, and why performance reviews are toxic

Reflections on beef jerky day - feeling like my colleague was a jerk

I'll just share the video I recorded at the end of the day. I basically felt like there was some gap in the engagement and accountability in the team.  You can tell I'm a bit pissed off in the video.



We are delusional as people

So almost immediately after recording, and feeling discouraged about lagging engagement, and thinking back on the day, I had a realization.  It's interesting the two of us incorrectly perceived our contribution and role in the team. Who was who's apprentice?

And we're just freaking two people! We are delusional.

Good intention to help people not be delusional
I can now better appreciate why organizations create measurements and performance reviews - so as to check members from becoming 'delusional.' For example, if my manager and I agree that I was a 4 out of 5, and have it on paper, then I can't come back and say 'but I delivered more revenues than he/she who also has a 4 rating!'

Performance reviews are used to avoid perception of unfairness.

But it's wrong
While I can now appreciate first-hand the organizational leadership's position in defaulting to performance reviews, I also believe that it is the wrong step to take.

What you really want are individuals to become more self-reflective, self-aware, and self-sufficient. You can't enlighten people by banging them on the head with 360 reviews. That only makes them less engaged and bitter and resentful. It is a sure sign of distrust at a deep level among the team members. Instead, focus on dialogue and communicate your grievances.

Instead, focus on dialogue and communicate your thoughts. Support each other and help the counter-party see the reality. Difficulty conversations aren't supposed to be done through mind-numbing written performance reviews using sanitized words. (Didn't you always love that guy who had no filter in his mouth and said whatever the hell came to his mind?)

Talk to each other. Know that hard is good.

Yet there's a tension
I can also appreciate the tension present here. It is the tension between having great people, and being able to scale growth. If you had to hand-pick and cultivate great people one by one, you might spend too much time recruiting for the team.

How are you resolving this tension in your organization?

Learning by doing

To see what this overall project is about, see the original 12appyDays entry.

Today was project 5 - a skeleton eCommerce site for beef jerkys.  On the previous day, we built a simple and simplistic site using google map api to show the path back to the car. And on the prior day (project 3 pickr), I wrote about the experience of how knowing what's hard is ... hard.

And I'm learning so much, because I am building. Lot more so than I could by thinking and reading. 

Oct 7, 2013

day3: ActiveRecord, Pirates, and knowing what's hard is hard.

Appy Days

This is a day 3 reflection for 12 days of coding projects. We also have link to source code and other info on github pages at http://12days.github.io/.

Prior blog about this project and its rationale are:
Day 3 Reflection

step 1 - User Stories
We decided to build a Flickr clone with a pirate theme, hence Pickr (source code). What I learned was not that mind-blowing. Nonetheless it is worth capturing. As usual, we started with user stories.  Something like the following:
  • As a user, I want to be able to upload my photos and delete them (paperclip gem)
  • As a user, I want to see a livestream of recent uploads
  • As a user, I want to see a stream of my friends uploads
Once we understood the expected behavior, and the general idea that it's a photo application, we were ready to build.

step 2 - Survey Existing Tools
First, it's great to leverage existing technology. For example, we used a gem called paperclip for photo upload. It saved us a ton of time to be able to use this technology.

Since we wanted to be able to see friends uploads, we needed to be able to make friends, etc., and that means we needed to authenticate a user. It also meant that for the first time in three days, we would be using a database. Thankfully, there is also a gem called devise, which makes authentication quite easy - it gives you almost on the fly the ability to get users to sign up for an account with password.

step 3 - Mapping Data
So the next step is invariable mapping the object model relationships. In Rails programming (and more generally in the model-view-controller (MVC) paradigm of programming), "model" is the business logic of data object. So for example, in this case, we would have something like the 'user' object, which would have 'photo uploads' and also have 'friends.'

Rails abstracts these types of relationships via Active Record associations. Using this convention, one uses syntax that writes out model relationships in more or less plain English, like user has_many uploads. Or photos belong_to user.

step 4 - have fun
And pirates ... well, we just want to have fun while working. Arrrrggghh!


What we learned

So, using gems like paperclip and devise, we set up the initial authentication and photo upload in no time. Before noon, we had a running app.

Then, even after sketching out database table relationships, we found that it was not very straight-forward to build the many-to-many relationships between users and friends, especially since we wanted to be able to allow users to interact on a permission-based flow of first receiving a request, and then deciding to accept or reject a relationship. It was pretty late in the night when we had all the models hashed out, and it fell to the more experienced among us (Josh) to do most of that coding and validation.

As someone less experienced struggling through the associations and related validations, what I learned was the following:
  • As a new web developer, we probably don't spend enough time thinking about database design and data associations. Frameworks like Rails has encouraged this by abstracting database queries. You no longer need to write SQL to look-up data. But, it is still necessary to build the right relationships, meaning one needs to get into the mindset of thinking about how data is stored, and what the relationships between data tables might look like. It's easy for those experienced, and yet very abstract and difficult to handle for those inexperienced.
  • Development time is hard to estimate. This is a truism. But, part of the 'hack' of placing a one-day constraint on building a product is to limit the error in estimation. Even so, it seems, we are notoriously bad at estimating our progress and estimated time to finish. We are often mislead by early success (as we were with a skeleton of a working app by noon). The harder pieces happened to come later, and took quite a long time to build.
  • Unless you've built it before, it's hard to know what's easy and what's hard. This is a catch-22. I would think that this insight is useful from hiring point of view. Why does one hire a senior developer vs. a junior developer and what does senior mean anyway? It means that the developer has built the very piece of technology you want, and knows exactly how hard it is. It is not to say that senior developer is better ... but just an important observation that knowing what's easy and what's hard is ... hard.
I think these were the main points, and the rest are probably not worth mentioning. If you enjoyed reading this post, you might also enjoy reading about my observations from attending a local meetup event called RailsBridge, and how I started to go down this road of web development after working in business as a MBA grad.

Finally, if you're interested in engaging Josh or me to help you with your web development projects, please feel free to reach out.

Pickr was hoisted up in a day and could use some love. Please fork it and contribute. Once again, you can get all of the posts, lists of projects, and source code links at the project page.