Tobias Lutke still writes code for Shopify
changelog.com
changelog.com
Good memory: Lutke's blog is responsible for a lightbulb moment of mine back in 2007, regarding cache invalidation. The post is long gone, but it was entitled "The Secret to memcached" -- the advice, which is incredibly obvious in retrospect but wasn't to me at the time, is to manage cache invalidation by adding a unique ID to the cached asset, and letting the cache fill and expire items on its own. Going into it, I had assumed I should be removing cached items in the code that was utilizing the cache. I was ignorant. I still am, but less so about memcached. Thanks, Tobias!
The Internet (Archive) remembers:
* https://web.archive.org/web/20120125060458/http://blog.leets...
Those terms should help you find more writing about this technique that I always forget isn’t obvious outside the Rails ecosystem
It's been hugely influential to the way I think about scaleable pages. It's a similar idea to the cache-busting techniques well-known with URLs (https://example.com?style.css=1234 etc), but applied to page fragments recursively, where a change in any component also "revs"/"bumps" its parent components.
Once you're in a management role, let alone a CEO role, your job not to write software. You defer defer implementation and architecture completely to your team. Your job is to hire and build that team and set high-level company direction.
The more power you have over your co-implementors' careers -- and the more junior they are -- the less comfortable they are standing up to your architectural or technical decisions. This stifling of collaboration can cause you to make poor decisions you wouldn't otherwise, and creates an uncomfortable dynamic.
This is why I don't believe in TLM ("tech lead manager") roles, also, fwiw.
Wanna code? Do it on your own time, Tobi! :)
Becoming a CTO myself within an 80 developers area, I found it invaluable to code infrequently still. It is quite simple: better decisions, better products.
To me, non-coding CTOs or most CEOs that do not understand Computer Science, it seems that they try to learn a foreign language by sending in their assistant to attend classes.
I mean this quite literally. My team can communicate to me in other terms and a different language than they would have in a simplified ELI5/KPI driven manner. And vice versa, I challenge them to think beyond day to day business.
It is not a lack of trust. It is about better understanding and better helping your team focus on the essential parts. And vice versa.
On the other hand, I was personally unhappy a lot of the time. On one occasion he pretty much tore apart one of my designs and I felt fairly humiliated (with reason, as a few other senior engineers confirmed in private conversations).
Did my design deserve to die horribly? I don’t know. The PR had already been accepted, but maybe the accepter was wrong. In any case it felt really crappy to be criticized so heavily by someone who in theory supports me.
I tried my best to be a supporting lead, everywhere i was in that role. I believe in leading by example, but i recognize the necessity to _let_ people do things themselves and not just hog power because "i know best". Let people implement imperfect designs. They'll own it, learn, and fix them in time. Your job is to lead, to give direction and not let total crap be put into prod, not keep people under your "benevolent dictator" heel.
The main factor to me is the team size and subsequently the organization of said responsibilities delegation. My personal context sweet spot is around a 50 persons team.
I agree about responsibilities part, however, if you don't let your people grow by simply vetoing the ideas, they won't grow. Discussing and openness to your subordinates' ideas is not a bad thing in my opinion. Letting people make proof-of-concepts and fail is not abandonment of responsibilities. Letting people implement their bad ideas in production is.
Well, I refer to the whole company as a team. This may be my SME bias :)
Now I run my own Shopify store, selling my software.
We once needed to cache a list of objects that was unacceptably slow serialize the JSON for. We needed to cache them in memcache, but also needed reliable cache invalidation without having to instrument every ingestion point with the logic. Here's what we ended up doing.
1. Every record gets an int field titled "index" or similar.
2. Every time a record is inserted or updated, index is changed to the next value from a sequence
3. The cache key for memcache includes the number of records and the maximum index from all the records returned (including any intermediate objects if joins are involved)
4. Infinite TTL for all cache keys, but the entire cache is LRU guaranteeing that stale records are eventually removed.
This setup works because any conceivable operation done would change the cache key. If new records are inserted or deleted, count and index change. If a record is updated, then the max index changes. Even deleting and adding a new record will change the index, meaning that no matter what happens you'll get a new key and the system will continue to cache appropriately.
From the outside though, the company does extremely well.
Nonetheless, CEOs are generally not supposed to „make“ but to manage. There has to be a tradeoff somehow.
For example, a cached snippet of HTML for a related products section should invalidate if the product IDs change, so you hash the Item ID with the product IDs and bam, you got a cache key that will let you know when you need to reprocess that snippet.
Put that bad boy as a child of another snippet and you can cache the whole lot. It's cache keys all the way down!
Caveat: not worth the engineering effort for simple systems, just use an FPC and call it a day.
Talking to customers would be one better way to maintain said clear understanding.
Running your own Shopify store (which Tobias also does) could potentially be another.
BTW, I am not surprised. A technical, programmer, CEO can always write code. Nothing wrong with that. It's just like an exercise. It is amazing that is able to do that.
All it shows is complete lack of trust and complete desire for control.
Shopify is an awful company to work for unless you’re a junior dev who likes nerding out and refactoring code over and over again.
Source: worked there
BTW what it shows is that, he loves to code. He already built an incredibly successful company. Whatever is that he does works. I love writing code too been doing it since I was 14. One of the reason I do not want to move to Engineering Management is the expectation of abandoning it.
> we started to see performance slowly degrading in terms
> of response times on the server, and eventually we kind
> of had to do something about it [...] Interesting story -
> the initial commits for that applications were Tobi
> himself
This sounds entirely like a founder who still solves problems with code, but then stands back and lets his company form a team around it if it's valuable.
No inside knowledge or anything, this just doesn't sound...bad.
It was super motivating for the reps, mostly junior in that role, to see their CEO doing it and remaining empathetic to what they're facing every day.
Not sure if that's like... the best reason in the world when he could be doing other more important things, but it was definitely a morale booster for the company to see him in the pit once in a while.
It's also good PR. That's why it's also mentioned by FB employees that Mark Zuckerberg has also made some commits to the their codebase.
BTW I
> Interesting story - the initial commits for that applications were Tobi himself, who took it upon himself to start something, and as a prototype gets something up and running and make it as lean as possible to get started. And then eventually, that became a team, and we picked it up, and that became the project that we’re working on.
The Founder-CEO is in the commit history. Duh. So what? That doesn't mean he's writing code right now.
I suspect it might be cultural - I've definitely got the impression that in some countries CEOs see themselves as "gods" who should not be questioned by the minions.
https://www.npr.org/2019/08/02/747660923/shopify-tobias-l-tk...
https://www.infoq.com/presentations/lutke-rockstar-memcachin...
But why or how on Earth would a person like Tobias Lutke find the time to do this? Are there other people who run multibillion dollar public companies who poke around in the codebase?
"Ultimately he had to force himself to stop revising and perfecting his peers’ work. “I had to say to myself, ‘Ok, we’re going to ship code that I didn’t edit,’” he said. “And that was hard for me, but I kinda got over that.”" https://www.cnbc.com/2018/05/10/bill-gates-quit-this-bad-hab...
One source suggests he last created production code in 1989, three years after MS went public (https://www.quora.com/When-did-Bill-Gates-last-write-code-fo....)
I also imagine that there was much less 'adult supervision' of Microsoft. They probably did not take (any?) VC money, did they?
The scene today is very different, so I wonder how such a thing happens in modern-day startups. As an investor, I would be alarmed at such egregious misallocation of valuable founder/C-suite time and brainpower.
EDIT: I have read many an anecdote (from Joel Spolsky, for example), wherein Bill Gates was said to have pored over the minutest specification in documents spanning hundreds of pages and understood all the subtlety involved. Once again, how on Earth did Bill find the time?