33 stories
·
2 followers

Monday, October 16 - decades

2 Shares

Monday, October 16

decades

Paul Ford wrote about starting ftrain 20 years ago:

I started this website 20 years ago, give or take a week. The original address was www.interactive.net/~ford. Eventually it migrated here into the form you see. I took it very seriously for many years and it earned me thousands of readers, thousands of emails, and tons of opportunity. It was better at generating opportunity than money. I drifted away for all the regular reasons.

Which got me thinking: The oldest surviving bits of this website go back to April of 1997, so it's 20 years, give or take six months. It lived other places for a while (GeoCities and a shell box with a tilde in the URL) until I actually got a domain for it. p1k3.com was the first domain I ever bought, and I chose it because my middle name is Pike and I like the number 13 and it was four characters long, which even in the early years of this century was getting to be kind of hard to come up with. There was also this running joke with friends from IRC, about whether a pike was a weapon or a fish, and I guess that must have played into my thinking somehow.

p1k3 has clearly not made me into a low-key internet celebrity. I don't know about opportunity, but it has helped me get a couple of good jobs, and probably prevented me from getting several more bad ones. To guess at its current readership, I think that about a dozen humans might see this post sooner or later.

I wrote one possible variation on the post you're reading now back in February — the one where I regret writing so much stupid bullshit. That one doesn't really explain why I've written so much less this year than most, though. This other one where I worry about self-surveillance in an age of weaponized data and network fascists comes a lot closer to the mark.

In 2017, I've fully given up on some things. A big one is the World Wide Web. The "open web", as such, is dead. Or at best on life support. The actually existing web is, mostly, bad. It's an abject failure in the terms I thought I was involved with it on, and its architecture has helped bootstrap an internet that's hostile to my values, if not ultimately to human life itself.

It's no longer possible to use the web in a way that respects your privacy, autonomy, basic personhood, etc. And for the same reasons, it's incredibly difficult to work on the web for a living in any kind of ethical fashion.

But then: So what?

I think it's broadly true that most of us should treat the network as a hostile environment, and that any information we publish about ourselves will be used against us and our communities by systems we have no control over — systems operating under few legal constraints, answering only to the profit motive, under the authority of complete assholes with no sense of responsibility, proportion, or historical perspective.

It's really tempting, in the face of this conviction, to shut up and just focus on sequestering myself from the network to whatever limited extent that's still possible.

On the other hand. Writing is one of the only real powers I've ever had, and the surface of this terrible website is still mine to write on. The web is dead to me, as a hope or a cause, and the world it's made — the world that so many thousands of us helped to make — is in bad shape and getting worse. But why should I give up my only real canvas, the only place where I have any voice at all?

Possibly (almost certainly) having a voice is itself an illusion, irrelevant to the course of things now. But I guess it's something.

Read the whole story
thcipriani
18 days ago
reply
brennen
19 days ago
reply
Boulder, CO
Share this story
Delete

Digital Resource Lifespan

1 Comment and 4 Shares
I spent a long time thinking about how to design a system for long-term organization and storage of subject-specific informational resources without needing ongoing work from the experts who created them, only to realized I'd just reinvented libraries.
Read the whole story
thcipriani
18 days ago
reply
Share this story
Delete
1 public comment
tante
19 days ago
reply
Digital Resource Lifespan
Oldenburg/Germany

@20

1 Comment
Not any kind of eulogy, thanks. And no header image, either.
Read the whole story
thcipriani
31 days ago
reply
"With every flap of their terrible fins they squash another good idea in the interest of consolidating pablum into a single database, the better to jam it down our mental baby duck feeding tubes in order to make even more of the cognitive paté that Silicon Valley is at pains to proclaim a delicacy."

Huh.
Share this story
Delete

Software Is About Storytelling

1 Share

Software engineering is more a practice in archeology than it is in building. As an industry, we undervalue storytelling and focus too much on artifacts and tools and deliverables. How many times have you been left scratching your head while looking at a piece of code, system, or process? It’s the story, the legacy left behind by that artifact, that is just as important—if not more—than the artifact itself.

And I don’t mean what’s in the version control history—that’s often useless. I mean the real, human story behind something. Artifacts, whether that’s code or tools or something else entirely, are not just snapshots in time. They’re the result of a series of decisions, discussions, mistakes, corrections, problems, constraints, and so on.  They’re the product of the engineering process, but the problem is they usually don’t capture that process in its entirety. They rarely capture it at all. They commonly end up being nothing but a snapshot in time.

