Clean Code: 5 Tips for Best Practices

Last week, another developer from Hyland and I had the opportunity to go out and give a talk to computer science students at Bowling Green State University, courtesy of the university’s Women in Computing club.  They were kind enough to let us choose our own topic, and after tossing out our first 50 ideas, we decided to talk about how to write clean code.

Both Rebecca and I are second-career developers, and the two of us are called on to give the “second-career-woman-in-tech” talk fairly often, so we wanted to talk about something technical!  Besides which, university comp sci majors are probably not a group that needs a “second career” talk.  We headed out to Bowling Green after work on aWednesday, had a lovely drive out, and spent a few hours giving the presentation and chatting with the students.

I don’t want to dump the entire presentation here, but I did want share some of our key points.  Also, if you have an organization that’d be interested in hearing the talk, drop me a line and one/both of us can make arrangements to come give it!

Point #1: Coding is a social activity.  Programmers spend more time reading code than we do writing it!  The ratio on reading to writing code when it comes to development is something like 60:40.  This is because programming languages don’t exist for computers.  Think about it!  All the computer cares about are ones and zeros; the switch is either on or off.  We have high-level programming languages because programmers have made them for other programmers.  Languages are a tool that lets us share ideas with each other and communicate what we’re trying to achieve with our code–which is why you should always write clean code.  Pretend that the next developer to touch your code is a psychotic serial killer who knows where you live; you don’t want to make them angry.

Point #2: The two hardest things in computer programming are cache invalidation and naming things.  (Admission: I stole this saying from my dude Dave Goerlich).  You want to make sure that your names for things convey your intent!  Follow common conventions for whatever language you’re using, use one word per concept (i.e. don’t use “get”, “fetch”, and “retrieve” if they all mean the same thing), and avoid one-letter variable names (unless it’s a short scope or you’re naming an iterator variable).  Variables (customerAccountNumber) and classes (customerAccount) are nouns, booleans are yes/no answers (isValidAccount, isNotFlagged), functions are verbs (getCustomerAccountNumbers).  You also don’t want to mislead your reader–so don’t name an array of Customer objects a “customerList”.  Names should also be pronounceable and understandable–don’t make weird acronyms, or use nonsense words that have no meaning outside of very specific knowledge set.

Point #3: Classes and functions/methods should be small!  Very small!  Very, very small!  They should also obey the SRP (Single Responsibility Principle).  Functions should do one thing and do it well; classes should only have one reason to change.  For functions, the ideal number of arguments is nil–then one, then two, perhaps, three, but after that, many input arguments are a bad smell and indicate that the function is probably not adhering to the SRP.  Stay away from output arguments if at all possible–we’re far more used to seeing input arguments, and output args can lead to confusion.

Point #4: Keep it DRY.  Don’t Repeat Yourself!  This argument may have been done to death a thousand times before, but it’s worth repeating in every talk about clean coding practices.  We can also talk about organization here: try listing your functions ordered by level of abstraction.  One function should call those functions directly beneath it, although there are (of course) exceptions to this rule (I had one in my example code!).  Try making your code as easy to read as possible so that they next developer doesn’t have to keep scrolling up and down lines, looking for the next function call.

Point #5: Comments can be evil.  It’s very, very tempting to comment away badly-written code, but that’s a cardinal sin of clean coding.  Comments are not an excuse for skipping refactoring–if you think developers are bad at maintaining clean code, imagine how bad we can be about keeping comments up-to-date!  Comments that are redundant, misleading, or arbitrarily-required need to go, as do large block of commented-out code.  End-of-block comments are a smell that your code block is too long and refactoring is needed, and log comments on every file aren’t needed with any good modern version-control system.  Documentation comments, TODO comments, legal disclaimers, and short informative or clarifying comments can be good, but these all still run the risk of becoming outdated, and care should be taken to update them along with the surrounding code.

That’s not the entirely of the presentation, but those five tips are our key points for code cleanliness.  Also, if you’d like to see our slide deck, you can see it here!

 

The Black Magic of HTML5 Data Attributes

Okay, so, rewind to about a year and a half ago, when I was lying on the sofa, having a whine about my retail job du jour, and remembered that I actually had some skills outside of smiling and accepting the blame for my store being out of arbitrarily-sized t-shirts. This train of thought ended up with a friend of mine sending me copies of a couple front-end ebooks to get me up to speed on HTML5 (which had just come out) and CSS3, since I was a little out of date with what was going on in the Great Big Hello World of Web Development.

So, I’m reading this HTML5 book, all like:

But, there was one thing that it either didn’t cover, or—more likely—I got bored and quit reading before I got that part, because it wasn’t like I couldn’t already HTML, and reading about HTML is not the most exciting thing on Earth. (Also, HTML is now a verb, I’ve decided.) The thing that I missed? Data attributes, or, as they are also known, black freakin’ magic. The first time I saw them being used, I was like:

