File that under “inspirational.” Last year I went to my company’s yearly hackathon for the first time. I was in the middle of my internship and too intimidated to compete. Instead of doing a project, I drank beer with engineers who were doing something with Drones and Slack and prayed they didn’t ask me to do anything. It wasn’t the scariest thing in the world, but I ended the week feeling left out that I wasn’t good enough to whip out a project in a week.

This year, I had a really good idea. It was ambitious, but I knew if I could pull it off, it would be impressive. And that has always been my biggest motivation. Once I get a picture in my head of what success would look like, I can’t stop until I get it. See also- what if I could become an engineer in year…

And as the spoiler alert indicates, I won it. The first hackathon I ever competed it. Which feels kind of badd ass ::insert kanye mic drop gif here::

But an interesting take-away is that I didn’t at all win by being the best engineer, although the tech was pretty slick imo. I won by having a super clear goal, being strategic and working like soooper hard.

So while I’m by no means an expert on hackathons, considering this was my first, here’s some stuff I learned from the process.

First off, VIP to know- I called the project “Luca” after my dog 🙂

Elevator Pitch- Luca is a virtual concierge device that uses a semantic processing algorithm, a speech to text API and translation API to answer questions a guest might have about a hosts home like “where are the coffee filters?”

A tad ambitious no? Well, that’s part of the strategy. AI and natural language processing is at a beautiful sweet spot right now of equal parts impressive to DIY but easy because of all the open source. The really hard problems, like transcription and translation are all open source, and the semantic processing is actually pretty basic string extraction and key word matching code. I wrote the algorithm in a few hours. The real REAL magic, in things like Siri and Alexa and Google Home is the massive data they have to detect intent. But there’s an 80/20 rule that gets these things working “pretty decently.”

For example, part of my intent detection database looks like of like this:

The real secret sauce of good voice assistants is the almost genome-mapping completeness of the english language, which unlike genes, is a moving target. Like trying to use math to explain why certain songs give you goosebumps, you can do a good job, but it’s never perfect.

So stragetic decision #1 -> Find something that looks much harder than it is (at least for a demo.)

Then, overcoming a whole slew of fears, I put my idea out there and asked if anyone wanted to join. I got 3 incredible interns who were more perfect than I could have hoped for. They were ambitious, hard-working, excited, humble and were more than happy to let me take the lead.

These are them. So adorable ❤

Not only were they brilliant engineers, but they were vote hustlers. During the demo fair, they were grabbing people to come by and try it out and asking them to vote for us. This seems obvious, but just asking people to vote for us was an important part of winning. Most people do work hackathons for fun and don’t focus too much on winning, so it was a pretty effective strategy.

So strategy #2-> Work with people who are good at the things you are not.

The final part is unavoidable, but important to mention. Putting in the work. And I want to specify that it’s the “right work” that’s important to put in. So no, we weren’t up til 3am testing and adding features. But I did spent a significant amount of time practicing our pitch and making sure the interns were set up to succeed. I scouted out the best location in the demo hall to make sure our audio had a good shot of working. I designed pretty art for the backboard so people who couldn’t demo it, got the infomation. And most importantly, i focused only_on_the_demo. The interns were excited to learn and build a beautiful codebase that tackled the tech in a really elegant way, but I made sure to steer us toward a good demo, not a good product.

It was an emotionally exhausting and incredibly inspiring week. The confidence gained from the experience  has the most rewarding.

I think the lesson is pretty clear. Always Always Always, do the stuff you’re scared of. How much you’re scared of it is directly proportional to how much you care about it and thus how hard you’ll end up working on it. and then y’know, profit.

xoxo nerds,

kartarr

 

 

 

you know what makes people suck at blogging? taking their blog too seriously.

seriously…

you get the slightest bit of exposure from something that catches and then you get nervous about people reading it and you think “blogging is part of my social brand and i should writing meaningful helpful SEO-friendly content or nothing at all” and then guess what, you write nothing… for like a long time…

and then you battle with why you started a blog in the first place. After all, you weren’t writing medium articles to tweet about. You didn’t link your blog to your facebook. This was your private place to vent and be honest and humble and vulnerable. This was counterculture. This was why your first blog was at 13 was: members.aol.com/WhyAreMidgetsHittingMewithFish.com

this was art and therapy and journaling. and then you put it all into a video and omgeveryonelovedit and people were so nice and thanked you for being so honest and humble and vulnerable.

but then other people told you that social media was no place for humility. that posting anything that questioned your abilities was harmful to your career. and it was “fine in the beginning” but “you don’t want to be this ‘new’ programmer forever.”

and that made sense. a lot of sense actually.

if you’re still complaining about how hard this is after x years, there must be something wrong with you. and/or you’re not smart about how to use these tools to your benefit.

