How do you eat an elephant?*

by Zach Briggs

One bite at a time? What? How are you even a project manager? 

If we have to eat an elephant, then we start by renting some commercial freezer space, a chainsaw, and a vacuum sealer because we're not getting through this thing in a single sitting. How did we even come into the possession of a dead elephant that needs to be disposed of? How long do we have to make this thing disappear?

What? Whoah whoah whoah whoah. Whoah. So we've got a hard deadline of 4 days and don't yet have an elephant of any sort, much less a freshly butchered one? No, I don't think "spike out a trip to Africa and look for a sick one" is a reasonable first step. Yeah, no, we cant just "use a jQuery plugin for that."

How about we take the product owner out for some drinks and manage expectations? We can find out what they're trying to accomplish with all the endangered animal murder and see what else we can do for them.

 *The correct answer is "by cheating."

 

Shut Up

by Zach Briggs

That is the constant refrain from our brain, so please allow me to present a rebuttal.

What you have to say

  • Isn't irrelevant.
  • Isn't so basic that everybody knows it.
  • Isn't wrong.

The Real Power Of A Pomodoro

by Zach Briggs

Asking your pair "what the hell are we even doing" will save their life. A few hours of it, anyway.

An afternoon spent in isolation, banging out code, is an afternoon wasted if we're not even solving a problem that somebody cares about. Avdi Grimm relates a story where he is building a screen scraper to access content, an arduous process, and it did not occur to him to just parse the RSS feed that he helped define. A pair sitting with him would have pointed that out very quickly. I have done far stupider things in isolation for far longer that a pair would have prevented.

Sometimes we need to get stuff done while alone, though. Being pretty horrible and blaming not having a pair is one option. Another option is the judicious use of pomodoro's.  In brief, a pomodoro is a 25 minute distraction-free work period followed by at least a 5 minute break. 

This pattern of 25 minutes of concentration followed by a hard stop prevents the insidious flow from happening and allows or brains to reset. We have a chance to stop fixating on hard problems that need not be solved and focus on the ones that other humans care about.

I try not to code alone but when I do it's never for more 25 minutes at a time. 

Purple Rain

by Zach Briggs

Every trip out to Google for something we do not know costs 10 minutes. If our search returns visited links then that was 10 minutes needlessly wasted.

In my talk, I mention that I started to write down little licks on index cards whenever I see that I've searched for something more than once. In my case it's going to be Ruby syntax, JavaScript syntax, or *nix commands due to my Double Agent status but I suspect that this technique applies to any information worker.

It's important that I write what I didn't know with pen and paper because I type for a living. There is something about seeing that information in a second context that etches it into my brain. So much so that the mere act of writing the syntax down immediately before using it is often enough to induce memorization without the need to review the information later. Waiting until I need that information a second time (looking for the purple links) before committing it to paper provides a great filter so that I'm not committing obscure 1-time-use trivia to memory.

I now produce at double the speed that I used to because I'm not constantly shifting focus between my work and a browser. I also find that I'm more creative. Since I now speak fluent Ruby I can use lateral thinking to compose thoughts outside of a phrasebook. The speed is wonderful but that increased creativity means that I'm more likely to build stuff that somebody might actually use.

That seems like a pretty nifty metric, right? Building a thing that is used by humans.

Effective Immediately: Promotion

by Zach Briggs