…look, kids, back in the day, we had to come up with weird names for CSS classes and use JavaScript to parse them into something meaningful if we wanted data available in the DOM. Now, you just prefix with “data-*” on an element, and you can store whatever the heck kind of string you want in there (within reason). You can store JSON in it, for example, which is just—whaaaaaat, where has this been all my life? (Or maybe not—HTML5 is only two years old, so for the vast majority of my life it hasn’t existed… still, have I totally been living under a rock for two years?!)

So now, say I have an unordered list, and I want to grab a value (or several values) and display it when the user selects a list item, without making an Ajax call or querying a database or any of that nonsense. I’ll just stick my data in some data attributes—let’s call them “data-registration-number”, “data-color”, and “data-codename”:

  • <ul id="nonsenseList">
    
     <li data-registration-number="1701" data-color="yellow"
    
     data-codename="Enterprise">Nonsense</li> 
    
     <li data-registration-number="74656" data-color="blue"
    
     data-codename="Voyager">More Nonsense</li>
    
     <li data-registration-number="74205" data-color="red"
    
     data-codename="Defiant">Even More Nonsense</li>
    
     </ul>

So now, I can use JavaScript to grab one of those values from my list items, and use it however I want:

<script> 
//this first script uses the element.getAttribute() function to nab the value from our data attribute:
var nonsenseList = document.getElementById("nonsenseList"); 
var firstItem = nonsenseList.children[0]; 
firstItem.onmouseover = function(){ 
 var regNumber = firstItem.getAttribute("data-registration-number"); 
 window.alert("Registration Number: " + regNumber); 
}; 
</script>

Admittedly, this is a pretty lame example with little/no practical application. The point is, I was able to tell my script to get the value of the attribute named “data-number” off a particular element, and it did. You should note that in order to have to a valid data attribute, the attribute name must be prefixed with “data-”, have at least one character after the first hyphen, be XML-compatible, and contain no uppercase ASCII letters (as per w3 spec for HTML documents, read more here).

But wait! There’s more. There is actually an even better way to access what is stored in your data attributes, and it’s through the new HTML5 dataset API. This API exposes an element attribute named dataset, which returns a DOMStringMap object. The DOMStringMap keys are the names of the data attributes (without the “data-” prefix), and the corresponding values are the string values contained in the attributes themselves. If the data attribute name is made of multiple words (like our data-registration-number), it’s converted to camelCase (in this case, registrationNumber). The dataset API is dead simple to use, too—just call it using dot notation on a chosen element:

<script>
//let's try it again using the dataset API:
var nonsenseList = document.getElementById("nonsenseList"); 
var secondItem = nonsenseList.children[1]; 
secondItem.onmouseover = function(){
 var regNumber = secondItem.dataset.registrationNumber; 
 window.alert("Registration Number: " + regNumber); 
}; 
</script>

The dataset API is widely supported in modern desktop and mobile browsers (aside from in Internet Explorer, which only supports it in IE11, because it’s Internet Explorer). There is a shim out there for it (only a Google search away), but if you’re concerned about compatibility, you can always fall back on using more vanilla Javascript functions like getAttribute(). I’ve also read that using the dataset API is slower, but unless you’ve got a load of stuff stored in your attributes or need to read out of a whole bunch of them very quickly, performance shouldn’t be a concern—and, side note, if this is an issue, it’s my opinion that you’re probably weighing down the DOM with too much data, and need to rethink your architecture.

Another side note: data attributes should only be used when a suitable HTML5 element or attribute does not already exist. Additionally, unlike microformats, data attributes are meant to be private—that is, they are not intended to be read by outside software, and are meant only for custom data in the context of the site they are located on. Data attributes are meant to be used by the site’s own scripts, meaning that you shouldn’t be implementing them to store publicly-usable metadata. If you want to do that, use microformats, that’s what they’re for!

If you’d like to try it with some quick and dirty code, here’s the pointlessness that I threw together for this post–feel free to pop it into your editor of choice and use it as a starting point for playing around with data attributes:

<html> 
<head>
 <!--doing some quick/dirty styling so that things aren't as ugly-->
 <link href="https://fonts.googleapis.com/css?family=Homemade+Apple" rel="stylesheet"> 
 <style>
 .container { 
 width: 25%; 
 text-align: center;
 }
 li { 
 display: block; 
 margin: 10%; 
 padding: 10%;
 border: 5px solid black; 
 border-radius: 10px;
 font-family: 'Homemade Apple', cursive;
 }
 </style>
</head>
<body>
 <div class="container">
 <ul id="nonsenseList">
 <li data-registration-number="1701" data-color="yellow"
 data-codename="Enterprise">Nonsense</li> 
 <li data-registration-number="74656" data-color="blue"
 data-codename="Voyager">More Nonsense</li>
 <li data-registration-number="74205" data-color="red"
 data-codename="Defiant">Even More Nonsense</li>
 </ul>
 </div>
</body>
</html>