so…

so then….

so then you stop talking.

completely.

and you join the other team. the ones who deserve to be there but make no effort to be humble. who make dangerous assumptions about what they know. by filling in the gaps with assumptions. and rely on a very specialized skill set and vocabulary to compensate for communication.

and then, while on a vacation of sorts, you have time to finally do your first side project. which seems silly because you’ve been hacking financial pipelines for the last year. but also isn’t, because when you self teach on a stack then get hired into it, your free time is overflowing with personal tech debt. and side projects stay in the “ideas” folder.

but you take a vacation-ish and you’re itching to solve a problem. so you write a silly program. literally a script 55 line script.

and you learn the following things:

1- How UTF encoding will randomly suck up 6 hours because you never care about until you have to and “have to” does not happen in established code bases.  / see also- philo. what *is* language really?

2- How to send emails in a script. / see also- Wtf has smtp meant this whole time

3- How to store passwords in source code / see also- “history is written by the winners, and rewritten by those who accidentally commit passwords.” /see also- overcoming the recursion of committing gitignore files

4- APIs /see also- but like actually what that means and not just an oddly meaningless placeholder for what feels like the word “code.” /see also- how to hack URLs when the app only has private apis and public ones are annoying to use.  /see also- how to leverage this by hacking pizza delivery apps when they introduce bugs and you notice before twitter because, pizza and … you. 

5- How to effectively manage separate personal and professional git accounts on the same laptop. /see also this won’t be the last time, best get a new mac book

so in conclusion, you know what makes people not suck at blogging? wine /see also- alone time, / see also- game of thrones premier and aforementioned hacked pizza bounty /see also 13.5 hours of coding and forgetting to eat so your brain starts getting psychotically weird about problem solving at all costs but then you hack pizza apps so you solve 2 problems at once making you feel like a god… one who’s not hungry anymore. /see also- no meeting wednesday tomorrow

Why is engineering so hard to learn and does it need to be?

As a self-taught programmer who moved from finance to engineering, the most common question I get is “what’s the best way to get started?”After it became unscalable to  provide tailored advice for everyone I met, I created a resources page on my blog.  Recently, I’ve been writing a book on Java with some fellow engineering friends and have developed strong opinions on how this stuff should and shouldn’t be taught. The problem is that most resources are written by incredibly bright and experienced engineers. And sadly, most of them suck at teaching it.

It’s a problem of unconscious competence and it’s not just a problem in engineering. Psychologists refer to the “stages of competence” to describe the process one goes through when learning a new skill. At first, you don’t know what you don’t know. As you learn you start to get a better idea of what you’ve learned and how far you have to go. As you move into expertise, however, things become so second nature you don’t even realize what you know or how you know it. And this is when people decide to write books.

But more problematic than unconscious competence is that programming just is really hard. The operational process of development is designed to best suit those who already have an advanced skill-set. Designed for programmers by programmers. Simply put, it’s not a user-friendly process and there’s no incentive to make it so.

First, we desperately need to rethink the common metaphors used to explain programming. They’re are a powerful way to grasp abstract concepts, but bad metaphors, do more harm than good. They need to be air tight or one is left to incorrectly fill in the gaps. We often explain programing as writing  a recipe given to a chef, or driving a car. While these get a couple core things right, the rest of the environment; the kitchen, the driver, the chef, is left to interpretation. And the problem isn’t just in metaphors used to teach, but metaphors used in programs themselves. Git commands like “push” and “pull” feel unintuitive, but we eventually accept them and move on, trying to conceptualize how “rebasing” is like “rewriting history,” since time travel is such an easy concept to visualize.

Visualization is not a novel concept in programming. Something new programmers learn very quickly is the importance of good debugging techniques. From fancy debugging tools inside IDEs down to adding print statements to functions, visibility is imperative to success. And yet visibility is exactly what’s lacking in the way programming is taught. New programmers are told that “Hola! Me llamo Kari” means “Hello! My name is Kari” Then told to switch out “Kari” with a different name and notice how now the sentence means something entirely different. You’re left to guess what the rest of the words even are or how they function.

There’s a story I’ve always loved about how the University of Florida accidentally designed incredibly efficient sidewalks on campus. They spent so much time analyzing possible traffic patterns that a few weeks after classes started students had worn paths walking through the grass and they just built the sidewalks over them.

The lesson here is to build a system that enables us to easily do what we naturally do anyway. When I first started in functional programming, I would leave the text editor and use wire-framing software to map out data flows that were particularly complex. The fact that IDE’s don’t visually represent data flow feels like a huge miss. Worse though, is the sense of pride among engineers to be able to read through code bases without needing visualization. To suggest something like this isn’t seen as innovative, it’s seen as complaining about something you just “have to go through.”

