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 :)
- Video game developers confess their hidden tricks at last: Good summary of the lenghty Twitter thread, interesting to see how we get cheated often to feel better than we really are :)
- The Right Way to Manage Secrets with AWS: Self-explaining if you use AWS and know what KMS is.
- NGINX Unit: This can be really interesting, a small application server that promises zero-downtime configuration changes and easier updates.
- Lessons Learned Scaling Airbnb 100X: Product-related advices are nice, encouraging you to not fear crunches, I tend to disagree except if they are really rare.
- Pub-Sub the swiss army knife (tech pill): Another post from my ex-colleage Eferro, this time explaining how pub-sub works and where it fits best.
- New in Chrome 61: I don't usually write about browser new features, but one caught my eye: WebUSB!!! This can be so fun combined with web bluetooth and other pieces like service workers!
- Atlassian launches Stride, its Slack competitor: This chats and bots flood is curious, I wonder if is really worth all this hype. And let's remember that Atlassian already has Hipchat, cannibalizing your own product sounds strange... except if you plan to phase off the old one.
- Titan in depth: Security in plaintext: Google is building its own security chips for their servers. The kind of things you can only think about doing when you have so much money... but still a nice move.
- Azure Confidential Computing will keep data secret, even from Microsoft: And Microsoft is also adding hardware-based security to their cloud platform...
- As Amazon Pushes Forward With Robots, Workers Find New Roles: Not everything is bad news regarding "robotized workers", and also a good inside view of an Amazon warehouse.
- Introducing Atom-IDE: Atom releases IDE extensions because... it wasn't IDE enough already? I really don't get why, except for getting extra news coverage and/or to keep Atom "core" minimal as it is opensource, but hey, whatever eases our developer lives is welcome.
- Here's What Security Experts Think About The iPhone X's New Face ID Feature: "What if a cop stops you and points the phone at your face, one Twitter user asked, while they have you in handcuffs — then he or she proceeds to look at your phone without a warrant?"
- Face ID Raises Some Scary Questions—Here Are Some Answers: "Face ID is supposed to improve on this by requiring 'user attention' Basically, this means you have to have your eyes open and make eye contact with your phone to get it to unlock" And, if you're completely drunk, will it unlock too?
- What you should know about privacy and Apple's FaceID on iOS 11: Another article. Three in total because while cool and handy to use it raises a few triggers on my personal privacy and security alarms.
- Google Chrome will block auto-play video starting January 2018: But actually since Chrome 61 you can already do it, just type as a URL
chrome://flags/#autoplay-policy and select
Document user activation is required.
- Founder of Fan-Made Subtitle Site Convicted for Copyright Infringement: Sad news, it seems you're not even allowed to create your own subtitles "without authorization", at least in Sweden. Another laws nonsense...
- The React license for founders and CTOs: Although the license was finally changed, an interesting reading on why it was initially released as Facebook BSD+Patents.
- "15 years ago, the internet was an escape from the real world. Now, the real world is an escape from the internet" -@Noahpinion
- Devs unknowingly use "malicious" modules snuck into official Python repository: I wouldn't thought that companies should security-audit code from official repos, but it seems is a good idea lately...
- AMP vs non-AMP: Most interesting point that many of us have suffered with integrations of different kinds: "It's important to recognize how much extra work things like AMP, Facebook Instant Articles, Apple News, whatever Amazon dreams up next, etc. etc., dump on your development team -- the maintenance alone can swallow up countless hours"
- Per-Second Billing for EC2 Instances and EBS Volumes: Name says all, finally one of the big critics of AWS gets solved. No more leaving the machines up for 55 minutes to "squeeze them as they are paid for a whole hour".
- World Wide Web Consortium abandons consensus, standardizes DRM with 58.4% support, EFF resigns: DRM extensions have been officially approved by the W3C, and the EEF resigned due to that decision.
- How Booking.com manipulates you + Truth about Booking.com: Yet another story of not so good working environment, but in this case with user manipulation added to the mix. Some really nasty UX and psychological tricks.
- Here's Why You Should Have a CAA DNS Record for Your HTTPS Website: Proposal to add a Certification Authority Authorization (CAA) DNS record so browsers can check if the certificate a webpage is serving is valid because the CAA record says the issuer is valid/allowed.
- New in postgres 10: Lots of improvements, especially partitioning and replication related.
- Google to acquire HTC's Pixel smartphone team for $1.1 billion: Good move, they leave HTC independant but at the same time adquires and moves to Google their best engineers, securing the future of GPhones...
-SRECon EMEA 2017 Notes: Notes, links and additional resources of the conference.
- Low-complexity leader election with AWS: Simple algorithm to perform EC2-based leader election with AWS.
- Collection of free ebooks from Packt Publishing: Self-explanatory names, the books that Packt gives for free during 24h.
- One Tinder user's data request turned into 800 pages of probing info: The subheader is perfect "when a service is free, you are the product".
- The Mega HTML5 Cheatsheet: As long as interesting indeed!
- How I hacked hundreds of companies through their helpdesk: Social engineering and phising worry me much more than software/hardware security, harder to "fix".
- Have Smartphones Destroyed a Generation?: Interesting read, as I'm past mid 30s I no longer know youngsters' habits so well, but it is true habits are changing (and for all ages).
- Just Do As Expected: Like the general guidelines:
- Everyone is responsible
- Continuous Improvement
- Respect others and their opinions
- Bias towards action
- Code as expected
- Code Quality
- Ship it!
- Transitive property
- Android users rejoice! Linux kernel LTS releases are now good for 6 years: Really good news, as the phone is something we use too much to have it become obsolete as quickly as happens now (1/2 years max, depending on when the OEMs add their layers of "stuff").
- 1 Trillion HTTP Requests Per Month: More than the actual throughtput what I like from the article is the evolution story, how they faced different problems and how they scaled and rewrote things.
- Apple is really bad at design: I'm no designer but the examples are really good arguments...
- Apple Collecting Browsing Data in Safari Using Differential Privacy in macOS High Sierra: Ah, if instead of a bitten apple we were talking about a Redmond multicoloured windows logo, this would smell to lawsuits, but being a "cool company"
- Apple Open Source: But for once, not everything is bad, they released all their kernel source codes!
- Free Selenium Tutorials: Really huge, detailed and very well explained compilation of Selenium tutorials, from begginer to advanced topics. Highly recommended if you build browser tests with the tool!
- Open a terminal and type
telnet mapscii.me (more details)
- "Former Twitter employee reveals what we can all observe. Reducing abuse on the platform a non-goal since it hurts 'engagement'"@Carnage4Life: I loved the platform but is slowly declining between the rage, hate, manipulation and not caring about quality of content...
- Tfl plans to make £322m by collecting data from passengers' mobiles via Tube Wi-Fi: And again, when you don't pay with money, you pay with your data...
- Breaking Up the Behemoth: How applications usually evolve, and how to keep complexity of them under control. Nice advices, go read the full post.
- Streams: a new general purpose data structure in Redis: I love redis, and the streams look more and more as a great alternative to Kafka or AWS Kinesis streams. The article is long but enters into a lot of detail about what to expect from streams (spoiler: they are so well thought).
- Google Chrome Will Block Tab-Under Behavior: Didn't knew this dirty trick but nice to see them
- Web and Android Scholarship Program: Google and Udacity are offering free scholarships to learn web (frontend or backend) and Android development.
- Microsoft Edge for iOS and Android: What developers need to know: And why the hell would you do that...
- Windows Phone is now officially dead: A sad tale of what might have been: ... until you read this article and then see that Windows Phone is not anymore de facto dead but officially too.
- Explaining the new cryptocurrency bubble—and why it might not be all bad: I do still think we're playing at a dangerous game here, but it is true without doing things different there would be no change or innovation.
- A 1 KB Docker Container: Demoscene for devops X-)
- How Kaspersky AV reportedly was caught helping Russian hackers steal NSA secrets: Woah, need to read this one slowly, hackers detected by hackers who were inside the system already. If wasn't so convoluted around computer hacking would make for a nice spies movie.
- The Future of HHVM: Facebook's compiler for PHP will stop said compatibility, not only regarding PHP7 but also regarding PHP5. They want to improve their improved version, Hack, so no more looking back.
- Extending per second billing in Google Cloud: Excellent answer to the recently announced AWS per-second instance billing.
- The SQL I Love. Efficient pagination of a table with 100M records: Nice solution and explanation
- The Absurdly Underestimated Dangers of CSV Injection: Amazing that both MS Excel and Google SpreadhSeets can be exploited with injected code. Short read but very relevant if you use any of both tools.
- Silicon Valley: Interesting analysis of how Apple is winning on the hardware side by getting the edge on microprocessors, sensors, etc.
- "Space X sends a rocket up into space. Lands back on its feet back on earth 7minutes later. I can't even run an npm install in that time."@toddmotto
- Pornhub Launches AI-powered Model That Detects Over 10,000 Pornstars in Videos Using Computer Vision: Porn industry always adapting itself to technological advances :)
- I Wrote a Hit Song With Justin Bieber. Want to See My Royalties?: Wow, incredibly low numbers from streaming earnings, something's broken on the pipeline because numbers are really really low...
- High-impact refactors keeping the lights on: Slides of my talk given at the PyConES and a local meetup (one of the reasons this post got delayed).
- Remote Work: Why it's cool to work in underpants: And slides of an internal talk I gave at my previous job about how to improve remote work and become trully "remote first" (insted of just "remote friendly").
Book 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 :)
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.
- Roomba vacuum maker iRobot betting big on the 'smart' home: but betting on a sad area... selling your house's map to Amazon, Google or other similar big company.
- How Microsoft brought SQL Server to Linux: Quite interesting because I thought it was a mere VM-like wrapper and while uses virtualization, it is more advanced.
- High-Resolution Custom Metrics and Alarms for Amazon CloudWatch: Finally, 10-second precision alarms at AWS.
- piprot: Small Python library that checks how outdated are your requirements (libraries/components). Really handy.
- History of iPhone pricing, including the average selling price: Interesting that there is a more or less stable baseline, despite going higher and higher (into indecent prices for a phone).
- "The most popular software for writing fiction isn't Word. It's Excel" @brianalvey
- "If you don't run experiments before you start designing a new system, your entire system will be an experiment" -Mike Williams (via @compscifact)
- Instead of hacking self-driving cars, researchers are trying to hack the world they see: Clever and scary in equal parts, demonstrates how advanced our sight and brain are compared with automated cars. Related article on how to hack signs.
- How I didn't become a SoundClouder: Sad example of why companies shouldn't lie to applicants and probably directly not hire anybody if they are having money issues. There was a similar situation in Spain around end of 2016 with a known company hiring people and sometimes weeks after firing them due to layoffs. The solution is simple: Talk to HR and ask them to stop any hiring procedure, you're playing with people's professional careers, not with mere spreadsheet numbers that you can adjust instantly.
- LinkedIn: it's illegal to scrape our website without permission: It was nice that they lost, because it feels fully anti-nature to on one side provide public information and on the other say it is illegal to scrape/gather it. Still makes me sad to see how the nice and public and free internet gets more and more attempts to put bars, borders and walls.
- The Android Browser: Slidedeck about how terribly fragmented seems to be Android's browser.
- How to Host a Website on S3 Without Getting Lost in the Sea: Nice summary, saving it for the future me that will probably want to host some static site.
- Operation Luigi: How I hacked my friend without her noticing: Scary tale about social engineering and forgotten account dangers.
- No, Facebook Did Not Panic and Shut Down an AI Program That Was Getting Dangerously Smart: Same crap I avoided at TV from unconfirmed, flamboyant and sometimes fake news, seem to be happening lately a lot.
- Slides and links for 2017 talks of the GopherCon
- Ethereum miners are renting Boeing 747s to ship graphics cards and AMD shares are soaring: Personally I think this is getting absurd and is another tech bubble waiting to explode, so much electricity wasted on cryptocurrencies...
- Investors poured millions into a storage network that doesn't exist yet: And another example, a "blockchain-based cloud storage technology" that has raised 52$ million and is just an idea...
- Why is ARKit better than the alternatives?: Huge but really interesting article on augmented reality, not just on Apple's ARKit.
- Google fires engineer who "crossed the line" with diversity memo: There's still hope in humanity, because I thought it was going to be let go just for the shake of "freedom of speech", but no, I'm not the only one thinking there are lines you cannot cross "despite you can". Some things are plainly wrong.
- If you want to debate the Googler's Manifesto and you're also a good person: Because we confuse freedom of speech with "anything goes", and as the article points out, some discussions cause harm, are not just a discussion.
- When tech firms judge on skills alone, women land more job interviews: Speaking of inequality...
- Queues vs Distributed logs (tech pill): Nice brief but well explained summary of what both are and when to use each.
- Blizzard and Google betray humanity with StarCraft 2 tools to train artificial intelligences: It is so nice to see official APIs!
- Inside the crash of Fling, the London startup whose founder partied in Ibiza while his company burned through $21 million: Self-explaining title, a typical burned startup story.
- [Silicon Valley's wealthy elite have made social inequality worse](https://www.spectator.co.uk/2017/08/silicon-valleys-wealthy-elite-have-made-social-inequality-worse/: I knew things at SF are crazy, but this is really sad.
- Learning at work: Nice point of view and suggestions, I don't agree with all of them but the general message is relevant.
- Block-breaking game in vim: Intelligent and fully playable, kudos to the author!
- Ad blocking is under attack: Sad that lawyers and DMCAs are pouring even at Ad-blocking level. Instead of curing a disease, they force their way through mostly the only visitors protection...
- Scalable design pattern sample (tech pill): Another "tech pill" of an example where a combination of distributed log + queue provides a great solution. One that I've been part of at a past job and it indeed worked great :)
- SQL Tutorial: How To Write Better Queries: Really excellent summary of general and less general tips and improvements to apply when writing SQL.
- Why Github can't host the Linux Kernel Community: A nice article on the whys, pros and cons of both Github and the Linux Kernel community itself. You might agree or not with how they work but at least this is a polite, fundamented explanation.
- Tesla workers and the Model 3: To hell and back again: Sad to read that such a revolutionary car, manufacturing plant and general vision comes with an unsafer environment for the workers (higher tan average auto factories injury stats).
- Chess Is Being Forever Changed by Technology: Interesting how not only computers are able to win by "brute force" or raw computation power, but also provide powerful analytics to help chessmasters analyze past champions and improve their techniques.
- FP vs. OO: I wish there were more discussions like this article, trying to balance both sides and not being radical on any.
- Linux load averages: "system load averages" is much better, as it includes disk/NFS I/O and wait locks. Reasoning makes sense once you think this requires resources too. Still dividing the average between amount of CPUs works as a rough measurement, just don't take it as 100% precise.
- About React licensing, how to hide things in an apparently simple language: React license caused quite some stir this past weeks, but is nice that raised awareness of being careful with not-so-hundred-percent-free licenses.
- security.txt: A "standard" that allows websites to define security policies. Looks interesting, let's see if gets some adoption.
- How long employees are staying at the 10 biggest companies in tech: Quite revealing that people still switch "early" to another company despite being at one of the top/best ones. Whenever it is for getting more money or better conditions or simply more interesting projects, in the end is what happens at lower levels too.
- Why Even the Hyperloop Probably Wouldn't Change Your Commute Time: Interesting reading about city growth. Also learned about Marchetti's constant. TL;DR: average travel time stays approximately constant.
- Designing a Microservices Architecture for Failure: Some highlights (but you should read it all):
- careful with network failures
- 70% of the outages are caused by changes in a live system
- Reverting code is not a bad thing
- skip unhealthy instances from load balancers
- self-healing can cause trouble
- failover caching -> two different expiration dates (short for normal situation, longer during failure) -> better outdated data than nothing.
stale-if-error HTTP header useful for HTTP-based communications
- a larger amount of retries can make things even worse (cascading effect). Also should be abke to handle idempotency (using idempotency-keys)
- rate limiters and load shredders both for traffic peaks and traffic control to allow critical operations to complete
- to fail fast and separately -> bulkhead pattern (segregate resources, protect limited ones). using timeouts is an anti-pattern -> circuit-breaker pattern (protect resources by checking success / fail statistics of operations)
- test your system against common issues (and frequently) -> survive various failures
- AWS Glue Now Generally Available: One of those AWS services you might have never heard of, it is an apparently simple ETL service. Having done some non-trivial ETL work at a past job I'm curious about how powerful it really is.
- Expanding the Medium Partner Program: aka "Expanding the paywall". I firmly believe on openly accessible information so I'm glad I never had the urge to move to that platform. I'm just sad the monetization attempts are pushing it into a more closed system...
- Tesla's Push to Build a Self-Driving Car Sparked Dissent Among Its Engineers: Again better to wait until technology matures, but also I think this metric is quite... relevant: "Human error causes 94% of crashes, according to [american] government statistics".
- VW engineer sentenced to 40 months in prison for role in emissions cheating: So, now not only you do have moral decisions to take, but also can be legally held accountable if you pick the wrong one. The guy lied more than once, not just "wrote some lines of code" but still it sets a precedent for the future.
- On Quiet Developers: Interesting read, especially now that all seems to orbit around GitHub profiles and contributions.
- Django Migration Don'ts: Pretty similar solution for delicate migrations than the one we built at CartoDB. We implemented a quick rollback feature that checked if there were RoR migrations and if so wouldn't let you do the quick one (so you do the full rollback and check data is still fine),
- In Silicon Valley, Working 9 to 5 Is for Losers: I have no interest on working in the United States, but Sillicon Valley is becoming quite unfriendly. Disgusting is the best summary for the article, but go read it.
- On MongoDB: Nice 3 part detailed walkthrough of Mongo's 5 years of life, with mistakes and success reasons. I like the mentioned simple three part process (PAT) when assessing hyped technologies:
- Problem: Understand your problem deeply
- Assess: Critically assess claims in potential solutions
- Tradeoffs: Weigh tradeoffs in the short and long term, rather than thinking about good vs bad
- Cloud Native Landscape: Nice visualization with a summary of many players on each of the areas regarding "clouds".