<script> 
//this first script uses the element.getAttribute() function to nab the value from our data attribute:
var nonsenseList = document.getElementById("nonsenseList"); 
var firstItem = nonsenseList.children[0]; 
firstItem.onmouseover = function(){ 
 var regNumber = firstItem.getAttribute("data-registration-number"); 
 window.alert("Registration Number: " + regNumber); 
}; 
</script>

<script>
//let's try it again using the dataset API:
var nonsenseList = document.getElementById("nonsenseList"); 
var secondItem = nonsenseList.children[1]; 
secondItem.onmouseover = function(){
 var regNumber = secondItem.dataset.registrationNumber; 
 window.alert("Registration Number: " + regNumber); 
}; 
</script>

Burnout & Broken Things

As 2016 wraps up, I’ve been waxing nostalgic about the past few years. I moved back to Cleveland from England on August 15, 2014; my divorce was finalized December 15 that same year, and I graduated from bootcamp on December 12, 2015—almost a year later. The disastrous culmination of my first tech interview process on December 30, 2015 taught me enough to fully recover for the next one, which resulted in a job offer from Hyland with start date of Februrary 22, 2016. I’ve been able to pull all of those dates right off the top of my head, somehow, even though I literally have to stop and think before telling people the date of my child’s birthday (March 3, May 5, same thing—right?).

The thing is, there’s a lot out there about how to live your best life—how to get a decent job, how to ditch your abusive partner, how to de-stress, eat right, exercise, meditate, how to dress for success, how to wing your eyeliner, how to clean dog puke out of upholstery. There’s all sorts of ways to get there–Google it, and you’ll find it. What no one seems to have is any advice for it what comes afterward… when you’re sure that you’re fierce and independent and capable, and suddenly, you’re sitting in front of an auditorium full of people with a microphone in your lap, and someone in the crowd raises their hand and say, “this is a question for Tori,” because they’ve decided that they want their best life, too, and they think you have the answers they’re looking for.

In a nutshell: 2016 has been both extremely rewarding, and utterly terrifying. I got a job—a full-time job, at a company that hired me for reasons other than that I’m capable of showing up on time and speaking in full sentences. After two years, I was finally able to pack up and move my kid, my dog, and myself out of my parents’ spare bedroom and into a house. I don’t worry about making my son’s school tuition payments, let alone worry that I’m not going to be able to afford medicine or food.

I’ve done this with the realization that if I hadn’t had my parents’ patience (and their spare bedroom), at least one good friend (hi, Dave), and someone to loan me $9,000 without even checking my beyond-terrible credit score (thanks, WCCI), this might not have played out so well. Even with the advantages, I still had to ask Hyland to move my start date up two weeks from their initial offer, because I had run out of money to keep putting gas in the car. Truth is, there are many, many people who had it far, far worse than I had it—which is exactly why I need to have answers when someone says, “this is a question for Tori”, because hard is hard, and I’m going to offer whatever slivers of hope and strength I can.

An apprentice at We Can Code IT contacted me recently and offered to take me out for coffee. If we do end up going for coffee, she’s not paying for it. She’s paying nine thousand dollars already; there’s no way she needs to spend an extra two bucks on buying her mentor a cup of coffee. I’ll buy my coffee, I’ll buy her coffee, I’ll buy pastries if she wants one. I’ve realized that you don’t just get out what you put in—once you climb the mountain, the good thing to do is to turn around and reach down to help the next person.

2016 has been humbling. I’ve also spent the last few months of the year fighting with a bout of anemia brought on by switching out one of my medications, which is its own special version of terrible. I’ve had to drop projects I was excited about, and push myself to finish others while exhausted. Good news, though—I’m a month into taking iron supplements, and I almost feel ready to try out some short hikes again. Strapping on a pack and putting down substantial miles is still a bit far off, but getting the boots on for a couple miles in the park is beginning to sound appealing again. Some of the things I had to drop off in 2016 should see new efforts in 2017, which I’m finally excited over (instead of exhausted just thinking about).

The title? Burnout, obviously, from the anemia—trying to do too much while my body wasn’t getting what it needed. I spent a couple months insisting that I was fine, and that my elevated heart-rate and constant fatigue were from stress and not having time to hike on weekends. In retrospect, that was ridiculous, because I had plenty of time to hike on weekends, I just wasn’t able to make it out of bed. I did force myself to Philadelpha for Ela Conf, which was very much worth it, and to attend a few events and start a couple of projects, but the physical cost was pretty great. Thankfully, I shouldn’t have to deal with it very much longer. Broken things, though—that’s a little more introspective. I’ve spent a long time identifying myself by what was wrong with my life—no money, no job/bad job/low-paying job, bad relationship, etc. There is still plenty wrong with my life (debt up my eyeballs, I live in a bad rom-com, my dog likes to eat things she shouldn’t), but I’ve quit defining myself by it. This has been the year that I finally started defining myself by the things I’ve accomplished and the things I enjoy, not the things that I don’t have or the things I’m not good at. That’s a lesson I want to share with people going forward.