When I first started writing algorithms in Ruby, I insisted on writing all of the basic functions myself, before I’d let myself use any of the magic built in. So no .length or .iseven?  unless I understood how it worked. It made me wonder if there was a way to see the code for things like .length. But not being able to read C yet, I asked around to see if there was anything that translated ruby functions back into ruby. The confused looks and “why would you WANT that?” led me to believe I must be asking something stupid, so I gave up, feeling demotivated and reluctant to ask questions.

None of these ideas are in new by any means. Programming models that solve some of these basic problems were being used in the 70s and never caught on. Unfortunately, since then, we seemed to have forgotten that you can have new ideas about programming models in the first place. We defined it, created a curriculum to learn it and closed the door.

So my advice to new programmers is to remember this: there will be a beautiful and fleeting phase in your journey where you know enough to actually do stuff but you won’t really know what you’re doing. This will inspire the creativity to try anything you can think of and for a time, you’re mind will be completely receptive to all ways of thinking. Once you think you know what you’re doing, however, you’ll stop looking around for other ways to do it. You accept the world at face value and start telling the next class of new programmers to suck it up and get with the program (ha… sorry).

So trust anytime you feel like something is harder than it should be. Trust every time you wonder if there’s a better way of doing something. Trust every question, every insecurity and every idea that feels out there. Do not trust in the status quo. Do not trust that the solution in the book is the best one. And don’t, even if and especially if you are one, trust the experts.

 

Step 1- Spend a year learning Ruby in a modest but hardy codebase where SQL strings do much of the heavy lifting.

Step 2- Intern with the engineering team and spend 3 months doing ruby based projects in wildly different parts of the codebase, while your team builds an entirely new system in Scala.

Step 3- Transfer to the team and inherit a codebase written in a new language, using a new framework, using new concepts you peripherally knew existed but now need to be fluent in just to understand at a high level how anything works like, “functional programming” and “distributed data systems.” Make sure the language is relatively new enough and used in a unique enough way that stack overflow is now rendered almost completely useless.

Step 4- Make sure your new team cultivates a culture defined by the complexity of the problems they solve and  pride around being incredibly bright, so that any thoughts of “well, these are *actually* super challenging problems” that might make you feel a little better, get replaced by imposter syndrome and fear.

Step 4- Make sure your team is consistently under deadlines that never seem to go away (driven by scary third party customers like “auditors” and “regulators”) and require working every holiday weekend and after months and months, no one even pretends to try to hide their stress anymore.

Step 5- Make sure you’ve got no way to calibrate yourself except against the rest of your team who, although they have years more experience and formal education, is not excuse because you’ve been “doing this for a year” and you should be able to keep up by now. And they wouldn’t have hired you if they didn’t think you couldn’t pick this up in *at least* a year. And every day that passes and you’re still not as good as they are, make sure to feel slightly worse than the day before.

Step 6- Make sure that the combination of tight deadlines, little online resources and an uneccessarily complex new codebase that only 6 people understand even parts of, create an atmosphere where you can’t brute force your way through solutions and just plain *need_help* and *have_questions* but know that asking for help takes time away from their projects and deadlines and no matter how nice they are about it, make sure to feel guilty and like you’re only 1-2 dumb questions away from losing their respect.

Step 7- Also since you’re still slow and weren’t a core member of the team that built the new system, and it would likely take someone some time to bring you up to speed, make sure to hop around on tangential projects that have zero overlap in knowledge and constantly feel like starting from scratch and have no precedent so you’re always inventing solutions and it always takes you longer than it feels like it should and you start to loath the morning standups because while everyone else is updating about how they finished their 5th task and are halfway done with their 6th for the week, you’re “still trying to get {it} to work.”

Step 8- Make sure to keep telling yourself to “suck it up” and work every day until you get so frustrated you start to cry and have to leave the room because you don’t want to set women engineers back a decade by having emotions.

Step 9- If possible, read every PR your team sends out but never add any review comments because you’re not good enough to find improvements on their already functional solutions. And make sure this makes you feel guilty and afraid because you know it’s a crucial part of being seen as a productive, respected team member.

Step 10- If you haven’t already thrown your Macbook out of a window and skipped town, make sure you write an entry like this because you wrote a beautiful, elegant algorithm that even you were impressed by, because you actually are really smart and great at problem solving and you got it working in Ruby because you’re actually competent in it but by the time you figure out the 38 questions you have to convert it to Scala, no one will care because it will have already taken you 3X times the amount it should have and they needed it last week and if someone didn’t already just write it themselves since you were taking too long, they will once they make some comment on your PR that requires another 3 days work for you to figure out how to implement and even tho it took you almost 2 years to be able to do this in 3 days and that’s actually insanely impressive, no one will care. Least of all you, because you’re so buried in pressure and guilt and fear that you’ll forget that you actually are doing phenomenal and you should be proud and have fun.

