My first weeks at Artefactual Systems Inc.

There was a great response to my move away from the public sector into a private sector company (that’s right, I no longer work for the government!).

The organisation I joined, we, (Artefactual) specialise in developing open source digital preservation, archival description, and discovery solutions.

Looking forward to welcoming @beet_keeper to Artefactual! https://t.co/87VibS9DaO

— Archivematica (@archivematica) October 23, 2017

I started November 1, and today is December 16, so we’re a month and a bit down the track.

What a whirlwind it has been:

• Managing a few personal bits of pieces in the early parts of November
• Learning how to work remotely
• Learning to work on an hour-by-hour system vs. a salary, which I’ve long been used to

But more than that, re-learning how to develop in a team again, and now, a much wider community ecosystem.

Good *sigh*. Much relief! Much re-learning how to code sustainably in a wider developer/user ecosystem/community in the last few weeks. Good fun though. Really supporting colleagues. #digipres #software #coding pic.twitter.com/pzQMrPAdci

— ???????? #Digital ⚓️ #Vagabond ???????? (@beet_keeper) December 12, 2017

Does that seem strange?

I have been a community person probably about as long as I have been on Twitter. Maybe before, but it’s my own Twitter epoch that made me realise that there was a community out there for ‘us’ in digital preservation.

Relevant as well, is my first GitHub commit was 25 April 2012:

https://github.com/digital-preservation/droid/commit/3c4142f829510a06362de8c371e9f86fb71c7223

This was creating DROID’s GitHub repository and beginning to commit its source code at the beginning of The National Archive’s Digital Repository Infrastructure project.

That is the first time i was introduced to publishing code publicly – really publicly – like, not just inside the corporate subversion repository. Learning how to get over the fear of people ‘looking at you’, and just being ‘open’.

Like many, of course, I discovered, no one is really looking at you that closely. A lot of folk are actually really just happy to see you publish something that might be useful to them. And so I continued.

But a lot of my continuing efforts, including my evolution in PHP, Python, and now most-recently, Golang, was done on my own. Self-taught, on small- to medium-sized projects, ranging from counting the distance in bytes between two binary values, to my own database language.

Rarely did anyone use or comment on it which makes it difficult to improve the quality of what is underneath. Not impossible, just that idiosyncrasies will be apparent throughout.

And so the last few weeks have been tough, but good learning around building what will be needed to be a valuable contributor to the Artefactual team, and our respective, digital preservation, archival, and records and information management communities.

Here are some highlights.

Code Reviews are Awesome

I really value the outlook of one of my fellow developers when they talk of code review as a conversation. Your code is ostensibly working but you’re inviting colleagues, in my view, to:

“to help capture any potential errors in logic, or issues for future maintenance of the code. But primarily help ensure the long-term legibility of the work.”

I participated in both my code being reviewed, and had the opportunity to review another’s work. It taught me about parts of the software that I still need to learn, and helped improve my style, and also improve the confidence I had in what I was doing.

For years I have been writing print and write statements in Python fairly verbosely:

There is more than one way to skin a cat

sys.stderr.write(“Error: “ + str(error_code) + “ something has gone wrong.\n”)

It’s a very deliberate way of writing but it won’t be remembered a high-point in my own style. Take instead the guidelines here at pyformat.info which my colleague sent to me.

We can do this instead:

sys.stderr.write(“Error: %d something has gone wrong.\n” % error_code)

First of all, the statement is shorter. One less function is called directly. I’m not manually making sure my integers, or other data types are being ‘cast’ into the correct type for printing to the console; it’s all done by the inbuilt Python formatters.

It’s a piece of syntactic sugar that had escaped me. Maybe because I also didn’t participate in community development more myself? Maybe I could have read more around the language? I’m glad it’s something (small but) new that I have picked up.

I look forward to learning new alternatives to my current coding tendencies.

Git is Hell! (at First)

But it’s also a spectacularly useful tool. I’ve had to learn about remote repositories, rebasing, and of course merging!

It is a cliché – merging can be tough – and I had very little experience working with the other techniques. But it all pays off.

I have often seen others develop in separate branches. At Artefactual there is often a branch per issue. It keeps the stable branches exactly that – stable – they work. And on the outside, these branches open up the maximum amount of flexibility and ability to express oneself as a developer.

Rebasing means that at the end of the work, all your commits are turned into one single commit and so become a summarized manageable and understandable history of changes. And the code is merged back into a quality assurance branch and then a stable branch for community consumption.

Never again will I take one of my own repositories, render it unstable while I add a new feature, and fundamentally take that work out of service with very little ability to reverse changes.

I am Groot! Branch branch branch!

Measure many times, cut once…

It’s an old adage. One of the things I was struggling with most over the first couple of weeks working for Artefactual was how long things were taking. You want to impress? Right?

Ultimately, I was going at my own speed, in a way that I am very familiar with working – I was looking at every possible different option for the feature I was implementing. I would look at creating files to test work-flows. Unit tests that existed that would need to be modified to test new features. I looked at how each component enacted upon each other along the way.

By the end of the process, myself and the team had identified three or four different components of the system that would need modifying.

It took about 95% of the time to understand each part and the changes that would need to be made. The code took 5% or the time – maybe even less. The code was easy. Writing the important parts – the acceptance test use-cases, understanding the architecture and impacts; making sure users had maximum choice; definitely the hardest part and definitely took the longest.

There has been a lot more…

Even as I type, I am learning more about how to contribute issues to Git more usefully. I am learning Python frameworks that are new to me. I’m still getting my head around everything I did for this first release I was involved in – but by doing it all over again!

Julia Evans released this Zine about being a Wiz this very day, https://twitter.com/b0rk/status/941901614796943361:

I am far from being a Wiz. I’ve already worked my way through most of these pages and it’s super useful! With a little help from this, and colleagues like this past release, maybe, just maybe (and with a little more perseverance), it might be possible to get there.

—

Header image from: https://www.artefactual.com/portfolio-type/ross-spencer/