There’s 2016 wrapped up neatly, let’s put on a bow on it and move on.

Ela Conf 2016

So, I went to Ela Conf in Philadelphia, PA this past weekend, and, like, I don’t even know.  I don’t even know what happened.  I’m going to try and write a blog post, but I’m also sure there’s no way to put the experience into words that properly express how amazing the weekend was.

First, some disclosure.  I knew I wanted to go to a conference, but every time I heard about one I could even think of going to, it was impossible–either registration had closed, or going would have cost me a thousand dollars, or both (usually both).  Even though I make sweet, sweet developer money now, I’m still a single mom with bills and a crapload of debt, so let’s be real: if it’s gonna cost more than a few hundred bucks to go to something, I’m not going.  I’ve heard from other people that a $400 conference ticket is “so cheap”, that the associated $800+ hotel stay is “reasonable for the venue”, and it’s totally okay to do things like fly across the country and eat $100 hotel-restaurant meals in the name of networking.  Maybe that’s true for people who aren’t nine months into their first real jobs and don’t have hundreds of thousands of dollars of debt, but for me?  Networking doesn’t keep my lights on and my kid fed.  (I guess I could set all the business cards I’d collect on fire for warmth, but that seems impractical.)

Here’s the first amazing thing about Ela: through sponsorship, they were able to pay stipends for speaker travel and childcare, and provide grants for ticket cost to any woman who applied.  In case you can’t figure out where this is going, my broke self got a ticket grant, which left me enough money to book a motel in New Jersey and buy gasoline to drive back and forth from Cleveland.

Takeaway: if a small, second-year conference in Philadelphia can get sponsorship enough to do this, why the hell can’t conferences with much more name recognition and/or budget do it, too?

Read more

Making A Case for Art History

Disclosure: I am a dual citizen of the USA and UK, who was born and raised in the United States. Unlike Dr. Yates, I did not sit AP exams, the US equivalent to A-levels. I do, however, have a BA in art history from Cleveland State University (USA) and a MA in the same from University College London (UK). Particular life circumstances forced me to make an abrupt change from academia to software development, but I will never regret my degrees or my decision to pursue them.

When I first heard about the move to cut art history A-levels, my thought was, “that’s too bad”. It wasn’t until the next morning, when the first of Art UK’s long-form blog post responses caught my eye, that I thought about it further. Significantly, the title—“My Art History isn’t ‘Soft’!”, by Dr. Donna Yates of the University of Glasgow—is what inspired me to read on. It’s a wonderfully personal post about how important early exposure to the topic is for those who go on to make it into a career, and about how important careers utilizing art history are to society as a whole.

Feeling compelled to hit the retweet button for Dr. Yates’ post, I added a comment: What I tell people again and again about my career change: the brainwork involved in art history has prepared me for many other adventures. It was just enough to get through in 140 characters, and I didn’t think much of it—then Art UK used it in a response to person who made a rude comment, the likes of which I and many other art historians have heard too many times before: “yes, because there are thousands of jobs for art historians…?”

For starters, I don’t think that person read Dr. Yates’ post, because it is about how her high school art history experience influenced her very successful archeology career, and about the importance of job fields involving art history. Also, she’ll probably take a least some issue with my added comment, which seemingly goes entirely against the point of her post (oops). However, I’d like to try and explain…

I have, for quite some time now, been very concerned and frankly rather annoyed by some of the tactics used in pushing STEM (science, technology, engineering, math) education. Although I am an advocate for more/better/earlier STEM education for young women, minorities and disadvantaged populations, I also realize that there can be too much of a good thing, and in some cases, I think we’re there. When the humanities become an afterthought, and liberal arts and soft science programs are cut in favor of STEM topics, nobody wins, and we run the risk of stifling young learners by narrowing their options when it comes to fields of study. Dr. Yates is absolutely correct when she says, “…by ‘soft’, critics don’t mean ‘too easy’, they mean ‘too fluffy’.” Art history is far from an easy subject to tackle—it involves rote memorization, critical and analytical thinking, the ability to make a good argument, highly developed communication skills… it is also extraordinarily interdisciplinary, pulling together topics from philosophy, psychology, political science, anthropology, and many, many more.  In my opinion, we should be pushing for introduction to “hard” humanities like art history in the same way we’re beginning to push basic STEM skills like programming and logic–the study of both helps to ensure they’re getting a comprehensive education that utilizes left- and right-brain thinking.