Step 11- Place Macbook on curb…

 

 

 

here’s what today feels like.

You’re on one of those cooking competition shows and the judges are explaining the contest rules and you’re trying to write down their instructions on a moleskin while simultaneously ransacking the cupboards for things you sort of remember hearing about.

you’re pretty sure you hear them say something about tuna bruschetta, which stops your brain from processing new information because you thought bruschetta was defined by being made out of tomatoes. So you’re wondering if the tuna replaces the tomatoes or is added in addition, then you realize you’ve been zoned out for 4 minutes and missed the rest of the appetizer instructions.

you wince when they start talking about a something that you think is a kind of Sushi because you’ve been putting off learning to make Sushi. Sushi seems like a lot of work for something you need to eat 400 of to feel full. You open the fridge and realize you don’t even have any fish so you’ll have to go all the way to the store and get some. which is gonna set you back hours.

but whatever, one problem at a time. you remain optimistic despite the ever growing list of grocery stores crowding the pages of your notebook.

then they say something about biscuits! yay biscuits! you’re so on board with the biscuits. Flour, water. salt maybe? check! sounds easy. Then you ask if they want it with butter and they look at you like you’re an idiot.  There’s an awkwardly long silence and you finally realize the since the head judge is British and he’s probably talking about something you think of more as a cookie. So you quietly climb down off the counter where you’d been reaching for the flour, dejected.

Sometimes you write ingredients, sometimes websites where you remember a good recipe and others you just write down what they say verbatim and hope its something you can google later.

After a while the judges leave and you’re standing alone in the kitchen, arms wrapped around boxes of pastas and bags of produce, moleskin in between your teeth, instruction manual for the oven under one arm, cutting board under the other.

You throw everything onto the counter and a pear, a box of figs and a bottle of syrup go rolling off and settle under the fridge, forgotten.

but you’ve got an old photo of a family sitting down to a beautiful thanksgiving dinner, so you tape it to the wall, put Daft Punk on the Sonos and sigh, knowing you won’t be eating until long after dinner is over.

I’m a big fan of the phrase “delta v,” borrowed from orbital mechanics,  which for the purposes of this blog, is essentially the concept of “trajectory”. I use it when talking about the small decisions you make today to set you on the right course toward where you want to go.  When you’re self-taught the lack of guidance and structure can cause you to waste a lot of time focusing on the wrong things or learn things in inefficient ways. Last week I began learning Scala, which is my second language, and I’ve been doing a lot of reflecting on what I’m doing differently this time around, what I wish I’d been doing all along and what I wish I’d known a year ago. Thus, here are my favorite tips on learning to program.

1. If you’re stuck on where to begin, start with google and be able to answer 2 questions:

What is your actual goal?

Learning to program is most likely not your actual goal, it’s a means to your goal. Giving this some real thought can get you past the biggest time suck, not starting.  For me, I wanted to work for my company and I knew what their stack was, so I at least knew what language to start with and generally what kinds of things I’d need to know.  Is your goal to get a job as a programmer or to build an app in your spare time?  If it’s to get a job, what kind of company do you want to work for? If it’s a side project, what do you want to be able to do? Figure this out first and then do the research on what to do to get there.

What’s your time commitment like?

Be realistic about what you’re trying to achieve and the time you’re able to dedicate. I have a friend who’s goal was to become an engineer at his dream company in the bay area. To do that, he quit his job, studied for months full time, finished a bootcamp, worked at a startup, hired a tutor and THEN went through the interview process before getting his offer. This is a lofty goal and required a lot of time and effort. Another friend of mine, just wanted to build an iphone app, so he read a book on iOS and played around in his spare time. Be honest with how much time you’re willing to commit and evaluate if they match up with your goals.

2. Get coding fast

Once you’re ready to start. just. start. anywhere really but the best approach is the one that will get you doing stuff. fast. Interactive online tutorials like codecademy.com are great for this. One of the hardest parts of programming is getting set up to program. If you work for a tech company, you’ll probably spend your first week just setting up your computer and installing all the software you need. Interactive tutorials won’t teach you everything you need  to run off and start developing web apps, but it will take care of the messy front-end setup and let you start writing functions and seeing results within minutes. As a beginner, the sooner you get out of the abstract and into the practical, the better.

3. Get comfy with the high level

Someone once told me “the key to being a good developer is to be able to find your answer as quickly as possible without learning anything else.” 

