Compare commits
27 commits
valuatng-d
...
master
| Author | SHA1 | Date | |
|---|---|---|---|
a0e6a44929
|
|||
|
c8c6a35ab8
|
|||
|
d954c592c0
|
|||
|
810708960e
|
|||
|
f2968ca002
|
|||
|
12dc73abe3
|
|||
|
c4fab04e88
|
|||
| 91ae8c89f8 | |||
|
af1fce60a9
|
|||
|
b7918b1916
|
|||
|
59b20ecda8
|
|||
|
febcecfb67
|
|||
|
83551f4054 | ||
|
|
6f91249367 | ||
|
5fe8e838a6
|
|||
|
|
6fbb12fbc1 | ||
|
|
f70bfc9427 | ||
|
fa562c716e
|
|||
|
cbb5833011
|
|||
|
43ca19117c
|
|||
|
|
01a2ae4215 | ||
|
|
36d1911feb | ||
|
5dbd9ac124
|
|||
|
07bd39d84b
|
|||
|
88c3455822
|
|||
|
a6471f5baa
|
|||
|
0e7711771d
|
21 changed files with 1506 additions and 131 deletions
|
|
@ -1,139 +1,215 @@
|
|||
<!DOCTYPE HTML>
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8">
|
||||
<meta viewport="width=device-width, initial-scale=1">
|
||||
<link rel="stylesheet" href="styles.css">
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta viewport="width=device-width, initial-scale=1" />
|
||||
<link rel="stylesheet" href="styles.css" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>
|
||||
Hi, Pablo here
|
||||
</h1>
|
||||
<p>
|
||||
Welcome to my website. Here I discuss thoughts and ideas. This is mostly professional.
|
||||
</p>
|
||||
<hr>
|
||||
<h2>What you'll find here:</h2>
|
||||
<ul>
|
||||
<li><a href="#about-me-header">About me</a></li>
|
||||
<li><a href="#contact-header">Contact</a></li>
|
||||
<li><a href="#my-projects-header">My projects</a></li>
|
||||
<li><a href="#writings-header">Writings</a></li>
|
||||
</ul>
|
||||
<hr>
|
||||
<section>
|
||||
<h2 id="about-me-header">About me</h2>
|
||||
<p>A few facts you might care about:</p>
|
||||
<ul>
|
||||
<li>I'm based in Barcelona, although I'm happy working for anyone located anywhere (as long as we can
|
||||
find a time to meet).</li>
|
||||
<li>My career has focused in Data teams and positions, playing roles such as Data Lead, Data Engineer.
|
||||
</li>
|
||||
<li>Having said that, I have a lot of weird interests that might mix somehow, including:
|
||||
<ul>
|
||||
<li>Austrian economics and its societal and political implications</li>
|
||||
<li>Bitcoin</li>
|
||||
<li>P2P and privacy friendly applications</li>
|
||||
<li>Self-hosting and lowering the cost of people using advanced IT on a personal level</li>
|
||||
<li>Riding motorcycles</li>
|
||||
<li>Being annoyingly contrarian</li>
|
||||
<li>3D printing maps</li>
|
||||
<li>Teaching</li>
|
||||
<li>Film photography</li>
|
||||
<li>Calisthenics</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<hr>
|
||||
<section>
|
||||
<h2 id="contact-header">Contact</h2>
|
||||
<p>You can contact me on:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p><a href="https://www.linkedin.com/in/pablomartincalvo/">On LinkedIn</a> for professional matters.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>At this stage I'm not open to other contacts.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>If you are looking for my CV, no need to reach out, <a href="my_cv.pdf" target="_">you can fetch it
|
||||
yourself here.</a></p>
|
||||
<p>Good reason to reach out include:</p>
|
||||
<ul>
|
||||
<li>You want to work with me.</li>
|
||||
<li>Some of my interests, projects or writings caught your attention and you want to discuss them with
|
||||
me.</li>
|
||||
<li>Something fun!</li>
|
||||
</ul>
|
||||
<p>Bad reasons to reach out include:</p>
|
||||
<ul>
|
||||
<li>You want to sell me something, and you mostly care about selling that thing to me, not me loving the
|
||||
thing.</li>
|
||||
<li>You don't like something posted here and want to let me know your feelings.</li>
|
||||
</ul>
|
||||
</section>
|
||||
<hr>
|
||||
<section>
|
||||
<h2 id="my-projects-header">My projects</h2>
|
||||
<p>Some of the projects I've shared publicly:</p>
|
||||
<ul>
|
||||
<li><a href="https://github.com/pmartincalvo/dni" target="_blank" rel="noopener noreferrer">My Python
|
||||
package to handle Spanish DNIs better</a></li>
|
||||
<li><a href="https://www.meetup.com/bitcoin-barcelona" target="_blank"
|
||||
rel="noopener noreferrer">Barcelona Bitcoin Only, a local Bitcoin meetup and community I've
|
||||
helped organize and run</a></li>
|
||||
</ul>
|
||||
<p>There are also some other projects that I generally keep private but might disclose under the right
|
||||
circumstances. Some notable hints:</p>
|
||||
<ul>
|
||||
<li>That one time I made a lot of money doing something everyone said was stupid</li>
|
||||
<li>Some work around helping people ignore EU regulations around exchanging Bitcoin and Fiat
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<hr>
|
||||
<section>
|
||||
<h2 id="writings-header">Writings</h2>
|
||||
<p>Sometimes I like to jot down ideas and drop them here.</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="writings/one-efective-but-risky-way-to-find-the-top-budget-for-the-vacancy.html"
|
||||
target="_blank" rel="noopener noreferrer">One efective but risky way to find the top budget for
|
||||
the vacancy</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/bitcoin-mining-is-like-adding-the-final-piece-to-a-puzzle.html" target="_blank"
|
||||
rel="noopener noreferrer">Bitcoin mining is like adding the final piece to a puzzle</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/credit-cards-affairs-and-chatgpt.html" target="_blank"
|
||||
rel="noopener noreferrer">Credit cards, affairs and ChatGPT</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/when-new-is-not-better.html" target="_blank" rel="noopener noreferrer">When new is
|
||||
not better</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/i-want-code-defined-dashboards-so-badly.html" target="_blank"
|
||||
rel="noopener noreferrer">I want code defined dashboards so badly</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/a-simple-solution-to-spam.html" target="_blank" rel="noopener noreferrer">A
|
||||
simple solution to spam</a>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</section>
|
||||
</main>
|
||||
<footer>
|
||||
<p>Pablo Martín Calvo</p>
|
||||
</footer>
|
||||
<main>
|
||||
<h1>Hi, Pablo here</h1>
|
||||
<p>
|
||||
Welcome to my website. Here I discuss thoughts and ideas. This is mostly
|
||||
professional.
|
||||
</p>
|
||||
<hr />
|
||||
<h2>What you'll find here:</h2>
|
||||
<ul>
|
||||
<li><a href="#about-me-header">About me</a></li>
|
||||
<li><a href="#contact-header">Contact</a></li>
|
||||
<li><a href="#my-projects-header">My projects</a></li>
|
||||
<li><a href="#writings-header">Writings</a></li>
|
||||
</ul>
|
||||
<hr />
|
||||
<section>
|
||||
<h2 id="about-me-header">About me</h2>
|
||||
<p>A few facts you might care about:</p>
|
||||
<ul>
|
||||
<li>
|
||||
I'm based in Barcelona, although I'm happy working for anyone
|
||||
located anywhere (as long as we can find a time to meet).
|
||||
</li>
|
||||
<li>
|
||||
My career has focused in Data teams and positions, playing roles
|
||||
such as Data Lead, Data Engineer or Data Science Researcher. I've
|
||||
also tinkered quite a bit with many areas and technologies outside
|
||||
of data, but not in professional, production-grade settings.
|
||||
</li>
|
||||
<li>
|
||||
Having said that, I have a lot of weird interests that might mix
|
||||
somehow, including:
|
||||
<ul>
|
||||
<li>
|
||||
Austrian economics and its societal and political implications
|
||||
</li>
|
||||
<li>Bitcoin</li>
|
||||
<li>P2P and privacy friendly applications</li>
|
||||
<li>
|
||||
Self-hosting and lowering the cost of people using advanced IT
|
||||
on a personal level
|
||||
</li>
|
||||
<li>Riding motorcycles</li>
|
||||
<li>BBQ-ing</li>
|
||||
<li>Being annoyingly contrarian</li>
|
||||
<li>3D printing maps</li>
|
||||
<li>Teaching</li>
|
||||
<li>Film photography</li>
|
||||
<li>Tinkering with bicycles</li>
|
||||
<li>Calisthenics</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<hr />
|
||||
<section>
|
||||
<h2 id="contact-header">Contact</h2>
|
||||
<p>You can contact me on:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="https://www.linkedin.com/in/pablomartincalvo/">On LinkedIn</a>
|
||||
for professional matters.
|
||||
</li>
|
||||
<li>
|
||||
On keybase: <a href="https://keybase.io/pablomartincalvo">https://keybase.io/pablomartincalvo</a>.
|
||||
</li>
|
||||
<li>
|
||||
On Nostr. My npub is:
|
||||
npub1a29gdc6p7c05az2ka3qwwpl9kfcqmws3xlwmjefmtkulfhgd7u6shuqatg
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
If you are looking for my CV, no need to reach out,
|
||||
<a href="my_cv.pdf" target="_">you can fetch it yourself here.</a>
|
||||
</p>
|
||||
<p>Good reasons to reach out include:</p>
|
||||
<ul>
|
||||
<li>You want to work with me.</li>
|
||||
<li>
|
||||
Some of my interests, projects or writings caught your attention and
|
||||
you want to discuss them with me.
|
||||
</li>
|
||||
<li>Something fun!</li>
|
||||
</ul>
|
||||
<p>Bad reasons to reach out include:</p>
|
||||
<ul>
|
||||
<li>
|
||||
You want to sell something to me, and you mostly care about selling
|
||||
that thing to me, not me loving the thing.
|
||||
</li>
|
||||
<li>
|
||||
You don't like something posted here and want to let me know your
|
||||
feelings.
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<hr />
|
||||
<section>
|
||||
<h2 id="my-projects-header">My projects</h2>
|
||||
<p>Some of the projects I've shared publicly:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="https://www.meetup.com/bitcoin-barcelona" target="_blank" rel="noopener noreferrer">Barcelona Bitcoin
|
||||
Only, a local Bitcoin meetup and community I've
|
||||
helped organize and run</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://github.com/pmartincalvo/ntfy-emergency-app" target="_blank" rel="noopener noreferrer">A micro
|
||||
webapp to let your loved ones grab your attention via ntfy</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://github.com/pmartincalvo/dni" target="_blank" rel="noopener noreferrer">My Python package to
|
||||
handle Spanish DNIs better</a>
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
There are also some other projects that I generally keep private but
|
||||
might disclose under the right circumstances. Some notable hints:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
That one time I made a lot of money doing something everyone said
|
||||
was stupid
|
||||
</li>
|
||||
<li>
|
||||
Some work around helping people ignore EU regulations around
|
||||
exchanging Bitcoin and Fiat
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<hr />
|
||||
<section>
|
||||
<h2 id="writings-header">Writings</h2>
|
||||
<p>Sometimes I like to jot down ideas and drop them here.</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="writings/a-note-for-the-future-the-tax-bleeding-in-2025.html" target="_blank"
|
||||
rel="noopener noreferrer">A note for the future: the tax bleeding in 2025</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/notes-and-lessons-from-my-departure-from-superhog.html" target="_blank"
|
||||
rel="noopener noreferrer">Notes and lessons from my departure from Superhog</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/is-your-drug-dealer-a-homophobic-socialist.html" target="_blank"
|
||||
rel="noopener noreferrer">Is your drug dealer a homophobic socialist?</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/gresham-law-has-nothing-to-do-with-bitcoin.html" target="_blank"
|
||||
rel="noopener noreferrer">Gresham's Law has nothing to do with Bitcoin</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/my-tips-and-tricks-when-using-postgres-as-a-dwh.html" target="_blank"
|
||||
rel="noopener noreferrer">My tips and tricks when using Postgres as a DWH</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/dont-hide-it-make-it-beautiful.html" target="_blank" rel="noopener noreferrer">Don't hide
|
||||
it, make it beautiful</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/the-roi-of-toilets.html" target="_blank" rel="noopener noreferrer">The ROI of toilets</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/your-customers-dont-care-that-your-bathroom-is-dirty.html" target="_blank"
|
||||
rel="noopener noreferrer">Your customers don't care that your bathroom is dirty</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/if-i-started-a-data-team-again.html" target="_blank" rel="noopener noreferrer">If I started
|
||||
a Data team again</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/one-efective-but-risky-way-to-find-the-top-budget-for-the-vacancy.html" target="_blank"
|
||||
rel="noopener noreferrer">One efective but risky way to find the top budget for the
|
||||
vacancy</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/bitcoin-mining-is-like-adding-the-final-piece-to-a-puzzle.html" target="_blank"
|
||||
rel="noopener noreferrer">Bitcoin mining is like adding the final piece to a puzzle</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/credit-cards-affairs-and-chatgpt.html" target="_blank" rel="noopener noreferrer">Credit
|
||||
cards, affairs and ChatGPT</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/when-new-is-not-better.html" target="_blank" rel="noopener noreferrer">When new is not
|
||||
better</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/i-want-code-defined-dashboards-so-badly.html" target="_blank" rel="noopener noreferrer">I
|
||||
want code defined dashboards so badly</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="writings/a-simple-solution-to-spam.html" target="_blank" rel="noopener noreferrer">A simple solution
|
||||
to spam</a>
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
</main>
|
||||
<footer>
|
||||
<p>Pablo Martín Calvo</p>
|
||||
</footer>
|
||||
</body>
|
||||
|
||||
</html>
|
||||
56
public/keybase.txt
Normal file
56
public/keybase.txt
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
==================================================================
|
||||
https://keybase.io/pablomartincalvo
|
||||
--------------------------------------------------------------------
|
||||
|
||||
I hereby claim:
|
||||
|
||||
* I am an admin of https://pablohere.contrapeso.xyz
|
||||
* I am pablomartincalvo (https://keybase.io/pablomartincalvo) on keybase.
|
||||
* I have a public key ASDgHxztDlU_R4hjxbkO21-rS4Iv1gABa3BPb_Aff7aNAgo
|
||||
|
||||
To do so, I am signing this object:
|
||||
|
||||
{
|
||||
"body": {
|
||||
"key": {
|
||||
"eldest_kid": "0120d9bde13d9012e681cef2edd668d70426f1f6ef69ce7dfae20b404096eca5b06f0a",
|
||||
"host": "keybase.io",
|
||||
"kid": "0120e01f1ced0e553f478863c5b90edb5fab4b822fd600016b704f6ff01f7fb68d020a",
|
||||
"uid": "8e71277fbc0fb1fea28d60308f495d19",
|
||||
"username": "pablomartincalvo"
|
||||
},
|
||||
"merkle_root": {
|
||||
"ctime": 1755635067,
|
||||
"hash": "4f91af0b9c674e0f1d74a7cfad7abd15a7065cded92b96ac8a6abeb5c8553318599aa1bf7b065a3312e303506256b729b8b60b3a5dd06b68694423f4341a6a14",
|
||||
"hash_meta": "6472dbf2ed33341fb30b6a0c5c5c7fb39c219dd0ffd03c6e08b68c788e0de60a",
|
||||
"seqno": 27031070
|
||||
},
|
||||
"service": {
|
||||
"entropy": "LEFJJ4FMmlJQWPPFEO4xHE5y",
|
||||
"hostname": "pablohere.contrapeso.xyz",
|
||||
"protocol": "https:"
|
||||
},
|
||||
"type": "web_service_binding",
|
||||
"version": 2
|
||||
},
|
||||
"client": {
|
||||
"name": "keybase.io go client",
|
||||
"version": "6.5.1"
|
||||
},
|
||||
"ctime": 1755635082,
|
||||
"expire_in": 504576000,
|
||||
"prev": "37f12270050ab037897ccf6ef9451b1911cb505eca7c3842993b0b8925bc79b8",
|
||||
"seqno": 31,
|
||||
"tag": "signature"
|
||||
}
|
||||
|
||||
which yields the signature:
|
||||
|
||||
hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEg4B8c7Q5VP0eIY8W5Dttfq0uCL9YAAWtwT2/wH3+2jQIKp3BheWxvYWTESpcCH8QgN/EicAUKsDeJfM9u+UUbGRHLUF7KfDhCmTsLiSW8ebjEIAnIWTmufZ017e9WLdI1LhKBPaZ3HzmTrgyASDvY3PwoAgHCo3NpZ8RA9a3xgkSTU6Ht7M7DCsy4ClMmoWFtDEqzX9/dqskeoH2DrJUZYVymBQE1nyB0p1GuXiZA1cP5WY5SDURWZ5bBC6hzaWdfdHlwZSCkaGFzaIKkdHlwZQildmFsdWXEIEJZ4g4HC5qXcqbFf6sJ8XuZyMtoppazFqr1zPu0LH5co3RhZ80CAqd2ZXJzaW9uAQ==
|
||||
|
||||
And finally, I am proving ownership of this host by posting or
|
||||
appending to this document.
|
||||
|
||||
View my publicly-auditable identity here: https://keybase.io/pablomartincalvo
|
||||
|
||||
==================================================================
|
||||
BIN
public/my_cv.pdf
BIN
public/my_cv.pdf
Binary file not shown.
BIN
public/static/computers.png
Normal file
BIN
public/static/computers.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.5 MiB |
BIN
public/static/data-alley-oop.jpeg
Normal file
BIN
public/static/data-alley-oop.jpeg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 246 KiB |
BIN
public/static/homophobic-socialist-drug-dealer.png
Normal file
BIN
public/static/homophobic-socialist-drug-dealer.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.2 MiB |
BIN
public/static/hospitals-inside.png
Normal file
BIN
public/static/hospitals-inside.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 10 MiB |
BIN
public/static/hospitals-outside.png
Normal file
BIN
public/static/hospitals-outside.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 MiB |
BIN
public/static/plumbings.png
Normal file
BIN
public/static/plumbings.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 MiB |
BIN
public/static/stations.png
Normal file
BIN
public/static/stations.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 10 MiB |
BIN
public/static/streetlamps.png
Normal file
BIN
public/static/streetlamps.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 MiB |
|
|
@ -21,7 +21,8 @@ img {
|
|||
display: block;
|
||||
}
|
||||
|
||||
figcaption a {
|
||||
figcaption {
|
||||
font-style: italic;
|
||||
font-size: small;
|
||||
text-align: center;
|
||||
}
|
||||
|
|
@ -0,0 +1,188 @@
|
|||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta viewport="width=device-width, initial-scale=1" />
|
||||
<link rel="stylesheet" href="../styles.css" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>Hi, Pablo here</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr />
|
||||
<section>
|
||||
<h2>A note for the future: the tax bleeding in 2025</h2>
|
||||
<p>
|
||||
I hate taxes deeply. I fell through the rabbit hole of libertarian and
|
||||
anarcocapitalist ideas some years ago, and taxes have been repulsive
|
||||
to me ever since. I go to great lengths to not pay them, and feel
|
||||
deeply hurt everytime they sting my wallet against my will.
|
||||
</p>
|
||||
<p>
|
||||
I know life goes by fast, and what today is vivid in your memory fades
|
||||
away bit by bit until it's gone. I'm truly hoping that, some day in
|
||||
the future, the world will have changed to the better and people won't
|
||||
be paying as much tax as we're doing today in the West. Since in that
|
||||
bright, utopical future I'm dreaming of I might have forgotten about
|
||||
how bad things were on this matter in 2025, I've decided to make a
|
||||
little entry here making an estimate on how many taxes I'm
|
||||
theoretically bleeding on a yearly basis right now. So that we can
|
||||
someday look back in time and wonder: "how the fuck did we tolerate
|
||||
that pillaging".
|
||||
</p>
|
||||
<h3>Inventory</h3>
|
||||
<p>
|
||||
Before going hard into the number crunching let's list all the tax
|
||||
items I'm aware of being subject to:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
Income Tax: for the sin of making money, the state takes a hefty
|
||||
bite of my salary.
|
||||
</li>
|
||||
<li>
|
||||
Social Security: the state runs a forceful Social Security
|
||||
programme. If you work, it is illegal to not pay for it. It is
|
||||
specially unnerving since it is quite literally a ponzi scheme. At
|
||||
least Madoff lured you into it with pretty words, not violence.
|
||||
</li>
|
||||
<li>
|
||||
VAT Tax: for the sin of buying stuff, the state takes another hefty
|
||||
bite.
|
||||
</li>
|
||||
<li>
|
||||
Real State Tax: for the sin of owning an apartment, the state
|
||||
charges me rent. Do I own it actually?
|
||||
</li>
|
||||
<li>
|
||||
Vehicle Tax: for the sin of owning a motorcycle, the state charges
|
||||
me a yearly fee.
|
||||
</li>
|
||||
<li>
|
||||
Wealth Transfer Tax: when you buy real state, you must pay 10% of
|
||||
its value in taxes. This is a one off fee if you only buy one house
|
||||
in your lifetime, but it is such a slap on the face that it would be
|
||||
dishonest to not consider it.
|
||||
</li>
|
||||
<li>
|
||||
Inheritance tax: you thought you were going to keep daddy's loot all
|
||||
for yourself? When you inherit, you'll go through the register
|
||||
again. Like the wealth transfer tax, is not a frequent one, but it's
|
||||
big so let's consider it.
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
There may be some other small, less frequent taxes that I'm not
|
||||
considering. These are the ones that will hit most people in my
|
||||
country.
|
||||
</p>
|
||||
<h3>The numbers</h3>
|
||||
<p>
|
||||
Okay, let's go compute the hideous bill. I'll make a hypothetical
|
||||
profile that's roughly close to mine, with a few assumptions along the
|
||||
way.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
<em>Salary</em>: online sources say the typical salary for my job
|
||||
position in my area is 70k€ yearly. Including the Social Security
|
||||
paid by the company, the sum rises to ~85K€. I consider this way of
|
||||
measuring honest, since I think that all the money paid out by the
|
||||
employer reflects what's the true salary and value of the employee.
|
||||
I read it as, "the company is willing to pay 85K€ for this. What
|
||||
ends up in the employees pocket, and what in the State's, they don't
|
||||
mind".
|
||||
</li>
|
||||
<li><em>Expenses</em>: I'll assume I spend half of my salary.</li>
|
||||
<li>
|
||||
<em>Home Purchase</em>: I'll assume that, during my adult life, I
|
||||
would buy once the average home in my town. From what I could find
|
||||
online, that's somewhere around 500K€.
|
||||
</li>
|
||||
<li>
|
||||
<em>Vehicles</em>: I own a motorcycle and share the expenses of a
|
||||
car with my partner, so I'll count 1.5 vehicles.
|
||||
</li>
|
||||
<li>
|
||||
<em>Inheritance tax</em>: I found a figure stating the average
|
||||
windfall in my country is 250K€. We'll go with that.
|
||||
</li>
|
||||
</ul>
|
||||
<p>With those clear, let's see the actual figures:</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Tax</th>
|
||||
<th>€/year</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Income Tax (IRPF)</td>
|
||||
<td>22,401 €</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Social Security (worker + employer)</td>
|
||||
<td>
|
||||
25,375 €
|
||||
<small
|
||||
>(worker 4,445 € + employer 20,930 €)</small
|
||||
>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>VAT (blended basket)</td>
|
||||
<td>5,250 €</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Real Estate Tax (IBI)</td>
|
||||
<td>1,000 €</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Vehicle Tax (1.5 vehicles)</td>
|
||||
<td>225 €</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Wealth Transfer (10% home, spread 50y)</td>
|
||||
<td>1,000 €</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Inheritance (7% of 250k, spread 50y)</td>
|
||||
<td>350 €</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
<tfoot>
|
||||
<tr>
|
||||
<th>Total</th>
|
||||
<th>55,602 €</th>
|
||||
</tr>
|
||||
</tfoot>
|
||||
</table>
|
||||
<p>
|
||||
So there you go. A peaceful existence as a tech professional living a
|
||||
normal life leads to bleeding at least 55K€ per year, all while
|
||||
getting an 85K€ salary. The tax rate sits at a wonderful 64%. How far
|
||||
away is this from hardcore USSR-grade communism?
|
||||
</p>
|
||||
<p>
|
||||
And this is generous, since I didn't model (1) what gets stolen
|
||||
through inflation diluting savings and (2) any capital gains that this
|
||||
profile might end up paying for whatever investments he is doing with
|
||||
his savings.
|
||||
</p>
|
||||
<p>
|
||||
Then you'll see mainstream media puppets discussing why young people
|
||||
don't have children. As if it was some kind of mistery. They're being
|
||||
robbed their children's bread left and right, while getting hypnotized
|
||||
into believing that protecting themselves against this outrageous
|
||||
robbery is somehow morally despicable.
|
||||
</p>
|
||||
<p>Motherfuckers.</p>
|
||||
<hr />
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
</body>
|
||||
</html>
|
||||
125
public/writings/dont-hide-it-make-it-beautiful.html
Normal file
125
public/writings/dont-hide-it-make-it-beautiful.html
Normal file
|
|
@ -0,0 +1,125 @@
|
|||
<!DOCTYPE HTML>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8">
|
||||
<meta viewport="width=device-width, initial-scale=1">
|
||||
<link rel="stylesheet" href="../styles.css">
|
||||
</head>
|
||||
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>
|
||||
Hi, Pablo here
|
||||
</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr>
|
||||
<section>
|
||||
<h2>Don't hide it, make it beautiful</h2>
|
||||
<p>I'm currently living in a flat, and my internet connection physically comes in through my living room. That's where
|
||||
my home router is placed. However, my main workspace is not in my living room but in my working room,
|
||||
which is a few meters away. I would love to have a wired internet connection for my laptop, but unfortunately, with
|
||||
the router being so far away, setting it up would require running a lot of cable through the walls and
|
||||
ceilings. I could either leave the cable visible or go through some serious construction work to poke holes through walls and fake ceilings and
|
||||
tunnel the cable through there. The latter is out of the table, since I don't even know where would I start.</p>
|
||||
|
||||
<p>The first option being the only available one, there is one fundamental and unavoidable reason I don't do this: aesthetics. My partner is very conscious about
|
||||
keeping our home visually pleasing. I care too, though she probably values aesthetics even more than I
|
||||
do. She likely doesn't find a wired internet connection to be as essential as I do. So, for now, I have to rely on
|
||||
wifi to connect from my workspace to the home router.</p>
|
||||
|
||||
<p>When I was on holiday in Thailand a few years ago, I noticed that Thai homes are far more practical than
|
||||
European ones in such matters. In Thailand, plumbing, electrical systems, and other maintenance-requiring
|
||||
installations are typically very visible, just out there on the wall. They don't hide these things behind
|
||||
fake walls or ceilings. I believe they do this because they highly value the ability to access and work
|
||||
on their home's systems themselves. Many Thai people build and maintain their own homes, so they leave
|
||||
everything exposed for easy access.</p>
|
||||
|
||||
<p>I sometimes envy this approach. Which is funny because I don't think they do it for pleasure but out of necessity.
|
||||
Still, when I saw a Thai homeowner fixing their plumbing outside their house, I thought to myself: "Damn, you're so
|
||||
in control of your home". If something bad happens—like a fallen tree damaging the plumbing—they can fix
|
||||
it themselves. Meanwhile, if that happened to me, I wouldn't even know where to start. I don't even know
|
||||
where my plumbing is because it's all hidden behind walls.</p>
|
||||
|
||||
<p>That makes me wonder: Is there a way to make these essential systems both accessible and aesthetically
|
||||
pleasing? Could we have the convenience of exposed infrastructure without it looking ugly? I believe we
|
||||
can.</p>
|
||||
|
||||
<p>I find the problem is that we have decided certain things—plumbing, electrical wiring, visible
|
||||
infrastructure—are inherently ugly. But they don't have to be. Some household items, like lamps, must be
|
||||
visible by their very nature. Since they can't be hidden, we put effort into making them look good. We choose stylish designs
|
||||
that complement our home's aesthetics. Why can't we do the same for cables and pipes?</p>
|
||||
|
||||
<p>Imagine if all the wiring in your home was encased in beautifully braided, colorful ropes, arranged in
|
||||
elegant geometric patterns. The connections, junction boxes, and fittings could be crafted from
|
||||
high-quality materials like metal and wood with artistic designs. Wouldn't that be nice?</p>
|
||||
|
||||
<p>Now, you might think I'm crazy—that these things are just ugly by nature. But they're not. In fact, many
|
||||
aspects of modern design have become uglier over time, and we've just accepted it.</p>
|
||||
|
||||
<p>Consider street lamps. In most cities today, they are dull, industrial-looking poles—rusty, ugly,
|
||||
and purely functional. Yet, in older parts of my city, we still have beautiful, ornate lamp posts from
|
||||
over a hundred years ago. They were designed with care, meant to serve a purpose, to be visually
|
||||
appealing, and to last ages. Take a look:</p>
|
||||
|
||||
<figure style="width: 75%; margin: 10px auto;">
|
||||
<img width="100%" height="auto" src="../static/streetlamps.png" alt="">
|
||||
<figcaption>On the left, your ugly, could-be-anywhere post 1971 streetlamp. On the right, a 19th century bad body from Gaudí.</figcaption>
|
||||
</figure>
|
||||
|
||||
<p>The same goes for train stations. Modern stations are bleak, sterile spaces—metal, plastic, and harsh
|
||||
lighting. They resemble hospital emergency rooms. But look at the older ones, like this one.
|
||||
Those stations are masterpieces, designed like grand halls with chandeliers and intricate details.</p>
|
||||
|
||||
<figure style="width: 75%; margin: 10px auto;">
|
||||
<img width="100%" height="auto" src="../static/stations.png" alt="">
|
||||
<figcaption>On the left, Sants Station, built in 1975. On the right, France Station, built in 1848.</figcaption>
|
||||
</figure>
|
||||
|
||||
<p>And talking about hospitals, they are also a good example. Most modern hospitals have the same white, cold, spaceship-like
|
||||
aesthetic. While cleanliness is important, there's no reason they have to be so uninviting. In my city,
|
||||
there's a hospital built over a hundred years ago that's so beautiful people visit it as a tourist
|
||||
attraction. On the other hand, the hospitals I visit personally are plain depressing, soviet style
|
||||
atrocities.</p>
|
||||
|
||||
<figure style="width: 75%; margin: 10px auto;">
|
||||
<img width="100%" height="auto" src="../static/hospitals-outside.png" alt="">
|
||||
<figcaption>A random modern clinic in Barcelona vs A small section of the outside of Hospital de Sant Pau. I can skip the left and right thing now, right?</figcaption>
|
||||
</figure>
|
||||
<figure style="width: 75%; margin: 10px auto;">
|
||||
<img width="100%" height="auto" src="../static/hospitals-inside.png" alt="">
|
||||
<figcaption> Some random room in that same modern clinic vs Your regular corridor in Sant Pau.</figcaption>
|
||||
</figure>
|
||||
|
||||
|
||||
|
||||
<p>I think we can bring things back, if we care enough.</p>
|
||||
|
||||
<p>Look at computers. Most office desktop cases are dull, gray boxes—uninspired and purely functional.
|
||||
Naturally, many of them end up buried inside desks, or if they are small enough, simply hidden behind
|
||||
the screen on a VESA mount. But gamers, who deeply care about their PCs, go the extra mile to make their
|
||||
setups look amazing. They invest in custom cases, LED lighting, and stylish cooling systems. They turn
|
||||
their computers into art. They are testament to the fact that we can make practical things also be
|
||||
beautiful if we choose to.</p>
|
||||
|
||||
<figure style="width: 75%; margin: 10px auto;">
|
||||
<img width="100%" height="auto" src="../static/computers.png" alt="">
|
||||
<figcaption> The all-present ugly office optiplex vs A beautiful case from a passionate man.</figcaption>
|
||||
</figure>
|
||||
|
||||
<p>If we put the same effort into our homes, we wouldn't need to hide cables and pipes. We could proudly
|
||||
display them as part of our interior design. Infrastructure could be both functional and beautiful,
|
||||
giving us accessibility without sacrificing aesthetics. </p>
|
||||
|
||||
<p>I guess the point I want to make is... Don't hide it. Instead, make it beautiful.</p>
|
||||
|
||||
<hr>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
138
public/writings/gresham-law-has-nothing-to-do-with-bitcoin.html
Normal file
138
public/writings/gresham-law-has-nothing-to-do-with-bitcoin.html
Normal file
|
|
@ -0,0 +1,138 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta viewport="width=device-width, initial-scale=1" />
|
||||
<link rel="stylesheet" href="../styles.css" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>Hi, Pablo here</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr />
|
||||
<section>
|
||||
<h2>Gresham's Law has nothing to do with Bitcoin</h2>
|
||||
<p>
|
||||
This is going to be a thorough explanation for a simple thing, but we
|
||||
will take it slow since this topic somehow causes loads of confusion.
|
||||
</p>
|
||||
<p>
|
||||
Okay, so there are a lot of people in Bitcoin circles who talk about
|
||||
<a href="https://en.wikipedia.org/wiki/Gresham%27s_law" target="_blank" rel="noopener noreferrer">Gresham's
|
||||
Law</a>. They often say, “Gresham's Law states that bad money drives out
|
||||
good money”, then relate it to Bitcoin and the USD, and finally
|
||||
proceed to reason all sort of of things on top of that. But here's
|
||||
some very much needed clarification: Gresham's law has nothing to do
|
||||
with Bitcoin's relationship to the USD. In fact, it actually has
|
||||
nothing to do Bitcoin, or with the current USD for that matter.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Gresham's Law is relevant to a very specific type of monetary system:
|
||||
when we used coins that contained precious metals (spoiler: we don't
|
||||
live in that period of history anymore). The law states that bad money
|
||||
drives out good money, but what a lot of Bitcoiners seem to miss is
|
||||
the actual meaning of “good” and “bad” in this context. People tend to
|
||||
interpret “good” and “bad” as meaning “hard” and "easy" money, so they
|
||||
reason something like: “Because Bitcoin is harder than the USD,
|
||||
Gresham's law applies here.” But that is not what Gresham's law is
|
||||
about at all.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the context of Gresham's law, “good” and “bad” refer to face value
|
||||
versus commodity value. That doesn't ring a bell? Let me explain:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Imagine a magic land where there is only one type of coin. There's no
|
||||
other money — just this one coin. These coin states on themselves that
|
||||
they contain one gram of gold, and right now, they really do contain
|
||||
one gram of gold. Everyone uses it, and everyone is happy. There's no
|
||||
“bad” money, no “good” money — it's all nice and simple.
|
||||
</p>
|
||||
|
||||
<p>Now, let's spice it up a bit.</p>
|
||||
|
||||
<p>
|
||||
After some time, a cheeky bastard (typically, a king) comes along and
|
||||
starts making coins that look exactly like the original coins. I'll
|
||||
call these the bad coins. The original coins will be the good coins.
|
||||
Both types of coins say on them “one gram of gold,” but the bad coins
|
||||
only have half a gram of gold actually in them (hence why they are
|
||||
bad).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
So, to recap:<br />
|
||||
- Good coins: one gram of gold on the coin, and actually one gram of
|
||||
gold inside.<br />
|
||||
- Bad coins: one gram of gold on the coin, but only 0.5 grams of gold
|
||||
inside.
|
||||
</p>
|
||||
|
||||
<p>This is where Gresham's Law applies.</p>
|
||||
|
||||
<p>
|
||||
People in this coiny fantasy land are not stupid — they know that the
|
||||
gold content is what matters. At some point, someone will realize the
|
||||
bad coins don't have as much gold as they claim and will develop a
|
||||
preference for the good ones. So, if I'm John the Blacksmith and I
|
||||
want to buy some iron, and I have a stash of coins — some good, some
|
||||
bad — I would rather keep the good coins and spend the bad coins. Why?
|
||||
Because I want to keep as much gold as possible, of course.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
What happens eventually is that people grow into the habit of trying to get
|
||||
rid of the bad coins and hold on to the good coins. They exploit the
|
||||
confusion created by the fact that all coins have the same face value
|
||||
(it says “one gram” on all coins, so everyone assumes they're worth
|
||||
the same), even though the actual commodity value (the gold inside)
|
||||
differs.<a href="#footnote-1">[1]</a>
|
||||
</p>
|
||||
|
||||
<p>That is the quick explanation of Gresham's law.</p>
|
||||
|
||||
<p>
|
||||
Now, back to the original point: what are the face value and commodity
|
||||
value of Bitcoin?
|
||||
</p>
|
||||
|
||||
<p>
|
||||
That makes no sense! Bitcoin is not a physical coin with metal in
|
||||
it. It has no concept of face and commodity value. And neither does the
|
||||
USD nowadays. Therefore, Gresham's law has absolutely nothing to do
|
||||
with Bitcoin, the USD and any preferences the world might develop
|
||||
between the two.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Hopefully, this explanation helps make things clear. From now on, if
|
||||
you want to keep your public image intact, please refrain from
|
||||
invoking Gresham's law when discussing Bitcoin and USD — because doing it
|
||||
shows you don't know what Gresham's Law is actually about. Don't feel
|
||||
too bad if it happened to you though: it can happen even to
|
||||
<a href="https://river.com/learn/terms/g/greshams-law/" target="_blank" rel="noopener noreferrer">massive
|
||||
exchanges with a great reputation.</a>
|
||||
</p>
|
||||
|
||||
<p id="footnote-1" class="footnote">
|
||||
<em>[1] Not relevant to the point of this post, but it's worth noting
|
||||
that Gresham's Law situation is not always sure to happen in the
|
||||
described scenario. If the difference between the good and bad coins
|
||||
is massive, and no force opposes it, the market might jump into
|
||||
<a href="https://en.wikipedia.org/wiki/Gresham%27s_law#Reverse_of_Gresham's_law_(Thiers'_law)" target="_blank"
|
||||
rel="noopener noreferrer">Thier's Law</a>
|
||||
instead.</em>
|
||||
</p>
|
||||
<hr />
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
</body>
|
||||
|
||||
</html>
|
||||
150
public/writings/if-i-started-a-data-team-again.html
Normal file
150
public/writings/if-i-started-a-data-team-again.html
Normal file
|
|
@ -0,0 +1,150 @@
|
|||
<!DOCTYPE HTML>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8">
|
||||
<meta viewport="width=device-width, initial-scale=1">
|
||||
<link rel="stylesheet" href="../styles.css">
|
||||
</head>
|
||||
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>
|
||||
Hi, Pablo here
|
||||
</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr>
|
||||
<section>
|
||||
<h2>If I started a Data team again</h2>
|
||||
<p>
|
||||
In November 2023, I joined <a href="https://truvi.com/">Truvi</a> (<a
|
||||
href="https://truvi.com/blog/superhog-becomes-truvi/">back then called Superhog</a>) as the first
|
||||
member of its new Data team, effectively making my hiring and the team's birth the same thing. The CEO
|
||||
and COO brought me in to help a young, upcoming and quite chaotic UK SaaS company make it out of the
|
||||
void of Data darkness, where no one knew shit, figures came in with three months of delay and VLOOKUP
|
||||
was the closest thing there was to integrating data from two systems.
|
||||
</p>
|
||||
<p>
|
||||
The team is nowadays very much established and critical for the business. We've built our spot within
|
||||
the org, and many colleagues wonder how life could ever exist before. We can tell many tales on
|
||||
delivering value to Truvi, and we have ambitious plans to keep doing more and better. And I'm having a
|
||||
blast leading it.
|
||||
</p>
|
||||
<p>
|
||||
For me, it was quite a journey: it was the first time I started a Data team from a greenfield situation.
|
||||
Some day I'll make a longish writing on the whole experience, but today, I wanted to focus on a few
|
||||
regrets I have. I personally think I've done a good work, I'm proud of where the team is at today, and
|
||||
the words (and actions) of the company board show that they are aligned with this. But still, there's
|
||||
always room to fuck up, and I do have a few parts of the story where, looking back in retrospective, I
|
||||
think I took the wrong turn.
|
||||
</p>
|
||||
<p>
|
||||
The first thing I regret is not hiring faster which, taking personal responsibility, means I didn't
|
||||
focus enough on it and I wasn't as effective as I should have been. When I started the team, I quickly
|
||||
secured consensus from the founders to go hire two more members for it, and we all agreed it made sense
|
||||
to spend those bullets to find two Data Analysts. We found <a
|
||||
href="https://es.linkedin.com/in/oriol-roqu%C3%A9-paniagua-708946158" target="_blank"
|
||||
rel="noopener noreferrer">Uri</a> and <a href="https://es.linkedin.com/in/joaquin-ossa"
|
||||
target="_blank" rel="noopener noreferrer">Joaquín</a>, which are still with us today doing a
|
||||
terrific job.
|
||||
</p>
|
||||
<p>
|
||||
The bad news is they joined in May 2024, which means it took a whopping ~6 months from decision to
|
||||
result. It didn't feel terrible at that moment. I was very much busy with the onslaught of work that
|
||||
comes with kickstarting the team (meeting everyone, aligning with other teams, designing and starting
|
||||
out infra, doing basic, urgent starting deliveries, etc.). But now I realise some of those things would
|
||||
have been easier to do with the guys already around. So there goes regret number one. Lesson: if you
|
||||
have agreement to get more hands on the team, make it priority #1.
|
||||
</p>
|
||||
<p>
|
||||
The second thing I'm not happy about is not completely dropping and rebuilding a few legacy bits I
|
||||
inherited when joining. Truvi had an insane amount of unmet needs in data and reporting right before I
|
||||
joined, so a bit of capacity from the development teams was derailed at some point to create a couple of
|
||||
basic reporting and data exporting tools to support other teams. Those were small and done in a rather
|
||||
crude way, as a result of (1) being done by backend guys with no previous experience in the Data domain,
|
||||
and (2) in parallel to other very important product development work. I don't blame them, <a
|
||||
href="https://retrospectivewiki.org/index.php?title=The_Prime_Directive" target="_blank"
|
||||
rel="noopener noreferrer">I assume they did the best they could given the circumstances.</a>
|
||||
</p>
|
||||
<p>
|
||||
My mistake was to decide early to inherit and continue those, instead of bulldozering them and building
|
||||
things from scratch with better tools and practices. It would have been quite easy to do at the time
|
||||
given that those data products were rather small (and coming back to my first regret, it would probably
|
||||
have been even easier to bulldozer them if the new hires would have been around already). At the time, I
|
||||
traded off leaving those be and have a continuist approach to building incrementally in order to get
|
||||
going with some other fresh new scopes faster. I'm not fully sure that the call was wrong (perhaps in a
|
||||
parallel universe, I would think we shouldn't have rebuild those from scratch because it delayed
|
||||
delivering other important things). But I do feel it was wrong right now. As a consequence, today we
|
||||
have several data products and architectural constraints which are a royal pain in the ass to maintain
|
||||
and grow with the company. For example, we're currently stuck with a lot of reporting in Power BI, which
|
||||
I hate for multiple reasons, one of them being <a href="i-want-code-defined-dashboards-so-badly.html"
|
||||
target="_blank" rel="noopener noreferrer">how badly I want to have code defined dashboards</a>.
|
||||
Bulldozering and replacing now will be much more painful than it would have been back then, so the
|
||||
velocity of the team is now paying for this mistake.
|
||||
</p>
|
||||
<p>
|
||||
There goes another lesson: if you're inheriting a few, small legacy products that don't fit in your view
|
||||
and you can afford to remove or re-build them to allow your plans to be pristine, do it now. Don't wait.
|
||||
</p>
|
||||
<p>
|
||||
A third thing I would have done differently is to start working on Data literacy across the company
|
||||
earlier and more intensely. In part of the work we do in the Data team, we come in with a very polished,
|
||||
mature result: this is exactly what you need to know, or the exact pristine, read-only grade data you
|
||||
had to check, or the informed decision you are after. But in many other cases, our delivery ends at the
|
||||
start of what I like to call the analytical last-mile: we produce some curated piece of insight and/or
|
||||
data that a colleague will grab and work a bit more before getting to the final business outcome. For
|
||||
example, I might export a set of KPIs around certain client accounts, and an account manager will pivot
|
||||
and fuck around with them to decide certain things around how he will handle some comms with his
|
||||
accounts.
|
||||
</p>
|
||||
<figure>
|
||||
<img src="../static/data-alley-oop.jpeg" width="75%">
|
||||
</figure>
|
||||
<p>
|
||||
This kind of two-step deliveries sometimes are insanely valuable: there are some analysis where
|
||||
the final user of the data is the most capable of juicing the right way, such as when someone takes
|
||||
the data to use it in real time in a negotiation meeting.
|
||||
</p>
|
||||
<p>
|
||||
The bad news is that, if John from Marketing fucking sucks at Power BI, Excel, or whatever tooling you
|
||||
rely on to interact with your colleagues, the whole plot falls down. I'm not expecting John to crank out
|
||||
a monster workbook with thirty layers of business logic and seven modules of VBA, but pivoting a bit,
|
||||
filtering, multiply this col by that row, etc. You get the gist. If you're thinking to yourself: "anyone
|
||||
can do such basic things!", I would kindly invite you to sit down 15 min with some rando in your company
|
||||
and see them use Excel live, potentially having chunked some tranquilizer down.
|
||||
</p>
|
||||
<p>
|
||||
Training more colleagues outside the Data team to be more proficient working with data (let it be
|
||||
working on Excel, writing SQL or just reasoning) is something we're actively working on now, but I think
|
||||
we should have started out earlier. I think this because of two reasons: the first, the ROI, measured in
|
||||
time, is tremendous. 5 hours of working with Jane from Finance to skill her up from 0 to Excel basics
|
||||
are probably much more impactful than that extra dashboard you are building, which you already sense
|
||||
won't be that used or valuable. The second is, this is one of the things that has a capped max pace to
|
||||
it, and won't happen faster than that no matter how hard you would like it to, or how many resources and
|
||||
money you want to throw at it. People learn at a certain pace, so it's better to start early and slow,
|
||||
than to trick yourself into believing you'll be able to turn Jimmy into a Power BI God in 2 days if you
|
||||
try hard enough when the time comes.
|
||||
</p>
|
||||
<p>
|
||||
So, final lesson: I would start running Data literacy initiatives early. It doesn't need to take a big
|
||||
chunk of your capacity: sprinkling a few open sessions here and there, and running some 1:1 or small
|
||||
group ones with bright people, should be more than enough. It will compound over time, leading to the
|
||||
company better leveraging your data and tools, and the central Data team having more capacity to keep
|
||||
building since more end-users will be more independent.
|
||||
</p>
|
||||
<p>
|
||||
There goes my non-exhaustive list of things I would do differently when starting a Data team from
|
||||
scratch. I hope it serves you if you are in a similar spot. I'm personally delighted with the idea of
|
||||
not screwing up in these ways if I ever find myself starting another team from scratch. I would very
|
||||
much rather screw up in new ways.
|
||||
</p>
|
||||
<hr>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta viewport="width=device-width, initial-scale=1" />
|
||||
<link rel="stylesheet" href="../styles.css" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>Hi, Pablo here</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr />
|
||||
<section>
|
||||
<h2>Is your drug dealer a homophobic socialist?</h2>
|
||||
<p>
|
||||
Lately, I've noticed a branch of
|
||||
<a href="https://en.wikipedia.org/wiki/Cancel_culture" target="_blank" rel="noopener noreferrer">cancel
|
||||
culture</a>
|
||||
I've come to find quite disturbing. I think it has mainly extended in
|
||||
the US, though I think it's starting to happen in Europe too. It's
|
||||
this tendency for people at companies to politically and morally judge
|
||||
business counterparties and come to the conclusion that business
|
||||
shouldn't be done with them because of it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
I experienced this first hand during some afterwork beers, and for
|
||||
some reason the scene got burned into my retina. A colleague of mine,
|
||||
beer in hand, said something like, “We're working with this customer,
|
||||
and they're unbearable because they complain a lot and challenge us
|
||||
all the time when we run the monthly reconciliation. Plus, they're
|
||||
from Israel.” I was mindblown at how casually that was dropped, with
|
||||
not even a footnote-like explanation deemed necessary. I played my 5
|
||||
year old child attitude card and asked, "What's the problem with them
|
||||
being in Israel?" She said, "Well, you know, they're in Israel and the
|
||||
whole thing is happening. It's terrible. We shouldn't deal with them."
|
||||
</p>
|
||||
|
||||
<p>
|
||||
I couldn't hold it in: I asked her if her hairdresser was from Israel.
|
||||
She looked at me completely puzzled: “I don't know. Why does that
|
||||
matter?” I told her, “I don't know. Apparently, you're upset about
|
||||
dealing people from Israel, so I'm assuming you need to check if
|
||||
everyone you do business with is from there to not do it if that's the
|
||||
case.” Silent stood and the air got thick. Someone jumped in with a
|
||||
nervous joke to break up the tension that my child like questions had
|
||||
somehow brought to the room, and the conversation moved on.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Ever since that day, I've come across this kind of
|
||||
social-justice-business-censor thinking pop up a lot. Since that fun
|
||||
first encounter, whenever someone points out at how business should
|
||||
not be done with <whatever ideology/country/demographic they don't
|
||||
like>, I started jokingly triggering them by asking, “Actually, are
|
||||
you making sure your drug dealer a homophobic socialist?” They
|
||||
generally laugh, not grasping how their stances on politically
|
||||
deciding to do or not do business with someone sound as ridicolous to
|
||||
me.
|
||||
</p>
|
||||
|
||||
<img src="../static/homophobic-socialist-drug-dealer.png" alt="" style="width: 50%" />
|
||||
|
||||
<p>
|
||||
Here's what disturbs me: trade is a very civilized act. When we
|
||||
trade—whether it's goods, services, or anything else—we're putting
|
||||
aside our differences and doing something mutually beneficial. We both
|
||||
walk away better off. We hurt no one. We make things a tiny bit better
|
||||
overall. Deciding not to trade with someone because of some political
|
||||
detail which is completely irrelevant to the trade itself is
|
||||
backwards. Even if I didn't like communists, I wouldn't care if a
|
||||
communist is selling me bananas. It just doesn't matter.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Seeing people blow up trade over politics makes me sad. I think it's
|
||||
ignorant and hateful. And I don't think they realize where that kind
|
||||
of thinking can lead.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the end, I just hope people can leave politics out of business.
|
||||
Let's do business and all be better off thanks to it.
|
||||
</p>
|
||||
<hr />
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
</body>
|
||||
|
||||
</html>
|
||||
|
|
@ -0,0 +1,173 @@
|
|||
<!DOCTYPE HTML>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8">
|
||||
<meta viewport="width=device-width, initial-scale=1">
|
||||
<link rel="stylesheet" href="../styles.css">
|
||||
</head>
|
||||
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>
|
||||
Hi, Pablo here
|
||||
</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr>
|
||||
<section>
|
||||
<h2>My tips and tricks when using Postgres as a DWH</h2>
|
||||
<p>In November 2023, I joined Superhog (now called Truvi) to start out the Data team. As part of that, I
|
||||
also drafted and deployed the first version of its data platform.
|
||||
</p>
|
||||
<p>The context led me to choose Postgres for our DWH. In a time of Snowflakes, Bigqueries and Redshifts,
|
||||
this might surprise some. But I can confidently say Postgres has done a great job for us, and I can even
|
||||
dare to say it has provided a better experience than other, more trendy alternatives could have. I'll
|
||||
jot down my rationale for picking Postgres one of these days.</p>
|
||||
<p>
|
||||
Back to the topic: Postgres is not intended to act as a DWH, so using it as such might feel a bit hacky
|
||||
at times. There are multiple ways to make your life better with it, as well as related tools and
|
||||
practices that you might enjoy, which I'll try to list here.
|
||||
</p>
|
||||
<h3>Use <code>unlogged</code> tables</h3>
|
||||
<p>The <a href="https://www.postgresql.org/docs/current/wal-intro.html" target="_blank"
|
||||
rel="noopener noreferrer">Write Ahead Log</a> comes active by default for the tables you create, and
|
||||
for good reasons. But in the context of an ELT DWH, it is probably a good idea to deactivate it by
|
||||
making your tables <code>unlogged</code>. <a
|
||||
href="https://www.crunchydata.com/blog/postgresl-unlogged-tables" target="_blank">Unlogged
|
||||
tables</a> will provide you with much faster writes (roughly, twice as fast) which will make data
|
||||
loading and transformation jobs inside your DWH much faster.
|
||||
</p>
|
||||
<p>You pay a price for this with a few trade offs, the most notable being that if your Postgres server
|
||||
crashes, <a href="https://www.postgresql.org/docs/current/sql-createtable.html#SQL-CREATETABLE-UNLOGGED"
|
||||
target="_blank" rel="noopener noreferrer">the contents of the unlogged tables will be lost</a>. But,
|
||||
again, if you have an ELT DWH, you can survive by running a backfill. In Truvi, we made the decision to
|
||||
have the landing area for our DWH be logged, and everything else unlogged. This means if we experienced
|
||||
a crash (which still hasn't happened, btw), we would recover by running a full-refresh dbt run.</p>
|
||||
<p>If you are using dbt, you can easily apply this by adding this bit in your <code>dbt_project.yml</code>
|
||||
:</p>
|
||||
<pre><code>
|
||||
models:
|
||||
+unlogged: true
|
||||
</code></pre>
|
||||
|
||||
<h3>Tuning your server's parameters</h3>
|
||||
<p><a href="https://www.postgresql.org/docs/current/runtime-config.html" target="_blank"
|
||||
rel="noopener noreferrer">Postgres has many parameters you can fiddle with</a>, with plenty of
|
||||
chances to either improve or destroy your server's performance.</p>
|
||||
<p>Postgres ships with some default values for it, which are almost surely not the optimal ones for
|
||||
your needs, <em>specially</em> if you are going to use it as a DWH. Simple changes like adjusting the
|
||||
<code>work_mem</code> will do wonders to speed up some of your heavier queries.
|
||||
</p>
|
||||
<p>There are many parameters to get familiar with and proper adjustment must be done taking your specific
|
||||
context and needs into account. If you have no clue at all, <a href="https://pgtune.leopard.in.ua"
|
||||
target="_blank" rel="noopener noreferrer">this little web app</a> can give you some suggestions you
|
||||
canstart from.
|
||||
</p>
|
||||
<h3>Running <code>VACUUM ANALYZE</code> right after building your tables</h3>
|
||||
<p>Out of the box, Postgres will automatically run
|
||||
<code><a href="https://www.postgresql.org/docs/current/sql-vacuum.html" target="_blank" rel="noopener noreferrer">VACUUM</a></code>
|
||||
and
|
||||
<code><a href="https://www.postgresql.org/docs/current/sql-analyze.html" target="_blank" rel="noopener noreferrer">ANALYZE</a></code>
|
||||
jobs <a href="https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM" target="_blank"
|
||||
rel="noopener noreferrer">automatically</a>. The triggers that determine when each of those gets
|
||||
triggered can be adjusted with a few server parameters. If you follow an ELT pattern, most surely
|
||||
re-building your non-staging tables will cause Postgres to run them.
|
||||
</p>
|
||||
<p>But there's a detail that is easy to overlook. Postgres automatic triggers will start those quite fast,
|
||||
but not right after you build each table. This poses a performance issue: if your intermediate sections
|
||||
of the DWH have tables that build upon tables, rebuilding a table and then trying to rebuild a dependant
|
||||
without having an <code>ANALYZE</code> on the first one before might hurt you.</p>
|
||||
<p>Let me describe this with an example, because this one is a bit of a tongue twister: let's assume we have
|
||||
tables <code>int_orders</code> and <code>int_order_kpis</code>. <code>int_orders</code> holds all of our
|
||||
orders, and <code>int_order_kpis</code> derives some kpis from them. Naturally, first you will
|
||||
materialize <code>int_orders</code> from some upstream staging tables, and once that is complete, you
|
||||
will use its contents to build <code>int_order_kpis</code>.
|
||||
</p>
|
||||
<p>
|
||||
Having <code>int_orders</code> <code>ANALYZE</code>-d before you start building
|
||||
<code>int_order_kpis</code> is highly benefitial for your performance in building
|
||||
<code>int_order_kpis</code>. Why? Because having perfectly updated statistics and metadata on
|
||||
<code>int_orders</code> will help Postgres' query optimizer better plan the necessary query to
|
||||
materialize <code>int_order_kpis</code>. This can improve performance by orders of magnitude in some
|
||||
queries by allowing Postgres to pick the right kind of join strategy for the specific data you have, for
|
||||
example.
|
||||
</p>
|
||||
<p>Now, will Postgres auto <code>VACUUM ANALYZE</code> the freshly built <code>int_orders</code> before you
|
||||
start building <code>int_order_kpis</code>? Hard to tell. It depends on how you build your DWH, and how
|
||||
you've tuned your server's parameters. And the most dangerous bit is you're not in full control: it can
|
||||
be that <em>sometimes</em> it happens, and other times it doesn't. Flaky and annoying. Some day I'll
|
||||
write a post on how this behaviour drove me mad for two months because it made a model sometimes built
|
||||
in a few seconds, and other times in >20min.
|
||||
</p>
|
||||
<p>
|
||||
My advice is to make sure you always <code>VACUUM ANALYZE</code> right after building your tables. If
|
||||
you're using dbt, you can easily achieve this by adding this to your project's
|
||||
<code>dbt_project.yml</code>:
|
||||
<pre><code>
|
||||
models:
|
||||
+post-hook:
|
||||
sql: "VACUUM ANALYZE {{ this }}"
|
||||
transaction: false
|
||||
# ^ This makes dbt run a VACUUM ANALYZE on the models after building each.
|
||||
# It's pointless for views, but it doesn't matter because Postgres fails
|
||||
# silently withour raising an unhandled exception.
|
||||
</code></pre>
|
||||
</p>
|
||||
<h3>Monitor queries with <code>pg_stats_statements</code></h3>
|
||||
<p><a href="https://www.postgresql.org/docs/current/pgstatstatements.html" target="_blank"
|
||||
rel="noopener noreferrer">pg_stats_statements</a> is an extension that nowadays ships with Postgres
|
||||
by default. If activated, it will log info on the queries executed in the server which you can check
|
||||
afterward. This includes many details, with how frequently does the query get called and what's the min,
|
||||
max and mean execution time being the ones you probably care about the most. Looking at those allows you
|
||||
to find queries that take long each time they run, and queries that get run a lot.
|
||||
</p>
|
||||
<p>Another important piece of info that gets recorded is <em>who</em> ran the query. This is helpful
|
||||
because, if you use users in a smart way, it can help you isolate expensive queries on different uses
|
||||
cases or areas. For example, if you use different users to build the DWH and to give your BI tool read
|
||||
access (you do that... right?), you can easily tell apart dashboard related queries from internal, DWH
|
||||
transformation ones. Another example could be internal reporting vs embedded analytics in your product:
|
||||
you might have stricter performance SLAs for product-embedded, customer-facing queries than for internal
|
||||
dashboards. Using different users and <code>pg_stats_statements</code> makes it possible for you to
|
||||
dissect performance issues on those separate areas independently.</p>
|
||||
<h3>Dalibo's wonderful execution plan visualizer</h3>
|
||||
<p>Sometimes you'll have some nasty query you just need to sit down with and optimize. In my experience, in
|
||||
a DWH this ends up happening with queries that involve many large tables in sequential joining and
|
||||
aggregation steps (as in, you join a few tables, group to some granularity, join some more, group again,
|
||||
etc).
|
||||
</p>
|
||||
<p>You can get the query's real execution details with <code>EXPLAIN ANALYZE</code>, but the output's
|
||||
readability is on par with morse-encoded regex patterns. I always had headaches dealing with them until
|
||||
I came across <a href="https://dalibo.com/" target="_blank" rel="noopener noreferrer">Dalibo</a>'s <a
|
||||
href="https://explain.dalibo.com/" target="_blank" rel="noopener noreferrer">execution plan
|
||||
visualizer</a>. You can paste the output of <code>EXPLAIN ANALYZE</code> there and see the query
|
||||
execution presented as a diagram. No amount of words will portray accurately how awesome the UX is, so
|
||||
I encourage you to try the tool with some nasty query and see for yourself.</p>
|
||||
<h3>Local dev env + Foreign Data Wrapper</h3>
|
||||
<p>One of the awesome things of using Postgres is how trivial it is to spin up an instance. This makes
|
||||
goofing around much more simpler than whenever setting up a new instance means paperwork, $$$, etc.</p>
|
||||
<p>Data team members at Truvi have a dockerized Postgres running in their laptops that they can use when
|
||||
they are developing on our DWH dbt project. In the early days, you could grab some production dump with
|
||||
some subset of tables from our staging layer and run significant chunks of our dbt DAG in your laptop if
|
||||
you were patient.</p>
|
||||
<p>A few hundreds of models later, this evolved to increasingly difficult and finally became impossible.
|
||||
</p>
|
||||
<p>Luckily, we came across Postgres' <a
|
||||
href="https://www.postgresql.org/docs/current/postgres-fdw.html">Foreign Data Wrapper</a>. There's
|
||||
quite a bit to it, but to keep it short here, just be aware that FDW allows you to make a Postgres
|
||||
server give access to some table in a different Postgres server while pretending they are local. So, you
|
||||
query table X in Postgres server A, even though table X is actually stored in Postgres server B. But
|
||||
your query works just the same as if it was a local genuine table.</p>
|
||||
<p>Setting these up is fairly trivial, and has allowed our dbt project contributors to be able to execute
|
||||
hybrid dbt runs where some data and tables is local to their laptop, whereas some upstream data is being
|
||||
read from production server's. The approach has been great so far, enabling them to actually test models
|
||||
before commiting them to master in a convenient way.</p>
|
||||
<hr>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
|
|
@ -0,0 +1,203 @@
|
|||
<!DOCTYPE HTML>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8">
|
||||
<meta viewport="width=device-width, initial-scale=1">
|
||||
<link rel="stylesheet" href="../styles.css">
|
||||
</head>
|
||||
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>
|
||||
Hi, Pablo here
|
||||
</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr>
|
||||
<section>
|
||||
<h2>Notes for myself during my departure from Superhog</h2>
|
||||
<p>I'm writing this a few days before my last day at Superhog (now called Truvi). Having a few company
|
||||
departures under my belt already, I know a bit on what will come next. I know one part of the drill is
|
||||
that 99% of the details of what happened during my tenure at the company will completely disappear from
|
||||
my memory for the most part, only triggered by eerily coincidental cues here and there every few years.
|
||||
I will remember clearly a few crucial, exciting days and situations. I will also hold well the names and
|
||||
faces of those with who I worked closely, as well as my personal impression and judgement of them. I
|
||||
will remember the office, and some details of how my daily life was when I went there.</p>
|
||||
<p>But most other things will be gone from my brain, surprisingly fast.</p>
|
||||
<p>Knowing that experience is a great teacher, and regretting not doing this in the past, I've decided to
|
||||
collect a few notes from my time at Superhog, hoping they will serve me in making the lessons I've
|
||||
learnt here stick properly.</p>
|
||||
<ul>
|
||||
<li>Growing really fast an organization without an incredibly solid vision you're going to stick to is
|
||||
terrible. Time, money and effort will be wasted left and right, and unless you have some magic tric
|
||||
up your sleeve, you'll run out of money and panic. Growth is about having a great vision, going for
|
||||
it and hoping for the best, not about collecting resources and hoping that they will somehow align
|
||||
themselves towards making money.</li>
|
||||
<li>
|
||||
If you're in the leadership of a company, you make decisions, and then things go badly because of
|
||||
them, people are going to think you've fucked up and won't be happy about it. Should you publicly
|
||||
retrospect in an intelligent way and clearly show you've learnt the lesson, you have a chance at
|
||||
some degree of redemption, and you might even make some of the employees hopeful again that there's
|
||||
still a second chance to go for success. If you don't retrospect at all and pretend the mishaps have
|
||||
nothing to do with your management, they won't just think you're incompentent: they simply won't
|
||||
take you seriously anymore, and won't be honest to you because smart people don't invest calories in
|
||||
arguing with people who they consider idiots.
|
||||
</li>
|
||||
<li>
|
||||
If you're in a B2B business where customers will have a long-term relationship with you, and you
|
||||
have sales people, giving them incentives that are all about getting people onboard, and not about
|
||||
long term performance, might be an expensive mistake. I've observed sales people who only care about
|
||||
scoring deals engage in undesirable behaviours such as:
|
||||
<ul>
|
||||
<li>Sell to anyone, regardless of whether there's a good fit between your offering and the
|
||||
customer needs.</li>
|
||||
<li>Cut corners, surely do and say things that are in moral gray areas. If you're unlucky, even
|
||||
clearly cross moral red lines.</li>
|
||||
<li>
|
||||
Drive the people who build and deliver your offering crazy. Since they have no incentive to
|
||||
care about what happens after a deal is signed, they don't care if their actions in the
|
||||
sales pipeline turn into landmines during the long-term business relationship and execution
|
||||
of the service.
|
||||
</li>
|
||||
</ul>
|
||||
I think many of these issues get solved by structuring compensation so that sales people do well
|
||||
once the leads they convert have been doing well for some time, however you want to measure that.
|
||||
Not only nasty behaviour can be avoided, but even new, good and constructive actions might arise.
|
||||
For example, your sales people will care more about building a great product, and so they'll
|
||||
regularly feedback to engineers and operations and care deeply about collaborating in improving
|
||||
things.
|
||||
</li>
|
||||
<li>
|
||||
If you're lucky to find talented employees, go crazy about retaining them.
|
||||
</li>
|
||||
<li>
|
||||
The unexpected death of collegues can be a great blow to the business.
|
||||
</li>
|
||||
<li>Non-technical founders need CTOs with strong characters nearby to protect them from themselves.
|
||||
Soft-hearted CTOs with a pleasing attitude and aversion to conflict will feel sweet at first, but
|
||||
their lack of fightning back on certain topics will lead to sour consequences down the line.</li>
|
||||
<li>During my tenure, my team and I managed to deliver astonishing amounts of value with extremely
|
||||
simple tooling that was just enough for what we needed. This had many advantages and was a silent
|
||||
win. It's not sexy, but I think it should be.</li>
|
||||
<li>If you are silently efficient budget wise, as in you manage to achieve something consuming way less
|
||||
money than whatever is average for your context, but you don't explain it are notably noisy about
|
||||
it, nobody will give a damn. Even worse, your levels of efficiency may be taken for granted and you
|
||||
might encounter trouble when asking for more bucks, even if you're still way below average.</li>
|
||||
<li>When there's a feeling that a ship is going down, I've observed there's a direct correlation between
|
||||
how talented an employee is and the chances he departs early. The less gifted will stay until the
|
||||
end.</li>
|
||||
<li>
|
||||
If you're a SaaS and want to scale, don't leave your Finance team orphan of IT resources. Invoicing,
|
||||
gathering customer payment details, the most frequent accounting journals, etc. should be treated as
|
||||
first class requirements of your architecture, not as an afterthought. Your finance team needs to
|
||||
grow in engineers, not accountants. And if you have the feeling that the number of accountants is
|
||||
growing linearly with the volume of the business, you are in serious trouble and need to do
|
||||
something. Failing to do this will lead to some very nasty tech debt that will kill your speed and
|
||||
potentially make you lose a lot of money.
|
||||
</li>
|
||||
<li>If you've had employees rotating through various departments in your org, doing very different jobs,
|
||||
their views and opinions are worth solid gold and should be valued as such.</li>
|
||||
<li>Right befores starting in this company, I had just read the book It doesn't have to be crazy at work
|
||||
by Jason Fried and DHH. At that time I thought I believed by then that it's worth creating a calm
|
||||
environment to think clearly, since doing the right thing is way more important than executing fast,
|
||||
and fast paced environments are not great to keep your head clear. After my time here, I'm a x100
|
||||
times more of a believer.</li>
|
||||
<li>Giving people in the business some basics on SQL is really useful, but that usefulness gets
|
||||
multiplied by the tidyness and documentation of your DWH. If they need to call you up every time
|
||||
because there's no way they can find and understand what they need in the DWH, teaching them SQL is
|
||||
pointless and only leads to frustration.</li>
|
||||
<li>
|
||||
If you were part of the decision to hire someone, and then they decide to leave, you should talk
|
||||
with them. Even if you're not working together every day anymore and the org has changed quite a
|
||||
bit. You had a stake in this person's entrance, they remember it vividly, and not calling them to
|
||||
grab a coffee and say bye properly will disappoint them.
|
||||
</li>
|
||||
<li>If a manager gets fired and you get their direct reports now reporting to you, and you know they had
|
||||
strong respect for him, make sure to recognize that feeling the first thing. Saying something along
|
||||
the lines of "Guys, I know you respected X and were fond of working with him, and that you might not
|
||||
be happy with his departure and having to report to me instead. I understand that and think it's
|
||||
natural", will go a long way in helping with the grieving and making them feel more comfortable.
|
||||
</li>
|
||||
<li>
|
||||
Engineering leadership is quite a bit like parenting when it comes to mirroring. Regardless of what
|
||||
you say should be done, people will ignore that a lot and tend to do what you do. If senior
|
||||
engineers do patchy shit on the database, don't document a thing, cut corners instead of building
|
||||
properly, mindlessly submit to absurd requests instead of collaborating productively with their
|
||||
non-tech colleagues, etc, the rest of engineers will do it as well, regardless on how many training
|
||||
sessions on best practices you run. Conversely, if you focus on quality, give time and room to do
|
||||
things right, reward ingenious solutions to problems, treat incidents in professional and serious
|
||||
ways, push back from stupid managerial situations to work things out in a way that is good
|
||||
for everyone, document your work properly, etc. you will soon find the rest of your colleagues
|
||||
(specially, the most junior ones) following your lead, often times without you even needing to
|
||||
insist on good practices.
|
||||
</li>
|
||||
<li>People care little about having an office on the beachfront.</li>
|
||||
<li>If you manage to raise a team to have team-ownership mentality (as in, they know what's their high
|
||||
level goal and will always strive for it, even if you don't provide strict guidance or are not
|
||||
around at all), you might get an ego hit because it suddenly feels like you are not needed. Rest
|
||||
assured, even if you're not immediately needed, your team values you, and other managers and
|
||||
executives will notice the work you've done with the team, even if they don't voice it.
|
||||
Unfortunately, it's likely that the appreciation for your achievement only becomes visible when you
|
||||
decide to leave and people panic.</li>
|
||||
<li>People with cowardly and anxious characters might seem harmless. But don't undersestimate their
|
||||
ability to allow terrible things to happen precisely because stepping up and acting would require
|
||||
courage and they have none. Basically the way <a href="https://www.youtube.com/watch?v=uW9Q1cm_Tnw"
|
||||
target="_blank" rel="noopener noreferrer">Upham gets Mellish killed in Saving Private Ryan</a>.
|
||||
The attrocities that can be tolerated or even supported by cowards in this manner can be terrible,
|
||||
and even more depressing that the loud acts of bold, evil men. Plus, if there are many cowards
|
||||
clustered together, group thinking will give them comfort and normalize the behaviour in the fashion
|
||||
of the bystander effect.
|
||||
</li>
|
||||
<li>
|
||||
Only badmouth a colleague in front of others if you are going to eventually raise the issue to
|
||||
either him or his superiors. Don't ever pointlessly complain with third parties if you will never
|
||||
act on the issue. Specially with your direct reports. It generates a nasty victim culture, and once
|
||||
you get it started, it's hard to stop.
|
||||
</li>
|
||||
<li>
|
||||
I have found that the lack of easy access to data and skills like SQL and data analysis are orders
|
||||
of magnitude less of an issue to organizational data literacy compared to managers who don't expect
|
||||
a data-driven approach from their reports. People start caring about data when their boss demands
|
||||
they do their work using data. People continue ignoring data when their boss tolerates the lack of
|
||||
data. And when observing this, it's vital to also keep in mind that reports adjust their behaviour
|
||||
to what their manager actually rewards/punishes, not what their manager <em>says</em> he will
|
||||
reward/punish.
|
||||
</li>
|
||||
<li>Joel Spolsky wrote <a
|
||||
href="https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/">this thing
|
||||
you should never do</a>. The company decided to do it anyway. We fucked up and we paid for the
|
||||
consequences exactly as Spolsky lays out.</li>
|
||||
<li>Employees with little retrospective capacity are dangerous. Partly related to the previous point.
|
||||
This quote from Spolsky hits right on the nail: <em>It's important to remember that when you start
|
||||
from scratch there is absolutely no reason to believe that you are going to do a better job than
|
||||
you did the first time. First of all, you probably don't even have the same programming team
|
||||
that worked on version one, so you don't actually have “more experience”. You're just going to
|
||||
make most of the old mistakes again, and introduce some new problems that weren't in the
|
||||
original version.</em> I would only nuance that if you can retrospect deeply and learn from the
|
||||
mistakes you made on the first run, perhaps there's some hope you may do a better job starting from
|
||||
scratch. But I guess if you manage to retrospect and learn properly, you could also do a better job
|
||||
working yourself out incrementally from the fucked up situation you failed yourself into.</li>
|
||||
<li>If you set up a variable/bonus scheme, refrain from changing the structure frequently, even if you
|
||||
are not really making it more stingy. Too much shuffling on that area will get employees thinking
|
||||
you're playing games on them, even if it's not the case.</li>
|
||||
<li>When an engineer who designed, deployed, and since then operated a non-trivial production system is
|
||||
about to leave, ask him to finish his handover and lock himself out days before his actual last
|
||||
working day. Challenge him to a nice treat by making it clear that, once he's locked out, he doesn't
|
||||
have any other duties other than help his colleagues should something not work after his departure.
|
||||
This way, you provide him with an incentive to handover as perfect and fast as possible (paid
|
||||
holidays), and you make sure that you get a chance to try to operate the system without him
|
||||
<em>before</em> he leaves. Not doing this, and instead simply waiting for his last day to remove his
|
||||
creds and users from the infra, is dangerous.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
<hr>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
78
public/writings/the-roi-of-toilets.html
Normal file
78
public/writings/the-roi-of-toilets.html
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
<!DOCTYPE HTML>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8">
|
||||
<meta viewport="width=device-width, initial-scale=1">
|
||||
<link rel="stylesheet" href="../styles.css">
|
||||
</head>
|
||||
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>
|
||||
Hi, Pablo here
|
||||
</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr>
|
||||
<section>
|
||||
<h2>The ROI of toilets</h2>
|
||||
<p>Years ago I worked under the organizational umbrella of this COO. He was my boss' boss. Sometimes we
|
||||
bumped into each other for big meetings and presentations.</p>
|
||||
<p>The COO had a background in finance and audit, which gave him certain management quirks that coupled in
|
||||
rather funny ways with the nature of our data and analytics departments. There was this specific one
|
||||
that was always itchy to me. At the time I was still a very junior and inexperienced professional, and
|
||||
my default stance on things was to humble out, shut the fuck up and listen. But I always had my opinions
|
||||
locked in my brain, and in cases like this one, I couldn't hold them back.</p>
|
||||
<p>
|
||||
The quirk this gentleman had was to try to measure the ROI of every little thing. He would ask for the
|
||||
ROI of projects, the ROI of developments, the ROI of acquiring licenses, the ROI of going out for a
|
||||
smoke. It was an understandable quirk for a financier who had never actually built or serviced anything,
|
||||
but rather always looked, judged and measured from the outside. He wasn't that interested in the things
|
||||
themselves, but rather in measuring them in units that would fit in his Excel sheets.
|
||||
</p>
|
||||
<p>
|
||||
I generally thought (and still think) that assessing ROI is a good thing to aim for. But intuitively, I
|
||||
found his obsession with it misplaced and counterproductive. I now have much better words to critique
|
||||
and argue against his stance, but at the time I lacked those and only had a gut feeling of "this is
|
||||
stupid".
|
||||
</p>
|
||||
<p>
|
||||
One day we were in one of those meetings where he would start asking about the ROI of something while I
|
||||
thought to myself: "We just need this thing and it's obviously more valuable that the money it will
|
||||
cost, why are we having this conversation uuuugh". As I spiritually (not physically) rolled my eyes, I
|
||||
couldn't hold it in anymore and just shot: "What's the ROI of the office toilets?"
|
||||
</p>
|
||||
<p>
|
||||
The COO and my boss suddenly stared at me, mouths open, eyebrows pressed down as they squinted their
|
||||
eyes: "What?"
|
||||
</p>
|
||||
<p>
|
||||
"We have toilets. We have to pay for them. We could use them for desk space, but instead we put toilets.
|
||||
Then we have to do plumbing and stuff. We need to pay people to clean them. it's a nuisance. How can we
|
||||
know that they are the best use of shareholder funds? Who has measured the ROI of those toilets?". It
|
||||
all came out naturally out of the blue. I had a great relationship with these people, but I still was
|
||||
clenching my but, wondering if I had gone a bit too hard. Oh how nice it is to be young.
|
||||
</p>
|
||||
<p>
|
||||
They chuckled and got my point. The COO stopped insisting on specific figures for the cost
|
||||
element we had at hand, although he didn't surrender a good old "write a business case for this so we
|
||||
can refer to it later", which probably was a wise thing to do.
|
||||
</p>
|
||||
<p>
|
||||
I've faced similar situations a few times since then, and I've found myself in many others where it was
|
||||
up to me if and how precisely should the ROI of something be measured. I now have a much clear mental
|
||||
model and opinion of when it should and shouldn't be done. But that's for another day.
|
||||
</p>
|
||||
<p>
|
||||
Nobody ever told me what was the ROI of the toilets, though. Perhaps we should remove them?
|
||||
</p>
|
||||
<hr>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
<!DOCTYPE HTML>
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Pablo here</title>
|
||||
<meta charset="utf-8">
|
||||
<meta viewport="width=device-width, initial-scale=1">
|
||||
<link rel="stylesheet" href="../styles.css">
|
||||
</head>
|
||||
|
||||
|
||||
<body>
|
||||
<main>
|
||||
<h1>
|
||||
Hi, Pablo here
|
||||
</h1>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
<hr>
|
||||
<section>
|
||||
<h2>Your customers don't care that your bathroom is dirty</h2>
|
||||
<p>The other night I went out with the missus and we went to a fancy pants restaurants, which is unusual for
|
||||
us. We prefer neighbourhood, simple places.</p>
|
||||
<p>
|
||||
During the dinner, she went to the bathroom and came back horrified: "God, their bathroom is fucking
|
||||
disgusting". "Much worse than the usual one?", I asked. And she said: "No, but I would expect an upscale
|
||||
place like this to have it squeaky clean".
|
||||
</p>
|
||||
<p>
|
||||
I then laid down my thesis on why all restaurant bathrooms, even in really posh places, are always
|
||||
terrible: "They don't care because you don't really care". "I do care!", she hit me back. "No, you
|
||||
don't. You think you do: you obviously don't like it, and you would love to see it clean instead of all
|
||||
filthy. But the truth is, when next month you're thinking about where to go out for dinner, you'll judge
|
||||
this place and remember the meal, the waiters, how you felt. But not the bathroom. What was the last
|
||||
time you discarded a restaurant because the bathroom was gross". At this point she agreed, and quickly
|
||||
drew her attention to the desserts menu. Sometimes I invest too much energy and talk in things people
|
||||
find boring.
|
||||
</p>
|
||||
<h2>The bathrooms of products</h2>
|
||||
<p>
|
||||
There are a couple of things we can learn here.
|
||||
</p>
|
||||
<p>
|
||||
Your product surely has <em>bathrooms</em>. Those little corners that are not the main course, and
|
||||
your customers don't care about much. You need them. Not having them would be problematic. I don't fuss
|
||||
over a dirty bathroom in a restaurant, but I'm pretty confident I would remember a restaurant not having
|
||||
a bathroom at all if it was responsible for some desperate run-for-it trip in search of a place to drop
|
||||
my bombs.
|
||||
</p>
|
||||
<p>
|
||||
Your product's bathrooms are those secondary features your customers kind of need, but don't care much
|
||||
about. It's that export to CSV button. Your customer John needs it to push the data into his accounting
|
||||
books. The formats of the date columns are weird, and the columns names are confusing, and the fact that
|
||||
you send a link to his email to download it instead of just triggering a download in his browser the
|
||||
moment he hits the button, make it all quite cumbersome. But, all in all, it's minor pain. The moment he
|
||||
uploads it into the accounting software, he forgets about it.
|
||||
</p>
|
||||
<p>
|
||||
I think it's important to be aware of what those are in your product, so you can prioritise accordingly
|
||||
and avoid some feature-prioritisation bike shedding. Theoretically, it should be obvious, because you
|
||||
know what's important (right? Right?!?), and whatever is not important, is probably not important. But
|
||||
then somehow I still see mistakes made around this type of feature.
|
||||
</p>
|
||||
<p>
|
||||
I recently had a conversation with my company's CTO about a situation like this. I had some frustration
|
||||
to vent. We had invested so much time and effort in improving the UI of one of our applications. And it
|
||||
was so pointless. "There's a good chunk of our customer base that pretty much never go into this UI", I
|
||||
told him. "They only contact us through a form when they need the service they hired. I don't think they
|
||||
care about this, and I don't think the nicer UI is going to bring any value to them, nor any money to
|
||||
us".
|
||||
</p>
|
||||
<p>
|
||||
That UI has to be there. It's where they check some settings. Reset their password. The boring stuff.
|
||||
But having achieved being functional, there isn't much more value to provide in improving it.
|
||||
</p>
|
||||
<p>
|
||||
I think it's important to identify which are your bathrooms and make sure you act accordingly. I find
|
||||
it's not enough to only care about making the important stuff top priority: it helps to also make it
|
||||
clear what's not important, and be explicit about it being low priority. Just like when I define the
|
||||
scope for something, I like to both think in terms of what are we including, and also making a explicit
|
||||
list of what we are NOT including for the sake of clarity. Theoretically, just listing the positive list
|
||||
should be enough. In reality, my experience tells me making the negative helps a lot.
|
||||
</p>
|
||||
<p>
|
||||
So, what are your bathrooms? Are you cleaning them with a toothbrush? Or you have them nice and dirty?
|
||||
</p>
|
||||
<hr>
|
||||
<p><a href="../index.html">back to home</a></p>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
Loading…
Add table
Add a link
Reference in a new issue