It’s often the sign of an inexperienced engineer when someone looks at something and says, “this is stupid” or “why are they using X instead of Y?” They’re ignoring the context, the fact that circumstances may have been different. There is a story that led up to that point, a reason for why things are the way they are. If you’re lucky, the people involved are still around. Unfortunately, this is not typically the case. And so it’s not necessarily the poor engineer’s fault for wondering these things. Their predecessors haven’t done enough to make that story discoverable and share that context.

I worked at a company that built a homegrown container PaaS on ECS. Doing that today would be insane with the plethora of container solutions available now. “Why aren’t you using Kubernetes?” Well, four years ago when we started, Kubernetes didn’t exist. Even Docker was just in its infancy. And it’s not exactly a flick of a switch to move multiple production environments to a new container runtime, not to mention the politicking with leadership to convince them it’s worth it to not ship any new code for the next quarter as we rearchitect our entire platform. Oh, and now the people behind the original solution are no longer with the company. Good luck! And this is on the timescale of about five years. That’s maybe like one generation of engineers at the company at most—nothing compared to the decades or more software usually lives (an interesting observation is that timescale, I think, is proportional to the size of an organization). Don’t underestimate momentum, but also don’t underestimate changing circumstances, even on a small time horizon.

The point is, stop looking at technology in a vacuum. There are many facets to consider. Likewise, decisions are not made in a vacuum. Part of this is just being an empathetic engineer. The corollary to this is you don’t need to adopt every bleeding-edge tech that comes out to be successful, but the bigger point is software is about storytelling. The question you should be asking is how does your organization tell those stories? Are you deliberate or is it left to tribal knowledge and hearsay? Is it something you truly value and prioritize or simply a byproduct?

Documentation is good, but the trouble with documentation is it’s usually haphazard and stagnant. It’s also usually documentation of how and not why. Documenting intent can go a long way, and understanding the why is a good way to develop empathy. Code survives us. There’s a fantastic talk by Bryan Cantrill on oral tradition in software engineering where he talks about this. People care about intent. Specifically, when you write software, people care what you think. As Bryan puts it, future generations of programmers want to understand your intent so they can abide by it, so we need to tell them what our intent was. We need to broadcast it. Good code comments are an example of this. They give you a narrative of not only what’s going on, but why. When we write software, we write it for future generations, and that’s the most underestimated thing in all of software. Documenting intent also allows you to document your values, and that allows the people who come after you to continue to uphold them.

Storytelling in software is important. Without it, software archeology is simply the study of puzzles created by time and neglect. When an organization doesn’t record its history, it’s bound to repeat the same mistakes. A company’s memory is comprised of its people, but the fact is people churn. Knowing how you got here often helps you with getting to where you want to be. Storytelling is how we transcend generational gaps and the inevitable changing of the old guard to the new guard in a maturing engineering organization. The same is true when we expand that to the entire industry. We’re too memoryless—shipping code and not looking back, discovering everything old that is new again, and simply not appreciating our lineage.

Read the whole story
thcipriani
38 days ago
reply
Share this story
Delete

Code Review, Forwards And Back

1 Comment
This Friday, at PyGotham, Jason Owen and I are co-presenting "Code Review, Forwards and Back". This is not a standard technical conference talk. It's a 25-minute play, basically a one-act.

The setting: an office conference room. The characters: a developer, who's written a chunk of new Python code, and a team lead, who's about to review it. You'll see the code. It's not great.

What happens if the reviewer waves it through, or lets conflict aversion get the best of them? What if the reviewer says it should be "better" but doesn't articulate how? What if the review is abrasive, or nitpicky, or laid-back? What if the reviewer rewrites the code right there and then? And if we fast-forward to the same team years later, how has this code reviewing style affected the quality and evolution of the codebase, and the team's culture, skill and sustainability?

See a fast-paced montage of ways things can go. Recognize patterns from your past and present. Learn scripts for phrasing criticism constructively. And laugh.

Or, to put it another way, it's Run Lola Run but about code review.

I was getting advice about this from a friend who's both an actor-playwright and a senior developer, and I may as well tell you what I told him, about why I want to do this. I have artistic and educational reasons.

Artistically: it's frustrating to me that there's such a limited range in how we persuade and teach each other in sessions at technical conferences. Most commonly I see conferences with lots of lectures, panel discussions, and live tool demonstrations. Those aren't very interactive, and so I welcome conferences who bring some variety into the mix on the axis of interactivity, such as hands-on workshops and trainings, and birds-of-a-feather discussion sessions. But also, we could be learning a lot more about spectacle from the giant field of endeavor that is all about entertaining people who are watching you perform on a stage.* We encapsulate wisdom as, e.g., songs and cartoons whose entertainment value helps us value and retain their lessons; Jason and I are interested in seeing how theater can do things a lecture can't do, can be like a demo of behavior, while talking about tech.

And educationally: especially when it comes to the emotionally fraught art of code review, the medium of theater seems like a promising way to encourage empathy in the viewer. Code review is a moment of great vulnerability, an opportunity for courage and healthy conflict. We only know ways to be if we can imagine them. Jason and I hope this play illustrates a few ways we can be.

So we're preparing that. I hope it goes all right.


* No actual stage in the conference room where we'll be performing. But, you know. Figurative stage.

Read the whole story
thcipriani
47 days ago
reply
"Code review is a moment of great vulnerability, an opportunity for courage and healthy conflict."

<3
Share this story
Delete

It’s Magit! And you’re the magician!

1 Share

There’s nothing I can praise about Magit that hasn’t been written in a dozen blogs already, but since Jonas started a kickstarter campaign for it I knew I had to say something. If you use Magit, you already know the greatness of it. And if you don’t, hopefully I can convince you to try it in time to back the campaign.

I could go on and on about the virtues of this gem. It’s probably the package that most saves me time, and has taught me more about git than I learned reading a whole book on it. But that’s all just sparks and glitter on top of the real show. For Magit is a magic show, and its real feature is making you the magician.

Controlling Magit feels like putting on a performance. Move your fingers quickly enough, and you’ll be rebasing faster than the eye can see. But if your crowd is not impressed yet, you move on to tagging, cherry-picking, rewriting, reflogging until they’re left staring unblinkingly at your monitor, their jaws unknowingly open in awe.

But, if you’re one of those that only cares about practical benefits, then here are few Magit commands I use just about everyday.

f a Fetch all remotes
Usually how I start my day. Updates information about all remote branches, without messing with your local branch. Really helps that it’s a one-handed combo, so I can do it while sipping the morning coffee.
r u Rebase upstream
Upstream usually means origin/master. If fetch-all indicates that my local branch is out of date with upstream, this will quickly bring it up to date. If I don’t want to rebase this branch, I can m m and merge instead. Since fetch-all has already done all of the slow networking, both merge and rebase are super quick.
b s Branch spin-off
Creates and checks out a new branch, while carrying over any ongoing (and possibly committed) changes. It even undoes the commits on the previous branch. Super useful if you realise you forgot to branch-off from master before starting to work.
b c Branch create
Over time I’ve been gradually using less b s and more b c. When I need a new working branch, instead of having to switch to master, pull origin, and then spin-off, I simply b c straight from origin/master (it never really matters if my local master is outdated).
P … Push!
Feels silly that pushing is so far down my list, but here you go. P p is 95% of my usage, but P t is also useful and you’ll occasionally need a -f in there.
c … Commit powers
c c is your basic commit. But I couldn’t live without c w (for quickly fixing a commit message) or c e (for throwing more changes into the last commit).
l l Log current
Magit is pretty good at keeping you informed of the commit difference between local and remote, but l l is a quick way to get your bearings if you ever feel lost.
y Branch viewer
Concise list of all refs. Great for finding and removing old branches with k (both local and remote). Magit even warns if you try to delete a branch that isn’t merged.

And a few commands I don’t really use everyday, but rather eagerly look forward to the next chance to use them.

l r Reflog
Don’t know what reflog is? Neither did I! Magit taught me about reflog without saying a word, and you should learn it too (it feels like a superpower).
r s Rebase subset
At work, when I need to hotfix something I branch-off from origin/production instead of origin/master. Occasionally though, I’ll forget to do that, commit my hotfix, only to realise my branch is now 100 commits ahead of production. Rebase subset solves this is a blink, by taking only the commit I want and placing it on top of another branch.
r i Rebase interactively
I admit, I was a little scared when I first tried this feature. I had no idea what it did, but that “interactively” menu option had been teasing me for months. If I explain it here I feel like I’d be robing you of the discovery, so I’ll just describe it as “omnipotence over history”.

All of this arsenal combines into some fast and powerful git manipulation. Just yesterday a colleague asked for help on one of his branches. The whole checkout, edit, commit, push process took less than 30 seconds. One more b b and I was back in my branch doing my own stuff.

What’s more, it all feels right. My editor is where I manipulate the source code, that’s where I ought to be changing branches, not alt-tabbing to a terminal.

Comment on this.

Read the whole story
thcipriani
54 days ago
reply
Share this story
Delete
Next Page of Stories