#writing code

"One of those projects that I built thinking it would solve the purpose, but I was wrong, yet the application works perfectly, better than WhatsApp, collecting dust on it, needs a lil finishing and this is what I will work on this weekend with another project I am already working on."

Although I was initially worried that my blog had been fully deleted, since I had seemingly been logged out on all platforms, what had actually happened was my custom theme had disappeared and my blog was running the default Tumblr theme. When I finally logged in and opened my blog settings, I got a pop-up saying “Your custom theme has been reset because we detected some suspicious code” and no option but to click “OK”. No, Tumblr, it was not fucking okay! You couldn’t have sent me a sanitised version of the theme? Told me what was wrong and asked me to remove the offending part first? Holy shit bro, way to ruin people’s days

I panicked for a little while at this point, especially after I discovered that Pixel Union removed all their Tumblr themes like three years ago and it was literally impossible to install the Effector theme fresh from the Theme Garden any more. I was contemplating the arduous task of rebuilding it manually, using Wayback Machine snapshots and the Tumblr themeing documentation. Every passing second that I entertained this idea, it seemed even more impossible to achieve

Fortunately after poking around in my files I discovered I had actually saved a backup of the full theme HTML in April 2014, probably right when I switched to using the Effector theme in the first place. I wasn’t sure what changes I had made to it over time, but after applying it and figuring out the right combination of settings to return my blog to its former glory, it seemed the only lasting modifications had been to the grid of social icons

The Wayback snapshots proved helpful for recovering the little bits of HTML that I had customised. Tumblr didn’t nuke my custom CSS, but if it had I would have been able to recover a copy of that as well. The end result is that after a few frenzied hours, my blog looked the same as it ever did. Well, the social icons have been rearranged a little because I alphabetised them while I was there, but otherwise it should be no different to before :p

I have taken this opportunity to start performing real, proper backups of my theme HTML and my custom CSS. In fact I’m now managing them with a (local) Git repo, just to be extra serious about it. My theme HTML is probably better than it has ever been! I’ve cleaned up the indentation, and fixed a few bugs with block variables that weren’t closed properly. These may have been fixed in later releases of the theme: my backup was of v2.1.0, while @effectortheme​ (which presumably would have been kept up to date to show off the latest features) is running v4.4.4 (August 17, 2015). That’s about a year and a half of further development, and apparently two major revisions worth of changes! Well, it looks basically the same, so here’s hoping they were minor edits or features I wouldn’t have wanted >.>

So, here I am at my desk, with a huge flask of tea, ready for another late night. I am on the main data analysis section of my roadmap to thesis completion, and I have a lot of data to analyse. Don’t get me wrong, lots of data is every researchers dream, but lots of data also means a hella lot of time commitment for quality checks, figuring out best use, and actual analysis (visualisation, writing code, etc.). Fortunately, I have been very organised with my data from the get go, so that’s saved me some time, but that’s just one part of the process and I am currently finding myself a bit behind schedule. And on that note, I am going to go get back to it. 

Have a grand rest of the week and thank you to 850+ of you that follow my journey! <3 Illustration: Basically me, but less cheery, and with a lot more hair. Source: Tumblr.

But ANYWAY I’m having trouble with sidebars? Like I used W3Schools, and watched youtube tutorials on how to use nav bars, but the only thing they don’t show you is how to click on your link and have it open in the main part of the page. when you do frames you can do target=“right”, but that doesn’t work with a sidebar. i can get it to open in a new page, but not in the main part of the current page. and no tutorials actually show you this. I might go oldschool and use frames afterall. This was what I was originally going to do anyway, because I want to make it look as 90s as possible.

So, this was fun:

you’d think that when i do this kind of stuff all day at work i wouldn’t want to do it in my free time... wrong. There’s no pressure and the outcome is going to be really cool, so it’s fun.

I've learned a lot about how to be a better engineer after almost two years of writing code at Tumblr. The majority of Tumblr is built on a few massive shared codebases, so I've learned that the strength of the product is only as good as our collective ability to write code for each other. And we ship a lot of code all the time—we have engineers writing code, getting it reviewed, and deploying it to production within the first few days of being on the job.

I've found that coding at scale is more social than technical, and this is a very good thing. When writing code in a large scale environment with a codebase shared by more than a handful of people, I'm not writing code just for the computer to read anymore: I'm writing code for the dozens of other engineers who share the codebase with me. At some companies, and for some open source projects, a codebase can be shared by hundreds or thousands of people; your experience with another person may be solely through their code or code review. With this in mind, it's extremely important to have good, humanist coding practices.

A humanist coding practice means my code is easy to read by anyone who shares the codebase with me. My code is explained not only by the way it's written (the literal syntax, structure, and variable naming) and the unit tests I've written for it, but also by documenting it inline with comments. In my world, there can never be too many comments explaining how something works. Documenting the internals of my code is just as important as documenting its interface. Too often engineers focus their documentation effort into making clear the way to use their code without spending any time documenting how their code actually works.

It's similar to the idea of "good taste" when coding. While it's important to keep complexity low and efficiency high, it's even more important to keep readability (by humans) high. If I write code in a shared codebase that's highly performant, but nobody else can understand it, is it really all that useful at the end of the day? Almost never. While it's true that I'm writing code to be performant on a machine, my first priority should be to make sure my code is maintainable by other people. Every engineer needs to be able to take a vacation and feel confident that someone else can fix a bug in their code.