• Load Bearer

    Building a Team

    This is going to seem a bit odd. I’m going to compare building a software development team to building a house. But not in the traditional sense of a house; foundation, walls, roof, etc. I am going to compare building a software development team to spreading weight over load-bearing walls.

    I won’t bore you with too many details. But just in case you aren’t familiar, a load bearing wall is a wall in your house that is structurally sound. Take that wall down without distributing the weight and you have real problems. The weak areas start to cave, and then, well you know…

    The counter point is that some walls are non-load bearing. You can tear them out and the rest of the house will be fine.

    I’ve been building a software development team for about two years. The load that any one member of that team can hold is both critical to it’s success, and critical to it’s longevity.

    Parts of the Team

    If we step back and think of a software development team, we have three parts or skill levels.

    1. Senior
    2. Mid Level
    3. Junior


    Senior is the most important. Not because I am senior, but because that’s your first load bearing wall. Without that first piece, you can’t build more walls for expansion. Something, or someone, has to take the weight initially.


    I know I am a little out of order here. Bear with me.

    Junior is your non-load bearing wall. He doesn’t hold a lot of weight. He’s part of the structure, but can be removed without much, or anything, going wrong.

    Mid Level

    A mid level member is starting to take some weight away from the senior. He’s not a full load-bearing wall yet. But it’s a start. The load-bearing senior can breath a little. The part of the house he is holding up isn’t as heavy as it used to be. And it gives the non-load bearing juniors room to expand into a load-bearers.

    Expansion and Growth

    Think of team growth in terms of house expansion. In order for a house to expand, it needs more walls. That’s how it either gains width or height.

    If you expand your house without a considerable number of walls, you’re going to have problems. In fact, things will be worse than they were before you decided to expand.

    In order for the house to not fall on top of itself, it needs more load-bearing walls.

    It simply can’t expand without them.

    Here is that part that might sting. If a non-bearing wall goes too long without taking on some weight from the load-bearing walls, it must be replaced. The structure, in this case the software development team, cannot grow.

    Okay great. But How?

    Okay, that stung a little. You might have someone in mind and think to yourself they have to go. Not so fast. There may still be time.

    To take a non-load bearing wall and make it a load bearing wall, a couple of things have to happen.

    1. Make sure the wood isn’t too green. If it’s not hardened enough, it will warp. And things won’t turn out the way you had planned. No one liked warped walls.

    2. Start slow. Add a brace to the left side. Then one to the right. Before you realize it, the non-bearing member is now helping to distribute the weight.

    Okay, so this was sort of weird. I mean who compares wood and people. The walls are clearly developers. Some carry the weight of the team. Some do not. Some carry some of the load, and that enables expansion and growth. Those are the ones you must keep.

    If your non-load bearing developers on your team can’t move to load bearers, you can never grow.

    Read Load Bearer →
  • Codecation Recap

    I thought writing down some thoughts everyday would be easier. I’m always wrong, but I still try.

    That’s not what this is about. It’s about codecation. I haven’t had any updates. So I wanted to list what I planned on doing, and what I actually did.

    What I thought I would do:

    1. Journal via this site everyday. All the things that were going on, with some images and possibly videos.
    2. Finish my side project to a point where I could ship upon returning.

    What I actually did:

    1. I did recorded some stuff in the notes app on my iPhone, but I didn’t write or blog anything. However, I did share a bunch on Instagram. So maybe I get like a half of a point.

    2. I did not finish the side project. I did make some progress, and I am super close, but not ready. I failed. I underestimated spending two days at a conference and exploring a great city I had not been to before. No regrets. I still had a great time.

    If I ever do a codecation again, I would make a couple of changes.

    1. I would not try to wrap it around a conference. Especially one as cool as Deconstruct.
    2. I would have more structure. I spent a lot of time during the day walking around and exploring. I would have like two days planned to get to know the area, and then dedicate days to working and nights for play for the remainder of the time.
    3. I might have more people. Not sure if this is good or bad. I think it could bring some accountability, but I think it could be added distractions.
    4. As awesome as Seattle is (I would love to move there), it was really far. I might go some place closer. At a minimum, I would add a shopping day for groceries to cut down on costs and the need to go out for food.
    Read Codecation Recap →
  • Great People Do Great Work

    I’ve been reading Creativity Inc. It’s really just a book about how Pixar was built. Ironically, it has a management twist. I didn’t realize this when I bought it. I’m just a fan of Pixar and have been reading biography type books lately. I’m a sucker for movies based on true stories. So I figured why not read some books of the same type. But back to the point.

    In the book, Ed Catmull is talking about some of Pixar’s successes and some of their failures. He says something that has stuck with me for a few days now.

    Getting the team right is the precursor to getting the ideas right

    The general idea is this: You can give a mediocre team a great idea and they will build that great idea, but a mediocre team will never make a mediocre idea great. Contrary, you can give a great team a mediocre idea and they will make it great.

    This backs up my thought process behind recruiting and hiring at Whitelabel. I look for great people, not necessarily great developers. Not because I don’t value great developers. But because a great person can become a great developer. A great developer that is a jerk, can’t always become a great person.

    Bet on people, not skills.

    We’ve had huge success with this at Whitelabel. We have great people that have become great developers.

    I’ll bet on character over skills every time. No question.

    Great people do great work.

    Read Great People Do Great Work →
  • Codecation is Getting Closer

    I may be a little too excited. It’s the month of my codecation and I’ve been counting down the days on Twitter. I imagine this may get annoying for some people, but it does a couple of things for me.

    1. Help remind me to hang in there. I almost have a vacation. It’s been several years since I’ve had an actual vacation. The last time I had a vacation was when my daughter was graduating from bootcamp for the Marines in Parris Island, S.C. – Not sure that qualifies as a vacation, but that’s those closest this I have in about 4-5 years. I’m ready!

    2. Remind me that I have work to do before April 19th gets here. I have a lot of pre-work to do before we leave. Some last minute travel details, but more importantly, I need to get my side project in a place that is good for me to finish it. This includes hangover days.

    With roughly four weeks until codecation is over and I need to ship, here is my loose schedule for my project. Disclaimer: I’m about 80% done, but not happy. I decided to go back and wireframe the entire thing so I can get a good plan for finishing. I never did that at the beginning. I just hacked some stuff together.

    Week One - Wireframing Done.

    Week Two - Remove stupid design that is in place now. It’s garbage.

    Week Three - Build graph. The app I am building has graphs for some commit data.

    Week Four - Billing stuff and launch!

    Read Codecation is Getting Closer →
  • Finishing

    I am an expert at starting projects. I mean like a super expert. I know everything to do. The methods of getting started sometimes change. Sometimes I start with a pen and paper. Sometimes I make a digital wireframe. Sometimes I open a text document and start writing what the app is and what it does.

    The point is that I have nooooo problem starting. I have tons of apps that I have started. The team I work on is pretty good too. We are actually eager to start something new. Everyone is happy. One might even say giddy to get started.

    But. As with thousands and thousands of creative people, finishing is an issue. It’s that last 10%. And worth mentioning that 10% varies by project. But it’s that last little bit that goes on forever.

    I wish I knew the solution. It’s actually kind of depressing. It even effects me in my day job. I guess I take that responsibility on.

    I’ve been spending some time thinking about finishing. I have a couple of conclusions.

    I think creative people that have trouble finishing, have trouble with the following:

    • Shipping feels final. Especially for client applications. For me, when I say something is done, I feel like I am saying this is the best I can do. That’s never the case. I can always do better.

    • Done brings judgement. Similar to the previous point. Judgement like this is great, but it doesn’t do x.

    • And a general punch list of things that have been discovered and need to be added.

    In other words: I always feel like I could do better.

    I think I have a solution. It’s goal setting. I know I know, booooring. But it’s the best I got.

    Agile brought this idea that software projects never finish. And that’s true. Completely. But since then, I’ve worked on very few projects with a defined timeline, or even a loosely defined timeline. All of my side projects have no timeline. I don’t think about what done looks like. I don’t think about when that should happen. And I sure don’t track my progress and course correct.

    Day job is a little different. I do think about what done looks like. But we often lose that at about the halfway mark. We still ship, but we don’t finish as well as I’d like. We can better. Much better.

    I’m going to try and make better milestones/timelines for some side projects and see what happens. I need to define some goals for codecation. Seems like a good starting point.

    Maybe I should talk about it publicly. Nahhhhh. That’s too scary.

    Read Finishing →
  • Codecation

    I’ve wanted to go on a codecation since I first heard about it a couple years ago. It’s a great idea. A couple of developers holed up in a new location and a new place (probably an AirBNB) with no distractions. Just an laptop and a product to build or code to write. I’m finally getting my chance and I’m pretty sure it’s going to be awesome!

    When a friend and I heard about Gary Bernhardt’s Deconstruct Conf, we immediately knew we were interested in going. I hadn’t really considered a codecation type of thing. But when you surround yourself with brilliant people, they think of things for you. And so, we decided on an amazing conference in Seattle and mini vacation to blast out some code.

    I have a project that I have been trying to ship. Like for a long time. Because I suck at finishing. That’s what I will be working on for about four days. It’s a product around hiring and recruiting for tech companies. Codename: Rockstar Ninja. Again, the name was not my idea, but an idea from the same dude that said Hey! Let’s take a codecation.

    I plan on recording some parts of the trip. Not sure what I will do with it yet, but hopefully something interesting.

    Read Codecation →
  • Ignoring Files Locally With Git

    — layout: post title: Ignoring Local Files with Git date: 2017-02-04 —

    When your are working on a team, it changes some of the decisions regarding things you may or may not want to add to the codebase. If everyone has their personal preferences in a project, it can become pretty polluted.

    I often like to have some text files to track tasks and other notes regarding a feature I may be working on. I could add these files to the .gitignore file, but I’m sure I’d be questioned as to why I was adding that. And with good reason. I should only add things that are project specific, not programmer specific.

    Turns out, I can have some sort of local .gitignore.

    Your .git directory has a lot of stuff. Lots of useful stuff. Admittedly, I’ve never really looked inside. As it turns out, it contains an exclude file in .git/info/exclude

    By default, it looks something like this:

    # git ls-files --others --exclude-from=.git/info/exclude # Lines that start
    with '#' are comments.  # For a project mostly in C, the following would be
    a good set of # exclude patterns (uncomment them if you want to use them): #
    *.[oa] # *~

    Anything you add to that file will be ignored locally.

    So, in my case, I want to ignore issues.txt. Adding that line to the file, sets me up.

    # git ls-files --others --exclude-from=.git/info/exclude # Lines that start
    with '#' are comments.  # For a project mostly in C, the following would be
    a good set of # exclude patterns (uncomment them if you want to use them): #
    *.[oa] # *~ issues.txt

    I can see a potential issue with forgetting that you added lines to that file. For more information, check out the docs https://git-scm.com/docs/gitignore

    Use with caution.

    Read Ignoring Files Locally With Git →
  • Writing Code

    Anyone that knows me, knows I’m a huge fan of readable code. I think all code should explicitly say what it does. I’m favorable to long method names. Sometimes long class names. And if it makes sense, I am okay with a large number of files. Even if those files don’t contain a lot of code, but help the programmer understand what the program does.

    The style I favor is not quite Literate Programming, but close. I’m not really a fan of writing a mountain of documentation to explain every facet of a program. I am a fan of writing just enough documentation to help the reader understand.

    But better than writing documentation to understand the program, I prefer to write the program in a way that is clear what the program does. Code is written for programmers. The computer only understands it once it’s in binary form. The computer doesn’t care if your methods are short, how many of them there are, or how clever the code is. (of course this doesn’t take into account performance. The computer obviously cares about how efficient code runs.)

    In Code Complete 2, Steve McConnell talks about Common Software Metaphors. One of the first ones he mentions touches on Software Penmanship. It reads:

    The writing metaphor suggests that developing a program is like writing a casual letter— you sit down with pen, ink, and paper and write it from start to finish. It doesn’t require any formal planning, and you figure out what you want to say as you go.

    Not sure I would go that far. I might say that the writing metaphor suggests that writing code is like writing an essay. Thinking about what you want to say, outline it, write it, and then edit until it’s good writing.

    Writing a casual letter requires you to think about things you might want to say as you go along. In my experience, this always results in things that I have forgotten to say. In software, this results in incomplete features or bugs. Because of that, I think the metaphor fails a bit.

    McConnell seems to agree with my theory.

    For an individual’s work or for small-scale projects, the letter-writing metaphor works adequately, but for other purposes it leaves the party early— it doesn’t describe software development fully or adequately. Writing is usually a one-person activity, whereas a software project will most likely involve many people with many different responsibilities. When you finish writing a letter, you stuff it into an envelope and mail it. You can’t change it anymore, and for all intents and purposes it’s complete. Software isn’t as difficult to change and is hardly ever fully complete.

    McConnell talks about growing a system. Writing code incrementally. But, with a more detailed approach.

    You design a piece, code a piece, test a piece, and add it to the system a little bit at a time. By taking small steps, you minimize the trouble you can get into at any one time.

    If approached like an essay, more thoughtfulness is involved and ideas can still be added as you go. I think this leads to a better experience for the developer. Both the developer writing code and the developer reading the code.

    The act of writing code is an act of telling another programmer what you expect to happen when the program is run.

    Read Writing Code →
  • Directing

    Going from developer to manager. Or from regular developer to senior developer. Okay fine. Director of Engineering. Whatever it is. Pick a name. At any rate, it’s not difficult. But it’s certainly different.

    I spend most of my time now thinking about how to make sure the developers on the team have everything they need. I work for them now. I spend the rest of my time thinking about engineering stuff. How can we make deployments better? How can I make the environment productive? How do we ensure that we are shipping the best possible code we can in a reasonable amount of time.

    Once in a while, I fall back to programming. I need to jump in and start building features. By far, the most difficult thing I do is jumping from programming to mentoring/leading and back again. It’s such a context shift. I find it really hard to do both. I’m fine with one or the other.

    When I just lead, set direction, make sure obstacles are removed, or jump in to help developers get unstuck. That’s where I am at my best.

    At some point. developers figure out that they are more valuable sharing knowledge than keeping it to themselves. Some developers never figure it out. Managing isn’t a bad thing, it’s just a different thing.

    Read Directing →
  • Failed Experiment

    I’ve been inspired by Jennifer Dewalt and her quest to learn how to make websites that resulted in 180 websites in 180 days.

    That’s an epic achievement.

    I wondered how this could be applied to programming? Could I create a new program/application everyday for 30 days? Not even 180. Just 30. I got my answer. NOPE.

    The first day was easy enough. A simple Pomodoro App. I actually thought I could do this. Day one was pretty simple. Well… day two… not so much. I could make some progress, but I couldn’t finish something everyday. Not and have it worthwhile or interesting.

    So I failed.

    That’s okay.

    Regroup and try something else.

    So now I am trying to just program something for fun everyday. A couple of rules.

    1. It cannot be work. Meaning it can’t be a work project, or something I have to do for my job. Even though that stuff can be fun too.

    2. It cannot be a startup, business, or for money. This changes my mindset. I think about these differently. When I mix these, the projects always fail.

    We will see how this goes.

    Read Failed Experiment →

subscribe via RSS