AQA says that the art history A-level has been dropped due to “the complex and specialist nature of the exams,”* but I feel their decision is a very poor one. The study of art history is more than the study of art and/or history: it’s about learning to piece together information from diverse sources of knowledge and turn that information into a constructive argument. Yes, it is complex and specialist—but that is why it is an excellent demonstrator of abilities that have value far beyond academic applications. The truth is that we need a combination of humanities and STEM to keep going—even as technology changes our world, there will always be things that computers can’t do. Just today, I had another developer thank me for writing documentation about a process we’re currently working on. This is a recurring problem—we have brilliant software engineers who can make themselves understood by machines, but ask them to explain their solution to another person, and they’re stuck. The methodologies and thought processes acquired in the study of art history have positive benefits beyond academia and humanities careers, and cultivating the ability for critical thinking, discourse and argument with humanities study at A-level will benefit future engineers and mathematicians just as much as it will future art historians. Rather than trimming humanities programs from the roster, we should be encouraging more young people to pursue them, no matter what their future career goals may be.

*https://www.theguardian.com/education/2016/oct/12/last-art-history-a-level-axed-after-michael-gove-cull-of-soft-subjects

Recent Engagements

I am so, so pleased to tell you, readers, that this past Saturday, I was on a panel of women answering attendee questions about their careers during Hyland’s first Women in Tech conference! Here’s the official press release blurb:

“Hyland will host the Women in Tech Conference on Saturday, October 8 at its headquarters in Westlake, Ohio. Working with close partners the Ohio Collaboration of Women in Computing (OCWiC) and We Can Code It, the half-day conference aims to inform women about the career opportunities within computer science and information technology (IT) professions.

Attendees will hear from female software developers, quality assurance (QA) specialists and senior IT managers who will provide insight into their technology backgrounds, what interested them about their chosen fields and the roles and responsibilities for their positions.”

Source: http://www.prweb.com/releases/2016/10/prweb13733094.htm

Feedback for the event has been overwhelmingly positive. It was a great day at Hyland for those of us who were speaking, and I’m really glad to hear that it was a great day for our attendees, too! There was a lot of good energy in the room that came from over fifty women in one place with one goal: to represent and increase the presence and visibility of women in technology. The conference opened with a talk by Brenda Kirk, Hyland’s Senior Vice President of Product & Strategry (and my big boss!), followed by a presentation by two of our developers, the Q&A panel where attendees asked us about our career paths and opportunities at Hyland, a talk by my frentor (that’s friend + mentor, for those unaware) Mel McGee of We Can Code IT, and a presentation by volunteers and attendees of the Ohio Celebration of Women in Computing (OCWiC).

For more information on Hyland, We Can Code IT and OCWiC, check out:

I was also asked to speak at a recent We Can Code IT commencement, but that’s its own blog post, and it hasn’t been written yet! I’ve been keeping busy lately and am looking forward to finally being able to give updates on all the projects I have going on, including a new website (here’s a hint: I now own http://www.mylittlecoding.com) and a new meetup group. Stay tuned. 🙂

 

Ipsy Review: September Glam Bag

Subscription boxes are all the rage right now—pay a set amount every so often, and receive a mystery package with a selection of goodies. For the past six months, I’ve been subscribed to Ipsy, which delivers a makeup pouch and five cosmetic/haircare/skincare samples for $10 a month. It’s my way of treating myself to something small and exciting—I like getting mail (who doesn’t?) and the bag contains samples of things I would otherwise never think to purchase, because I am a) cheap and b) …no, that’s it, I’m mostly just cheap. I probably will never purchase a full-size replacement for any of my Ipsy samples, because I’m cheap. Well… maybe one of the Elizabeth Mott blush they sent that one time, but the sample looks like it’s going to last awhile, so maybe not.

My problem is that I also now work in an office with a very lax dress code, so I am not driven to make myself entirely presentable every day. I show up in jeans and a hoodie every morning, and although I started off wearing makeup every day, my colleagues have now seen what I look like without it, stumbling in at 9 AM with only two cups of coffee in my system. It’s a sight they can’t unsee, so I don’t bother as much. Once that curtain comes down, it’s down forever.

The above paragraph is part of the reason why my August bag sat untouched until my September bag showed up—between working at work and working on the house, the only time I got dressed up to go out was when I went to give the commencement address at We Can Code IT. (I also put on some makeup to take a new headshot, but that doesn’t count because I didn’t leave my house.)

Therefore, I am starting a new category on this blog for the review of items in my Ipsy bags. This will actually force me to use the items in the bag, plus, it’ll help me sharpen my review skills—and maybe it will even help someone out there is looking for something like hyaluronic acid toner or shimmery pink highlighter.

Also, even though this blog is obstinately tech-related, I don’t think there’s any harm in an occasional post about makeup and skincare products. Awhile back, I wrote a post entitled “I Am Not Developer Barbie,” in which I said that being concerned with my appearance in no way detracts from my intelligence or ability to write code. Heck, if a woman somehow finds my blog because she’s searching for makeup and decides to sign up for Codecademy afterward, that’s great. If a woman in tech who doesn’t otherwise wear makeup finds my blog and decides to sign up for Ipsy, that’s great, too. I’m allowed to be a femme developer, and so is everyone else—or not. Personal freedoms, yo. Hashtag justlibertarianthings.