Effective immediately, all Junior Developers are hereby promoted to the position Developer. Developer responsibilities include, but are not limited to:

    • Being just as responsible for the success of The Project as the most senior member of the Team.
    • Gathering domain information relevant to the project and disseminating that knowledge to the Team. This may involve inviting somebody from Business or Sales out to lunch. Really.
    • Honestly and openly letting people know when the Developer does not know something. And taking the time to learn it afterwards.
    • Saying no when a request is made of the Developer that runs counter to their ethics, morals, or would involve working hours that negatively effect their personal life.
    • Acting as a Delegate and a Salesperson so long as this organization has done right by the Developer.
    • Informing Management as soon as the previously mentioned responsibility cannot be discharged so that Management has an opportunity to correct course.

    There is no associated pay increase. Congratulations.

     - Management

    Exponentials

    by Zach Briggs

    Update: Jon Hogue thinks 10X is too low.

    The top 1% of developers are an order of magnitude more effective than the bottom 1% of developers. That old saw about the top 1% being 10 times as effective as the median programmer is not true, they're merely 3 times as effective.

    Merely 3 times as effective. 

    I firmly believe that the only difference between these exponentials and the rest of our community is the absence of smug self-satisfaction. They fight the Tar Pit of Immediacy not by constantly looking for evidence of how awesome they are, but by finding new and interesting ways in which they suck. By writing code that they hate not 6 or 3 months after it leaves their fingertips but code that they hate immediately.

    Go forth and write some code that you hate, today. Write that code and then search for a way to make it better.

    I wish/ If only + S + past

    by Zach Briggs

    Yesterday my long absent friend "if only" dropped by for a surprise visit. He wished that I had prepared my talk by bouncing ideas off of other smart people instead of working on it in isolation. My long absent friend is a douche bag because I don't actually own a time machine.

    That voice of regret is very useful in some indirect ways despite the fact my I-wish's are unachievable without time travel. Whenever it pops up I know that it's a warning flag alerting me to some sort of buried anxiety that I should probably deal with. 

    Questions that I ask myself

    • What is really bugging me. Is there something unrelated that's really at the root?
    • Is it truly too late? Can I try again and use the new wisdom to succeed?
    • If it is too late and life now sucks, now what?

    My regret over my talk not being better prepared is probably anxiety that I blew my one chance to speak at a national conference. My action here is to gut the original talk and build a new one with many small iterations involving feedback from smart people. 

    Don't Believe in Yourself

    by Zach Briggs

    Stop believing in yourself and stop telling others to believe in themselves, too. Self confidence is a trailing indicator that occurs after you get some successes under your belt. Imploring others to have that confidence early does them no good and makes you sound like an inspirational poster.

    Instead of believing in yourself, have a recipe for change. Simple and foolproof, when followed to the letter it makes 1 dozen awesome every time. Adjust cooking time for altitude and human. Follow that recipe a few times and self confidence will follow.

    You've got to find that recipe for yourself, though. Here are some places to start looking:

    Learning On The Job Is A Lie

    by Zach Briggs

    We don't learn; we race into tar pits.

    Oh sure, we naturally learn at a very rapid pace right up until the moment we can ship production code at that new job. I submit that our natural state after that is a plateau, we all but stop naturally getting better. We're in a hurry, right? We've got production code to ship so when we're under the gun we keep reaching for the first thing that worked. Ever hear "the same year of experience 5 years in a row?" Yeah, that.

    I believe that this is why the common advice of learning a new programming language every year came into vogue. It gives us a place to zero out our proficiency so we can race into new and exciting tar pits. 

    I also think that learning a language that we're never going to put into production is a highly inefficient way to get better. We can stay at that job, using the same language, and through dedicated practice become terrifyingly good.

    Learning on the job might not be a lie but it sure as hell isn't the default. We've got to opt into it.

    Fundamental Particle of Development

    by Zach Briggs

    In Rails Active Record is not a fundamental particle because we slip into SQL very often. Knowing this I would recommend that a person learning Rails actually start with enough SQL to pull off some select * from table statements from memory before attempting that first app.

    What about jQuery on the front-end? Is the jQuery CSS selector such a good abstraction that I never need to manipulate the DOM without it? Is it worth my time as a novice to understand what jQuery is hiding from me? Is it enough that I get the gist or should I be able to implement a significant web app without it?

    Your Employer Owes You Nothing

    by Zach Briggs

    You don't deserve more money, a bigger office, a nicer chair, or more vacation time. "Look at the car the owner is driving; they can afford to pay me more."

    This is not about what they can afford or what you deserve, this is about the market*. We trade goods and services for money, and your time is no different. If you feel that you are not sufficiantly compensated then start looking somewhere else. 

    Your time is worth exactly what somebody will pay for you for it but you'll never find out what that is until you start looking. Buy a hiring manager from another company a beer sometime and strike up a conversation. Make some good stuff happen for yourself.

    You deserve it.

    *This is not a political statement but a call to action for employed information workers.

    The Two Ways I Learn

    by Zach Briggs
    1. I have to
    2. I have to

    That's it, though some explanation could be in order on the why's. Way 1 is due to external forces pushing me outside of my comfort zone and indirectly inducing me to learn a new skill as a means to an end. My favorite example is how I learned to build and deploy a Rails app because I had too many reports to generate by hand. Now I write Ruby and JavaScript for a living from my home. If it weren't for that first shotgun app then I would probably still be doing Direct Mail analytics in Lancaster, OH.

    Way 2 is being so into something that it is impossible not to learn. My friend Joe has a sickness with playing guitar; he just can't not play and therefore is freaking amazing at it. I want to want to play guitar as well as Joe does, but I just don't and it bugs the heck out of me. (I probably need to let myself off the hook for that.)

    Since I cannot simply learn through wishing I had more discipline I must therefore be sure that I'm in situations that are always slightly outside of my comfort zone. When I feel terrified of messing up then that means I am living life well.

    • Do not suffer a profession that doesn't push you.
    • Volunteer for something just outside of your ability. Want to start teaching? GDI could use some volunteers.
    • Troll Craig's List for freelance work. Want to break into Web development? Agree to build a Web app for money and be amazed at how dedicated you become to finishing it.
    • Let yourself off the hook for shit that you're not ever going to do. You'll feel better for it. and that might open up the space for a thing that you'll actually love.

    Don't Let A Mentor Slow You Down

    by Zach Briggs

    Another common refrain I hear is "I need a mentor." This is probably because a relationship with a great mentor is a rare gift that should be protected and nourished. Those that were guided, hand-in-hand, by a mentor right from the beginning are super lucky. Let me tell you a little secret about me, though.

    I didn't get here by waiting around to be mentored.

    The best way to learn is going to be pretty specific to you, but you're going to need to do the heavy lifting on your own. Decide what you want out of life, perform some tutorials, solve some puzzles, attend a class, build some shit, or commit the important stuff to memory. These are verbs. Learn to love them.

    You don't need a mentor and waiting around to find a good one could even slow you down. I'm not saying that you shouldn't ask for guidance, but don't use being on your own as an excuse. You got this. The verbs, remember?

    Drop me a line if you get stuck, though. If you're against a brick wall and making no progress for more than half an hour, you're better off getting a hand from somebody like me rather than slogging through it on your own. I'll also be happy to pair with you or hop on a hangout for an hour or so and we can bounce ideas off each other. The various ways to contact me are listed here.

    But don't treat me like a mentor. I'll just slow you down.

    How I Test Controllers

    by Zach Briggs

    I don't.

    My controllers tend to come in two flavors:

      1. Scaffold
      2. Other

      Type 1 is providing an external api to a database and is interacting directly with an Active Record object. Type 2 will be making calls to a Plain Old Ruby Object or maybe my own interface defined in a model. In either case, there is absolutely no testable logic left in a controller, therefore it is not under unit test.

      I arrived at this solution not because I was drawing colored rectangles on a whiteboard and reveling in Architecture. No, it's because testing controllers is a pain in my ass and I would rather not do it. Extracting every last drop of logic out of them just happens to be the path of least pain.

      My path.

      Refactoring Is Its Own Skill

      by Zach Briggs

      And I suck at it. Don't get me wrong, I can start a Rails app from scratch and grow the thing; shipping features at an almost linear velocity. It is a skill that I worked my ass off to achieve and am quite proud of it, thank-you-very-much.

      But starting with a mess, that is a different story altogether. Think of when the code is already tangled; interpolated SQL in the 1,000 line controller, everything else shoved into the junk drawer of the User model. Starting from there I have a much more difficult time; to the point where I doubt my confidence as a programmer.

      That is changing.

      Katrina Owen was good enough to give a workshop on refactoring at RailsConf using this online tutorial that she wrote. I am in the process of memorizing the steps and turning my greatest weakness into an asset. Consider doing the same, you won't be sorry.

      Update:
      Katrina has an excellent writeup of her surprise 90 minute live coding session from RailsConf. 

       

      Reading Tech Books

      by Zach Briggs

      They tend to be awful and you should never feel obligated to read one. Generally they are written in a formal tone with less emphasis on conveying information in a digestible manner and more on making the author sound smart. There are a few that manage to buck this trend, but even then I do not learn enough to change the way I program without additional practice.

      I actually do start tech books all the time and put most of them down after dragging myself through 1 or 2 chapters having learned nothing. I have read exactly 2 tech books from cover to cover because I found the narrative riveting. 

      The act of reading these still did not teach me anything directly but rather moved some chunks of knowledge from unknown unknown over to known unknown. From POODR, for example, I knew that I didn't know how to apply composition but I at least knew that was a thing that I should pick up. Sitting in bed with the Good Parts didn't teach me a lick of JavaScript but the book instilled in me a respect for it as a real language and inspired me to spend time learning it.

      I have used many more tech books than those two to learn programming, but never by actually reading them. I'll write a post on how I approach learning from books some other day. Today, though. Today is going to be for actually writing code rather than writing words.

      Because I have code in my fingers that needs to get out.

      How to Get Your First Ruby Job

      by Zach Briggs

      The steps are simple but not easy; achievable by anybody who has successfully pushed a hello world website to Heroku. 

      1. Practice the Ruby on Rails Tutorial until you can implement Twitter from memory.
      2. Go to the local Ruby user group EVERY MONTH. More importantly, go to the bar with the group afterwards; even if you don't drink. Buy 1 beer for a hiring manager every time. Bring an ally if bars are problematic.

      It was a short list. If you live in a city without a Ruby user group and writing Ruby makes you happy, then move. Seriously. Entry level remote junior positions do not exist, but after a year you will be able to find a distributed mid-level position and move back.

      If you can't afford 1 beer a month for a hiring manager then I will mail you a $10 bill. If you are in the unfortunate position of needing to move, then I will help you find a couch to crash on in your target city. If there is another barrier in the way, email me and we'll work through this together.

      Make it happen, because nobody is going to do this for you.

      Watch Me Run My Mouth on Growing Developers

      by Zach Briggs

      Thanks to Zee over at Growing Developers for inviting me to run my mouth on the show.  I had some very strong opinions on moving people from beginner to intermediate and some vague ideas on moving from intermediate to expert. Talking with the panel gave me a much clearer path on the next leg of my journey; maybe it can help you on yours.

      http://growingdevelopers.com/self-directed-learning-part-1/

      Dotfiles >> Git in 3 Minutes

      by Zach Briggs

      This is inspired by the last (for now) Destroy All Software screencast. I've been meaning to get my dotfiles back into source control for a long time now, but the various symlinking scripts are a royal pain in the ass; both to maintain and to setup for the first time. Somehow it never occurred to me to just, I don't know, add my files directly to git?

      1. Start by ignoring everything by default.

      $ ls -An >> .gitignore

      2. Clean up .gitignore by replacing file info with a "/"

      /.DS_Store
      /.Trash
      /.anyconnect
      ...

      3. Initialize the repo

      $ git init
      $ git status

      From here it's a matter of whitelisting the files that are going into source control by removing them from .gitignore and then committing/ pushing to a server. Mine are up on Github for anybody who is looking for the secret to an 8 mile long path.