Crack me

Don’t hate the hacker, hate the code.

These are some excerpts from a presentation I gave at a ladies who linux meetup in San Francisco. 


I have always really enjoyed puzzles and games. Building forts, making indestructible cars from k’nex, rock climbing, even backpacking and trying to figure out how to make a fire in the pouring rain with only one match. There are so many things in our daily lives that force us to think critically and break apart a bigger problem into a bunch of smaller, more manageable problems. My love for puzzles was one reason why I wanted to explore the tech world. What I assumed and what I have found to be true is that the tech world is really just a giant playground of puzzles. So since I have you all right here, I thought we could do a little puzzle here together.

If you recall, our topic for the evening is security. Less than two weeks ago I moved into a new place on Treasure Island. I share a house with a few others who I didn’t know previously. My sister happened to be in town for the weekend, so on Friday night I picked up the keys to the space, dropped off a handful of things and headed up to Napa to meet her and some friends for a few days. I didn’t think much of it. When I got back I started to move the rest of my things in. I got up to my room and quickly realized that a brand new pair of running shoes I had just purchased two days previous were missing, along with a few things I had purchased from IKEA. weird right? I didn’t want to assume the worst, so I checked my car for the shoes, but to no avail. Why am I telling you about my stolen shoes? I am supposed to be talking about security. I’m telling you this story because when I first thought about security, I dove right into the deep. I started researching the seven layers of OSI, about TCP vs UDP, network mapping and the list goes on. But I just told you all, I’m a beginner – I have no experience with any of those things – and the story of my shoes reminded me of some very basic fundamentals of security. When we think of security, we often go right for the hard stuff and forget about the basics. When I moved into my new space, It’s not that I should have been overly cautious or paranoid about the living situation – but I should have taken precautions to better set myself up for success. All I really needed was a simple lock on my door.

Security does not need to be complicated, you just have to make sure you cover your bases. Make sure to password protect your accounts, cell phone, and computer. Don’t use the same password for multiple things (although I’m pretty sure we are all guilty of this one).  Make sure to use two-step verification for important logins like work emails, online banking, etc. Before you worry about the deeper levels of security, make sure you have taken care of the basics.

So – on to our little puzzle.

The is a copy of this project on github under Holberton school – so you are all welcome to clone it and try it yourself at home. Check it out here.

Before we start, I am going to open up a VM. Since we don’t know what exactly these files could contain, we want to protect ourselves by doing all this little puzzle on a VM. Things are a little more contain on a VM.

vagrant up

vagrant ssh

First I am going to clone it from github – you can see that there are a few files in this repo, we are only going to be dealing with a.out tonight, but feel free to explore the others on your own time, each one increases in difficulty and not all are solvable.

Change directory to our newly cloned repo.

cd don_hate_the_hacker_hate_the_code 

Check to see what files are here

ls a.out     crackme   crackme2  crackme3

I am going to make a copy of a.out because I know from experience that if we try to execute the program with the wrong password the file will delete itself – that feature was built into the program.  So I am going to save us time and hassle .

cp a.out ladies.exe

Now we have ladies.exe

ls  a.out      crackme    crackme2   crackme3   ladies.exe

Okay – we are all set up to start cracking. If you haven’t guessed it already, we are going to be attempting to crack the password to this file. Like I mentioned earlier, this first one is pretty easy and if you want a challenge you can try any of the others.

First thing we want to do is to gather some information about the file we are dealing with – it’s a simple command

file  ladies.exe

We can learn a lot about our puzzle at hand by learning about the file type.

ladies.exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, not stripped

We can see that it is ELF which means it is in an executable and linkable format – and even that it’s not stripped.

If someone wanted to cover their tracks a little bit better, they could have stripped the file.

nm ladies.exe

You get somethig that looks like this.

0000000000601058 B __bss_start

0000000000601058 b completed.6973

0000000000601048 D __data_start

0000000000601048 W data_start

0000000000400550 t deregister_tm_clones

00000000004005c0 t __do_global_dtors_aux

0000000000600e18 t __do_global_dtors_aux_fini_array_entry

0000000000601050 D __dso_handle

0000000000600e28 d _DYNAMIC

0000000000601058 D _edata

0000000000601060 B _end

When you use nm, you are listing the symbols from object files. You can strip that infomration quite easiy though. Run these commands and see what happens.

strip ladies.exe

nm ladies.exe

file ladies.exe

Now if we wanted to know a little more about the file type, despite the fact that we are the ladies who linux, we all need a man in our lives. Just man file to find out a bit more about the file command.

man file

Okay, so we have gathered some information about our file. What’s next…? Run the file?

Maybe we can read the file and find out more.

emacs ladies.exe

Woof – that’s rough. That’s not going to be of  much help. Welp – I have a few other tricks up my sleeve. How about ltrace.

man ltrace

ltrace is a program that simply runs the  specified  command  until  it exits.   It  intercepts and records the dynamic library calls which are called by the executed process and the signals which  are  received  by that  process.   It  can also intercept and print the system calls executed by the program. – Basically it will show us what library functions are being used in this file. When you use trace,  make sure to use the executable format since it actually executes the program when you run it. 

ltrace ./ladies.exe

__libc_start_main(0x40060d, 1, 0x7fff775943a8, 0x400760

printf(“Usage: %s password\n”, “./ladies.exe”Usage: ./ladies.exe password

)   = 29

puts(“See you next time hacker!”See you next time hacker!

)                = 26

You can see it’s using printf  and puts. But it looks like printf was looking for the file along with a password, so lets try it with a password now.

ltrace ./ladies.exe password

__libc_start_main(0x40060d, 2, 0x7fff451bbfe8, 0x400760

strcmp(“password”, “#cisfun”)                    = 77

strcmp(“password”, “passw0rd”)                   = 63

puts(“Access denied :(“Access denied 😦

)                         = 17

puts(“See you next time hacker!”See you next time hacker!

)                = 26

Now we see that it’s using strcmp – lets checkout what strcmp does…

man strcmp

The strcmp() function compares the two strings s1 an s2. It returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be less than, to match, or the be greater than s2.

You can see the program comparing the password we put in with two other strings, #cisfun and passw0rd. That gives us a pretty good hint that maybe one of these strings is the password. You can try them both.

Since #cisfun starts with a special character, make sure to include quotation marks around the password when you type it in.

ltrace ./ladies.exe “#cisfun”

__libc_start_main(0x40060d, 2, 0x7fff98524a78, 0x400760

strcmp(“#cisfun”, “#cisfun”)                     = 0

puts(“YES it is fun isn’t is? :)”YES it is fun isn’t is? 🙂

)               = 27

puts(“But this is not the right passwo”…But this is not the right password.

)      = 36

puts(“See you next time hacker!”See you next time hacker!

)                = 26

We get something different that time, but it’s still not right. So go ahead and try the other possibility.

ltrace ./ladies.exe passw0rd

__libc_start_main(0x40060d, 2, 0x7fff70c8f778, 0x400760

strcmp(“passw0rd”, “#cisfun”)                    = 77

strcmp(“passw0rd”, “passw0rd”)                   = 0

puts(“Access granted \\o/”Access granted \o/

)                      = 19

+++ exited (status 0) +++

It looks like it worked!

Okay let’s try something else. In programing, there are always lots of ways of solving a problem. Strings is another tool we can use.

man strings

Okay, strings – print the strings of printable characters in files. That seems like it could be useful. If there is a password in this file, it may be contained in a string.

strings ladies.exe

It looks a little bit different from ltrace. Here you can see some of the strings used in the program.

Usage: %s password

See you next time hacker!


#cisfun! :);

Try again later


YES it is fun isn’t is? 🙂

But this is not the right password.


Access granted \o/

Access denied 😦


Now – we could write a bash script to brute force the password. We are programmers after all, so why not? This is a short program written by a fellow student at Holberton School.


for passwrd in $(strings ./ladies.exe)


 cp ladies.exe tmp2.exe

 ladies=$(./tmp2.exe $passwrd | grep -v “Access denied :(“)

 echo “Trying: $passwrd”

 if [ “$ladies” != ” ]


   printf “\nThe password is: %s\n” “$passwrd”

   exit 0




Yet another way to go about this is with assembly code.

objdump -d -j.text -M intel ladies.exe

I am not going to go through the assembly code now for times sake. But essentially you just have to follow one clue to another.
That’s the basics of cracking a password. If you enjoyed this, head on over to Holberton school’s github and try the others.

Ladies who Linux

Silicon Valley is an interesting place to be studying software engineering. Patricianly if you don’t come from a tech background…(like me). I live about 45 miles from where I attend school; so every morning I have to take a commuter train into the city.  By 6 a.m. that train is filled with every tech badge imaginable – some I saw this morning, Salesforce, Oracle, Pinterest, Slack, Uber…just to name a few. How do I know…? Because it’s embroidered on everyones jacket, backpack, or other form of branded apparel. It’s a density of no comparison. It can be overwhelming most of the time, but sometimes I get to reap the benefits of of this close proximity to so many resources.

Last night I attended a Meetup at Dropbox. The theme of the night was ‘Ladies who Linux’. The Meetup caught my attention by the title. Not because it was specially for women, but because it was from a line from one of my favorite musical, song by one of my favorite actresses. The song is directly poking fun at women who are pursuing very little in life – the crux of their day being brunch. It’s funny and ironic choosing that for a title of a Meetup for women who are in fact doing the opposite, pursuing the world.

“Here’s to the ladies who lunch–
Everybody laugh.
Lounging in their caftans
And planning a brunch
On their own behalf. “

Elaine Stritch, from Stephen Sondehim’s “Company”

I joined a group of women who are working in the industry, and who all really enjoy Linux. That is an opportunity that only proximity can give you. All of these women, ranging in experience and personality, had such so much to bring to the table. Tammy Bütow, formally with DigitalOcean, now with Dropbox, organized the evening. She recently ran a similar group in New York when she was living there, but now that she has relocated to San Francisco, she decided to help create the space for women to come together and share experiences and knowledge based around the topic of Linux.

My biggest highlight was talking with Jessica McKellar – currently  an engineering manager at Dropbox (although, she tends to wear many hats at the same time). Jessica is quite impressive, and she filled the space with an air of composure and strength. She has worked hard to get to where she is today, and I believe that her passion for low-level systems has been her driving force. Jessica is a director of the Python Software Foundation, and won the O’Reilly Open Source Award for here contributions to Python back in 2012.  She’s written a few books on the subject as well. It’s women like her that give me the confidence to burst through walls when I come face to face with them. Right now Jessica is working on a video series on an introduction to Python. You better believe that I will be following that series to soak up as much as I can from a women who knows what she’s talking about.

I asked her for some advice for a beginner programer. Her one tip… contribute to open source projects. That is now on the top of my priority list.

– So here’s to the Ladies who Linux –

Changing the world one line of code at at a time.




Numbers are not just symbols on a page

The above was the title of a project we had to work on this week. We have had a few projects in C before, but all of the previous projects were mainly an introduction to the language. This new project was very different. See, Holberton School’s goal is to shape us in to ‘full stack’ engineers.

mmmm… but that term is a little vague, and is used loosely in this industry. In fact when I was thinking about heading west to attend Holberton School, I was weary of the term. Before coming out to San Francisco, I was planning on attending Mobile Makers in Chicago, a boot camp for iOS. Don Bora, co-founder and chief instructor of Mobile Makers, and a friend of my father, was excited when he heard I was going to attend Holberton, but was weary of how the school train up ‘full stack’ engineers. Full stack is a very broad term, and it morphs into a lot of different things deepening on how people want to use it. You might run into people who call themselves ‘full stack’ engineers because they can do both front-end and back-end. Cool, great… glad you can do two things…. but ‘full stack’ at it’s core means something very different. Look at it this way – lets take for example a a webpage to purchase a flight to California (this being an open invitation for my Chicago friends to come visit…hint…hint). You have the front-end, the part of the webpage that you are interacting with, where you put in your personal information and your select a destination of California. The back-end deals with servers, an application and a database, so that when you log back into that webpage, you can check your flight status and see that unfortunately it is delayed because of bad wether in Chicago (more reason to visit California).  So there you have it- front-end and back-end… but wait… there is so much more to software engineering then just that. What about all the other parts like security, and the construction of the very languages that everything is written in?  I haven’t even mentioned the soft skills like marketing , or other behind the scene things like system administration. There are so many layers when it comes to software engineering. With a humble and realistic understanding that nobody can be and expert in all areas of the full stack, Holberton’s goal is to make us all at lest proficient enough to peel away each layer and deal with bugs no matter how deep down they go. To be able to do that, you do not need to master every aspect of software engineering, you just need to have a solid understanding of how each part fits together and have the tools in your tool box to figure it out from there. And that is why we are solving algorithms in C.

SO back to the top of this post. Our task was to ‘Write a function that takes an integer in parameter and prints it’. Sounds easy right. Just write a function that takes ‘n’ number and prints it on the screen. HA. NOPE. Not easy at all. This was a restriction among many others.

  • You are not allowed to use the standard library. Any use of functions like printf, puts, etc… is totally forbidden.

WOOF. The only function we could use was ‘print_char’, which prints a single character. Not super helpful when a six long digit is passed into the parameter. We needed to figure out an algorithm that would take a given number, figure out how many digits were in that number, from that extract each individual integer that makes up that number and print them in order. Figuring out the algorithm was daunting. After the task was posted, a bunch of us were still stumped… so we shoved ourselves into the only meeting room with a white board to hash out the problem. A few hours later, we had a semblance of an algorithm, with no code attached. Some of us felt like, “oh, great… we haven’t gotten anywhere”. But Julien, one of our co-founders, wanted to make a point with that. He said, the hardest part of this task was figuring out the algorithm, the code part is easy (well, maybe once I am better at C it will be the easy part). He wanted us to realize that when we are faced with a problem like this, you can not start with the code – you have to first figure out how to solve it with pen and paper. Let me make myself clear, pen and paper will never be antiquated. It’s a hard lesson to learn when you have been spending upwards of twelve hours a day typing way on a computer.

Algorithms are not going away. We are learning to use our brains and the tools at hand to solve problems. And that is exactly what a ‘full stack engineer’ should be able to do with confidence an ease. I’m not there yet, but conquering algorithms and C are a few of the tools in that tool box.

Queue the metamorphoses – the cusp of deep learning

I currently have three windows up on my computer, this web page, terminal, and Rick and Morty playing in the background.

I absolutely love Rick and Morty (thanks Kyle for introducing it to me). The tech industry take itself very seriously sometimes, and this TV show manages to lighten the mood. One of my favorite snippets is in an episode from season 2 – Rick and Morty want Summer to stay in the car while they go and take care of something. Rick proceeds to instruct the car  ‘to keep summer safe‘. The parameters ‘keep summer safe’ then proceed to break all convention in an attempt to fulfill that one goal. Watch the clip and you will know what I’m talking about. The short scene is almost a synopsis of the movie ‘A Space Odyssey’ – adhering to these three rues (in this order)… 1. do not harm humans, 2. obey humans, 3. protect yourself. Put in the hands of un-conscience beings, these parameters do not seem to work in a world of conscious ones.

Lets start by establishing that we are ALL very well acquainted with deep learning. YES – YOU – you have a lot of experience with deep learning. Here are some everyday, concrete examples… Google allows us to find information based algorithms, Netflix recommends shows and movies based on what you have enjoyed in the past, and Amazon suggests products based on what is currently in your shopping cart. These are all examples of machine learning, or more specifically deep learning. Right now a lot of us are entranced with the idea of deep learning. Wether it is body augmentation, or the dream of owing a self driving car, we all have ideas about how deep learning could improve our lives – make us more productive while at the same time making our lives easier.

This past week Louis Monier and Gregory Renard gave a seminar on deep learning at Holberton School. They covered everything from the ethics of deep learning to hands on projects allowing us to see how machine learning happens first hand. At the very end we had a fire side chat about some of the ethical implications, both good and bad, of deep learning. There was mention of the possibility of improving elderly care, or those with disabilities, but we kept coming back to this one issue… what will happen when deep learning has to make moral decisions?

Let me give you a specific example. In about fifteen years when self driving cars have become the norm (and yes, that is inevitable at this point), what happens when the car is in a situation where it needs to make a moral decision? Lets say the car is driving down a busy city side street and out of nowhere, a small child runs in front of the car chasing after a ball. The car does not have enough time to make a complete stop without hurting the child. To the right of the car is a cement barrier and to the left is someone on a bicycle. The car needs to decide how to react to the situation. If it goes straight, the child is harmed, if it goes right the passenger is harmed, and if it goes left the bicyclist is harmed. How should it proceed? Now, this might be a hypothetical situation – maybe a little unrealistic… but humor me. How do you program a car to make a decision like that. One might argue, well, people find themselves in situations like that all of the time, and we always have to make moral decisions like this every day. If self driving cars did not exist, the passenger would be the driver, and they would have to make that decision in a split of a second  – harm the child, harm the bicyclist, harm herself. Moral decisions are made by every singe one of us every single day. The big question being ‘How do you program morals’? This isn’t a new question, and the discussion is going to be around in the foreseeable future. Deep learning integrating into our lives is inevitable, but it brings along some very difficult questions. Get your thinking caps ready, because we are in for some trough conversations.


(Greg getting our fireside chat going)

If you are behind in your A.I. media – watch these to catch up

  • Rick and Morty (pretty much any episode)
  • A Space Odyssey (one of the most classic examples of deep learning)
  • Terminator (deep learning gone wrong)
  • Eureka – (season 1 episode 2 – the next steps in home automation – or the internet of things)
  • Her (but be prepared to be depressed about the future of our relationships with technology)
  • Transcendence (Johnny Depp uploads his brain to a computer – can you take human intelligence and transfer it to another object)
  • Ex machina (who can we trust, humans … or technology)

Impossible Octopus Fitness


One of the things that I am really loving about Holberton School is how they iterate on projects to give us a full emersion experience of what it is like to be a software engineer in the real tech world. We are most recently working on a simple web page. Part of the application to get into Holberton School was to create a web page, so it’s nice to be able to revisit front-end development now that we have some experience under our belts. The first part of the project was simply to create a web page with very specific guidelines – all designed to force us to learn specific skills. Elements like, float, clear, and myriad css statements. Once we finished that project, we were given an iteration based on SEO (search engine optimization). The same web page is now a small competition in web marketing. The goal – get the highest ranking on google for a given query. What’s the query you ask… if you haven’t guessed already “impossible octopus fitness”. The website was made in about two days, and it was the only the second one I have ever made, so it is by all means, not a great site, but do me a favor and check it out, maybe Rona (my partner on this project) and I will raise in our rankings when you do a google search of impossible octopus fitness.

impossible octopus fitness

Don’t trust. Verify.

Today marks the end of week one at back at school. It has felt strange and refreshing not being at work anymore – I feel challenged and leave exhausted at the end of the day. The type of exhausted that means I REALLY did something today. On the other hand, it’s terrifying. I got my last pay check today from my previous job. That means that it’s budget time. I have a very specific amount of money to ride out on for the next foreseeable future. At times that scares the shit out of me. I’ve cut as many corners as I can – but at the end of the day I am still living in the most expensive city in the country – and I still need to eat, and get from point A to point B – and that is far from cheap.

Today, we had a Nicolas Bacca, the CTO at Ledger an Btchip, come in to talk to us about security. His tag line was – don’t trust. Verify. He wanted to drive home the point that in the technology industry, we can’t just trust every program we run or every website we log into – you need to verify everything. Trust leads to holes in security. Trusting things, without verification, means hackers have the opportunity to swoop in and take advantage of your information. This is a crucial tag line to implement when you work in the technology industry. I got to thinking about it more – and I quickly realized that it may work for the technology industry, but it doesn’t work in most other parts of life. Or – at least it shouldn’t. Don’t trust, verify – it implies that we should assume all control. That just isn’t feasible in life, nor is it healthy. We are not in control.

A few months back when I was just starting to talk about the possibility of starting down the path of software engineering, I found myself standing in the kitchen of the Lewis family home. I was talking to Mary Lewis, a mentor and friend. The past few years, I have been helping out at the Lewis home with their five girls (ranging in age from 5 to 17). But long ago, before Mark and Mary were parents of these five girls, they were actors in New York. Originally from Arkansas, Mary found herself in love with New York. Between her work on soap operas, and stellar roles dancing on broadway – the Big Apple had captured her heart. While in New York, Mark was offered a job in the Communications department at Wheaton college (just west of Chicago). Seeking council, the two headed to their pastor – at that time it was Tim Keller. Tim Keller is a big supporter of Christians choosing to live in our cities (I put some links to some recent posts from Tim Keller on the subject). That being said – when Mary went to seek council, she was pretty sure Tim was going to tell them that they were needed in the City. You can guess where this is going – Tim told them to go to Wheaton. Shocker.

Mary didn’t want to go at first. But God had bigger plans – plans Mark and Mary couldn’t quite see yet. When I got accepted to Holberton School, I felt a similar way. I couldn’t make out a clearly defined path of what deciding to go into software engineering looked like. Making a big decision like that without knowing all the facts is scary – and very uncomfortable. But there I was, standing in the the kitchen talking to Mary about her decision to make uncomfortable decisions nearly two decades ago – not too different from mine. It wasn’t the decision to move across the country, leaving behind the city you love – but rather the decision to trust the doors that God opens for us, and to walk through them with grace.

Here is the take away. We try really hard as human beings to remain in control of our lives. We make plans, we save our money and tighten our belts if needed, we make safe decisions to ensure we live a comfortable happy life. But it doesn’t matter how much planning, or securing we d0 – disasters strike, stock markets fall, and our loved ones get sick. There is no verification in the world that could stave off the reality of this fallen world we live in. Control does not lead to happiness, it leads to a self-centered, stale, life. God gifs us times of trial – he places fog on the path right in front of us. Our job is not to wait for the fog to lift, or take out our map to check of the possible hazards that may lie ahead – our job is to trust that He has our best interest at heart.

I challenge you – the next time you see fog up a head, don’t wait for it to clear, but seek council and if God is leading you forward, walk with grace and trust that His plans are far greater than you could even imagine. Don’t verify – TRUST.

(My path is still foggy – I’ll let you know when it starts to clear)


The Difference Christianity Could Make in the City

The City, the Church, and the Future – Tim Keller

A little birdie Bash

Yesterday we were given our second batch of projects, with a due date at the end of the week. We all got to work right away. I think we are all still trying to figure out the pace of how this school is going to work. Thank goodness it’s not being run like a traditional school – no classes, no attendance -none of that rigamarole. This just means we have to figure out the ebbs and flows of this new chapter in our lives. We are all coming form very different places – different ages, ethnicities, countries, regions, religions and lifestyles. I guess the fun part is that we get to figure it out all together. So far one of the best things about this school, is that every single person here WANTS to be here. The part that will be interesting to navigate is going to be our different skill levels. There are some skilled programers here, and like me – some beginners. This means that we have a lot of resources to pull from, but it also means there is some pressure to get up to speed. It’s nice to feel the desire to work hard, but it’s also very nerve racking. Late afternoon yesterday, I remembered standing up to take a break and thinking that I was proud of my self for getting so far in the projects (I was almost halfway done). When I was talking with some peers in the break room, I quickly realized I was not ahead of the game, but rather just below par (birdie in golf terms). Maybe I’ll give myself that new title “little birdie”. Most of my peers had already finished all the projects we were given. I think these next month are going to be a humility check for me, I’m used to being ahead of the gang – at the head of the class. Not any more. No- back to my bash projects.

Do you GIT it yet?

Day 0 was orientation, basic knowledge, and more in-depth exploration about what to expect with Holberton School. It was super long, but things have only ramped up from there. We had two projects due by the end of the weekend. The projects were oriented around understanding our tools, so when we get started on group projects, the tools won’t hold us back. We had a project understanding git, and github. I was the first to finish that project, not because I knew what I was doing, but because I wanted to get the first project out of the way. It was a blessing and a curse. I know I didn’t do the worst on the project, but I also didn’t do great. I was able to learn a lot form the QA of the project, and I was able to help my peers to make sure they wouldn’t make the same mistakes I made. One of  the biggest things I missed was not using HTTPS and instead using SSH. SSH being the more secure way to do things, since the work would not be associated with my github username and instead a secure shell that recognized my computer. I learned my lesson.

Our second project was on understanding basic bash commands in linux. I think the lesson learned with playing with basic bash is that its simpler than you think. The basic commands are a single word, and yes, you can complicate them by adding comments and such, but at it’s essence, you just need one word.


Two projects done, I’ve learned a lot, but I still have no idea what I’m doing. I guess that’s the the beauty of this whole ‘going back to school thing’. I have lived my life so far, proficient in my previous jobs, somewhat knowledgeable about the world around me, and yet there is still so much to learn.

Day 1

I left the house at 5:57am this morning. I still am trying to figure out the best way to commute from  to the Embarcadero BART station in downtown SF. I have to navigate the timing of everything, because everybody else in the area is commuting at the same time. The parking lot at the Dublin/Pleasanton station fills up around 7am. Woof! Traffic and parking was fine this morning, but then again it’s a Friday, and Fridays seem to be a lot lighter in terms of commute (must be be nice to be able to work from home). It’s $3 to park, and it only takes cash. I remembered when I did a trial commute yesterday that there was a change machine, so this morning I took out my $50 to make some change. I figured if I am going to need $3 to park 5 days a week (no parking fee on Saturday and Sunday), I might as well get a lot of cash in single dollar bills. But lo and behold, the machine only takes 10s and 20s. UGH. Why am I so bad at this. I rummaged through the entire contents of my backpack, trying to find a bag I had stashed away somewhere down in the depths. The contents of the bag were numerous gift cards to various places such as Target and Starbucks, all gifted to me by my mother before I left on this great big adventure. I think she was worried I wouldn’t have money to eat (and rightfully so). I had remembered putting some dollar bills in there, but I had also remembered using a few of them at a gas station in Reno Nevada for some slots (it is fondly known as Nevada’s “other” gambling and resort town). Actually, I didn’t gamble, I gave a few dollar bills to my friends to try their luck at the slots. But I diverge. So here I am, at the BART station, digging though my bag in hops I will find a few dollar bills left unscathed, just my luck, I had just enough to pay for parking for the day. Phew.

LivermoreI bordered the train, and an hour later I arrived at Holberton School…a whopping hour and a half early. Well, I did stop to get a celebratory d
oughnut across the street before arriving at school. SO here I sit, chomping on some sugar coated fried dough (this is not an irreverent tone, I have a huge respect for sugar coated fried anything), and sipping on some below par dinner coffee, awaiting the begging of the next chapter. I’m really not so sure how this story will end. So keep reading and we can find out together.



Brick Wall #1

Class has not even started yet, and I’m freaking out. When I was first accepted to Holberton School in San Francisco, I knew I was going to be hitting some brick walls. I was not, however, expecting to hit them before class even started.

About a month ago, when a bunch of accepted students were talking on Slack, the communication forum for teams, we started to talk about arrival dates. Most everybody who is attending the school is not from around here, so I suggested that we meet up before school started to break the ice. The first day of school is hard, I thought it would be a bit easier to do the meet and greet ahead of time. A bunch of us meet up at the school, grabbed some picnic lunch at Yerba Buena Gardens, then split up to walk around and see a bit of this city we now all call home. I walked to the pier with a small group then trekked up to Coit Tower. We ended the afternoon with a walk through China Town. It was nice to spend some time getting to know some of the people I am going to be spending the next two years with.

The meet and greet was great. But my freak out happened about 10 minutes after walking in the door. I greeted Rudy, one of our co-founders, and then asked him for the wifi password. He directed me to a framed poster on the wall. It was code. So I took the code and sat down to start to figure it out. Only, I very quickly realized I had no idea where to start. So…I figured I would do some quick searches on my computer to see if I could find some resources or something…but wait, that would require internet. Dang-it. Brick wall #1. IMG_1388-2.JPG