As a beginner, I found this is next to impossible. The trouble is you don’t know how to gauge when you’ve learned enough. Experienced programmers have a handle on where they are in the spectrum of knowledge and can gauge what concepts are specialized edge cases. Beginners don’t know what to ignore and what to dig into. My advice here is to start paying attention to 2 things: your network and repeated information. What I mean is to give weight to things that your mentors or friends tell you to spend time on. That may seem obvious but your natural tendency will be to focus on the stuff you don’t understand instead of the stuff you sort of understand, and it ends up being extremely important to nail down core concepts. Same with repeated information. Let a couple of unknowns stay in your peripheral until you start seeing the same thing pop up over and over. You’ll have more context when you dig in, which will save you time. And if it really bothers you to gloss over topics, like it did me, keep a list of things to research when you’ve got some time to spare. Which brings me to…

4. Be methodical about how you learn

This is one of the critical delta-v factors. A VAST amount of information is flying at you from all over the place. And it can be difficult to see how it all fits together . Also unless you’re extremely silo’ed you’re going to be switching contexts frequently enough that you end up having to relearn something because you haven’t seen it in a while. For example, when I was just starting, I was merging code maybe once every 2 weeks. Because I wasn’t getting regular practice, I had to relearn all about rebasing every time it happened. It never stuck. My life saver has been a mind-mapping tool called X-mind and I really wish I’d been using this since the beginning. It’s where I keep everything I’ve learned in some semblance of a framework. I have a friend who swears by flashcards. Another has elaborate google docs. Whatever works for your learning style, write down what you learn and refer back to it.

For more on why this is crucial I could not more recommend the Janki Method more highly.

5. Work on something fun

I use the word “fun” somewhat liberally here,  but the key here is to find something that excites you. If you don’t do this, you will burn out much faster.  This is probably the biggest strength I had learning this in 12 months with a full time job. Granted, I was working on finance infrastructure, which is why I say “fun” in quotes, but I’m a nerd and I was consistently excited to hack at it late into the night. On the flip side, now that I’m full time, I’ve noticed I learn much slower the less excited I am about the work project. So to keep ramping up, I’ve started building little side projects for fun. This stuff is hard and frustrating and it’s important to keep learning, so the more fun you can introduce to it, the better off you’ll be.

6. Invest in your environment

Speaking of fun, spending time on the fringe elements of coding can be well worth your time. Take the time to set yourself up now, to save you time on tedium in the future. Enjoy this part, it’s where you join the ranks of opinionated tech elitists. Spend the time getting intimately acquainted with your text editor. Hell, if you want insta cred, start on vim and never look back. Get even more cozy with the command line. Pimp your bash profile with all the git shortcuts and ssh commands and compile code that’s wasted keystrokes and space in your brain.  Google things like “most useful linux tricks.” Ask your friends/coworkers for their config cheats. Learn the keyboard shortcuts. Set up a coding playlist, or steal mine.

7.  Learn how to debug

If you’re going to succeed as a programmer, you’re going to develop this skill because engineering at it’s core is just problem solving. So the earlier you start practicing, the better your delta-v. I got an awkward start to this and it took someone showing me a couple specific practices I could use. I was of the “try anything and see if it works” camp. Very simple concepts like, adding print functions to your code to see your output as it runs. Or more robust actual debuggers like pry that let you step through your code, making calls along the way. Practice this early, even in your simplest chapter one functions and you’ll develop a system that will carry you through even more complicated problems later.

8. Get a tutor

This is my “throw money at the problem” solution that while surprisingly simple, I never actually thought to do until a friend recommended it to me. Your first instinct will likely be to bug your friends and coworkers. But you’ll need more help than you’re probably comfortable asking for and it will slow you down. As great as books and online tutorials are, if you want to ramp up quickly, there’s just no substitute for a real conversation. I was extremely lucky in that one of my closest friends, who was extremely supportive and had a generous amount of free time, writes books on coding interviews (Thanks Gayle!). She and I worked through many, many algorithms using Hackerrank’s pair coding tool. But chances are, you’re not in the position for endless free mentorship, so my advice is, just pay for it. If you really want to give yourself the best chance why not give yourself every advantage? After a friend gave me this advice, I started seeing a mentor twice a week. It’s great for that list of “shit to figure out later” topics.

So these are just the things that worked really well for me and you are likely in a whole different camp. But what I do think is a somewhat universal piece of advice is to give this journey the same level of respect that you gave your education the first time around. Enjoy the journey, pay attention to your mind, and don’t deny yourself any advantage that can help you get to where you want to go.

Happy hacking!

Kartarr

something i regularly struggle with in engineering is being able to grasp a new concept just from an explanation. i’ve made peace with my learning style and i’ve compensated by doing what i do best: coming up with weird metaphors. not just any metaphor, it’s gotta be *sound.*

