Better to look after the product, not my time

Sometimes I feel the urge to go back and negotiate more favorable terms for me or my team. (I'm talking about features in a software system, not money.)

The client wants to implement something. Sometimes is better for us if they want fewer things. Maybe if we do some of them different will also save us time. My reaction is to always stand up, and try to change the client's mind.

That's not necessarily bad, but only when we are thinking about the final product, and not our own time. When I'm acting as the client, it really makes me mad having people trying to change my mind just because it's more convenient for them.

There's a huge difference in the conversation when you approach it from the product's perspective, and not your own self(ish) interest.

I'm teaching myself to suck it up and live up to the expectations that were put on me and my team. Unless I have a valid reason to change something, I'm pushing forward to deliver it all. I want to always shoot for more, not less.

If you don't know what else to do to contribute

Sometimes it's hard to know what to do to contribute to your company. Of course, besides coding all day long.

I think the best approach is to ask your manager.

But maybe you don't have to because I can convince you to use any of the following ideas:

  1. Find a relevant book. Read it. Use something from the book in your current project. Socialize it with your team.

  2. List (in order of importance) the three biggest technical problems you are facing with your current project. Propose a solution for them. Lead that charge.

  3. Make yourself responsible for managing the Technical Debt in your project.

  4. Come up with three ideas to delight your client or users. Three things that they aren't paying for, neither expecting them. Three things that will delight them.

  5. Find a process that's clunky for your team. Find an existing tool that fixes it. Socialize it with everyone. (Here are some examples of relevant tools in this category: Postman, PageSpeed, MailTrap, Loggly, Crashlytics, HockeyApp, RequestBin, ...)

  6. Are you doing Scrum? Fix it (I know there's stuff that's not working fine.) Aren't you? Then fix whatever process you are using today. Here are some questions to get you started.

  7. Go ahead and find which one of these will help you get to the next level: TDD, Continuos Integration, Pair Programming, Code Reviews, Refactoring.

  8. In your project, work in any of the following three aspects: Performance, Scalability, Flexibility. Propose solutions to improve any of these (or all three).

  9. Everyday find one task that if delegated to a teammate will make the whole process move along more efficiently. Talk it through and try it out.

  10. Help your teammate become as good as you are.

All of the above are related to software development. That alone will be a great start.

There are more questions, but here you've got 15

Today I thought about these. Useful every time I want to help:

  1. Does my team have the hardware they need to do their jobs? Is this hardware functioning in an optimal way? Is there anything that will make them more efficient?

  2. Why is my team staying late tonight? How can we avoid this from happening again?

  3. Is my team having lunch/dinner every time they are working past noon or after hours? Am I taking care of them?

  4. Are my designers communicating with developers and making sure they are creating "doable" designs?

  5. Is the approval process for designs taking too much time? Is it optimal?

  6. How are my designers receiving feedback? Is it consolidated? Is it clear? Is it counterintuitive?

  7. Are my designers enforcing a creative review process? Are they overlapping (and duplicating effort) with QA? How is this process working?

  8. Why is it taking too long to move tasks from Development to QA? Where is the bottleneck? How can we increase throughput?

  9. Is QA receiving enough details to test? Are developers commenting on what solutions they implemented and informing QA how to test?

  10. Is our Scrum backlog ready for grooming? Is it ready for Sprint Planning? Do stories have enough details to be clear?

  11. Are we properly prioritizing Stories and Tasks in the middle of the Sprint? How are we deciding what to tackle first and what should come last?

  12. Is it my team too big? Too small? Are they communicating efficiently and effectively? How are we dealing with remote team members?

  13. Did we talk about our problems during our last Scrum Retrospective? Did we solve any of them? What are we doing to prevent them from happening again?

  14. Are there any tasks taking too much time? Can we optimize them?

  15. Are we shipping? Are we gilding the lily?

There are more. So many more.

My team

I'm really picky with my team. It's not only about who gets in it, but about responsibilities in general.

I like people to be able to pull their weight. I like people to be extremely valuable, not only as individuals, but valuable to the team as a whole.

I like to start with the bare minimum, and grow only when absolutely necessary. Even after growing, I'd rather scale back down as soon as I can instead of staying big and fat and slow. Less is usually more for a team.

If someone doesn't know what to do, that's a problem (probably my problem). I prefer people doing too much than people not doing enough. I can help really easily with the former. The later is a nightmare.

I want my team to be as efficient and effective as I could possible dream. People, roles and responsibilities are three really important things.

But of course, this is just me. Just my team.

There's always something else you can do

Here is something I'm focusing on lately: determining what's good enough, and then doing something else; just enough to delight.

I work with very sharp people. Both my co-workers and clients have seen "good enough" plenty of times. They are used to it all the time, every time. If I can't give them better, why would they stick with me?

Today we built something good. The tendency was to close the task and keep moving. Instead, we spent another 20 minutes and turned "good" into "great". Another 30 and we ended very close to "amazing".

It doesn't always make sense; extra time doesn't always pay dividends. I love people that know where's the line and stop right before crossing it, but I don't like when folks draw artificial lines that only limit themselves.

(Sometimes I think about the relationship between money and the work I do. I want to do more and better for those who pay more, but I think that's somehow a little bit shortsighted. If the whole goal is to make those who pay little today pay a whole lot more tomorrow, not going the extra mile is a sure way not to accomplish this.)

By the way, contrary to what I know my "fans" will tell me, taking the extra step is not always expensive. There's a bunch of different things you can always do. Unexpected things. Things that make that other person stop and be grateful for having you.

And that's one thing that makes you different and valuable.

Postman

Sometimes I’m an old fashioned guy and spend too long doing the same things the same way. I like to fight this, albeit sometimes it makes me feel uncomfortable. I keep trying though.

(This is another shot at changing something for good.)

I think I’ve been using cURL for too long. A couple of people (maybe three or four?) recommended Postman. I tried it. Now I like it a lot.

I call REST APIs a lot. You probably do too. Postman makes the process easy, in a way that makes cURL feel like a telephone booth from the late eighties.

You can always read the list of features, but here are some of the cool stuff that made me write this post:

  • I can construct calls very easily. Headers, cookies, authentication, you name it. All there, in a 20th century user interface.
  • If I need OAuth2 to make a request, I can set up Postman to do the whole dance automatically for me. This alone is worth my next paycheck.
  • I have a history of all the requests I make. (Much better than the bash history I usually rely on.)
  • I can intercept all the calls made by my browser by navigating through a website. And they get directly into my history. And then I can execute them from Postman.
  • It pretty-prints the results. Nothing better than saving me the time of copying from the Terminal and pasting somewhere else.
  • I can share collections of requests with my team. We don't need to keep separate copies of each request anymore.
  • If you still need the raw request, Postman will give it to you in multiple flavors: for cURL, or Java code, or C# code, or JavaScript, or whatever. (Too many options to name them a all.)

(There's more, I promise. I'm just too lazy to list everything out here.)

So far, all of the above is free. But there's more when you pay of course. You get pre-request scripts, and teams, and tests...

Give Postman a try. If you are like me, you'll be very happy.

How to determine last 5 business days in BigQuery

This was for the same project I was working on when I wrote How to determine last Monday's date in BigQuery. This time I needed to determine the date of the last 5 business days.

I'm assuming here that business days are Monday through Friday. Holidays are not counted for this example:

select date
from
  (select date_add(current_date(), -1, "DAY") as date),
  (select date_add(current_date(), -2, "DAY") as date),
  (select date_add(current_date(), -3, "DAY") as date),
  (select date_add(current_date(), -4, "DAY") as date),
  (select date_add(current_date(), -5, "DAY") as date),
  (select date_add(current_date(), -6, "DAY") as date),
  (select date_add(current_date(), -7, "DAY") as date)
where dayofweek(date) >= 2 and dayofweek(date) <= 6

Executing this today returns the following:

  • Friday 2015-08-07
  • Thursday 2015-08-06
  • Wednesday 2015-08-05
  • Tuesday 2015-08-04
  • Monday 2015-08-03

Today is Monday, so the results looks pretty convenient for the non-believers. This is why I faked the date to be next Wednesday and here are the results:

  • Tuesday 2015-08-11
  • Monday 2015-08-10
  • Friday 2015-08-07
  • Thursday 2015-08-06
  • Wednesday 2015-08-05

Hope this helps.

Splash screens in Android

We are developing an Android app. Of course, the natural thing to do is to add a splash screen. We did, but it sucked, so I googled how to do it well.

And then I found Splash Screens Are Evil, Don't Use Them! Great post from Cyril Mottier with a very helthy perspective about splash screens in Android applications:

I have recently seen many Android applications starting with what I call a splash screen. A splash screen is an image that takes the entire screen space and usually shows branding information about the application (...) This screen is generally visible for a small amount of time while the application is starting or loading some resources in the background.

Once again, from my point of view, the splash screen paradigm is a port of the iOS equivalent.

Bottom line, we ended up getting rid of it. I'm really happy with that decision.

We need enough technical debt

I think developers tend to think that having technical debt is always a bad thing. It might. But sometimes it isn’t. Having piles of debt is certainly bad, but I think having none could be equally problematic.

When somebody tells me that they keep technical debt at zero all the time I think they are either lying to me, or spending too much time working on the wrong priorities.

(Here is where every project, situation, and team plays a role. Everything is relative, so what I’m assuming here might or might not apply to your current situation.)

On the projects I work, shipping is usually one of the most important features. All the time we spend getting rid of accumulated debt is time where we aren’t shipping. There has to be a balance.

Getting rid of all existing debt is usually unnecessary. Starving artists with noble ideals can’t pay the bills (by definition they don’t even have food to eat). I’d rather spend the time fixing only what’s really important.

But there’s a fine line between “this is important” and “this is not a big deal”. Here is where experience comes into play. There’s also a problem with accumulating a lot of not important issues (dead by a thousand cuts).

If I wanted to summarize the idea I’d say that knowing when to act on technical debt is a skill. (Another one we need.) Not too high, not too low. We just need enough.

When the session is timing out in both server and client

If you keep a session controlled by the server (with an expiration timeout) and a separate session logic on the client (also with an expiration timeout), keeping them both synchronized is too complicated and probably unnecessary.

You got to have that logic on the server side. Get rid of the client-driven session logic.

When users interact with the application you want to extend the session (keeping it alive). Client-heavy applications (also known as "Single-Page Applications") go to the server sporadically, so you have to implement a "keep alive" mechanism to avoid expiring the session prematurely.

Here is an easy way to do this:

  1. Add a keep_alive method to your server. This method does nothing other than making sure the session doesn't expire.
  2. Client calls the keep_alive method every now and then (you want to synchronize this with the session timeout in the server). For example, if session expires after 30 minutes of inactivity, you want to call the keep_alive method every 10 minutes or so.
  3. Client doesn't just call the keep_alive method. It does it only if the client has interacted with the application since the last time the method was called.

So if you keep a variable in your client application that stores the last time something happened (the user moved the mouse, or clicked somewhere, or whatever), you can easily tell whether there was activity since the last call to the keep_alive method.

As soon as the user stops messing with the application, the keep_alive method won't be called anymore. The session will expire on the server.

Notifying the client when the session expires

This is another thing: in the above scenario the client doesn't really know when the session expires. (That's why the logic was in both places to start with.)

This is what I'd do:

  1. Add another method to the server. This time I'd call it is_session_active.
  2. This method won't extend my session. It's only to query whether there's still an active session.
  3. I'd start calling this method only after missing a keep_alive call (whenever the code makes the decision of not calling this method because the user hasn't done anything with the application.) At that point, I'm sure the session has a higher chance to expire.
  4. If there's any activity before the session expires, stop calling this method.
  5. If this is_session_active method returns false, we know the session expired and we can proceed accordingly on the client side.

Note that this scenario doesn't work if we want to show a countdown timer on the client side to expire the session after a certain amount of seconds. To do this we'll need to have a client-driven session.