Kartones Blog

Be the change you wanna see in this world

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 :)


Book Review: Game Engine Black Book: Wolfenstein 3D

Review

Game Engine Black Book: Wolfenstein 3D

Title: Game Engine Black Book: Wolfenstein 3D

Author: Fabien Sanglard

I've been following Fabien's blog for many years, with his excellent videogame source code reviews and in general great articles, so when he announced he was finishing a book about Wolfenstein 3D I got so excited and actually preordered it (on Google Play/Android, read from a 9" tablet).

You can actually grasp the contents of the book not only by reading the whole author's blog, but with certain examples, like how the fizzlefade effect was built or how to understand floating point. But to give a general overview, it is a quite specific technical book: You get history about 90s hardware (the 80386, VGA graphic cards, sound systems and the dreaded MS-DOS RAM handling), some background about the team and who did what regarding Wolf3D, but then it is a dive into the source code, analyzing, explaining and commenting the most relevant parts of the game internals, from how the raycaster works to how the sprites were stored, the different subsystems (sound, input, memory, cache, ...). It feels short but is +300 pages long, and also contains appendices and sequels & ports chapters to learn miscellaneous things related with the game.

I loved reading it, mostly because Wolf3D was one of the first PC games that actually made me start enjoying my father's 386DX instead of only my beloved AMIGA 500, and while it wouldn't be until 1994 that I started learning to code and grasped VGA graphics programming and assembly, I love the amount of tiny but interesting details that I've learned, from how a digital joystick worked and would be read its inputs, to why there were different sound formats or how clever were the guys at id storing the sprites to speed up even their reading and writing with VGA planar modes.

A great technical and nostalgic walkthrough the source code of a game that changed everything, but also a reading about how at the early 90s and the old MS-DOS days everything was harder, from playing videogames (with the conventional memory limitations) to developing them (way harder than being able to play them :)

Notes

As I was reading a book about generating computer mazes I read the book announcement and couldn't resist to try to adapt the maze generators to export Wolfenstein 3D maps. The result can be seen here, as Wolf3D doesn't supports mods or external maps easily, I decided to reverse-engineer NMap's (an unnofficial mapping tool) .LEV file format and generate those files with simple data.

After reading the book now I want to do a raycaster (probably using PyGame for drawing :_)


Regarding Technical Code Tests

Quick post with some personal thoughts regarding the last Code on the rocks podcast, which was about recruiting and human resources, but it mentioned the topic of technical code tests for candidates.

First, a confession: I am quite terrible at doing code tests, due to two main reasons:

  • I tend to get nervous, so I try to complete them in one sit even if given more time (like "the weekend")
  • I always time-box them if they aren't limited in time

When I start a code test, I get into a state I can only think about it, so my normal life gets disrupted until I'm done. I'm unable to take long breaks, or sleep and then continue. I also know it can be harmful for me to time-box when I could instead take advantage, because I could for example do multiple iterations using the extra time to improve something, but my reasoning here is:

  • This is a test, so for me the rule "is take it as such, a test": not strive for perfection but "what you'd do in a few hours most"
  • My time is precious. I'm not going to spend a whole weekend with an unpaid code test, I'm sorry

I've only done 4 code tests in my life (out of 10 companies I've worked/work at):

  • one I nailed it
  • other I did well enough to get hired
  • one I failed (there were external factors but I still had mistakes)
  • the 4th wasn't evaluated as I got hired elsewere and they stopped the process. I'd like to think was going to be ok

Asking for a code test it's a standard practice, and in some scenarios it is one of the few alternatives (e.g. remote work), but I dislike them as it is hard to be trully fair/objective evaluating them. It is also quite hard to come up with unbiased coding challenges, too easy to fall into either algorithmic ones, or too specific/narrow problems that while you might actually be working at if hired, you might as well not have faced before (so is not fair to ask about them). And most times there's a subjectivity factor upon the reviewers: They might not like your style of code, they might have their biases and/or preferences, and sometimes happens that they might be reviewing the code for the first time and think there is only one "correct approach".

I instead prefer other alternatives:

  • do an actual job task (or bugfix): getting paid for it as will take some time, but is a nice way to get the feeling. The main problem of this approach is it's really hard to do while working
  • "work with us for a week": Similar to previous one, but becoming a member for a certain time. Best way to see (both sides) if there's a match, you're part of meetings, etc. and not just of a specific task
  • doing a real task while pairing with an actual engineer from the company, so you don't get overwhelmed by doing something without knowledge of the scenario/context
  • if not the previous one, at least doing a code test but live with a peer from the company, in a constructive way. Probably will make you nervous but at least you're able to explain your reasonings and the other side can also ask you why you take some decisions

Also, one thing I think it is critical is to give feedback to the candidate. I'm not saying you should reply with the failure points, but at least give some general feedback so they can improve. After all, they gave you time and effort by doing it.

And finally, coding tests are a cheap way to filter candidates for the recruiting deparment, but they do take effort both from candidates and from the technical side of the company (preparing and reviewing them). Effort that sometimes the recruiters could also spend filtering their targets instead of blind-shooting everywhere. This is a complaint because I've seen and still see so many bad examples.

For me code tests just work as a filter but act like a double-edged sword. I know of a few good engineers who have failed code tests, and I've met other people who probably were good "coding" but were not somebody I'd be happy to work with. As usual, there is no silver bullet.


Recommended Articles - 2017/09/05

Vacations delayed this post a lot, but on the other hand lots of interesting articles gathered during this weeks.


Previous entries