• 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.

    Continue Reading 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.

    Continue Reading 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

    Continue Reading 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!
    Continue Reading 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.

    Continue Reading 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!

    Continue Reading Codecation →
  • Ignoring Local Files with Git

    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.

    Continue Reading Ignoring Local Files 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.

    Continue Reading 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.

    Continue Reading 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.

    Continue Reading Failed Experiment →

subscribe via RSS