Kartones Blog

Be the change you wanna see in this world

Recommended Articles - 2017/12/15


JSON-schema for REST API tests

I wrote a blog post about using JSON-schema to build tests for REST API endpoints that output json at ticketea's engineering blog, so instead of just re-posting I'll just link it: https://engineering.ticketea.com/using-json-schema-for-rest-api-endpoint-tests/

It's a small yet interesting example, and will probably serve me as a quickstart for any future django project as it contains useful bits like:

  • classless django views
  • an example of pytest-django and two useful features it provides (the settings and client fixtures). I'm loving the concept of not needing to write scaffolding code
  • a small usage example of json-schema :)

Recommended Articles - 2017/11/10

Still a big list but improving from past ones ;)


About overwork

Overwork and/or crunch time is a recurring topic in the tech industry. From the videogame industry where it can be normal to work +80 hours per week during months to consultancy or startups, more or less everyone has at least once had some overtime experience. After a long time working in the industry (since 2001, fulltime since 2003), I've had varied examples and situations, so instead of just saying "wooo it is terrible!" why not sharing them as a small recapitulation.

Note: This is solely my experience and I talk about my personal overtime experiences, except when explicitly noted.


My first crunch was at a client working at ilitia. We were developing a Windows Live Agents bot (at 2008, who said bots are new in 2017?) for one of the major political parties and we were approaching a hard deadline: Either we shipped before a certain date, or Microsoft couldn't guarantee the bot would be online in time. So, two days before the deadline my colleage and I decided to setup camp at the client office and not move until done. It took 29 hours and so much coffee my colleage's hands were trembling a bit by next day's morning, but we sent it on time.

At Navteq we had a .NET server + J2ME mobile application for the Spanish market used at some relevant events (like "La noche en blanco", a night where most bookstores open at Madrid). When I joined it had severe performance issues rendering the maps and we had an event soon. I took the work laptop home and during most of the night rewrote the entangled server logic so it would serve hundreds of mobile requests per second with the same server hardware.

At Tuenti we kept an internal joke that if we were paid all the extra hours poured in, we'd all be rich (aclaration: we had bonus, performance evals, salary raises, etc.). In my case I tried to stick to the schedule, but there were two recurrent exceptions: I had so much new things to learn I had to frequenty spend hours and hours weekly reading books, articles or source code to be productive coding the next days. And then, more or less yearly we had some big redesign project that usually sucked up the whole tech and got us working overtime for a few months. Sometimes was just a few extra hours per week, other times way more hardcore, like working 13 days in a row, then one sunday "off", usually 10 to 12 hours at the office.

Other examples from other companies are preparing going to launch the new shiny website, that we had been months building and had a branding campaign signed so we had to stay for 20-something hours at the office until we got all the pieces working (and had to do a few horrible last-minute hacks to ship in time), or being at Manhattan debugging problems and publishing hotfixes on a friday night from a bar, switching laptops as the batteries were draining.

In general I think overtime can be justified when it is a special situation, something extra and rare that justifies the extra effort. Overtime causes damage, whenever short-term (sleep issues, zombie-state for a few days, loss of focus) or long term (I left Tuenti in part because after the 4h redesign crunch I got tired and was affecting my personal life). But what it most frequently ends up causing is burnout. I've also seen great, awesome engineers write buggy and messy code due to extended periods of time of sleeping few hours and working insane amount of hours, as tests are sadly the first thing that tends to get cut when under time pressure.

Because of those situations and others I've ommited, I now control a lot my overtime. It is also for the good of my employer, as if I get too tired my productivity will decrease and I'll have more mistakes.

If I'm allowed flexibility I do provide also flexibility: One day I'm late because of a home emergency? No problem, next day I'll make for it. I'm asked to come at 6:30 AM at the office to support a critical release? Fine, as long as nobody complaints if I also go earlier home to rest. But that's not even overtime :) On the contrary, I've also refused to do on-call when the company was expecting us to do it unpaid and as a norm (truth be said, in the end an on-call was setup).

I'm proud of some of the times I did overtime because I think it was really worth it, other times still agreed to do it because was good for the company (if not so critical), and very few scenarios there was really no other choice without getting into a violent confrontation so I though best to go ahead and take actions later on. But also learning to say no is a skill you develop (and you must).


Things that I do not consider overtime are extra activities in which I participate willingly, although there can be some peer pressure with time you develop resistance to it and I think I've never been manipulated to do them (in fact I quit from some when they weren't fun anymore). Some real examples:

  • At ilitia, we setup a CDi ("Club de Desarrollo ilitio"), once per week staying at the office with some beers to do brainstormings, pet projects and think about possible things to build (at the company) to make some money and separate from consulting services. We did product requirement documents, we built proof of concepts, but the general idea and willingness diluted away after a few months
  • At Tuenti, we had quarterly HackMeUps, 36-hour hackathons starting thursday. Some were great on the fun part (have drinks and long talks with colleages until late), some on the tech side (quite a few projects ended up in production after some polishing)... I didn't won any but tried to participate in most and usually stayed either all night or until late
  • Despite being shy, I like explaining what I know (not much), usually giving talks at user groups and sometimes conferences. I might spend some work time on thinking and peer-testing the talk, but I prefer to spend a few hours at night without any rush thinking the content, the structure, the main goal...


"Work hard and go home" - Slack company motto



Recommended Articles - 2017/10/14

Again long since I last wrote a list of articles so a few might even look "old news". Plus way way more articles gathered than I'd like to, but also lots of reading opportunities with so many topics :)


Previous entries