The quality of a solution is directly proportional to the ability to gauge its impact.
A monitoring plan, a measurement, are our doormen against “this feels faster”, “why wouldn’t this improve performance?”, and the artist’s “Perfect”.
They ensure that only genuine improvements enter our establishent.
Done well, they are trusty laborers that will stay with you for the duration of your project.
Afterwards you can shake their hand, introduce them to your boss, employ them again.
Done poorly, and they will rob you blind.
__In Python 2.
7:>>> "2" > 3>>> TrueFor months, this bug existed in a script of mine which delivered metrics to my employer, who in turn made decisions from it.
If the typical repository is impressionist, this script was a Jackson Pollock special — I had no tests.
Just as Dillard likens the writer to a building inspector that taps the walls looking for instabilities, for programmers, these are our tests, coming to our property upon every addition.
If you ask them to look at the right things, your code will stably mature over time.
Test the right things, and they will guide you to make good decisions.
This is a skill in itself.
Test the wrong things however, and it is no different from an actual house collapsing — at least the chimney survived.
—I had three great mentors during my first job in tech.
The first was one of the great programmer types I mentioned above.
He listened to my assumptions, dove into rabbit holes I made and resurfaced, later asking questions from 1000 feet high.
Cutting questions I didn’t understand the purpose of, like a chess player planning many turns ahead.
Why is he still up there when I’m on the ground?His questions showed that even though I was discussing nitty-gritty code — “Look at this one particular case…”, “but what about this case…”, he never lost sight of the larger issue.
He aimed to understand the problem and solve it the right way, the cardinal virtue.
When convinced we had the right approach, and only then, did he led the expedition to execute.
He was good at identifying false premises.
He was a great companion when starting this career path.
Patient, curious, a data steward, proponent of succinct documentation — he taught me a ton about problem solving.
This experience is not guaranteed; no one is obligated to teach anything.
When you find someone who does, thank them.
The second was ex-military, intimidating, and operated higher in the company.
He knew when to wield his intimidation to get results and when to coach a peer.
He could identify metrics executives cared about, delegate work to build them, use them to give actionable advice.
His management style was his best asset.
He understood the value of relationships, empowered me to own my work, and trusted I would focus on things that mattered.
He cared for his direct reports, followed up when I expressed impostor syndrome, asked about my personal life.
Sometimes we got beers, discussed personal and career goals, marriage, thoughts I had of enlisting at the time.
I cannot express in words how impactful his management was to my development.
When it came to solving immediate problems, he was a freight train barreling through obstacles.
His eyes were commonly bloodshot from lack of sleep.
When one team couldn’t deliver something he needed, he worked around it.
The company used him as a Fixer, moving him from department to department as they grew.
Together they were an arsenal that sliced through any problems they faced.
I worked with them for almost 2 years and then transitioned teams.
The third I only worked with for 3 months.
He was extremely soft-spoken, had long black hair past his shoulders, and always wore a hood indoors under a leather jacket.
He is self-taught, claimed to know like 7 programming languages .
I learned more about the art of programming, common problems, coding mindsets in those 3 months than I did from all other members of my new team combined.
Once, I had to parameterize model declaration in SQLAlchemy.
Our team had dozens of databases, all with the same schema.
The company was moving towards multi-tenancy, and we needed the ability to easily declare tables for new databases.
The thinking was — new tenant, new database, trigger Python script, database contains all tables.
From what I’ve seen, ORMs are designed with one database in mind.
You instantiate your engine in the outermost scope, and all models inherit from the engine.
Like so:engine = create_engine(db_uri)base = declarative_base(bind=engine) class TableA(base): __tablename__ = "tablea"etc (200+ lines)…Since the base variable is what needed to be parameterized, we declared these models in a function.
This function took the DB URI as an argument, instantiated the engine, then declared the models.
I don’t think I had ever declared classes inside functions before this.
def declare_models(db_uri): engine = create_engine(db_uri) base = declarative_base(bind=engine) class TableA(base): __tablename__ = “tablea" etc (200+ lines)… return baseWe had dozens of tables, so this function spanned more than 200 lines of code, therefore I didn’t think it was the right solution.
He explained why this use-case was uncommon : ORM’s are used with an application in mind, typically with 1 database.
He would say, “You’ve got to hold on to uncertainty a little longer,” when experimenting with code I didn’t understand, a mantra I still repeat to myself today.
Edison said it differently, “Many of life’s failures are people who did not realize how close they were to success when they gave up.
”Because of him, I feel free to explore when looking for solutions, even if I can’t envision the outcome.
He challenged me to wander when coding and to make bold design decisions.
In part, he was the reason I did not balk at running rmate and remote desktop when experimenting with GCP.
Because of my experiences with him, I am a better and braver programmer.
These experiences are fertilizer, but they are not promised.
Learn to work and blossom without them, like a plant in the wild.
If you are so privileged to be tended to, you will grow much taller than on your own.
—The best ways to learn anything are to do it for no reason and to do it wrong.
Artists are good at this.
Throw paint on the canvas, consider it, then throw more paint on.
Of course you don’t know what you’re doing.
This is ingrained in the process.
No one questions it.
For some reason, this is not so with programming — bad design decisions are excoriated, “Why don’t you just do _”, forks are discouraged.
No time is made for exploration — you have the better answer or you don’t.
I reject these ideas.
They have done nothing for me.
I learned the strengths of Python’s logging library because I tried to implement my own.
I know the rmate plugin because of a false premise.
I learned how to test because I got burned.
I can distribute Python packages because I spent hours failing to.
This is how I learned.
“Who will teach me to write?” Dillard asks, “The page, the page, … that page will teach you to write.
”.