And surprise surprise, I ended up at a company that’s as almost as excited about me blogging about software engineering as I am. I published a post for them a few days ago about working with your PATH, what the PATH system variable is, and how to access and change it.
This was a bit of an enduring mystery for me at Hackbright – this vital thing that comes up in so many tutorials but which so many smart, willing people had a surprisingly hard time explaining. I started thinking of it as everything and nothing, the alpha and the omega.
Late last fall, gainfully employed and feeling sillier by the day for not having mastered this important concept, I began a campaign of badgering my coworkers on Slack until I cobbled together a working explanation of what PATH is and what you might need to do with it. One coworker noted, after publishing, that this is a bash-specific explanation (given the system files I mention), and he is of course completely correct.
So do check out my bash-specific PATH tutorial, with the expectation that you people who use zsh and other fancy-pants shells will have to do a little adapting in your head. I’m sure you’re used to that anyway.
The photo is one from my recent trip to Sweden. I like to visit cemeteries when I travel; this is a photo from Skogskyrkogården, which was beautiful and worth a long-ish metro ride.
This one goes out to the new people who are, as I described myself a few minutes ago, “still building context.”
This error is not this. This error is not that. This is error is that you, perhaps like me, restarted your system recently and didn’t restart Postgres.app.
“I can’t reach the server,” it says. Maybe you, like me, will get stuck on the port thing, thinking that server.py is having some new and terribly exotic error. Server.py is running. What is its problem? It’s RIGHT THERE.
Restart your database server. (Or, y’know, start it.)
Then change your preferences so PostgreSQL starts after login for the duration of your project.
This blog post is brought to you by me wishing that I’d found the perfect, straightforward answer to this simple-ass question. Port 5432: not a part of server.py. No, it is Postgres. Just Postgres.
Now you know. Get it.
For Google fu, here’s the relevant text of the screencap above:
OperationalError: (psycopg2.OperationalError) could not connect to server: Connection refused Is the server running on host “localhost” (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host “localhost” (fe80::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host “localhost” (127.0.0.1) and accepting TCP/IP connections on port 5432?
Consider this picture your moment of zen. We’re about to dive into nightmare territory.
In the first week of class, I was pair programming, and we’d reached the point (one of fairly dozens that day) of editing and troubleshooting. We use Sublime Text 2, something I’m fairly used to at this point; what I wasn’t used to was Ubuntu. I hit an F key without meaning to; suddenly, our window maximized, and neither double-clicking nor dragging the top bar of the window down made it shrink. The maximized Sublime stared at us from two mirrored monitors, waiting.
So I began tapping the F keys again, one by one, thinking it would ultimately undo what I’d done, and I might learn a couple shortcuts too. This is a practice that has served me fairly well for the last 20-odd years, with not a casualty to speak of.
Til that day, anyway.
Somewhere around F-8 or F-9, all of our lines of code rearranged themselves. Instead of our 40-plus lines of tidily indented work, they had formed a perverse pyramid, blank rows at the top, and the rest below in order of descending indentation, alphabetized within those length blocks. Under the edit menu, undo was greyed out.
I think – I think – that I managed not to actually say “What even the fuck?” in front of my pair. (We were all still using people manners then; now there’s a post-it in one of the bathrooms telling you to drink more water, lest you get constipated, a problematic situation the post-it writer knows very well, ok?)
I called over my advisor, explained the situation, and watched as she tried a few of my steps again. No undo. No solution. Nothing.
She frowned and said words that were not meant to be an indictment but were nonetheless: when was the last time you committed?
It was about 5:50 pm. We’d last committed after we’d finished our last exercise. You know, at 1 pm.
“Well,” she said finally, rising from the keyboard. “You learned something.”
“I did,” I told her. “And I’m not – well, I’m not proud. But it’s not often that a person really manages to break something beyond repair with computers. It’s… notable.”
She shrugged and went to help less hapless people. I apologized profusely to my pair, who was altogether lovely about it.
I thought for a moment and closed Sublime. I counted to three and reopened it.
Our properly ordered, fully functional Python file was restored.
I’m not sure I took a whole breath in before I completed a commit on it. And now I, like all of us in our time, am a committing zealot. Early, often, excessively.
I don’t recommend being an anxious person. But for certain qualities? I totally recommend hiring them.
Here in week five, I have firmly established myself at Hackbright as the person with a UX background. (I have probably also established myself as the person who would like to tell you again that she has a UX background.) To give myself an exercise in applying my older skills to my newer ones and to approach this project in the way that I know best, I’m planning out a Very UX-y Hackbright Final Project.
Step one is a survey. Because of the limits of my time and budget (as in, I’m not paying anyone for this, and I do believe UX participant work should be compensated – at least if someone is making money from the product using the results), I knew I wouldn’t get anything resembling a scientific sample. Even so, I knew I’d feel better prioritizing my semi-planned product features with even a general sense of how people who are not me would use a web app like the one I’ll be producing through August.
In this post, I’ll explain how I came up with the idea, why I find it interesting, how I decided to use a survey to verify and prioritize my feelings as the unavoidable first user, and the principles I used to craft my short, very to-the-point survey. Read on.
Fish Waffles and Inspiration
My plan from the beginning, from before Hackbright was a possibility in my mind at all, has been to create a food truck tracking app. I came up with this idea in Seattle last year, sitting on a grassy slope with my boyfriend, eating a fish-shaped waffle. I’d never seen a fish-shaped waffle before, let alone knew they were something I could buy from a van within the city I’d occupied for nearly a decade. This bothered me, because I like to think I know most of the awesome things the places I live have to offer. Why wasn’t there an app for this? Why wasn’t this information more accessible, considering the ways I do research?
I originally thought of a mobile app, and I still have some interest in eventually going that direction with my work. We shall see. But when I was accepted to Hackbright and learned more about how their curriculum works, I never doubted what I would do. I would build the food truck web app that I wanted to see in the world.
Before we get into the actual coding part (oh, next week), I’m going to do as much research as I reasonably can. I’ll soon be reviewing the existing apps out there, web and mobile, to see what features are considered typical and expected, what information’s out there, and what seems to be working. But first: my survey. I kept it simple so that I wouldn’t be asking too much of people’s goodwill. This is a fairly central tenet of UX research done without participant compensation: make it fast, make it easy, and thank profusely. (Or maybe just a fairly central tenet of being a polite, respectful person asking people for favors.)
The Survey and My Strategy
I used a Google Forms survey to do this, passing the link via social media and hoping my friends would both take it and share it. (Many of them did. Thanks, friends.) I explained the scope of my project (that it’s for school; what the school is) and said some more grateful things because I was and am grateful.
The Survey Itself
1. How often do you eat at a food truck?
-Once a week
-Once a month
-Once every six months
-Once a year
-I’ve never eaten at a food truck
2. How do you find food trucks to visit?
–The truck’s Facebook page
–A mobile app
–Find them on the street
–At a gathering or festival
3. What do you need to know about food trucks to plan a visit?
–Type of food
–Location that day
–Schedule for future
–Method of payment
4. What features would you like a food truck tracking app to have?
–Text listings with search
–Search by food type
–Search by price
–Links to truck social media or websites
These were all required. The following were open-text fields and were not required.
What is your favorite truck, and what city is it in?
What is your favorite food truck-finding resource?
What is your favorite app or resource for finding places to eat?
What’s the best food truck pun name you’ve ever heard?
I got 127 responses. Not bad! I’d decided I’d be pretty thrilled at 100.
How I Made My Choices
Here are a few things I considered when putting this together:
I wanted to be as brief as possible to avoid having people open the survey, think, “Oh hell no,” and close it without completing it. I’m pretty generous with my time on student surveys (UCD school will do that to you), but I have definitely said nope to too-long ones.
I wanted a clear picture of feature/information priorities, hence the “choose all that interest you” and “choose the most important one” questions.
I wanted to be able to correlate feature/information priorities to frequency of food truck habits – a person who has been to a food truck once will probably not have as clear a view of the relevant information as someone who seeks them out regularly.
I included other fields to ensure that respondent options were not limited to my own possibly incomplete view of the relevant information and features.
I wanted to expand my list of sites, apps, and other resources to look at as I get deeper into planning my project.
I like puns and like including an open opportunity for survey respondents to have a little fun.
I’m currently working on a Python program that will tally my responses. It would probably be easier to just use Excel or certain other existing tools, but I want the practice, and I get to have some fun with classes and objects while I do it. So: CSV and my own Python efforts it is. Coming up, I’ll post about my conclusions and observations and how it effects my features list and how I set my priorities.*
*Aside from the simple question of, “Can this fit in five weeks?” and “Is this strictly relevant to what I want to learn and demonstrate that I have learned?”
P.S. The image is from the book that gave me the first exposure I ever had to food trucks. As I recall, totally worth the time.
I knew before coming to school that the Hackbright day leaned heavily on pair programming. During the first five weeks, days unfurl like this:
More pair programming
Profit? Or collapse onto BART. One of those.
I am told that it’s not a super common practice for tech companies, or at least not outside of training or special projects. But I know that people learn better if they have to learn, discuss, and then teach. I know that the general level of knowledge in the room rises if we have to work through problems together, combining what we know to make a greater, more effective whole. One of the reasons I decided to go to a school like this is that I have a well-documented tendency to read about how to make this loop or that data structure, nod to myself with some satisfaction, consider it learned, and move on.
That is a great way to learn some vocabulary terms; it is a piss-poor way to learn programming.
And it’s part of why I decided to go to school rather than going my usual autodidact way. I knew that, with the structure of school and the requirements of a major final project, I would have to read, digest, and then practice. I wouldn’t really learn anything otherwise. And that meant pair programming, with its constant verbalizing, sharing of knowledge, and immediate application of what we’d learned in lecture. Sounded great to me. Sign me up and tell me where to send the deposit.
I was right about every bit of it. Pair programming is a stellar communication tool, and, when paired with available expert help, it’s like having your own half-a-tutor. You learn things from them; you have to explain things to them. You really learn.
That said, I’m pretty excited to get to the second half of my program, because it means less pair programming and more time slogging through my project by myself. And it is absolutely not because of the people I’ve been paired with, who have all had good manners and and the good grace to teach me things.
I hate pair programming because I am a hard introvert with only so much social energy in a given day. The first week at Hackbright, I met about 40 new people, found myself in a new city where I have only two friends, and also had to talk through assignments with a near-stranger for close to four hours a day.
I’m surprised I didn’t actually melt into an Odo-like puddle in a bucket.
I’ve kvetched about this to my advisor. To friends. To fellow exhausted Hackbright students. And yet I’d never advise them to change this part of the curriculum, because I really can’t think of a different, better approach.
Instead, I’ve just dialed back how social I am. I have more lunches alone; I take quiet texting breaks. I don’t go out very much. And it’s a bummer, because I have access to 34 other aspiring software engineers, and so many of them are so very interesting.
But I can hear their life stories while I eat my reheated pizza, or I can have brain to solve programming problems. I can’t have both. So I retreat and read, and I use my social energy very carefully.
Five days a week, I go to class with scientists and electrical engineers and nurses and artists and people from fields in between and beyond. People at Hackbright take a lot of different paths to get there, which is one of my favorite things about the people you meet at continuing ed programs: the people are always so varied and so dedicated. The common ground at Hackbright is the thematic stuff, and it usually goes as follows:
The Hackbrighter wants to get paid.
They want to be sought after by employers who want to pay them.
They want to work on something that matters rather than feeling perpetually on the periphery.
They’ve always had some kind of technical ability or affinity and would like to see where it could take them.
I’m no different. I came to Hackbright from a background of online content and, later, UX and usability; my last job, which I adored, was UX content strategist. I realized, though, that there was a force at work on my career, which I named the Inexorable Drift Toward Marketing. It’s inevitable: you can use words? You are good at explaining things? On the internet? Then the related jobs usually see you explaining things made by one third party so that someone from another third party can buy them. Unsurprisingly, the money is where the people that might buy things are.
Sometimes, buying things is helpful and necessary; sometimes, guiding people to buying the thing they need feels like a useful service to provide the world. But even though those moments exist, content is forever undervalued, the first thing cut from a budget, the element of a project brought in at the last minute, so easy to neglect (even though it is, genuinely, a crucial part of your website, your company’s brand and voice, or your system).
Separate of that, I’d come to realize that I might have an ability, an important one, that had never really been used: technology doesn’t scare me. Programming, with a reasonable amount of effort on my part, makes sense to me. And I’m a dogged troubleshooter who will pursue the thing until it works and works well, refining and redoing until it’s as it needs to be or slightly better.
It’s a quality that’s served me well as a writer, but it’s one that could take me further in a different field. And so, early this year, exhausted by a then-fruitless year-long job search, I applied to Hackbright. I took an intro to computer science class at Code Fellows back in Seattle, which was the last thing I needed to convince myself that I really-no-seriously was interested in this thing. Had I not made it into Hackbright (did you know about their acceptance rate? It is low), I would’ve pursued Python or iOS development there.
My former boss (and current friend) asked me how much more of a unicorn I needed to be. I said I wanted to be an eminently employable one. I can create a content strategy, write and interpret a survey, do interviews, create user journeys, make smart and effective editorial recommendations for companies large and small, originate and grow a company’s social media presence, rewrite a company’s entire website, create genuinely useful company documentation, establish a vocabulary for a niche industry, and host an industry meet-up. But I also want to be able to make the things that make the world run. I want to materialize my own awesome ideas. I want to fully participate in the world I’ve grown up in. And so I am here.
What’s next? I’ll write about why I chose single-gender education, something I never considered for high school or college. I’ll tell you about learning something like this in a ten-week program (which is, fortunately, not a boot camp). I’ll write about introvert overload and how programming somehow completely changes your metabolism. I’ll show you progress on my project, which I’ll be starting in earnest in a couple of weeks.
And I’ll write about my week-by-week experience, starting in week four, which I am just starting as I write this. I wanted to write sooner, but honestly, I was way too tired to start before now.
And, in the meantime, if you want a hyperarticulate, overly literate, UX-practicing junior Python dev for your team? Let’s talk; I’ll be available in September.