While I Compile

… I compile my thoughts about programming

A very simple Pair Programming IP Rights Agreement

Once in 1998, I sat down with my manager (the only manager I’ve ever had who could program), and we banged out some code for about 2 days. It was a very fast paced synergistic activity where one idea fed another and at the end of 2 days our initial idea morphed into something completely different and a heck of a lot better.

Well, tonight 11 years later, I’ve convinced my colleague Ben Alabaster to come over and pair program. I don’t know how it will go, I’ve got high hopes, but I am confident at the end of the night both Ben and myself will be a little better as programmers, and might have even started something worth finishing.

But two things I do know: 1) if we come up with something good, we’re both going to want to use it. And 2) if we ever get to the point of needing an agreement outlining our IP rights, it will be too late to draft one. So, Ben & I threw together some basic rules yesterday. Frankly, I’m surprised I couldn’t find any on the net already, maybe I over think this stuff more than most people, or perhaps it’s because I just didn’t look that hard.

So here’s what we agreed to:

  1. Each of us, individually, is free to use any programming concept shared, discovered, or created.
  2. Each of us, individually, is free to use anything we cocreate as part of a larger project with a significant amount of additional functionality. This can be a personal project, business project, or consulting project.
  3. Each of us must agree to release any code or binaries either as a commercial product or open source. Each of us will share any credit and/or financial profits equally.

I’d love to hear other people’s perspective and comments about this.

Copyright © John MacIntyre 2009, All rights reserved

June 23, 2009 Posted by | Career, Programming, Team Dynamics | , , , | 4 Comments

11 Personal Programming Assumptions That Were Incorrect

Today I got side tracked and spent an unreasonable amount of time on StackOverflow.com. One of the questions I was looking at was What is your longest-held programming assumption that turned out to be incorrect?

Many of the answers immediately resonated with me, like Instantsoup’s answer That people knew what they wanted and JohnFx’s awesome answer about comparing his knowledge to the collective knowledge of all other programmers. Other answers reflected a poor initial understanding of the language or technology, many of these I was fortunate enough to not relate to.

As you can imagine, I immediately started coming up with my own answers, so I continued reading to make sure they weren’t already there. But as I read, I came up with more initial assumptions which proved to be false. I thought I’d pick out the best, and answer with that one, but realized I had a whole blog post!

So without further ado; here is my list of assumptions about programming and the industry which proved to be incorrect:

  1. The customer and user are the same person.
    In consulting with custom in house software this is (almost?) never the case. The customer has their eye on the budget and many won’t give 2 cents to make something easier for the user.
  2. You isolate and kill all bugs without exception
    Truth is; there will always be bugs, and what gets fixed is an ROI decision.
  3. Writing beautiful software as an act of craftsmanship
    It’s taken a LONG time for me to get it through my head that it’s just another financial investment, where you want to get as much as possible while giving as little as possible. However, although I know it intellectually, I still don’t ‘get it’.
  4. Working 24/7 would be rewarded
    Truth is, working all the time will burn you out, lower your productivity, and cause you to make stupid mistakes which reflect on your professional abilities.
  5. Vendors can be believed
    In my experience, don’t believe the product will integrate as seamlessly as they say without getting their API documentation and building the whole integration mentally first.
  6. You are not actually working from the monitor.
    With today’s GUI platforms, this is largely abstracted out, so you can actually program believing that a textbox is a physical entity. But when you are managing your own graphics, that textbox isn’t going to capture your keyboard presses and display them, unless you provide the illusion. It’s actually up to you to capture the keyboard input, and adjust the memory buffer containing your screen image with the newly typed letter in the control. This was a real mind bender for me, when I first got into this.
  7. That I wasn’t a very good programmer
    Like JohnFx’s answer, I was unsure about my abilities. I don’t have a C.S. degree, and was overwhelmed by the depth and breadth of the knowledge out there. But the more people I meet, the more I realized, I might actually be pretty good. Don’t get me wrong, under malicious attack, there are many who could expose and exploit the holes in my knowledge, but in my general area (business software), I’m finding that I’m not too bad.
  8. You need to / should grok a language or tool before you even start.
    Groking is a powerful way to start with a new language or tool. But in reality, especially with consulting, there isn’t always time. If you can hack something together in a completely unfamiliar language/tool/framework/paradigm/etc in 5 days, and it would take somebody who knows it cold 1 day, but it would take you a month to grok it … you hack. You may not want to, but from a business perspective … that’s the correct answer.
  9. You don’t say you know something unless you’ve grok’d it.
    Well, you don’t need to have too many conversations with too many programmers to know this idea is not wide spread.
  10. Other programmers saw beauty in their work.
    Personally, a well written piece of software is similar to a piece of art. It’s my form of artistic impression. It’s my baby. However, there are many people in our industry who do this 9-5, and appear to get no more enjoyment out of it, than I got out of a factory job I had in my teens.
  11. The best programmer is recognized
    In retrospect this is almost laughable, at least in consulting! If programmer A writes a wiz bang sub system, takes 2 weeks, it’s flexible to extend, and the core system never requires maintenance. Programmer A would not be held nearly in as high regard as programmer B who takes 1 week, hacks together a piece of garbage which is a nightmare to extend, and is maintained with multiple bugs for it’s life time. This is unfortunate, but in my experience, only a very capable manager would know the difference.

Copyright © John MacIntyre 2009, All rights reserved
WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

June 4, 2009 Posted by | Programming | , , | 12 Comments

   

%d bloggers like this: