#writing code

[st4rgirlinterlude]

art really do be imitating life i’m about to write a fic about some wild shit that happened at a function

feeling connected with nature, no longer chronically online, healed

[404daydreams]

"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."

-Well, ofcourse its ME.

[phidica]

So I woke up this morning to a very alarming message from one of my friends:

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 >.>

Regarding the “suspicious code” that tripped Tumblr into deleting my theme in the first place... Well, I doubt it was the stock theme itself. It was probably some of the commented out JavaScript I had left in the HTML from special occasions in the past: the code to render falling confetti (on my birthday), and the code to embed an auto-playing video of Usher saying “Merry Christmas Xbox”. I might dare to put that code back in some time soon, now that I have everything backed up securely, just to test out exactly what did it... But I also might not! Because, I don’t know if Tumblr is actually working on some sort of strikes system, and if repeatedly tripping their suspicious code filter could just get my blog outright deleted :x

[streamacademe]

Week 182, Day 1270.

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.

[this-is-a-love-story-isnt-it]

uuuuhhhhhh....... I’m trying to make my own website from scratch because I miss the 90s where people (including me) would just make websites bc geocities was a thing. Then I learned CSS when I customized my Livejournal. So I’m going to make a CSS and HTML website, and omg CSS is so much more robust now???!!?!!!! like, I haven’t used it since 2008-ish.

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.

Plus this editor is amazing, but it’s a free trial so I have no idea how much they’re actually going to make me pay for it. i’m still going to buy it, though, because it’s better than anything i use for work.

[lesterpubliclibrary]

Take the mystery out of coding!

[cyle]

How I Code Now

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.

With that in mind, my ability to write code is only as strong as the people who have reviewed my code. Similarly, everyone else's code around me is only as good as my ability to review it. When reviewing code, I try to assess whether the entire thing makes sense from a high level, and then down to the syntax, naming, and the raw work of the code itself. Not only answering the question "does it work?" but also "does this make sense?" in the context of itself and the whole codebase. I apply that same logic whenever writing my own code, expecting whoever reviews it to ask similar questions of it.

As engineers, we're prone to having tunnel vision with our code, shirking on documentation because we know how it works and the fact that it works should be self-documenting enough. Don't fall into this trap of overconfidence; make your code humble and assume nobody will know how your code works. You won't even remember how it works in six months.

In terms of actual programming languages, frameworks, design patterns, and best practices, it's important that I have strong opinions, weakly held. There are enough interested people in the world to objectively quantify what languages, frameworks, and patterns push bits around faster than the others. I have my own strong opinions about what I think works best for a given scenario, but I'm likely to be proven wrong about my opinion within a year. The fact that I'll stick to my guns, but am willing to be proven wrong, creates a balance between trying new patterns and not fixing something that isn't really broken.

Also, it's important to remember that some engineer is releasing a new language or framework somewhere in the world every minute. Every engineer is simultaneously building their own framework and has an extreme case of framework fatigue. I've stopped believing that there can even be the right tool for a job; mostly I now believe that you could go in any direction with your code and there's a framework somewhere to support your coding habits at scale. It's now even less about the code and more about whether or not you can defend your choices socially.

While trying to figure out which tool or approach is best for the job, I also believe in being data-driven but not data-determined. There's always one engineer who'll go the extra mile and do thorough benchmark tests against two seemingly identical code choices, and thank goodness for them. But just because something performs 2% better doesn't mean it's the right decision. Likewise, every modern product is doing live A/B tests with 1% of their users, but just because we can prove that the neon pink version of the button performs better than the standard blue version doesn't mean we should ship the neon pink.

Performance certainly has a weight in helping to define direction, and you can undeniably prove (with math!) that one thing does something better than another, but I often fall back to one of the first points I made here: the code has to remain readable. Things have to continue making sense, not just to the machine, but also to us humans. I can easily implement lots of crazy performance optimizations around the codebase, but those optimizations can be entirely useless if nobody else understands them and has to help maintain them. I can certainly ship the neon pink button, but the novelty is going to wear off and users are going to be left confused about the one neon pink button on the otherwise blue-and-white page.

My biggest point here is that no one person in a shared codebase can be an authority. Nobody really has any correct answers, only good ideas that still need to be reasoned out during code review. Until we can teach the machines to write the code for us, the most important consumer of our coding choices will continue to be every other person touching that same codebase. While setting strict standards and defining patterns are useful things to help guide each person's contributions, writing code at scale is a shared responsibility and principally a kind of social contract between people.

With these humanist coding practices, I've been able to refine my own style while maintaining the ability to ship good code that other people understand. As I've become a more senior engineer, I've started spending more time talking about code than writing actual code, and that's a good thing. I may not write the most insanely performant code, but at the very least I feel like I can go on a vacation and not have to worry about being the only one who knows how it all works.

[phidica]

The best part about working from home is that when I’m mad at my code I can scream and make loud annoyed noises and there’s no one around to judge me