Another Codemash has come and gone, which means there are more than a few recap posts out there, so I'll add mine to the pile.
The biggest take away for me this year was the sheer number of people I got to talk to, shake hands with, and bend an elbow with. In past years, that group has been basically limited to the other Quick folks that were up there or a small circle of people outside of Quick that I knew. This year, though, that number was much larger. I can easily attribute this to two things.
First, I got out and about in the community more in '08 than in past years, including a few speaking gigs around the region. I got to hang out for extended times with new colleagues from Cincy to Grand Rapids and a lot of places in between. That made for a lot of familiar faces while strolling around Kalahari.
Second, and this is probably the larger of the two: Twitter. I started in on Twitter last year after Codemash and before I headed to Mix, and it showed at this year's edition of Codemash. The number of people I could talk with in person because we'd had a few conversations on Twitter made starting those conversations much easier.
For the content itself, I was really impressed with the Pre-Compiler. This was the first year for the extra day, and I wish they'd have spread that material over the whole conference. I found myself wanting to be in three places at once on Wednesday. I ended up with a morning of Ruby with Joe and Jim, and an afternoon of Lean and Kanban with Dave Laribee.
For the full conference, I was all over the place. Some open spaces, some sessions, some hallway conversation, some recovery time that we don't need to discuss here, etc, etc. I took in Venkat's second session (skipped the Scala one), made sure I saw Mary Poppendieck, saw Laribee's DDD talk, and a few others.
Open Spaces I was really looking forward to on the heels of all the news from DevLink and what Alan Stevens did down there. I got to two, one on pair programming and one on branding yourself. I submitted one, but thanks to the snow and the room changing a couple times my turnout was five other people from Quick. We decided we could cover this at another meeting and headed back out into the sessions. So, overall I was a bit let down with the Open Spaces, but I think good content in the sessions combined with good content in the Open Spaces makes for some tough choices. Alan runs a slick Open Space, though. The ceremony is kind of cool. [Insert essence v. ceremony joke here]
My mini-speaking part in the show was when Jon Kruger, Steve Harman, and myself gave some first hand experiences with Kanban in the QSI vendor session. We ended up with a decent turnout and went 10 minutes over our allotted time taking more questions. I thought it turned out really well.
So, another Codemash behind me, and another kick in the butt to start the new year. Top of the list, clean up the blog. In the branding open space I learned that using the default theme from .txt turns people off...thank goodness I use the default blogger theme, instead. I'm going to get Graffiti installed and get a better look for it.
Sunday, January 11, 2009
Wednesday, November 19, 2008
Kanban-o-rama - Part 2
In part one I laid out the why and the how of our Kanban set up. In this part, a nice cell phone picture and some what it's done for us.
The Board
Here's our "borrowed" whiteboard. In stroke of genius from Mark, we drew the dividing lines with a Sharpie which makes them semi-permanent. One post-it note equals one work item, so for every post-it on the board there's a corresponding entry in our SharePoint work item list. Yellow post-its are regular priority items, purple tickets are high priority. (The stray colors are just strays...green == yellow, and fucia == purple.)
To the right of the names is where we start working with the tickets in the backlog column. It's sized to fit three tickets to help enforce our max three rule for that slot. Below that is the Blocked area, which isn't sized to scale of their respective max allowable tickets.
Moving to the right across the board is each developer's Work in Progress slot. Again, sized to enforce the max allowable items. This is where carried over our dotting strategy from the previous set-up: Yellow is domain understood, green is design understood and in dev, red is dev complete, blue is in production. (Though following this photo we have decided that blue will mean passed testing in staging, ready for production.)
At the bottom of the Work in Progress column is our Emergency slot. This is where our "drop everything" items end up. To our surprise, it hasn't been utilized as much as we thought it would.
To the right of the Work in Progress slot are our Ready for Test and Tested slots. These are the first real community slots on the board, and the honor system is in place for getting things tested. So far, so good on that.
The far right of the board is open space for notes, tracking what's gone into production, and blimp drawings.
What its done for us
So far the big win for us has been gaining focus on one item at a time. We still have some growing to do in this area, as the inevitable "How long would it take to do X?" questions come up daily, and you find yourself looking at code you weren't aware existed when you started the day. So, we're trying to push harder to keep the distractions down, and keep the focus switching lessened.
Another thing that moving to this system has allowed is that it's much eaiser to report up the chain of command what each person is working on. It's much easier to manage expectations on when something will be finished and when another item will be started. Also, when the, "Item Q has to be done right away," request comes in I can say which items are being worked and ask which one should be stopped to pick up Item Q. Now that I can better articulate what each guy is doing, these requests are more often becoming, "Oh, this can wait until one of those is finished."
We've been using this for about four weeks now, and have had a few discussions around it. The early returns from the dev team is that they like it quite a bit. The numbers reflect that it's working, too, as we've closed more tickets over the last four weeks than we had in any four week period since mid-July.
The Board
Here's our "borrowed" whiteboard. In stroke of genius from Mark, we drew the dividing lines with a Sharpie which makes them semi-permanent. One post-it note equals one work item, so for every post-it on the board there's a corresponding entry in our SharePoint work item list. Yellow post-its are regular priority items, purple tickets are high priority. (The stray colors are just strays...green == yellow, and fucia == purple.)
To the right of the names is where we start working with the tickets in the backlog column. It's sized to fit three tickets to help enforce our max three rule for that slot. Below that is the Blocked area, which isn't sized to scale of their respective max allowable tickets.
Moving to the right across the board is each developer's Work in Progress slot. Again, sized to enforce the max allowable items. This is where carried over our dotting strategy from the previous set-up: Yellow is domain understood, green is design understood and in dev, red is dev complete, blue is in production. (Though following this photo we have decided that blue will mean passed testing in staging, ready for production.)
At the bottom of the Work in Progress column is our Emergency slot. This is where our "drop everything" items end up. To our surprise, it hasn't been utilized as much as we thought it would.
To the right of the Work in Progress slot are our Ready for Test and Tested slots. These are the first real community slots on the board, and the honor system is in place for getting things tested. So far, so good on that.
The far right of the board is open space for notes, tracking what's gone into production, and blimp drawings.
What its done for us
So far the big win for us has been gaining focus on one item at a time. We still have some growing to do in this area, as the inevitable "How long would it take to do X?" questions come up daily, and you find yourself looking at code you weren't aware existed when you started the day. So, we're trying to push harder to keep the distractions down, and keep the focus switching lessened.
Another thing that moving to this system has allowed is that it's much eaiser to report up the chain of command what each person is working on. It's much easier to manage expectations on when something will be finished and when another item will be started. Also, when the, "Item Q has to be done right away," request comes in I can say which items are being worked and ask which one should be stopped to pick up Item Q. Now that I can better articulate what each guy is doing, these requests are more often becoming, "Oh, this can wait until one of those is finished."
We've been using this for about four weeks now, and have had a few discussions around it. The early returns from the dev team is that they like it quite a bit. The numbers reflect that it's working, too, as we've closed more tickets over the last four weeks than we had in any four week period since mid-July.
Sunday, November 16, 2008
Kanban-o-rama - Part 1
Our current project is much more of the maintenance variety than of the new development type. Originally we tried to apply our standard scrum-ish approach to it - feature cards, load sheets, 2 week iterations, etc. However, it became clear that working maintenance tickets wasn't going to fit that model. Our load sheets meant nothing after a while because they were just getting overloaded with work items that were un-estimated, but needed assigned to get worked. It also became increasingly difficult to track the status of an item. Due to the lack of information about some tickets, any developer would show multiple tickets being "worked" at any given time. Keeping track of that on prod push day wasn't very easy, either.
Enter the Kanban idea.
The idea was brought up after a Friday retrospective by fellow QSI guy, Alexei. Comrade, myself, and our PM had about an hour discussion around the idea, and the following Monday put it into action. I did some information gathering over the weekend, hit up a couple other Quick guys for some more information, "borrowed" a white board from an office in the building, and away we went.
Our setup
Our setup is pretty simple. You can have 1 item as "Work in Progress" at any one time. You can't work more than one item at a time. Focus on that item until complete, then pull an item from your backlog.
We set up the backlog not as a community backlog, but each developer has his own backlog. I know this isn't ideal, but it gives us one extra layer of control on the flow of which tickets go to which guy to fix them. (The system we're working on is pretty broad, and though I'd love to practice collective ownership of the whole thing across the whole team, that's just not practical.) The backlog can max out at 3 items, and the item you choose is your choice, unless there's a high priority item in your backlog. (Denoted by a purple ticket rather than the normal yellow.)
If your item becomes blocked, we have two blocked areas available to move the ticket into. The first is "Blocked, need more information." Tickets moved here are assigned back to the PM who will follow up with the user to get the information needed to complete the ticket.
The second blocked area is "Blocked, Internal" which is a horrible name...the creative juices just weren't flowing that day. Typically tickets get moved here when they're dependant on another work item to be completed prior to them being worked.
Our max tickets allowable in the Need More Info slot is 8, and the internal is 2. If we go over those counts, we stop and figure out what we need to do to move those tickets along.
Once a ticket is no longer blocked, it goes back into the developer's backlog that originally had it. If there's not room in the backlog when it comes unblocked, it will wait in the "Ready for Dev" queue that is maintained in SharePoint. All the tickets are tracked through SharePoint as well as on the board, but prior to hitting the board they're managed only in SharePoint.
Once a work item is completed, it moves to "Ready to Test." The rules of testing are you test a ticket you didn't complete, as we don't have dedicated QA resources available. When you complete an item and there's one available for test, take the time to test it before starting your next item. So far, using the honor system has worked well, though we do still have some testing to catch up on before we do our weekly prod push. (We've picked Tuesday, so there's some testing going on Monday afternoon.)
Following testing, the ticket moves to "Tested." There it sits until it's rolled out to production.
That's the standard flow we've been using, but we did open up an "Emergency" option. So far, we've only had three emergency items drop into that slot. When that happens, the developer chosen to work it stops the item he's currently working and switches gears to the emergency until it's complete.
I'll end part 1 here. Up next I'll show off some photos of our board and add some more details as to how its been working out for us.
Enter the Kanban idea.
The idea was brought up after a Friday retrospective by fellow QSI guy, Alexei. Comrade, myself, and our PM had about an hour discussion around the idea, and the following Monday put it into action. I did some information gathering over the weekend, hit up a couple other Quick guys for some more information, "borrowed" a white board from an office in the building, and away we went.
Our setup
Our setup is pretty simple. You can have 1 item as "Work in Progress" at any one time. You can't work more than one item at a time. Focus on that item until complete, then pull an item from your backlog.
We set up the backlog not as a community backlog, but each developer has his own backlog. I know this isn't ideal, but it gives us one extra layer of control on the flow of which tickets go to which guy to fix them. (The system we're working on is pretty broad, and though I'd love to practice collective ownership of the whole thing across the whole team, that's just not practical.) The backlog can max out at 3 items, and the item you choose is your choice, unless there's a high priority item in your backlog. (Denoted by a purple ticket rather than the normal yellow.)
If your item becomes blocked, we have two blocked areas available to move the ticket into. The first is "Blocked, need more information." Tickets moved here are assigned back to the PM who will follow up with the user to get the information needed to complete the ticket.
The second blocked area is "Blocked, Internal" which is a horrible name...the creative juices just weren't flowing that day. Typically tickets get moved here when they're dependant on another work item to be completed prior to them being worked.
Our max tickets allowable in the Need More Info slot is 8, and the internal is 2. If we go over those counts, we stop and figure out what we need to do to move those tickets along.
Once a ticket is no longer blocked, it goes back into the developer's backlog that originally had it. If there's not room in the backlog when it comes unblocked, it will wait in the "Ready for Dev" queue that is maintained in SharePoint. All the tickets are tracked through SharePoint as well as on the board, but prior to hitting the board they're managed only in SharePoint.
Once a work item is completed, it moves to "Ready to Test." The rules of testing are you test a ticket you didn't complete, as we don't have dedicated QA resources available. When you complete an item and there's one available for test, take the time to test it before starting your next item. So far, using the honor system has worked well, though we do still have some testing to catch up on before we do our weekly prod push. (We've picked Tuesday, so there's some testing going on Monday afternoon.)
Following testing, the ticket moves to "Tested." There it sits until it's rolled out to production.
That's the standard flow we've been using, but we did open up an "Emergency" option. So far, we've only had three emergency items drop into that slot. When that happens, the developer chosen to work it stops the item he's currently working and switches gears to the emergency until it's complete.
I'll end part 1 here. Up next I'll show off some photos of our board and add some more details as to how its been working out for us.
Sunday, August 17, 2008
eRubyCon takeaways
I had the pleasure of attending eRubyCon here in Columbus Aug. 15-17. This is the second year for the event organized by Joe O'Brien, and the first year I got to attend. Josh Holmes has put up great reviews of the sessions up on his blog.
Since I don't really want to repeat Josh, what were my takeaways from the event?
First, that I still need to get more involved in Ruby. This is just a cool language that allows you to do so much as a developer. The allure of RSpec aside, it just reads well and makes sense. So, a couple things came to mind as near term goals. First, I need to start with some simple scripts for everyday tasks, and write them in Ruby. Second, I'm going to try to wire up IronRuby to test some of my C# hobby code. Doubt I want to drag that one into the office just yet. Those two items should get the ball rolling for me.
Second, and I think the larger takeaway for me, was that the .Net community was almost totally missing. I noticed this in two areas, there were very few .Net developers in attendance, and most of the topics only recognized that Ruby people were converting from Java. There was a lot of Java venom being tossed around for that reason, but the opposite of love isn't necessarily hate. It's apathy. The .Netters took it on the chin in the apathy department.
What can we in the .Net space do about this? First and foremost, get out there and see what else is going on. There is a lot of software not written on a Microsoft platform, what can you learn from them? I'm not saying learn something top to bottom, but get ideas from others. In the end, language doesn't matter as we're all trying to solve people problems, and the better armed you are to solve those problems, the better off we are as a whole.
Before I lay all this at the feet of the .Net community, those outside the Microsoft environment have a little responsibility here, as well. When Michael Letterle and Josh Holmes were up to give the IronRuby, Silverlight double header the room cleared a good bit. For the same reason the .Net folks should look outside their comfort zone, maybe others should take the chance to look inside the big blue monster to see what's happening.
I'm well aware of time constraints and family and "I'm already learning seven other things!" and a reading list that's growing faster than it's shrinking. But, instead of hitting your fourth Day of .Net in a row, take in a Ruby or Python conference. Or, if you're already at a Ruby conference, stick around and see what IronRuby is bringing to the Microsoft and Ruby communities.
One of my favorite terms of late is Jim Holmes's "Specializing Generalist." Looking inside or outside the Microsoft space, as the case may be, will add to the Generalist side of the equation. And, who knows, may change what you decide to be a Specialist in.
Since I don't really want to repeat Josh, what were my takeaways from the event?
First, that I still need to get more involved in Ruby. This is just a cool language that allows you to do so much as a developer. The allure of RSpec aside, it just reads well and makes sense. So, a couple things came to mind as near term goals. First, I need to start with some simple scripts for everyday tasks, and write them in Ruby. Second, I'm going to try to wire up IronRuby to test some of my C# hobby code. Doubt I want to drag that one into the office just yet. Those two items should get the ball rolling for me.
Second, and I think the larger takeaway for me, was that the .Net community was almost totally missing. I noticed this in two areas, there were very few .Net developers in attendance, and most of the topics only recognized that Ruby people were converting from Java. There was a lot of Java venom being tossed around for that reason, but the opposite of love isn't necessarily hate. It's apathy. The .Netters took it on the chin in the apathy department.
What can we in the .Net space do about this? First and foremost, get out there and see what else is going on. There is a lot of software not written on a Microsoft platform, what can you learn from them? I'm not saying learn something top to bottom, but get ideas from others. In the end, language doesn't matter as we're all trying to solve people problems, and the better armed you are to solve those problems, the better off we are as a whole.
Before I lay all this at the feet of the .Net community, those outside the Microsoft environment have a little responsibility here, as well. When Michael Letterle and Josh Holmes were up to give the IronRuby, Silverlight double header the room cleared a good bit. For the same reason the .Net folks should look outside their comfort zone, maybe others should take the chance to look inside the big blue monster to see what's happening.
I'm well aware of time constraints and family and "I'm already learning seven other things!" and a reading list that's growing faster than it's shrinking. But, instead of hitting your fourth Day of .Net in a row, take in a Ruby or Python conference. Or, if you're already at a Ruby conference, stick around and see what IronRuby is bringing to the Microsoft and Ruby communities.
One of my favorite terms of late is Jim Holmes's "Specializing Generalist." Looking inside or outside the Microsoft space, as the case may be, will add to the Generalist side of the equation. And, who knows, may change what you decide to be a Specialist in.
Wednesday, July 9, 2008
TDD Starting to Sink In
Back in late March, I blogged about my issues getting going with TDD. At the time I was nearing the end of a project where I had attempted some unit testing, but had not done it up front. I was looking forward to a clean slate to get some more work on TDDing up my code.
That opportunity somewhat presented itself, though I was moving on to an established team, which presents its own challenges. However, this team, or a good portion of it, was practicing TDD. So, plenty of example code out there. Not only that, I ended up sitting about 3 feet from world renowned TDD zealot, Steve Harman. Steve is a great teacher, and only yelled at me a few times. (And I only cried the one time...)
That helped on the professional side of things, but even in my own hobby coding I started writing more and more tests before the code. I've been presenting on ASP.Net MVC at a few places recently, and the sample code I use there was written all TDD style. (And is presented test first.) Well, almost all of it...somebody wrote his repository wrong, and the updates didn't work so well. I have some refactoring to do.
So, here I am 3 months later, where do I stand on the points I brought up back in March?
1. I tend to wrestle a lot with when to layout some of the framework and when to just breakdown and write the tests.
This one became pretty easy when Steve introduced some BDD (Behavior Driven Design/Development) style grammar to our testing. This one shift in thinking opened up my ability to get the requirements into unit tests, and get them green quicker. In a nutshell, thinking along the lines of, "When X condition is present, then Y should happen," and naming the classes and test methods with that type of grammar took me well beyond wondering when to write the tests.
2. A recent project found our team working with a pile of generated tests.
Generated tests are a thing of the past. This is a non-issue at this point.
3. When to mock?
Again, a healthy dose of Steve helped here a lot. Also, Rhino Mocks 3.5 was released with the Arrange, Act, Assert syntax, and that cleared up a lot in the mocking area. No more record and playback blocks, and lots of lambdas to stub out that which you want doing the dirty work.
The answer to the original question finally became clear: Get the hard stuff out of the way with mocks. Beyond that, get the stuff that you're not testing out of the way with mocks. The AAA syntax made that pretty easy.
4. Is this test trivial, or needed?
OK, I still have a bit of trouble here. Not as much as before, but occasionally I find myself writing a test, looking at it, and going, "Gee, I'm testing the setter of that property...that had BETTER work!"
5. I still have large holes in what I test.
Again, still having trouble here. Even with the good TDD practices in place at the most recent project, I found myself frustrated and writing the code and screen testing it rather than writing my unit tests up front. I did have a deadline that I was up against, but cutting the unit tests is never the right solution. I fell back to an old habit, one I've been working pretty diligently on breaking.
In the March blog entry, this referred to unit testing my javascript. Well, ending up on a Webforms project pretty much ended my worries about getting my javascript tested.
So, with those steps behind me, what do I want to focus on now? Well, I can still improve on numbers 4 and 5 above, but I think those two will be continuous improvements. I'm going to continue down the BDD-ish path. It's not pure BDD, but it got me over the hump, and I like the syntax. But overall, I'm just going to keep going at getting the tests written up front. Focus more on the red, green, refactor as much as I can. I'm seeing the benefits, just need to get those old habits kicked.
That opportunity somewhat presented itself, though I was moving on to an established team, which presents its own challenges. However, this team, or a good portion of it, was practicing TDD. So, plenty of example code out there. Not only that, I ended up sitting about 3 feet from world renowned TDD zealot, Steve Harman. Steve is a great teacher, and only yelled at me a few times. (And I only cried the one time...)
That helped on the professional side of things, but even in my own hobby coding I started writing more and more tests before the code. I've been presenting on ASP.Net MVC at a few places recently, and the sample code I use there was written all TDD style. (And is presented test first.) Well, almost all of it...somebody wrote his repository wrong, and the updates didn't work so well. I have some refactoring to do.
So, here I am 3 months later, where do I stand on the points I brought up back in March?
1. I tend to wrestle a lot with when to layout some of the framework and when to just breakdown and write the tests.
This one became pretty easy when Steve introduced some BDD (Behavior Driven Design/Development) style grammar to our testing. This one shift in thinking opened up my ability to get the requirements into unit tests, and get them green quicker. In a nutshell, thinking along the lines of, "When X condition is present, then Y should happen," and naming the classes and test methods with that type of grammar took me well beyond wondering when to write the tests.
2. A recent project found our team working with a pile of generated tests.
Generated tests are a thing of the past. This is a non-issue at this point.
3. When to mock?
Again, a healthy dose of Steve helped here a lot. Also, Rhino Mocks 3.5 was released with the Arrange, Act, Assert syntax, and that cleared up a lot in the mocking area. No more record and playback blocks, and lots of lambdas to stub out that which you want doing the dirty work.
The answer to the original question finally became clear: Get the hard stuff out of the way with mocks. Beyond that, get the stuff that you're not testing out of the way with mocks. The AAA syntax made that pretty easy.
4. Is this test trivial, or needed?
OK, I still have a bit of trouble here. Not as much as before, but occasionally I find myself writing a test, looking at it, and going, "Gee, I'm testing the setter of that property...that had BETTER work!"
5. I still have large holes in what I test.
Again, still having trouble here. Even with the good TDD practices in place at the most recent project, I found myself frustrated and writing the code and screen testing it rather than writing my unit tests up front. I did have a deadline that I was up against, but cutting the unit tests is never the right solution. I fell back to an old habit, one I've been working pretty diligently on breaking.
In the March blog entry, this referred to unit testing my javascript. Well, ending up on a Webforms project pretty much ended my worries about getting my javascript tested.
So, with those steps behind me, what do I want to focus on now? Well, I can still improve on numbers 4 and 5 above, but I think those two will be continuous improvements. I'm going to continue down the BDD-ish path. It's not pure BDD, but it got me over the hump, and I like the syntax. But overall, I'm just going to keep going at getting the tests written up front. Focus more on the red, green, refactor as much as I can. I'm seeing the benefits, just need to get those old habits kicked.
Tuesday, June 17, 2008
The Summer Tour of Timbo
The summer speaking tour is about to get underway, fresh off the heels of my successful spring tour. (Successful after the QSI Tech Night unit-test-a-palooza fun.)
We'll be kicking off the summer tour in Cincinnati next Tuesday (6/24) at the June CINNUG meeting. I'll be presenting on the ASP.Net MVC framework, why it's cool, why you should be using it now, and how it will do simple household chores for you - walking the dog, doing the laundry, and cleaning the bathroom. (It doesn't do windows, though.)
Fresh off the evening in Cincinnati, I'll be heading to Dayton the very next evening to present the same riveting and engaging presentation to the good people of the Dayton .Net Developers Group. Fellow Quickie Jim Holmes helps run the Dayton bunch, so I expect heckling in Dayton.
Following the quick bang-bang trip across south western Ohio, I'm off for a few weeks before I head below the Mason-Dixon line to speak to the Memphis .Net User Group on July 24. "Memphis?!?!" you saying. Jeff introduced me to Colin Neller, president of MNUG, when I was in Vegas for Mix, and he invited me down after I expressed a little interest in getting out to do some speaking. My topic in Memphis is as yet undecided. Colin has a poll up in the MNUG forums for either an MVC deep dive or my Evangelizing the Pragmatic Programmer talk. Can't wait to see the results. It's 50/50 at the moment, so if you're in the Memphis area get your vote in...you could be the deciding vote!
That ends my scheduled trips at the moment, who knows what I'll rope myself into as August comes along.
We'll be kicking off the summer tour in Cincinnati next Tuesday (6/24) at the June CINNUG meeting. I'll be presenting on the ASP.Net MVC framework, why it's cool, why you should be using it now, and how it will do simple household chores for you - walking the dog, doing the laundry, and cleaning the bathroom. (It doesn't do windows, though.)
Fresh off the evening in Cincinnati, I'll be heading to Dayton the very next evening to present the same riveting and engaging presentation to the good people of the Dayton .Net Developers Group. Fellow Quickie Jim Holmes helps run the Dayton bunch, so I expect heckling in Dayton.
Following the quick bang-bang trip across south western Ohio, I'm off for a few weeks before I head below the Mason-Dixon line to speak to the Memphis .Net User Group on July 24. "Memphis?!?!" you saying. Jeff introduced me to Colin Neller, president of MNUG, when I was in Vegas for Mix, and he invited me down after I expressed a little interest in getting out to do some speaking. My topic in Memphis is as yet undecided. Colin has a poll up in the MNUG forums for either an MVC deep dive or my Evangelizing the Pragmatic Programmer talk. Can't wait to see the results. It's 50/50 at the moment, so if you're in the Memphis area get your vote in...you could be the deciding vote!
That ends my scheduled trips at the moment, who knows what I'll rope myself into as August comes along.
Monday, June 9, 2008
How I got started programming
I got called out by Jeff in his post on the same subject. I believe this idea can be traced back to Michael, and it's a pretty good idea. It's nice to see how our friends and colleagues have progressed.
Fair warning, this could get long winded. I am, after all, talking about my favorite subject...me. :)
How old were you when you started programming?
I think I was 12 when I first wrote some kind of program. Christmas of my 7th grade year, Ma and Pa Wingfield bought an Apple IIe, along with a couple games. However, I quickly got bored with the games and wanted to make that machine do the stuff I wanted. I talked mom into springing for the 128k upgrade card, and I got down to writing some BASIC programs.
Between the 7th and 8th grade, mom actually sent me to Ohio State to "Computer Camp." It was like Code Mash '83. A bunch of 12-14 year olds on OSU's campus for a week writing code. Oddly enough, at the time I was an "Apple Guy" because that's what we had at home, but all the machines at the camp were IBM's. So, I basically just focused on the BASIC code, and not all the screwy graphics stuff that only worked on the IBMs.
How did you get started in programming?
Through High School, I did very little programming. Females and football were my main focus, and after graduating I was off to OSU to get an Ag Econ degree. While at OSU I did take a beginning programming course, and it was one of the few courses I enjoyed. (Didn't take the hint, though.) In it, we were writing PASCAL on Macs...back to the Apple. (The irony is getting thick, here.)
After that class at OSU I let my programming gene slip again, and didn't really take it back up until I got a 486 in '93. After getting that, and with the web boom right around the corner, HTML and javascript were intriguing, so I hobbied around with them for a while. Then, got serious and went to Franklin to work on getting a CS degree. That's when it all started to come together and I figured out I really was a computer guy at heart. (At FU I did most work on a UNIX system...no Apple this time, but no PC, either.)
What was your first language?
As noted above my first language was BASIC on the Apple. Lots of GOTOs in my code, too. Nothing brought my 128k expansion card to it's knees quicker than a nice infinite GOTO loop.
What was the first real program you wrote?
This is kind of a two parter for me. The first large program I got working was a Stock Market simulator I copied out of a magazine. I made a few minor tweaks to it to make the stocks move faster and change the companies that were traded.
But, the first real program I wrote from scratch was a farming simulator when I was in the 8th grade for the IIe. I grew up on a grain farm, and decided to write a simulator for planting, harvesting, and trading grain. I titled the program "Appleculture" which I thought was pretty snappy. The most difficult part of the game to program was the random number stuff to make the grain prices move, but not move too much. And to make them trend up or down, not taking huge jumps in the opposite direction it took the turn before. It got pretty involved. It also had a banking portion to it, so I guess I was staring my "line of business app" future square in the face there and didn't even know it.
What languages have you used since you started programming?
Hmmm...BASIC, PASCAL, C++, Java, VB 5, HTML, Javascript, ASP, VBScript, PHP, C#, VB.Net, Ruby (just getting started on that one)
What was your first professional programming gig?
First professional programming gig was at a small lighting manufacturing company near the airport back in about 1997, I believe. I was brought in to build the website, oversee the computer systems, and do some other things around the building. Turned out the guy that owned the company wasn't all that good at delegating, so it ended up being more of a production manager position than web position. I did get the website launched before I left, and it was still the web site up until about 18 months ago. (Which is really kind of sad.)
If you knew then what you know now, would you have started programming?
Yes. If I knew then what I know now, I would have started focusing on programming much sooner. My real programming life didn't start until I was about 26 or so, even though I was writing random grain price generators when I was 13.
If there is one thing you learned along the way that you would tell new developers, what would it be?
I'll have to follow the crowd and say soft skills is a big one. Everything is a people problem, so to solve those problems you've got to deal with people. If you think fixing the problem is locking yourself in an office or hunkering down in a cube for endless hours typing away, you're mistaken.
Secondly - can't narrow this one to just one - and I read this in somebody else's post and heard it from Brian Prince, get a mentor or mentors. After leaving the small manufacturing place I've been lucky enough to have at least one person at each company that's been a mentor to me. At Quick it seems I'm surrounded by mentors. In this chosen career you're always learning, if you're not always learning YOU are the problem.
What's the most fun you've ever had ... programming?
Not sure I can narrow down a "most fun" time, but my most satisfying time was working on the MCCH project for the Attorney General's office. Simplified explanation, this was the web interface for the Amber Alert system in Ohio. My email address is still in the db for all Amber alerts in the state, and seeing, "Alert canceled, child recovered," come into the inbox always makes me feel good.
Jeff called me out, so I'll pass along the call outs. Like to hear the stories of...
Jim Holmes
Greg Finzer
Phil Jordan
Steve Horn
Matt Casto
Fair warning, this could get long winded. I am, after all, talking about my favorite subject...me. :)
How old were you when you started programming?
I think I was 12 when I first wrote some kind of program. Christmas of my 7th grade year, Ma and Pa Wingfield bought an Apple IIe, along with a couple games. However, I quickly got bored with the games and wanted to make that machine do the stuff I wanted. I talked mom into springing for the 128k upgrade card, and I got down to writing some BASIC programs.
Between the 7th and 8th grade, mom actually sent me to Ohio State to "Computer Camp." It was like Code Mash '83. A bunch of 12-14 year olds on OSU's campus for a week writing code. Oddly enough, at the time I was an "Apple Guy" because that's what we had at home, but all the machines at the camp were IBM's. So, I basically just focused on the BASIC code, and not all the screwy graphics stuff that only worked on the IBMs.
How did you get started in programming?
Through High School, I did very little programming. Females and football were my main focus, and after graduating I was off to OSU to get an Ag Econ degree. While at OSU I did take a beginning programming course, and it was one of the few courses I enjoyed. (Didn't take the hint, though.) In it, we were writing PASCAL on Macs...back to the Apple. (The irony is getting thick, here.)
After that class at OSU I let my programming gene slip again, and didn't really take it back up until I got a 486 in '93. After getting that, and with the web boom right around the corner, HTML and javascript were intriguing, so I hobbied around with them for a while. Then, got serious and went to Franklin to work on getting a CS degree. That's when it all started to come together and I figured out I really was a computer guy at heart. (At FU I did most work on a UNIX system...no Apple this time, but no PC, either.)
What was your first language?
As noted above my first language was BASIC on the Apple. Lots of GOTOs in my code, too. Nothing brought my 128k expansion card to it's knees quicker than a nice infinite GOTO loop.
What was the first real program you wrote?
This is kind of a two parter for me. The first large program I got working was a Stock Market simulator I copied out of a magazine. I made a few minor tweaks to it to make the stocks move faster and change the companies that were traded.
But, the first real program I wrote from scratch was a farming simulator when I was in the 8th grade for the IIe. I grew up on a grain farm, and decided to write a simulator for planting, harvesting, and trading grain. I titled the program "Appleculture" which I thought was pretty snappy. The most difficult part of the game to program was the random number stuff to make the grain prices move, but not move too much. And to make them trend up or down, not taking huge jumps in the opposite direction it took the turn before. It got pretty involved. It also had a banking portion to it, so I guess I was staring my "line of business app" future square in the face there and didn't even know it.
What languages have you used since you started programming?
Hmmm...BASIC, PASCAL, C++, Java, VB 5, HTML, Javascript, ASP, VBScript, PHP, C#, VB.Net, Ruby (just getting started on that one)
What was your first professional programming gig?
First professional programming gig was at a small lighting manufacturing company near the airport back in about 1997, I believe. I was brought in to build the website, oversee the computer systems, and do some other things around the building. Turned out the guy that owned the company wasn't all that good at delegating, so it ended up being more of a production manager position than web position. I did get the website launched before I left, and it was still the web site up until about 18 months ago. (Which is really kind of sad.)
If you knew then what you know now, would you have started programming?
Yes. If I knew then what I know now, I would have started focusing on programming much sooner. My real programming life didn't start until I was about 26 or so, even though I was writing random grain price generators when I was 13.
If there is one thing you learned along the way that you would tell new developers, what would it be?
I'll have to follow the crowd and say soft skills is a big one. Everything is a people problem, so to solve those problems you've got to deal with people. If you think fixing the problem is locking yourself in an office or hunkering down in a cube for endless hours typing away, you're mistaken.
Secondly - can't narrow this one to just one - and I read this in somebody else's post and heard it from Brian Prince, get a mentor or mentors. After leaving the small manufacturing place I've been lucky enough to have at least one person at each company that's been a mentor to me. At Quick it seems I'm surrounded by mentors. In this chosen career you're always learning, if you're not always learning YOU are the problem.
What's the most fun you've ever had ... programming?
Not sure I can narrow down a "most fun" time, but my most satisfying time was working on the MCCH project for the Attorney General's office. Simplified explanation, this was the web interface for the Amber Alert system in Ohio. My email address is still in the db for all Amber alerts in the state, and seeing, "Alert canceled, child recovered," come into the inbox always makes me feel good.
Jeff called me out, so I'll pass along the call outs. Like to hear the stories of...
Jim Holmes
Greg Finzer
Phil Jordan
Steve Horn
Matt Casto
Subscribe to:
Posts (Atom)