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

    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]
    # *~

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

    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 →
  • Just an iPhone

    Continuing with the I think I want to make videos era has me thinking of a new constraint.

    Not only could I use stories on Instagram and Snapchat. I could limit any videos to only iPhone created content.

    I think this forces me to not get fancy. Just think about what I want to record, record it, arrange it, and post it.

    So far I’ve learned that less is definitely better. I created something way smaller today. And I think I can go even smaller tomorrow to make it better.

    Oh, and I ordered a tripod for my iPhone. Shaky video has been a problem. Short and steady.

    Read Just an iPhone →
  • Making Movies. Sort of.

    If you are a programmer, you might have heard that you should have a hobby that is not programming. I’ve always said mine was playing guitar. But if I’m honest, I don’t play that much anymore. I still play around here and there, but not nothing serious.

    I’ve been watching Casey Neistat videos recently. I’ve really fell in love with his stuff. So much so that I think I’ve been inspired to try some sort of film making. Not full blown movies with actors and scripts, but short videos of some sort. It seems like it would be fun.

    A few ideas.

    • A documentary of the making of a web app from start to finish. A behind the scenes look at what it takes to make an app.

    • Some sort of a Day in the Life of a Developer series.

    I know nothing about film making. I’ve done a small bit of reading. I tried to record some footage and then edit it yesterday. I learned that it’s really hard. Like really, really hard.

    I’m currently playing with stories on Snapchat and Instagram. This gives me the freedom to play around with scenes and different things with the overhead of editing and such, while I learn some concepts. I suck pretty bad right now, but that’s the fun part. I get be a newb for a while.

    You should say hi over there.

    Instagram: ScottRadcliffAgain

    Snapchat: ScottRadcliff

    Read Making Movies. Sort of. →
  • Retreat

    Everything is messed up today. One of those days that is just messed up from the time you wake up. Bad news in text messages, a bad haircut, even my latte is bad.

    Sitting here in a coffee shop. I just needed some time. Time away from people, from the daily routine, just everything.

    This reminds me of people that take personal retreats. They just go off by themselves and just reflect. Reflect on where they want to be. Maybe where they came from. And definitely how they got to where they are now. Maybe they think about the things in their life that they don’t like. Things that don’t bring any happiness. By the way, you should shed all of those things.

    I wonder how a person can do this without the luxury of having enough free time for that. I know I can’t get that much free time. Maybe that’s part of the problem.

    Maybe retreat doesn’t mean what I think it means?

    I guess I took the term retreat as a term to describe this type of solo time, but if you look at the definition, it has some interesting variants.


    (of an army) withdraw from enemy forces as a result of their superior power or after a defeat: the French retreated in disarray.
    • move back or withdraw: it becomes so hot that the lizards retreat into the shade | a series of trenches which filled with water when the ice retreated | (as adj. retreating) : the sound of retreating footsteps.
    • withdraw to a quiet or secluded place: after the funeral he retreated to the shore.
    • change one’s decisions, plans, or attitude, as a result of criticism from others: his proposals were clearly unreasonable and he was soon forced to retreat.
    • (of shares of stock) decline in value: [ with complement ] : shares retreated 32 points to 653 points.
    • [ with obj. ] Chess move (a piece) back from a forward or threatened position on the board.

    I really like two of these. The first one. withdraw from enemy forces as a result of their superior power or after a defeat…. Often a retreat feels like regrouping after defeat. I doubt anyone would call it that. But that’s what it is. You’re defeated and need to regroup. The second one, and a more descriptive version of what I think a retreat is, says change one’s decisions, plans, or attitude… That’s really what it is. Actually. Maybe we can combine the two. withdraw from enemy forces as a result of their superior power or after a defeat, and plan to change one’s decisions, plans, or attitude for success I think I like that. I retreat because I am defeated and need to plan a new path for victory.

    If I now look at a retreat as a withdraw from enemy forces as a result of their superior power or after a defeat, and plan to change one’s decisions, plans, or attitude for success, I can manage that. I can manage a couple of hours a week to reflect and plan. It’s not always defeat, but there is always reason to plan and change direction.

    Read Retreat →
  • Unintended Consequences of Group Chat

    I’ve started to notice a side-effect of nearly instant communication within teams. This could be applied to any service. The results will be the same. But for this example, Slack is pretty much the default.

    The Era of Email

    The problem stems from how email works and how we have been trained to think about communication.

    When I send an email to a colleague, I can’t see them online. I have no expectation of when they might read and respond. Typically, I expect 24 hours reasonable. When I send a message via email, I am okay with a response the following day.

    Slack sets a different expectation. Especially direct messages. To me, a direct message communicates importance. When I receive a direct message from someone, I think this is important. It’s like setting a priority on an email. Thankfully no one does that anymore. It’s awful.

    Email doesn’t really communicate importance. Well, besides the priority method. Not that we haven’t tried. Stars, priority inbox, filters, etc.. These are all methods to try and extract things that are important. I think they all fail. Turns out chat fails also.

    Enter Group Chat

    Here’s the kicker. In Slack, we can see who’s online. More importantly, we can see who’s not online. This is where it gets tricky. If I am typing a message to someone, and that message is important to me, and I see them come online as I am typing it, still online as I send it, and then they go offline without responding to my message. It leaves me to think that they chose to ignore me. That whatever I had to say is not important to them. Even though it was important enough that I felt I needed to send it to them directly.

    Now that I know that they saw my message and chose to ignore it. Do I say why did you ignore my message? or maybe I say Did you see my message earlier?, knowing that I saw them come online and leave without acknowledgement. Maybe I just continue and say nothing knowing that I saw them ignore it. They don’t know I saw them ignore it, so it seems like a non-issue to them. A no harm no foul type of thing. This is what I do. Just let it go. But it does bother me.

    If this scenario is email. The same person can ignore my email. I have no idea they chose to ignore it and I have less of an expectation of a response.

    Maybe realtime communication is just as bad as obsessively checking our phones for updates. Checking in all the time to see if someone responded to me, to see if they are online yet, or just to see if I have missed something is unhealthy.

    Maybe this type of chat does more harm that good? Maybe I don’t use it correctly? Maybe 37Signals is right about group chat, it really is an all-day meeting with random participants and no agenda.

    And finally, maybe email still has it’s place for communication that is important and has no need to be in chat.

    Read Unintended Consequences of Group Chat →
  • Fun with Metaprogramming in Ruby

    I’ve been programming in Ruby for awhile. Somewhere around 5-6 years. And I don’t really play with the metaprogramming stuff much. I know it’s there, and I know it’s powerful, but I don’t often see a need in my day to day programming.

    I’ve been playing around with a toy app in almost pure Ruby. I say almost, because I am using Sinatra and some libraries, but no Rails or other frameworks. Sinatra has this weird instance variable thing going on where if you are sending the user back to the form after a validation failure, you don’t always get the object back, which leave the form without the previously entered values. I’m sure I’m calling something wrong. This is part of the problem with working in frameworks too much. You lose your edge on how to wire things up with just a programming language.

    So I thought it would be cool to build a couple of libraries to do some regular things that I could reuse.

    Enter FormValues. A simple class that can take a hash of values from a form and generates methods to call these values as needed. I figure this way I don’t need to keep track of objects, I can just call the methods as needed. Seems like a good place for cookies or sessions in pure Ruby. The CGI class has both of these.

    I wanted to show how I created a getter method for each key/value pair from the hash I pass in. The Hash will go away. It will probably become a cookie. I’m still hacking on this

    def initialize(params)
      @data = Hash.new
      params.each do |key,value|
        @data["#{key}"] = value
        define_singleton_method "#{key}" do

    So, if I pass a hash as params like this {first_name: "Scott", last_name: "Radcliff"}. I would get the methods #first_name and #last_name that would return Scott and Radcliff.

    Metaprogram all the things.

    Read Fun with Metaprogramming in Ruby →
  • Thinking is Underrated

    I try to start every programming task with some thought.

    I don’t mean thought as in hacking things together to see what works.

    I mean some thought as in thinking about possible solutions and refusing the accept the first one.

    I think this is a lost art. As programmers, we spend more time accepting solutions then we do thinking through solutions to make sure we are solving the right problem in the best possible way.

    Spending a few minutes scribbling down some notes in a notebook might be the best thing you can do to develop better solutions to problems.

    Read Thinking is Underrated →

subscribe via RSS