and thus git has escaped this treatment for the better part of a year. it’s been the bane of my existence ever since I first gained access to our codebase. i’ve scraped by  using the 5 things i’m fairly certain of and getting someone to take over when i eff myself into a git rebase cluster storm. git is hard. version control is hard to visualize in it’s entirety. and you can get away with not knowing most of it for a long time.

so today, being the friday of burning man, where offices around silicon valley are momentarily peaceful, I took some time to learn git on my own terms. and so here… is my metaphor…warning, this is stupid.

You and your friends are get together each week  to solve the New York Times Sunday crossword puzzle (i know, sorrynotsorry) and this is your wildly elaborate process for doing so:

Your friend Jeff is what we’ll call the “puzz master.” He’s the one hosting you and your friends at his house, and he’s mostly in charge of the master copy of the puzzle.

So before you and your friends arrive at Jeff’s place, Jeff is going to get everything set up for you guys to work on the puzzle together. First, he’s going to bring a big desk into his master bedroom. I’m calling this same as “mkdir ‘master_desk’ on a local system, basically just creating a place in the house for the puzzle to live.

Next he sits down at the desk, or ‘cd desk.’

With me so far?

Okay so now Jeff is going to ‘git init.’ What it does is turn the desk from a normal desk into something that he and his friends can use to do the puzzle. It’s basically going to lay out some general instructions on how to do crossword puzzles.

Next Jeff goes out onto his front porch and picks up his Sunday New York Times, pulls out the crossword puzzle, tosses the rest in recycling and walks back into the house. He lays the puzzle on his desk.

But so far this is all still in Jeff’s master bedroom, and he doesn’t want his friends going in and out of his room, so he walks into the kitchen and sets up his kitchen table, which he only brings out for puzzle nights. This is the same going into Git Hub and clicking on “create repository.” He puts a sign on the door to the kitchen that says “kitchen,” just to avoid confusion. This table, also has instructions on how to do puzzles, but it doesn’t have Sunday’s puzzle, which Jeff just put on his desk. So Jeff is going to do 2 things. First he’s going to put a sign on his bedroom door that says “master puzzle is in the kitchen.” This is to tell his roommate Kyle, who no one really likes, and has the unfortunate job of running back and forth between rooms and managing requests from you and your friends, where to take Jeff’s updates to. Next, Jeff is going to ‘git push kitchen puzzle.” He’s going to hand the Sunday puzzle to Kyle, who’s going to memorize what it looks like and go create the same one on the kitchen table.

Now Jeff and Kyle are ready for you and your friends. You arrive and walk immediately into one of the guest bedrooms. You do `mkdir desk` and set up a desk out of an old card table in the middle of the room. You ‘cd desk’ and sit down at the make-shift desk. But instead of starting from scratch, since Jeff already set things up in the kitchen, you’re just going to ‘git clone kitchen/master_puzzle.’ Almost immediately Kyle shows up with the instructions and copy of the puzzle. He sets them on your desk and tapes a sign outside your door that says “master puzzle in the kitchen” to remind himself where he should take your puzzle answers.

So Jeff is a bit of a times puzzle purist. He only does it in pen and he doesn’t allow anyone to put answers on the master copy of the puzzle. It’s kind of annoying but you love Jeff, so you comply with his ridiculous rules. He makes each of you copy the puzzle you have on your desk and set it next to the master copy. (Git checkout -b your_desk).  you move your chair over to the left so you’re sitting in front of the copy and get cracking.

20 minutes later you’re feeling pretty confident with the answers you’ve written down and you’re ready to have Jeff add them to the master copy in the kitchen. So first you take your puzzle and put it in a hanging folder just outside your door (git add). Since it’s outside the room, Kyle’s aware you’ve got some changes ready, but you haven’t called him over yet. So you call him over (git commit). Kyle comes over and makes a copy of your puzzle and files it in a filing cabinet underneath your card table. Then you’re ready to put it in the kitchen so you ‘git push kitchen your_desk.’ This takes a copy of your puzzle and puts it on the kitchen table next to the master copy of the puzzle. Kyle looks over your changes and makes sure there’s nothing on your puzzle that would overwrite other answers. Everything looks good so he stamps it green.

With the green stamp you ‘git merge’ your answers into the master puzzle where Kyle will write them down in pen.

And thus you and your weird OCD friends continue until you’ve decided the puzzle is finished.

So that’s my metaphor for now. I was going to cover merge conflicts and rebasing and reverting changes but I think this got long-winded more quickly than I’d hoped. Just like git to annoy me even in metaphor.

For posterity, I made this while I was writing this entry.

tl;dr- A wonderful opportunity fell into my lap to speak with my friend Zane Claes at SXSW on the topic of ‘Learning For The Job.’

plz to Click and vote for our submission 🙂 Also comment. be opinionated. get weird. The judges, they like “buzz.”

The longer version is that these past few weeks have been a whirlwind of amazingness. My coding montage video seemed to have found a good balance of humility, humor and inspiration and I’ve been getting a lot of love from people who are sharing these wonderful stories with me. Social media is kind of incredible, she said in a grossly meta/ironic understatement.

I’ll post more about my newly-found fascination with twitter and how personal branding is a dirty secret that everyone should embrace, but for now, vote(!!) for my submission and force me to speak in public (!!) about a subject i’m incredibly passionate about; the science behind learning, how to get over the hurdles and what ultimately gets you across the finish line.

night nerds!

~kartarr

http://panelpicker.sxsw.com/vote/52510

Tomorrow will mark 3 months as a full time engineer and as if on cue, I had a the most perfectly awful but wonderful day. A frustrating but deeply satisfying day where I struggled, celebrated, cursed, ordered pizza, high-fived and wrapped up before the hours became single digits again.

I say this was on cue because of everything I’ve learned in the last 3 months, how to deal with pressure has been the most vital. So in preparation for my 3 month check-in, I thought I’d reflect on some of the epiphany’s i’ve had along the way.

So here goes:

1. Make a list of everything you learn every day

I began doing this in a way, first by starting this blog, then later by writing super detailed training docs for myself, and most recently, a list of every new piece of information I pick up. The biggest mind-fuck I struggled with was feeling buried in the learning zone and not able to produce output. I discovered pretty early that “learning” on the job, while a great investment in your future, feels absolutely worthless at the end of the day if you have nothing to ship. Hence the list. The list also started serving as a useful data source. I started keeping track of what source files or websites were associated with something, so I could grab an example of it more quickly. Because as satisfying as it is to close tab after tab of stackoverflow threads when you figure something out, nothing is as sad as realizing it actually didn’t work and trying to find that “one” thread that had the answer. But at the end of the day, it just helped me sleep better on nights where I went to bed without shipping anything. I’m big into cold hard data. And looking over an extensive list of programming concepts I’d conquered, helped me see learning as progress.

2. Commit early, commit often. Not for just for git posterity, for your sanity

At the end of every week, I send my boss an email describing my progress, plans for next week and fires. It’s a bit corporate, but it’s good to document your work, lets you control your perception a little easier and managers tend to like it. About 2 1/2 months into my engineering gig, my boss asked me to include links to my PRs with the emails. I took it a step further and started committing small milestones, even if it wasn’t ready to ship, and tagging the commits to the emails. One of the worst things I struggled with was anxiety around having nothing to send my boss at the end of the week. Once my manager suggested I include PRs, I realized I could use leverage github as a record keeper and was able to relax… somewhat.

3. Break up your time into similar tasks

Probably the toughest thing about engineering is the never-ending amount of things to learn. Learning a language, building an app and conquering some coding questions is such a tiny part of programming. And it takes a really, really, really long time to find overlap in any of it. Which means it takes that much longer to feel like you’re making any progress. which makes it that much easier to want to give up. One thing that helped me was breaking up the week into common tasks so I didn’t have to deal with as much context-shifting. I spent most of the Monday through Wednesday working on my projects.Then in the evenings, I would pick something I didn’t feel solid on but had managed to get working and dig deep. I also dedicated time to general topics. Mondays was algorithms, Tuesdays was rails apps, Wednesdays was linux and git flows. Thursdays, I scheduled meetings with people to help me with stuff I was struggling with (side benefit was getting to temporarily put down something frustrating without feeling guilty). Thursday afternoons I would try and review other people’s code and stalk the slack channels to learn what was going on in the rest of the company. Fridays after the deploy lock, I’d pick a couple things from my “list of shit i heard someone say and don’t know what it is” and read up. As valuable as context-shifting is for an engineer, it’s terrible when you’re trying to learn. So I forced it.

4. Commit to the long hours

This seems obvious so allow me to explain why I’m including it. So, learning this shit is absolutely brutal. I pride myself on being extremely strong when it comes to learning new things. Moving around every 2 years growing up has left me with virtually no comfort zone. And I was still surprised at how brutal this is. The brutality was exhausting. And after 8 hours of laser-focused thinking, interrupted only by fits of rage, I would leave the office, come home, look at my computer and the anxiety would overwhelm me. And I would feel sorry for myself and decide I’d had enough torture for one day.

But I’d go into work the next day feeling behind, feeling even more pressure to get through things and much less able to handle setbacks. And I started making excuses. That everyone else had so much more experience, they never had it this hard. They got to learn in school, where you’re supposed expected to struggle.

Then one night, I was feeling so sorry for myself that I decided I was going to stay at the office until I finished something I was stuck on. I assumed it would take me all night. It did. But as I was walking home around midnight I realized it was the best I’d felt in months. There was pride in surrendering to the torture and coming out the other side. There was something relaxing about letting myself “take all night” on something. My self-proclaimed “success secret” is to make up for whatever you lack by working harder than everyone else. But somewhere amid the stress and identity crisis of not feeling smart for the first time in my life, my ego got the best of me. So, the lesson really, is to lower your standards for how you think you should be doing and just own your own pace, no matter how excruciatingly slow it may be. And if that means 15 hour days for a long, long time, then cancel your gym membership, stock up on redbull and get your fucking head down.

5. Learn early when to ask for the help and when to put time in the hurt locker

There’s two ways to get something done when you’re new; you can ask for help and or you can figure it out yourself. In engineering, the latter path can add days to a project. But you can’t always rely on the former and there’s an art to knowing which which to choose when. One thing to do early is setting yourself up with a good network. Get some people to commit to helping you ahead of time. Make friends in the beginning and take some time to figure out who the strong people are. Then play around with a mix of suffering through 6 hours of googling and bugging your coworkers for answers until you find the balance. And then let me know if you ever figure out that balance cuz I’m still lost af ; )

6. Don’t neglect your sanity

One thing I noticed immediately after my first week on the job was that how differently i felt after work. I was *exhausted.* And not just a usual “work tired.”  It took me longer than usual to shift from work to play mode. I struggled with small talk. I also started forgetting to eat. I would get buried in an intense problem and be so enraptured that it was suddenly 9pm and I hadn’t left my desk. Because of the nature of my projects, I had far fewer meetings than I did in my previous life and often would go an entire day at work not talking to another human being. it did weird things to my head. so i started doing crossword puzzles. like a lot of them. in 3 months i did the last 2 years of the New York Times. it helped me go from intense hard problems, to lighter problems, as a buffer before things go into social mode. I also make it a point twice a week to walk around the office and be social and get no work done and take care of my head. because it’s important.

So that’s my 90 day reflection. i know there’s a lot more to figure out but in keeping with the theme of this entry, i’m going to have a glass of wine (okay, continue drinking the glass of wine i poured when i started writing…okay i’m actually on my second glass). I’m gonna be proud of what i’ve learned, send it to a few friends so i can feel some connection and go watch nature documentaries.

Oh right, the Yak. Yak shaving is a term I learned a few weeks ago that describes the seemingly useless dependencies that derail you from the task at hand. Best described here:

I’ve made peace with the Yak.. or maybe just temporarily destroyed him in battle… either way, to be continued…

today i learned that memory and disk space are important distinctions and the difference between a source file and an executable file. I needed to know this to troubleshoot a gem install. which was step 1 of using a fake test server. which i need to TEST the FIRST piece of code i have for a much larger project. which already took me a week and a half to get working. because i had to back the fuck up and learn a bunch more stupid basic level ruby.

i feel like someone handed me a scalpel and said “go figure out how to perform this simple surgery, it’ll be challenging but you’ll figure it out.”

and then i’m like “whoa! there’s blood under here! I better figure out what this stuff is made of.”

and then i’m like “OMG CELLS ARE A THING!”

and then i’m like “uh oh, everyone else seems to know cells are a thing. i better keep this to myself.”

but then i need to figure out how mitochondria work.

but i don’t know the word mitochondria.

i just know it as “the purple thing that’s not working right.”

and the internet doesn’t have any results for “a purple thing.”

cuz everyone else knows the word mitochondria.

and also to find it, i really need to know what a membrane is. and an organism. and a eukaryotic cell.

which are all new words.

meanwhile my patient is bleeding out.

so i ask another doctor.

and he tells me it’s easy, i just need to make an incision.

which doesn’t seem to make sense considering i thought i was talking about cells.

so i wonder if maybe i’ve been wrong about what the word incision means.

but i’m standing there with a scalpel in my hand.

so i figure i better the fuck not ask what an incision is.

then he goes back to his own patient.

and people are coming in and out of the hospital. arriving sick, leaving better.

and i’m still on my first patient.

and i can’t let him down. so i keep googling.

and finally i figure out what the purple thing is.

and temporarily stop the bleeding.

and he’s not completely healed yet. so i have to come in and do it again tomorrow.

and i want to practice at home. i should be practicing at home.

but i can’t bring myself to face all that stress again. so i take a night off.

and start again tomorrow.

hoping i don’t kill him this time.

sorry, that got carried away and super dark.

new strategy is to live at the office forever. if it takes me 10 hours to do something another engineer can do in 10 minutes, then i will work another 10 goddamn hours.

a;lsdkfj

🙂