Read more

On Failing Gracefully

I haven’t blogged in three months.  To be honest, blogging is just another one of the things that have fallen by the wayside while I’ve been making a desperate attempt to keep my life in some semblance of order.  There has been so much going on (I’ll get to explaining why in a moment) and I’ve been trying to juggle so many things that I end up just dropping them, sometimes without even realizing it.  And so, for awhile, I’ve planned to write a post on failing gracefully–because that’s exactly what I haven’t been doing.

As a brief explanation of what I’ve been up to the past couple of months–I started having some stress about work, so I stopped working on my personal projects because at the end of the day, I was exhausted.  I also very suddenly had to move at the end of last month, into a house that needs a lot of renovation work.  I fought with my boyfriend a lot because I was so stressed out.  My dog destroyed my parents’ picture window, because she was also stressed out.  My kid started Kindergarten, so his tuition bills came due, and of course no one’s helping me with those.  To top everything off, I’d been talking about going up to Maine and backpacking for the better part of a year… and because of the move, the trip I’d been looking forward to couldn’t happen.

It’s been a pretty crappy time, to be honest.

Things came to a head the day before I had to sign the lease on the house, when my boyfriend (who is also stressed out because his business has been lagging) made the spur-of-the-moment, stress-induced decision to tell me that he couldn’t help pay the rent and I shouldn’t sign the papers.  The house is my parents’ rental property and they need a tenant to pay the mortgage on it, so if I didn’t sign the lease, my parents’ finances would take a tremendous hit–and they were already mad enough about my dog that I really had to be out of their house.  The only way I could afford the house and the rest of my bills comfortably is if my boyfriend moved in, so when he delivered this news–via Facebook Messenger, in the middle of my workday–I very calmly got up from my desk, locked myself in a stall in the womens’ restroom, wrote him a breakup text, and proceeded to completely lose my cool.

So why am I sharing all of these stressful failures with you, dear readers?  Do I expect you care about my window-eating dog, my parents’ rental house, and my boyfriend’s business ventures?  Not really.  But I do want to upfront and honest about something: I fail at things.  A lot.  And I don’t always fail gracefully.

What does it mean to fail gracefully?  In software, a one-sentence definition might be “averting catastrophe and providing a clear, understandable error message to the user when things go wrong”.  In life?  Perhaps we can emulate software–avert catastrophe, provide error message.  Instead of freaking out every time we fail at something, graceful failure means accepting that particular failure, moving past it, and learning from it.

I picked up a neat project at work, so I’m less loathsome of my office.  I signed the papers and moved into the house–and my boyfriend provided a check for half the rent.  I purchased a couple of radio barrier transmitters for my dog (like an indoor wireless fence), and she’s stopped eating windows.  I have enough money to pay for my child’s education.  None of the things I was so worried about turned out to be terrible–and, deep inside, I probably knew they weren’t going to be.  I allowed myself to catastrophize failure so much that I kept failing repeatedly, like software with no exception handling–the failure bubbled up until I broke down in the restroom.

Looking back on the last couple months, I’m a little embarrassed.  But I’ve tried to fail gracefully at my failure to handle failure–when I get stressed out over the house or work now, I ask myself if it’s really worth getting worked up over.  Most of the time, I realize that continuing to stress about it is counterproductive, and that makes it easier to either take corrective action, or to sit back and let the situation run its course.

For example, renovating the house–I pulled down wallpaper in the living room, and found that the previous homeowner (before my parents) had DIY’d some wiring.  I found this out because he had left gaping holes in the walls and stuck the wallpaper over them.  I’d been ready to paint the wall (the wallpaper had been sealed and painted over previously, but I found an unsealed spot to start peeling it up and couldn’t resist), but suddenly I was set back a week because I needed to patch large portions of wall.  Although I was distraught when it happened, the next day it was funny.  My boyfriend picked up some wall patches and compound on his way home from the office, and I put the wall back together.  Crying about it wasn’t going to fix the wall, so I laughed about it instead and did what I could to solve it.  Now that the wall is patched and painted, you can’t even tell where the holes were.

And so, gentle readers, do not be me.  Next time you experience a failure, take a step back, take a deep breath, and ask yourself if things are really as bad as they seem.  Chances are they’re really, really not.

Gettin’ Sass-y with CSS

Cascading Style Sheets came into the world 19 years ago, which is coincidentally about the time I realized I could build my own websites and put them online. Since my formative years were largely dedicated to messing around on the internet, I put in a lot of practice writing CSS in junior high and high school. Like, a lot of practice. However–still, to this very day, when I write CSS and need to figure out why something doesn’t work, it often ends with my banging my head into the desk and reminding myself that “they’re called Cascading Style Sheets because they cascade.”

Here’s what’s up: the CSS I’ve been writing hasn’t really been much different than the CSS I was writing in high school. Sure, I knew of the existance of those fancy extensions/preprocessors, but I wasn’t about to actually use them. It’s just CSS. How fancy does it need to get?

Well, I was working on my little group management app, CoLeadr–remember that? And as I was writing up the CSS for the main dashboard view, it occurred to me that it would, in fact, be really awesome if I could use variables in my stylesheet. I tend to develop in black and white and add a color scheme in later, and I was starting to see that particular stylesheet becoming a pain in the butt. So I decided to check out a CSS preprocessor.

I chose Sass (Syntactically Awesome Stylesheets), for the very grown-up and professional reason that “sass” sounds a lot more fun than “less”. So I typed “sass” into Google, and Google knew exactly what I meant because Google is magic. One line in the terminal later, and I was up and running.

There’s actually two different types of Sass file: the original indented syntax .sass, and the more recent .scss, which is similar to CSS. Both get interpreted to CSS with a simple terminal command, or you can set it up to watch individual files or entire directories for changes, and Sass will automagically interpret to CSS whenever there’s an update. I’ve been writing .scss, so I don’t have to teach myself very many new syntactical tricks. I also keep a terminal window open specifically for being able to repeat this command:

toribrenneison$ sass sass/marketing_sassy.scss marketing.css

Using variables is super easy. Sass recognizes colors, numbers, booleans and strings as variable values. Variables are declared with a dollar sign (or–someone introduced me to this and I have been in love with it since–a bling) at the start of your Sass file, and can then be used anywhere in the rest of the file. When the file is processed to CSS, Sass will fill in the variable values for whatever CSS is being compiled, so this:

$body-background-color: #ffffff;
body { background-color: $body-background-color; }

Turns into this:

