K. Sabbak

Here's a fun fact about me: I have a BA in Linguistics. What did I think I was going to do with that? Well, probably more school, but at some point I realized that was the wrong path for me. That being said, I really appreciated what I learned as a linguistics student.

The very first linguistics class I took was probably LING114 taught by Prof. Glick. The thing about Prof. Glick is he was the head of SUNY Binghamton's Linguistics department, and I took a lot of his classes. He had three principles about language that given how often I took his classes, I will likely never forget. The goal here is to try to apply them to code - after all, we may be coding in constructed languages, but they're functionally very similar to natural languages in many ways.

So you're at a party and someone turns to you and says "You do things with code, right? What's the blockchain?" and in you're head you're all "Oh my god, I do work with code, what is the blockchain???" and aloud you recreate this clickhole video on bitcoin. Everyone nods as if they understand you, you nod as if you understand you and then you go home and fall down a rabbit hole where you end up learning a lot about cryptographic hash functions, some nonsense about the blockchain and you can finally rest assured that the next time you're at a party and get asked, you can safely tangent about cryptographic hash functions, which sounds smart and cool, ergo making you sound smart and cool and the world is right again.

Or you can just read this blog post. It's not about the blockchain at all.

If you’re anything like me, and I know I am (who did I steal that from? It’s awful), change is hard. There are probably studies done that make a case for why this is, but regardless of the why, change is just really hard.

For me, learning design principles in writing code is basically on par with changing how I believe the world works. It’s hard and uncomfortable and this is how it goes:

I was tasked to build something with TDD a month ago, and along with TDD, one of the many things I ended up learning in the process was how to better estimate - not necessarily how to make my estimations better, but how to not just blurt out the first number that popped into my brain.

My background is a largely non-technical one with a lot of weird tech bits sprinkled on. My working background most recently has been of the variety where I was told "Do this by this date" with no room for input from me, so coming back into a world where I have a say has been quite the transition. In a moment of panic and pressure, I'd just give whatever estimate popped first into my brain -- giving estimates that were less than ideal and not wholly considered. And against all Agile ideals and principles of common sense, there I was, with estimates and work to do in that time and of course the thing that I sacrificed was quality, and the biggest area where I did this was in refactoring.

Agile! It's everywhere! Or at least the idea of Agile is there. I can't be the only one who gave very vague, wishy-washy explanations up until five minutes and one reading of The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers) ago.

Oh, yeah, Agile! It's like, you know, it's what you do with software. You have sprints and during the sprints you build like, user stories and stuff. Haha, post-its, am I right?

Don't be me. Have a primer: