Confession: I haven’t touched code outside of work in weeks. I’ve spent most of my free time recharging. Snuggling cats, hanging out with friends, being a slug on the couch and binge watching tv. All of these things lately have been much more exciting to me than poking at code that isn’t work related. I’m not the only one who feels this way. But I also know that I’m in the minority of people who don’t have a lot of extenuating circumstances surrounding their free time. I don’t have a family to take care of (unless you count my cats and my friends – which I do).
It seems to be that we as engineers are expected to code all the time. I myself used to want to “live and breathe code”, but that takes an awful lot of brain power and I’m not sure the type of person it makes me. You see, I am firmly in agreement that coding feels like a foreign language (side note: I don’t agree with the arguments that coding should count as a foreign language requirement, they definitely fill different niches in that regard). And spending your whole working life translating a foreign language is exhausting. Don’t get me wrong sometimes it’s AWESOME that I can think of something that would be useful for me to have and then I can go build it, but after I’ve spent at least 8 hours in at least one foreign language I just want to go home and let my brain thing in English for a while.
What’s especially hard (for me at least) is that I feel like I’m slacking if I just use technologies and frameworks I already know about in personal projects. If I’m going to be working on a personal project I should be learning something, right? So I get super sidetracked and slowed down learning all sorts of new things and then by the time I get back to the task at hand I’m exhausted and want no part of it.
I think probably the best way for me to handle this is to try to get back into it with just fun projects, projects that I don’t have to research, the just have to get built. But I also have to allow myself the possibility that personal projects might just not be for me. I can get my coding kicks outside of work by mentoring, attending conferences and even just reading about code.
Time to add another weekly to the mix. At my office I generally work from home on Fridays because it was a tradition before me and who am I to break a tradition? At my last job it was Thursdays, but it’s awesome that most eng jobs understand and allow for the space to get shit done with out distractions.
As part of my Fridays from now on, I’d like to carve a bit out of my day and just go down a rabbit hole. Most of them will be tech related (most of which will be frontend) but I’m not going to put a label on this segment other than the fact that it will probably not be quite as detailed (all though I say that now and then this one turned out to be a monster). Some weeks it might even be me just throwing up some links and commenting.
So lets start easy this week by opening the Pandora’s box that is Node.js. In my scant spare time I’m working on a side project that is essentially just an API with some munging of data. HOWEVER, I’ve grown bored with my standard Node/Express workflow and wonder if there’s anything newer or more exciting to play with. Lets find out together shall we?
So I’ve heard of some other alternatives, but haven’t really dove into Node stacks in a while because I’ve been a Python girl up until recently. So, let’s be lame and google alternatives to express.js (what, you were expecting high-tech sleuthing?). Immediately the apparent new darling Koa is all up in my grill. So Koa is all ES6 ES2015 – whatever I’m sticking with ES6, it’s not like we’re all going to magically start using ES2015 in 2015 anyway. The initial footprint is small, but you can’t do much with it without additional middleware.
Koa has always been something that I’ve kinda prodded at with a stick and never done much with. Each time I read about it I find it more and more interesting, but it seems like it would be overly complex for my small personal stuff. Besides being ES6 opinionated, you’re basically free to add whatever you want. You can use established middleware or roll your own without too much effort. For my small side project though, I just don’t have the energy to research yet another step of deciding which middleware to use or creating it all from scratch.
And then there’s the other standard in a trifecta of frameworks that everyone talks about called Hapi. I have never gone beyond looking at the Hapi documentation and going “nope!” but that’s just a personal opinion because I just don’t like the look of using objects everywhere for everything. It gives me Backbone flashbacks and I just can’t handle it. So I don’t have much to say about Hapi, but will take this to an aside that I enjoy how much like art coding is. I can have feelings about the tools I use. It may be amazing for someone else, but if I’m just not feeling it, I generally have other options.
So lets narrow it down, what I really want is an API layer. I don’t care as much about rendering pages. So lets keep going. A couple of new contenders – Restify and Loopback. Both seem decent, but I’m a sucker for not having to do as much work and we use Ruby at my new job so I love it when I don’t have to define all of my routes by hand. Loopback is also a part of something called StrongLoop, which I’ll admit I haven’t heard of before but seems to have some Node enterprise and monitoring apps. Oh… and it’s built atop Express. We have come full circle my old friend.
Alright, lets walk through the tutorial. I have mixed feelings about generators since they usually throw waaaaaay more at me than I will ever need, but FOR SCIENCE!
I told you it was for science. Alright, so before I create any models, I decided to poke around at the code generated. And I am immediately vaguely displeased. It includes a .editorconfig file, which while in sync with the configuration settings I generally use seems annoying to impose on someone. Also it generated a looooot of files. They seem orderly though, so lets press on.
And now I’m lost. This is not in the tutorial. -1 for out of date tutorial! Time to break out the docs!
In general, use PersistedModel as the base model when you want to store your data in a database using a connector such as MySQL or MongoDB. Use Model as the base for models that don’t have CRUD semantics, for example, using connectors such as SOAP and REST.
+5 for helpful docs. The other models are actually pretty cool too and I could see myself using them quite a bit in larger applications, but for now lets stick with PersistedModel.
And there you have it! I now have a person model! It’s some pretty json that’s easy to read and understand. So in summary: Loopback/StrongLoop reminds me immensely of Rails, which I’m OK with. I think I will continue to play with it, but so far it gets a thumbs up from me.
As an aside: For those wondering, I’m using the Peppermint theme with a basic bash terminal, though I do recommend zsh/ohmyzsh and use that at work. I also use Sublime Text with the theme & color scheme itg.flat – Dark.
Last week I helped out at an #ILookLikeAnEngineer event. There have been lots of write ups about the event, but I think my favorite, and not coincidentally the most critical I’ve read, was from Re/code. The last paragraph in particular sums up my mixed feelings about the event.
#ILookLikeAnEngineer was a nice gathering for people with first-hand knowledge of the problem. But having any lasting impact before the next Internet meme sucks all the air out of the room will require a bigger meeting place and a different guest list.
I understand the need to have safe spaces for underrepresented people, because that shit can be draining out in the real world. But if we only ever stand in an echo chamber then we’re just making ourselves feel good and sticking our heads in the sand (to awkwardly mix metaphors).
As a general rule, I have stayed away from women in tech meet-ups that only serve as a place to vent. I would rather spend my free time exhausting myself helping others to learn. To help women get good and get proud of their own accomplishments. I’d rather spend my time mentoring at an all women hackathon or one on one mentorship or helping out our interns.
I say all of this about my mentoring because I worry about coming off as “I got mine” or making it sound like we just all need to “lean in”. I will admit that a lot of my engineering career has involved the lean in philosophy for myself. I worked my ass off at a boot camp that only had 6 women. Interviewed at a bunch of places that were all dudes and ended up by sheer luck at a fairly diverse first engineering job.
Before all of that though, I dropped out of the computer science program in college because I was the last woman standing. I still regret that decision, but it has made me tougher. I’m not willing to compromise now. If I’m the only woman in the room, I’m still going to do my best work. I’m still going to work my ass off as an engineer and continue to help women into the space because I believe in strength in numbers.
I’m not sure where this puts me in the spectrum of engineering feminism, which I think is my main problem. I find dudes easier to talk to in general. My favorite engineer/mentor/friend is a guy. The only managers I’ve ever had an issue with about my role as a woman in tech were other women. So I continue to follow the path I’ve set out for myself. Blogging about culture, mentoring women, learning and being the best engineer I can. Every once in a while I poke my head up to see where other women in tech fall on their paths, but none of their paths look like mine.
So this feels like a lead up to some great revelation, but sorry to disappoint you. I don’t have one. I plan on continuing to “do me”. Helping out where I can, being selfish when I need to be, and continuing to grow as an engineer. Also I really enjoy off-color jokes – does that make me a bad feminist?
We had a super awesome intern working with us over the summer (I often referred to her as “my” intern, which wasn’t 100% true, but as the one on the team who had done a lot of mentoring before, I felt very mamma bear about the situation). She did some cool things and had done some cool work on her own before working with us but when she needed help and was frustrated out of her mind with a problem (like many of us still often are) it usually ended up being easy enough for a fresh set of eyes to spot the problem.
These are the times when having a mentor or even just a partner in crime who’s willing to give a quick code review make all the difference. Unfortunately not all of us get the luxury of a second set of eyes, so we fumble along adding and deleting things until we just throw it all away and start over (been there) or change so many things that one of them magically works but you don’t actually learn anything because what the hell was the problem in the first place (also been there). So for my fresh coder friends, I thought I’d throw together a quick cheat sheet of the things I see most often in my and my mentees code. I bet with any time spent coding you can probably guess a few.
This one hits where it hurts, because it is a stupid mistake. A variable named “container” is not the same variable as “contanier” (and is also an awful, very vague variable name, but that’s a different lesson). This will drive you nuts, I promise – it’s currently driving my spellchecker nuts as I type. Everyone does this. Everyone. Promise. Even that awful person you just had a horrible first interview with and now will never have the job of your dreams, yep, he’s misspelled “first” I bet. The Quick Fix: If you’re using an IDE (think Sublime Text, or Atom or whatever the kids are using these days). It’s pretty easy to spot. When you go to auto complete a variable starting with “cont” you will see two options and one of them will be not what you want. Go head and do a search for that errant misspelling and see where else it’s been used in the codebase and change it (unless some jerk really did have a variable named “contanier” in some obscure file, then change it and mock him for the next year).
This can technically mean a lot of things, but I’m talking about the “if not this or that do this” variety. Unsurprisingly, when you spell it out “If not A and not B” sounds much different from “If not A or not B”, but when quickly writing code it’s easy to forget. The Quick Fix: Say it out loud! Write out your logic flow using words! Do something that’s easier for your brain to see flaws in than the foreign language that is your code.
Blech, straightforward and an oldie but a goodie. Syntax errors are common. Everything from a typo to a misunderstanding of how a function works can lead to them. Thankfully most languages have been nice enough to also make them the easiest to solve. The Quick Fix: Learn how to read those stupid error messages. Each language is usually a little different, but most of them follow a pattern. They generally have a complicated error message and a line number. It’s like they’re giving you the answer for free! Check out that line number, does something look funny? Fix and try again. Does it all look, a-ok? Start googling that esoteric error message. I promise you’re not the first person to accidentally divide by 0.
Incorrectly nested divs
This one is a bit frontend specific but you are a lucky person if you’ve never accidentally had this madness in your codebase, especially frustrating with things like Angular scope. Missing that end div tag or adding one too many in the wrong place can be a nightmare. The Quick Fix: Always always use good HTML hygiene, indent for every new block.
This is a bit of a catch-all and a desperate plea to learn some git basics. Sometimes I’ll go wandering down a rabbit hole and not come up for air until I’ve changed at least four files. This is Not. Good. Do as I say and not as I do kids. This will lead to massive frustration when one part is making the entire thing fail or not compile. But shoot, you just made changes to four major files. So now it will take you at least 4x longer than it took to write to go back and debug. Make incremental changes, save progress with git. It’s like a video game – no one wants to do the boss battle again!
We can all make these same mistakes. In fact, I’m positive we all do, but for those of us who’ve been doing this a few years we can just shrug and groan and move on with our day. And this is probably that single point where I see newer engineers go off the rails. They feel dumb and like they’ll never be as smart as their coworkers or mentors. I know this because I remember it and I’ve seen it in people I mentor. My favorite way of taking the edge off, especially when they come up immediately on the defensive with an “I know this is probably stupid, but..” is to help them but then share a time when I’d done the exact same thing. We all had to learn this shit, some of us have just been learning it for longer (and have the dyed grey hairs to show for it).
Things have been quiet here at casa de Lindsey which is good for me, but probably not as exciting for the people who (maybe, sometimes?) read this thing. Since April I’ve been relearning why I love being a software engineer in a supportive and awesome culture at Scripted. It’s a small tight-knit team and I was a little worried about coming in as a newbie to a solid team but they’re amazingly lovely people and I love learning with them and from them. Front-end only land has been so busy I still haven’t had time to really even touch my first love of backend APIs (which would require me to learn Rails to do it justice at Scripted) but I haven’t really mourned that loss. Instead as one half of a front-end team of two I’m running around like crazy helping our backend/full-stack team be better front-end engineers, sitting down with our designer to craft better UX and handholding our marketing team through WordPress template changes when the starts align correctly.
Which brings me to my continued sermon on mentoring/pair programming and how much I luuuuuurve it. I keep reiterating it, but I’ll continue to reiterate. I love mentoring other engineers, I love pairing with people. It can be super awkward at first, because even if you’re the one who is supposed to be mentoring you won’t have all the answers. But that’s not the point! The point is for you to foster learning, for you as well as the other person. Software engineering is not a perfect set of knowledge that you can learn once and then just churn out the same thing over and over, but it’s also not always about going down the rabbit hole of discovery (especially if you have to earn a living writing code for a living). Mentoring and pairing almost feels like cheating to me, because I don’t have to solve all the problems myself. I might not even have to come up with the original idea for something, just help refine it and still get to take partial (but deserved) credit in the end.
Also there are so1 many2 better3 resources than my stream of consciousness musing on pair programming (and a MAJOR SHOUTOUT to a study on the benefits of pair programming for women – hint: it benefits everyone). Please check them out, give it a shot if you can. It is really, really hard at first and it’s definitely not for everyone but for me and most of my pairs it just takes so much stress of the engineering cycle.
My other hope in this transition is to get back into mentoring more. Working in Mountain View and attempting to mentor in SF was super draining on me, but now that I’ll be working in SF, I want to pour more of my free time back into mentoring and helping others join this awesome ride that is the tech industry. So I’ll be spending some time to think about how to approach that aspect.
Lately I’ve been interacting more and more with people trying to break into the tech industry. It’s something I’m keenly aware of as a recent wall breaker myself and my general desire to mentor and champion other people to do what they want.
I recently had the privilege with my co-host and awesome, awesome person Jennie to lead a talk for Udacity Nanodegree students on how to get into the industry and how to make connections/get a job/etc. I wish I could link you all to it, but it’s behind a paywall currently. Lies! Youtube video:
The talk itself was pretty standard:
Network, network, network.
Recruiters can be your friend/spy.
People are generally nice, especially when you don’t spam them and actually ask them things that are relevant to them.
But between that and a lot of the recentarticles on tech interviewing/culture (which I’m not going to give my opinion on in this post as it’s nuanced and hard, but spoiler: pair programming interviews are the bomb) I’m a little dissatisfied that I didn’t mention my number one rule for finding a job:
CULTURE IS THE MOST IMPORTANT FACTOR
I’m not going to pass judgement on different cultures as people are, shockingly, different. Just know that if you have the luxury, which thankfully is often the case in tech, please, please don’t choose a job just for prestige or some weird convoluted inner turmoil. Make sure your coworkers are rad. You will need them, a lot. Many of my best friends now are former/current coworkers. We have nerdy parties, we play video games, we send each other stupid cat gifs (okay, that’s just me sending them out to everyone else, but they appreciate them damn it!), but more importantly they have my back. They can help me troubleshoot stupid mistakes or understand my inner rage at a feature or just geek out with me over the hot new programming hotness.
I think a person I follow on Twitter put it best when he said: