Project Season or: How I learned to take breaks for better efficiency

Hello friends! I will begin my ninth week of Hackbright tomorrow. :) I’m about 75% of the way done. This makes me both excited and sad. Excited to begin my job search and eventual career as a developer. Sad because I deeply like and care about all my peers and instructors at Hackbright, and we won’t be seeing each other as often. Currently, we’re around each other five days a week for at least eight hours each day. It’s like a catalyst for putting relationships on the fast track.

So, I’ve been MIA for the past five weeks — mostly because of PROJECT SEASON. Project season begins on week six and ends in the middle of week ten. During this time, Hackbrighters independently work on building a web application of their own conception and design. A typical day looks like:

10am-11:45am: Lecture

11:45–11:55: Bio Break (find snack/stretch/use restroom)

11:55–12:05: Scrum*

12:05–1pm: Project Time

1pm-2pm: Lunch

2pm-6pm: Project Time

*Scrum is basically meeting in small groups to quickly discuss what we did yesterday and what we plan on working on today.

I’ve been keeping a very small journal to track what I plan on accomplishing in a day, what blockers I encounter (mostly debugging), and what I realistically completed by the end of the day. This helps me plan on what to work on the following day and also gives me an idea of how quickly I work on different aspects of a project — some people like to call this their personal velocity. It’s surprising to see what you think you’ll do in maybe a few hours, but end up taking only half an hour. It’s equally surprising to encounter a feature you think will take an hour, but takes an entire day.

If I ever get super stuck, I know I can ask an instructor for help, but we’re encouraged to problem solve on our own. I confess, I relied on instructor help a lot during the first week of project season, but lately they’ve begun doing less hand holding and more quick hints followed by immediate retreat. I think they’re starting to push us all out of the nest. :)

I’ve learned SO MUCH from project season. One of my biggest lessons: TAKE BREAKS. If I’m staring at a problem and I’ve been stuck for a significant amount of time, I’ll often convince myself to stay seated and push through the block until it works. WRONG. This is definitely the moment when I need to get up, walk away from the problem and do something completely different. I’ll take 15–30 mins and go for a walk, or color in my favorite coloring book, or both. When I return to my computer and try solving the problem again, I usually figure it out within ten minutes. This is hugely more efficient than when I don’t take the break and continue staring at the problem, which can take anywhere between 1.5–4 hours. I KNOW, RIGHT?! I’m not exaggerating. Computer programming has taught me to log data at every opportunity. I have the numbers to prove this. :)

I’ve got loads more to catch y’all up on, but for now, lets end on a NUGGET.

Continuation of Ruby problem from previous posts.

Vocab to learn: return

Line 27

Return statements instruct the program to give you a result from the method. In this case, we want to know what the reversed string is, so we return the reversed_string. If we did not want the program to give us a result, we would leave off the return statement. Many methods/functions will do this. They’ll perform a task but not be required to return anything.

Line 32

In order for our program to run, we have to call it. It’s kind of like having a tool in your toolbox, but if you want to use it, you gotta pick it up. On line 32, we’re specifying the name of the method (reverse()) and passing an argument into it (reverse(“goat”)).

This completes our reversed string Ruby problem! :) Next time, I’ll show y’all how to solve it in Python. ❤

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.