body { background-color: #ffffff; }

You can see how that would make a massive CSS file a lot more manageable when it comes to changing the values for things like colors, margins/padding, borders, and the like. Speaking of massive CSS files, Sass has some handy methods for splitting your Sass into manageable chunks. A partial Sass file _starts _with _an _underscore, and although they’re not generated into CSS files with the same magic, Sass was also kind enough to give us an @import command to bring those partials in and add them to the CSS file it compiles.

Sass also gives us mixins, which are like reuseable chunks of code. Let’s snag the example from Sass’s own website and say, for example, that you want to declare a border-radius value that will appear in several different places. Since it’s best practice to declare styles with several vendor prefixes (Google webkit, Mozilla, Microsoft, Opera) so that your code has the best chance of working in all browsers, typing can get tedious pretty quickly. With a Sass mixin, you can declare once (their example uses a variable for good measure):

@mixin border-radius($radius) {
-webkit-border-radius: $radius;
-moz-border-radius: $radius;
-ms-border-radius: $radius;
border-radius: $radius;
}

And use it anywhere:

.box { @include border-radius(10px); }

Which compiles to:

.box {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
-ms-border-radius: 10px;
border-radius: 10px;
}

Something else that is totally amazing about Sass? Inheritance. Sass will let you nest your declarations, although you should beware of going too deep, which will lead to over-qualified CSS (I’m looking at you, Bootstrap). So you can nest a declaration for a line item or a link inside of the declaration for your navigation class, which keeps the Sass file easy to read. Straight-up inheritance also works: just use the @extend command, and you’ll be able to add on to already-existing declarations. To once again steal from Sass’s website, you can build “success” and “error” off of an existing “message” class:

.message {
border: 1px solid #ccc;
padding: 10px;
color: #333;
}
.success {
@extend .message;
border-color: green;
}
.error {
@extend .message;
border-color: red;
}

Will turn into:

.message, .success, .error {
border: 1px solid #cccccc;
padding: 10px;
color: #333;
}
.success {
border-color: green;
}
.error {
border-color: red;
}

Sass will also do some math for you, but since I’m terrible at math, I’ve left that alone. I like to use a grid system like Bootstrap/Foundation/Skeleton to do my layouts, so I don’t really need Sass to do crazy layout calculations for me, anyway–I can see the value in it, of course, but it’s not something I’m ready to try and use myself.

Would I recommend Sass to a friend? I certainly would, and I’m doing it right now. Perhaps, at some point, I’ll try and play around with Less. But for now, I’m getting Sass-y, and loving it.

You can find documentation and read more about Sass by visiting the official website: sass-lang.com.

Motivation, Part I: Find Yourself, And Be That.

It is weird being a software developer with a MA. It is super weird being a software developer with a MA in art history.  And it is super ultra weird being a software developer with a MA in art history whose research interests lie almost entirely in twentieth-century German sociopolitical propaganda.

It’s been seven months since I started my programming bootcamp.  In those past seven months, I have had to explain to a lot of people how I came to be a developer with a graduate degree in one of the most degraded humanities subjects available.  We’ve all read it or heart it, and probably some of you have said it: “if people didn’t spend thousands of dollars getting art history degrees and studied something that would get them a job, we wouldn’t have a student loan crisis/an employment crisis/war in the Middle East/child hunger/fascism/the threat of nuclear armageddon”.  What people don’t realize is that art history is, in fact, really freaking hard.  I’m not going to go into detail, but art history is basically requires a lot of very twisty thinking, attention to detail, and the ability to put together tiny bits and pieces to make a compelling argument for a whole conclusion.  Anyway, I don’t think anyone should get ripped on for going to college, so when people try to pick this fight with me, I shut them down as quickly as possible.  It’s not just because I’m defending my major, though–it’s because I’m defending me.

When someone picks on my choice of degree, what they’re really doing is calling me an idiot.  Why would any smart person spend ten years of their life and go into an un-payable amount of debt for an art history degree?  I’m obviously not that bright if this is the path I’ve taken, right?  For those people, I have three words: oh, hell no.

This is the point of this post: in order to really find yourself, you have to tackle your hard truths.  It takes courage to grow up and become who you really are (e.e. cummings’s words, not mine).  One of my hard truths was the realization that I was letting people make me feel stupid, and that’s when I decided that no one would ever get to call me an idiot ever again.  I was in a relationship with a person who didn’t respect me and kept me dependent on them by making me feel stupid and incapable.  In an effort not to displease all of our mutual friends (who I realize now were not my friends) or my parents, I kept my mouth shut and continued feeling like an idiot for way longer than I should have.  It was only when the dichotomy between who I was when I was in class and who I was when I was at home reached crazy levels of different that I realized what was going on.  I mentioned to one of my friends that my partner was having yet another episode where they’d refused to acknowledge me for the past day and a half because I’d done something they didn’t like, and my friend just said, “Tori–that’s not okay.  What the [expletive] is going on?”

If you don’t like the place you’re in, go somewhere else.  I don’t physically mean pack up and move–that’s time-consuming, very expensive, and probably a last-ditch effort; not everyone can afford that.  What I mean is that you can’t afford to be a victim of your circumstances.  Getting away from that relationship cost me a lot, both literally (I had been out of the employment game for awhile) and figuratively (I lost friends, my parents yelled at me, etc)–but I am so much happier now that even my crummy days are better than the good days I had with that particular person.  Sometimes, you have to accept that you are spinning your wheels and not getting anywhere–and after you accept that, you have to get out of the car and keep going on foot.  It’ll be hard, and sometimes it will seem as though it’s not worth it, but things will only get better if you make them get better.

I had to reconsider my entire life after getting out of that relationship–but I’m glad I did it.  The best thing you can do for yourself is find what excites you and defend it wholeheartedly.  Think about where you are and where you want to be–and then make a priority to get where you want to be.  I filtered myself down to “I really love making cool stuff and sharing it with people,” and that’s how I got to be a software developer.  I moved back in with my parents, worked retail, updated the coding skills I already had, then pulled the trigger on going through bootcamp in order to get my first job.  In my spare time, I draw My Little Ponies, because I like My Little Ponies.  I go hiking with my dog, because I like hiking and dogs.  I like to have bacon and avocado on my cheeseburgers, and never again will I put myself in a situation where someone makes me feel like I can’t get a bacon avocado burger because bacon and avocado is an unnecessary expense.  I like bacon avocado burgers, dangit, and I will spend an extra two dollars and forty-nine cents of my money on burger toppings if I want to!

Once you determine where you want to be, it’s your responsibility to get yourself there. There’s no room for hand-holding; you’re ultimately the one responsible for your own happiness. This doesn’t mean that there won’t be people along for the journey (more on that in the next post), it just means you have to take responsibility for everything you do—which includes success as well as failure. You are the only real constant in your own life–and you’ve got to own up to your own imperfections and stop trying to be flawless. For me, this meant accepting that I have a tendency to become frustrated and overreact.  It’s still something that I struggle with (especially if I’m desperate–I totally did this during a job interview when I was totally broke and really needed the job, and bombed the interview), but I’m getting better.  That’s another lesson: it’s okay to fail, so long as you learn from your failure.  This can be just as hard as picking yourself up and moving on from things that don’t benefit you, because it’s easy to fall into the trap of thinking all you can do is fail.  When that happens, it’s okay to give yourself a break–go get a bacon avocado burger, sit out the next round, and try again when you’re ready.  The important thing is that you eventually get back up and try again.  When I want to give up, I think about how I’ll feel if I let myself give up: lousy.  You’ve got to determine that the hardness is better than feeling lousy–you’ve got to decide that you want success more than your’e afraid of failure.

Here’s my point: so long as you’ve got yourself, no one can stop you.  There will be people who are not interested in your success–but guess what?  You don’t need those people in your life.  Love yourself enough to really go after what you want, and the right people will find you.  We’ll talk about that in my next post. 🙂

 

If you’re looking for a little motivation, I’ve made a Pinterest board to go along with this post.  You can visit it by clicking [here], and feel free to follow it on Pinterest as I’ll be updating it as I find new material!