I'm on the road this week, visiting another office for development meetings. I've been trying to post something on Mondays, Wednesdays and Fridays. The trip has been very busy and the only alone time I've had is when sleeping, so that schedule did not work. I have some downtime now, so I'll knock something out fast.
This trip has been an excellent illustration of the importance of communication. You can exchange e-mails all day with someone, or talk to them on the phone now and again, but nothing beats being there in person, face-to-face with someone. That kind of high bandwidth communication removes all kinds of barriers where things can be mis-read or lost in translation.
More things were decided in a few days of meetings than happened in months remotely. Yet, there is often a reluctance to incur the expense of travel. Penny wise, pound foolish.
Thursday, March 27, 2008
Friday, March 21, 2008
Good Enough Hardware
Used to be, a "cheap" desktop computer hovered around a thousand dollars in price, without a monitor. Those days are now far behind us. Cheap desktop systems with bundled LCD monitors are easily found for less than five hundred dollars. Laptops have similarly crashed in price, with a race for the bottom still underway. There is still a high end to the market, with multi-thousand dollar machines, but only people with very specific requirements should buy them.
If you only drive a few nails a year to hang pictures, you can buy a five dollar hammer and you're set. If you take that five dollar hammer onto a job site and drive a few thousand nails with it you will quickly destroy it, rounding the head of it, shredding the handle, etc. In the same way if you are a hard core video game player you would not buy a five hundred dollar computer and expect to be happy.
All that said, most people can get by with the modern "low end" computer, that has more processing power, memory, disk space, etc. than machines they purchased a few years ago. And that computer will be sufficient for a fairly long time. In the 90's software could get ahead of your computer very quickly, and your hardware quickly became obsolete. With so much time between major updates of software now, plus the power available at the low end of the market, breaks this cycle.
The one place that this is somewhat not true is with the Microsoft Vista operating system, if you want to run it with all the bells and whistles. If you want that then the low end machines might not be exactly what you want. If you are only wanting to surf the web and do e-mail you should consider alternative operating systems that run on the same hardware, such as a Linux distribution like Ubuntu.
The Macintosh computers are more expensive, but come loaded with a lot more bells and whistles that narrow the gap between the low end PC and the low end Mac. They offer a good level of stability and if you are looking for easy they are hard to beat.
When you go to purchase your next computer, consider all the factors, including what you are actually SPECIFICALLY going to use the machine for, and do not fall for the sales pitch of the latest, greatest and fastest. A "good enough" computer is going to be sufficient for 95% of people, so don't turn up your nose at a computer because of its low price. You'll be pleasantly surprised by your new machine, regardless.
Make your choice techgnostically, and don't be swayed by hype (I'm looking at YOU, Microsoft).
If you only drive a few nails a year to hang pictures, you can buy a five dollar hammer and you're set. If you take that five dollar hammer onto a job site and drive a few thousand nails with it you will quickly destroy it, rounding the head of it, shredding the handle, etc. In the same way if you are a hard core video game player you would not buy a five hundred dollar computer and expect to be happy.
All that said, most people can get by with the modern "low end" computer, that has more processing power, memory, disk space, etc. than machines they purchased a few years ago. And that computer will be sufficient for a fairly long time. In the 90's software could get ahead of your computer very quickly, and your hardware quickly became obsolete. With so much time between major updates of software now, plus the power available at the low end of the market, breaks this cycle.
The one place that this is somewhat not true is with the Microsoft Vista operating system, if you want to run it with all the bells and whistles. If you want that then the low end machines might not be exactly what you want. If you are only wanting to surf the web and do e-mail you should consider alternative operating systems that run on the same hardware, such as a Linux distribution like Ubuntu.
The Macintosh computers are more expensive, but come loaded with a lot more bells and whistles that narrow the gap between the low end PC and the low end Mac. They offer a good level of stability and if you are looking for easy they are hard to beat.
When you go to purchase your next computer, consider all the factors, including what you are actually SPECIFICALLY going to use the machine for, and do not fall for the sales pitch of the latest, greatest and fastest. A "good enough" computer is going to be sufficient for 95% of people, so don't turn up your nose at a computer because of its low price. You'll be pleasantly surprised by your new machine, regardless.
Make your choice techgnostically, and don't be swayed by hype (I'm looking at YOU, Microsoft).
Tuesday, March 18, 2008
Object Relational Mapping
I saw a demonstration last night of object relational mapping (ORM) tools. The idea behind them is that object oriented programming (OOP) and relational databases (RDBMS) model the world in two totally different ways. OOP tries to express everything in terms of behavior and properties, whereas RDBMS focus on efficient data storage, and do not support the kind of behavior that OOP provides. You can program in a RDBMS (with stored procedures, or functions) and you can store data in objects. Both approaches have their pros and cons. At the moment, OOP is the dominant way to write software (Java and .NET languages sit on top of huge libraries of objects) and RDBMS is the dominant way to store data (Oracle, SQL Server, etc.).
Programmers being programmers, clever people have put together some ways to allow the OOP people to have their cake and eat it too. They can program against objects, and then have a whole bunch of backend code handle the dirty details of getting data out of and back into the RDBMS. Of course, there is no such thing as a free lunch, so there is an overhead associated with this.
I could see how the approach would allow you to cleanly separate out your business objects (e.g., customers, orders, etc.) from the nitty gritty of the data storage (e.g., the exact SQL statements to retrieve or insert data into a database) and insulate your business logic from future changes in data storage technology. Some frameworks go one step further and define a domain specific language (DSL) to allow you to express your business problem solution in something that resembles normal English (COBOL-esque?).
In a large number of cases, there is significant investment in existing code, written in such a way that you cannot simply switch approaches on a whim. When something like ORM comes along there needs to be a cost-benefit analysis (CBA) of whether or not it is worth it to make the switch. The software developers hear this and hear "blah blah blah", knowing that the suits just want to kill their fun. If they are serious enough about their fun they will go to a startup company that is doing greenfield development where they can indulge their latest cutting edge ideas.
Ironically, in three to five years something else will come along, and if they have totally bought into whatever the new thing NOW is (for example, ORM) they will decry any attempt to move away from it, having written tens of thousands of lines of code using it.
I guess it is the fate of all software development to eventually become obsolete and fall by the wayside, but in some niches you can survive for a very long time until that CBA finally tips the scales over, and the maintenance payments to whichever vendor or ability to find programming talent to keep your AS400 / COBOL / PowerBuilder payroll system alive become too difficult.
I suspect I will run a small pilot project using an ORM framework, to see what benefit there is, and to show that we are "keeping up", but for now I think it is going to be one of those things that simply does not pay off enough to warrant a wholesale shift.
Programmers being programmers, clever people have put together some ways to allow the OOP people to have their cake and eat it too. They can program against objects, and then have a whole bunch of backend code handle the dirty details of getting data out of and back into the RDBMS. Of course, there is no such thing as a free lunch, so there is an overhead associated with this.
I could see how the approach would allow you to cleanly separate out your business objects (e.g., customers, orders, etc.) from the nitty gritty of the data storage (e.g., the exact SQL statements to retrieve or insert data into a database) and insulate your business logic from future changes in data storage technology. Some frameworks go one step further and define a domain specific language (DSL) to allow you to express your business problem solution in something that resembles normal English (COBOL-esque?).
In a large number of cases, there is significant investment in existing code, written in such a way that you cannot simply switch approaches on a whim. When something like ORM comes along there needs to be a cost-benefit analysis (CBA) of whether or not it is worth it to make the switch. The software developers hear this and hear "blah blah blah", knowing that the suits just want to kill their fun. If they are serious enough about their fun they will go to a startup company that is doing greenfield development where they can indulge their latest cutting edge ideas.
Ironically, in three to five years something else will come along, and if they have totally bought into whatever the new thing NOW is (for example, ORM) they will decry any attempt to move away from it, having written tens of thousands of lines of code using it.
I guess it is the fate of all software development to eventually become obsolete and fall by the wayside, but in some niches you can survive for a very long time until that CBA finally tips the scales over, and the maintenance payments to whichever vendor or ability to find programming talent to keep your AS400 / COBOL / PowerBuilder payroll system alive become too difficult.
I suspect I will run a small pilot project using an ORM framework, to see what benefit there is, and to show that we are "keeping up", but for now I think it is going to be one of those things that simply does not pay off enough to warrant a wholesale shift.
Monday, March 17, 2008
So, what do you do again?
Having spent more of my working life as a non-manager than as a manager, I know how people often look at a manager and say "What does he/she DO all day? They're not producing anything - they're just dead weight" or something similar.
I went to the Manager Tools website and took a look at their podcast categories and culled out some that illustrate a fair amount of what it involves.
HR (and all that that entails)
Any one of these areas grows with headcount, as the number of communication channels increases. Some of the tasks are emotionally draining, while others take their toll physically.
Yet, I remember when I thought managers did not do anything but drink coffee and loaf around. So when somebody asks me what I do I say "Wander around and wave my arms, hoping it makes a difference." I suppose it diminishes the work somewhat, but the only other option is to try and laundry-list it all and nobody wants to hear about that.
I went to the Manager Tools website and took a look at their podcast categories and culled out some that illustrate a fair amount of what it involves.
HR (and all that that entails)
- Evaluations
- Staffing / Hiring / Interviews / Recruiters
- Retention
- Termination / Layoffs
- Employee Behavior
- One on Ones /Feedback
- Networking
- Employee Performance
- Company Strategy
- Communication
- Delegation
- Meetings
- Books
- Career
- Coaching
- Training
- Presenting
Any one of these areas grows with headcount, as the number of communication channels increases. Some of the tasks are emotionally draining, while others take their toll physically.
Yet, I remember when I thought managers did not do anything but drink coffee and loaf around. So when somebody asks me what I do I say "Wander around and wave my arms, hoping it makes a difference." I suppose it diminishes the work somewhat, but the only other option is to try and laundry-list it all and nobody wants to hear about that.
Friday, March 14, 2008
Drowning in information
Moving into management made me aware of how many things I did not yet understand. Getting people to do what you want them to do without using some form of force is a challenge, and "because I said so" only seems to work with my children (and even then it's hit or miss). One of the venues I've used for information on what to do is seminars.
I go to a seminar that is covering a topic that's of interest and applicable to some problem I am having. The presenter has their slide deck and content down cold, and they go through the process. At the time I think "Wow - this is GREAT information. I am going to use that the next time I need to address this." I leave the course at the end of the day, go back to work the next day and slam into the wall that I'd left behind the day before the seminar.
I go back to my notes from the class and try to recall exactly what was said, and can't quite conjure it up. So I go to the web and search around for similar information and indeed it is all out there, but before the seminar I did not know what to look for. Now I have the information from the seminar, and now from the web also. A lot of the information on the web is structured to make me want to pay for some product or service, so I'm skeptical of some of it.
I need something unbiased, I think. How about a book?
Off I go to Amazon. I search for the subject I am interested in and find a plethora of books, half of which have very high ratings. I cull through the list and find the one that seems most suited to me and order it up. As soon as the order is gone I go back into the storm of daily items.
About a week later I get the book, open it up and am flooded with memories from the seminar, the web search and the remarks on Amazon about the other books I didn't get. I am no closer to having something actionable than I was earlier. And then another crisis pops up, I put the book on the shelf with every intention of reading it cover to cover and making notes, and it sits there for months.
Every time I see the book I feel guilty for not following through.
Sometimes I wonder if can just use common sense? Can't I just take a stab at what seems to be reasonable and then note the result? If the result is good, do it that way again. If it is a failure, try to determine why it failed and do it differently next time.
I think I fall into the trap of wanting total information before I do something, in the belief that it will cause a better decision. There is so much information, though, that it backfires and I don't know where to start.
Perhaps I need to keep in mind the old adage "Good decision making comes from experience - experience comes from making bad decisions".
In the meantime, what do I do with all these books?
I go to a seminar that is covering a topic that's of interest and applicable to some problem I am having. The presenter has their slide deck and content down cold, and they go through the process. At the time I think "Wow - this is GREAT information. I am going to use that the next time I need to address this." I leave the course at the end of the day, go back to work the next day and slam into the wall that I'd left behind the day before the seminar.
I go back to my notes from the class and try to recall exactly what was said, and can't quite conjure it up. So I go to the web and search around for similar information and indeed it is all out there, but before the seminar I did not know what to look for. Now I have the information from the seminar, and now from the web also. A lot of the information on the web is structured to make me want to pay for some product or service, so I'm skeptical of some of it.
I need something unbiased, I think. How about a book?
Off I go to Amazon. I search for the subject I am interested in and find a plethora of books, half of which have very high ratings. I cull through the list and find the one that seems most suited to me and order it up. As soon as the order is gone I go back into the storm of daily items.
About a week later I get the book, open it up and am flooded with memories from the seminar, the web search and the remarks on Amazon about the other books I didn't get. I am no closer to having something actionable than I was earlier. And then another crisis pops up, I put the book on the shelf with every intention of reading it cover to cover and making notes, and it sits there for months.
Every time I see the book I feel guilty for not following through.
Sometimes I wonder if can just use common sense? Can't I just take a stab at what seems to be reasonable and then note the result? If the result is good, do it that way again. If it is a failure, try to determine why it failed and do it differently next time.
I think I fall into the trap of wanting total information before I do something, in the belief that it will cause a better decision. There is so much information, though, that it backfires and I don't know where to start.
Perhaps I need to keep in mind the old adage "Good decision making comes from experience - experience comes from making bad decisions".
In the meantime, what do I do with all these books?
Wednesday, March 12, 2008
Oh, the irony (one of many)
As a software developer for many years I often wondered what the management people were thinking. My patron saint (St. Dilbert) mocked them mercilessly and I found solace in the humor. I picked up Scott Adams' first book "The Dilbert Principle" and read it from cover to cover and thought it was pure, distilled genius. One thing that stuck out to me then, even more than the other items, was his supposition that the person doing the work of the company - the hands-on person (like me, the software developer) - is central to the company, and the process of creating policies is one step removed from hands-on work.
Damn straight, thought I. If I'm not here to write this code what are they going to do? Write it themselves? Ha!
Fast forward some years. I have been done one-on-ones (O3s) with my direct reports for a while now, once a month for an hour each time. I moved from a once a week O3 format because of how cluttered it made my schedule and because some of my folks did not think it was very useful. After switching to the once a month format, however, I found that a month was a long time to get O3 time with some of my people, in particular my remote people, so I wanted to move back to once a week 30 minute sessions. But, I wanted to get some feedback first.
I called a meeting.
Once everybody who was on-site came into the meeting it hit me suddenly that I was not only having a meeting (which most people do not like) about a policy (one step removed from REAL work), but I was having a meeting about TWEAKING a policy I'd already changed, back to the way it was previously. How far removed from real work was I?
The sheer irony of it was overwhelming.
Apparently, fate has a sense of humor.
Damn straight, thought I. If I'm not here to write this code what are they going to do? Write it themselves? Ha!
Fast forward some years. I have been done one-on-ones (O3s) with my direct reports for a while now, once a month for an hour each time. I moved from a once a week O3 format because of how cluttered it made my schedule and because some of my folks did not think it was very useful. After switching to the once a month format, however, I found that a month was a long time to get O3 time with some of my people, in particular my remote people, so I wanted to move back to once a week 30 minute sessions. But, I wanted to get some feedback first.
I called a meeting.
Once everybody who was on-site came into the meeting it hit me suddenly that I was not only having a meeting (which most people do not like) about a policy (one step removed from REAL work), but I was having a meeting about TWEAKING a policy I'd already changed, back to the way it was previously. How far removed from real work was I?
The sheer irony of it was overwhelming.
Apparently, fate has a sense of humor.
Monday, March 10, 2008
So where does "techgnostic" come into it?
From my title block:
Why append my name with such a title?
I have worked over the years on many flavors of Unix (Sun, HP, SG, BSD and Linux), different incarnations of the Mac OS (from when the whole OS ran off a single floppy in my Mac 512e) and DOS/Windows since the XT. There are zealots in every camp, and strong reasons for their biases. Untold billions of characters have been typed into computers during flame wars about the "best" OS, programming language, editor, database, you-name-it. There is only one thing that can be said for all of this.
All computers suck, equally. I'm not the only person who thinks so.
A bit glib, I admit, but nice and pithy and with enough truth in it to allow it to stand up. Each "platform" of hardware / software / applications was created to solve a particular kind of problem and usually accomplished its mission. When an attempt is made to repurpose it to another task it often fails. From a certain perspective, any other platform equates to "sucks".
So, beyond appearing to be a technological dilettante, so what?
My own technological belief is to use whatever tools, platform, etc. make sense for your own situation. Again this seems like just giving in, but it is not. There are still fundamentals to keep in mind in terms of getting support, safeguarding your data, etc. but they can be enacted on virtually any platform. For all the flak that Microsoft Windows takes it can be locked down quite well. For all the raves that the Mac gets for style there is a closely controlled platform that stifles some kinds of development. For all the intellectual purity of most Linux versions there is still often a steep curve for the computing novice. For all the vaunted stability, etc. of the mainframe there is a prohibitive cost and lack of common support in the workforce.
If you or your company already employ a bunch of Windows admins and everybody is used to Windows there is not much point in having a Mac or Linux jihad because of some perceived superiority. It just does not make sense in that situation. Similarly, if you have a Unix setup and all is well, why upset the system to introduce a single Microsoft application when there are ways to integrate it into your existing setup?
All that said, strong arguments can be made for using standardized PCs, running open source software in "clean sheet" situations where low cost is an overriding concern, such as with the One Laptop Per Child project, or indeed for any other organization who only needs certain kinds of generic functionality, not tied to a particular software package.
The techgnostic part of all this is that in an ideal situation where the platform has not been dictated there are many options to solve your technology problems and we should not shut ourselves off into any one camp. The personalities and business practices of the players should not play a major role in our decisions - what works for us in our situations should be front and center.
That is being techgnostic.
Why append my name with such a title?
I have worked over the years on many flavors of Unix (Sun, HP, SG, BSD and Linux), different incarnations of the Mac OS (from when the whole OS ran off a single floppy in my Mac 512e) and DOS/Windows since the XT. There are zealots in every camp, and strong reasons for their biases. Untold billions of characters have been typed into computers during flame wars about the "best" OS, programming language, editor, database, you-name-it. There is only one thing that can be said for all of this.
All computers suck, equally. I'm not the only person who thinks so.
A bit glib, I admit, but nice and pithy and with enough truth in it to allow it to stand up. Each "platform" of hardware / software / applications was created to solve a particular kind of problem and usually accomplished its mission. When an attempt is made to repurpose it to another task it often fails. From a certain perspective, any other platform equates to "sucks".
So, beyond appearing to be a technological dilettante, so what?
My own technological belief is to use whatever tools, platform, etc. make sense for your own situation. Again this seems like just giving in, but it is not. There are still fundamentals to keep in mind in terms of getting support, safeguarding your data, etc. but they can be enacted on virtually any platform. For all the flak that Microsoft Windows takes it can be locked down quite well. For all the raves that the Mac gets for style there is a closely controlled platform that stifles some kinds of development. For all the intellectual purity of most Linux versions there is still often a steep curve for the computing novice. For all the vaunted stability, etc. of the mainframe there is a prohibitive cost and lack of common support in the workforce.
If you or your company already employ a bunch of Windows admins and everybody is used to Windows there is not much point in having a Mac or Linux jihad because of some perceived superiority. It just does not make sense in that situation. Similarly, if you have a Unix setup and all is well, why upset the system to introduce a single Microsoft application when there are ways to integrate it into your existing setup?
All that said, strong arguments can be made for using standardized PCs, running open source software in "clean sheet" situations where low cost is an overriding concern, such as with the One Laptop Per Child project, or indeed for any other organization who only needs certain kinds of generic functionality, not tied to a particular software package.
The techgnostic part of all this is that in an ideal situation where the platform has not been dictated there are many options to solve your technology problems and we should not shut ourselves off into any one camp. The personalities and business practices of the players should not play a major role in our decisions - what works for us in our situations should be front and center.
That is being techgnostic.
Sunday, March 9, 2008
Manager Tools
When I assumed my management role I had up until then acted as a lead or senior developer, leading small teams of programmers.
In those positions I did not do performance reviews, except to provide feedback to managers when requested. I did not actively participate in recruiting efforts, outside of being asked to speak to candidates. My need to convey status was relatively simple, targeted towards what the group and I were working on. It was relatively manageable to keep an eye on what was being developed, to help out with coding issues and to guide the programming efforts.
Any other aspect of management was handled by my manager. I had taken organizational behavior courses at university, plus some psychology courses and had a general idea of how you should interact with people if you wanted them to not react adversely to suggestions or direction. To a great extent, though, people were still baffling, but I did not have to really deal with people issues very much. Those issues would be kicked up to the manager.
Previous experience in administration rotated around worrying about office details at a startup, and being seconded into helping make certain projects happen. The paperwork load as a senior / lead developer was not onerous, though at times annoying. Again, the manager had to handle all that, but that was his/her job.
When I started "managing" I suddenly found myself thrust into needing to deal with people issues, continual requests for status (a friend termed me the "answer monkey" - i.e., when someone wanted an answer they would rattle my cage) and administrative overhead to accomplish tasks like recruiting, setting up training, etc. I thought "OK, I've seen this done before. It can't be difficult."
After trying what I thought were the correct approaches I realized that I needed to learn some new techniques. I read some pieces on management (helped a bit), went to some seminars (helped more) and tried out different approaches. Some things worked, and I kept doing them. Others did not, and I stopped doing them.
I seem to be handling most management items acceptably well, hiring people in and my direct reports are getting things done. I still find myself snowed under with minutiae, and struggle to control a lot of the things that demand my time (I will go on in another post about "Getting Things Done"). As an attempt to squeeze more learning into a day without adversely impacting my existing personal and professional obligations I started listening to learning CDs in the car on the way into work. These helped also, squeezing a little more learning in.
However, listening to CDs was a bit too limiting as I also have time to listen when I'm walking or at the gym, so I transferred them to my iPod. That helped somewhat too, but some of the courses on CD are six or more hours long, and I found it hard to squeeze effective learning into the half-hour fragments I tend to have. I had been subscribing to some music podcasts, and recently had added a Spanish language and a legal issues podcast. I cast about for other podcasts to add and came across Manager Tools.
Ah ha!
I started listening to their podcasts from somewhere in the early 2007 time frame and was hooked. Here was a reasonably short podcast (in the 20 to 30 minute range) with specific actionable items that I could use immediately. The presenters provided all kinds of context and information about why to take the action, but the takeaway was the thing that you should do, or other nugget of good information. Rather than trying to make a single, monolithic work that covers every last aspect of management they have taken the approach of presenting bite-sized pieces of useful knowledge.
If you are interested in management at all, you need to go listen to these podcasts.
In those positions I did not do performance reviews, except to provide feedback to managers when requested. I did not actively participate in recruiting efforts, outside of being asked to speak to candidates. My need to convey status was relatively simple, targeted towards what the group and I were working on. It was relatively manageable to keep an eye on what was being developed, to help out with coding issues and to guide the programming efforts.
Any other aspect of management was handled by my manager. I had taken organizational behavior courses at university, plus some psychology courses and had a general idea of how you should interact with people if you wanted them to not react adversely to suggestions or direction. To a great extent, though, people were still baffling, but I did not have to really deal with people issues very much. Those issues would be kicked up to the manager.
Previous experience in administration rotated around worrying about office details at a startup, and being seconded into helping make certain projects happen. The paperwork load as a senior / lead developer was not onerous, though at times annoying. Again, the manager had to handle all that, but that was his/her job.
When I started "managing" I suddenly found myself thrust into needing to deal with people issues, continual requests for status (a friend termed me the "answer monkey" - i.e., when someone wanted an answer they would rattle my cage) and administrative overhead to accomplish tasks like recruiting, setting up training, etc. I thought "OK, I've seen this done before. It can't be difficult."
After trying what I thought were the correct approaches I realized that I needed to learn some new techniques. I read some pieces on management (helped a bit), went to some seminars (helped more) and tried out different approaches. Some things worked, and I kept doing them. Others did not, and I stopped doing them.
I seem to be handling most management items acceptably well, hiring people in and my direct reports are getting things done. I still find myself snowed under with minutiae, and struggle to control a lot of the things that demand my time (I will go on in another post about "Getting Things Done"). As an attempt to squeeze more learning into a day without adversely impacting my existing personal and professional obligations I started listening to learning CDs in the car on the way into work. These helped also, squeezing a little more learning in.
However, listening to CDs was a bit too limiting as I also have time to listen when I'm walking or at the gym, so I transferred them to my iPod. That helped somewhat too, but some of the courses on CD are six or more hours long, and I found it hard to squeeze effective learning into the half-hour fragments I tend to have. I had been subscribing to some music podcasts, and recently had added a Spanish language and a legal issues podcast. I cast about for other podcasts to add and came across Manager Tools.
Ah ha!
I started listening to their podcasts from somewhere in the early 2007 time frame and was hooked. Here was a reasonably short podcast (in the 20 to 30 minute range) with specific actionable items that I could use immediately. The presenters provided all kinds of context and information about why to take the action, but the takeaway was the thing that you should do, or other nugget of good information. Rather than trying to make a single, monolithic work that covers every last aspect of management they have taken the approach of presenting bite-sized pieces of useful knowledge.
If you are interested in management at all, you need to go listen to these podcasts.
- Web site: http://www.manager-tools.com/
- Podcast name: Manager Tools
- Podcast URL: http://www.manager-tools.com/podcasts/feed/rss2
- The "basics": http://www.manager-tools.com/manager-tools-basics/
Saturday, March 8, 2008
Some Background
My technology dalliances began with an Apple II+ at school, and a VIC-20 I purchased with my own hard-won paper-route dollars.
The paper route leads me to a tangent.
In the old days (i.e., the 70's and 80's) a child could sell him/herself into contract slavery, whereby they delivered newspapers six or seven days a week, for what amounted to less than minimum wages. Nowadays these first forays into the world of work have been supplanted by adults that scoop up huge delivery areas and pitch papers from their cars, rather than having youngsters pitch them from their bikes. I worked hard for my money, cutting lawns and delivering papers. I learnt important lessons about work and people that have stuck with me always.
So what? So it meant that I very much valued my little Commodore computer. I hooked it up to the family TV (the one and only) and would get my coding sessions in when others weren't wanting to watch a program. My work was saved to the cassette drive, another important lesson in backing up.
I never saw myself as a computer guy as I was using the computer to get other things, mostly to get to games, or to automate some task. My interest was to be able to live off some form of artisitic pursuit, be it writing, drawing (cartoons) or music. I'd dabbled with writing (so-so at it) and drawing (not so good at it) and music (yeesh - don't go there) right up to graduating from high school. I never had a clear vision of what I wanted to do, though I made good marks. I went into university with a mixed bag of courses, including computer programming, English, creative writing, art studio foundation and math. When I discussed this with my father he sat me down and said simply "Todd, you are not going to live at home forever".
Oh.
So, in the spirit of having to "do something" with what I was learning I did a Bachelor of Science degree in Economics where, again, computers were in there all over the place, but I did not think of myself as a computer guy. I also took all my pre-Commerce courses (organization behavior, various accounting courses, financial math, etc.). I got into geographic information systems (GIS) before I graduated, having a chance during a research project to work with one. When I graduated I had a few choices:
After the contract ended I realized I needed more technical grounding than I had and pursued a Civil Engineering diploma in GIS, wherein I learnt ferocious amounts about all the things that had been somewhat mysterious up until then, and I learnt C programming. My earlier exposure to Pascal in university saved me from the pointer-madness many of my classmates suffered. I graduated from the program and went to work in the oil and gas industry.
After four years and some contracts that depended upon the price of oil for continued funding I decided to look around for other opportunities less dependent on resource prices. An opportunity knocked and I relocated to Texas for a startup company gig. That experience did not last very long, but I again learnt some very important lessons. After that I tried to make a go of it on my own again but unfortunately chose the wrong market to try and enter. I took a job with Dell to get out of that experiment (again, more lessons learnt) and found out what working for a very large company was like (Dilbert became even more applicable).
I left Dell for the greener pastures of a hedge fund wherein I helped them move their desktop applications to the burgeoning web platform and again got some schooling in human nature and the nature of technology projects. About four and a half years into that I fell victim to some maneuvering and again moved on. A brief foray into retail web apps for Pier 1 was followed by going into the pharmacy processing field. For the last few years that has been my new experience, both in terms of industry and moving from a team lead / senior developer into a management role.
I have approached full-on management (not just team lead / senior) like any other role change I've had. That is, a lot of research, reading and looking for ideas. A lot of my old courses bubbled back up into my consciousness (clawing through the layers of API calls, hacks to get around IE versions and tweaks to make SQL run faster) and have helped. It's been an interesting transition, and part of that experience is why I wanted to start to blog again. I think that managing developers is somewhat different than other direct reports, in particular as it is often harder to measure what's going on, and the conditions for good code to come into existence are very tricky. Maybe getting all the ideas out and working them over will help.
So far, so good.
The paper route leads me to a tangent.
In the old days (i.e., the 70's and 80's) a child could sell him/herself into contract slavery, whereby they delivered newspapers six or seven days a week, for what amounted to less than minimum wages. Nowadays these first forays into the world of work have been supplanted by adults that scoop up huge delivery areas and pitch papers from their cars, rather than having youngsters pitch them from their bikes. I worked hard for my money, cutting lawns and delivering papers. I learnt important lessons about work and people that have stuck with me always.
So what? So it meant that I very much valued my little Commodore computer. I hooked it up to the family TV (the one and only) and would get my coding sessions in when others weren't wanting to watch a program. My work was saved to the cassette drive, another important lesson in backing up.
I never saw myself as a computer guy as I was using the computer to get other things, mostly to get to games, or to automate some task. My interest was to be able to live off some form of artisitic pursuit, be it writing, drawing (cartoons) or music. I'd dabbled with writing (so-so at it) and drawing (not so good at it) and music (yeesh - don't go there) right up to graduating from high school. I never had a clear vision of what I wanted to do, though I made good marks. I went into university with a mixed bag of courses, including computer programming, English, creative writing, art studio foundation and math. When I discussed this with my father he sat me down and said simply "Todd, you are not going to live at home forever".
Oh.
So, in the spirit of having to "do something" with what I was learning I did a Bachelor of Science degree in Economics where, again, computers were in there all over the place, but I did not think of myself as a computer guy. I also took all my pre-Commerce courses (organization behavior, various accounting courses, financial math, etc.). I got into geographic information systems (GIS) before I graduated, having a chance during a research project to work with one. When I graduated I had a few choices:
- Take my Economics degree and get a government job, crunching numbers forever;
- Continue my education and get a Masters degree, get a government job and crunch numbers forever; or
- Take a contract working on a GIS for the electrical utility.
After the contract ended I realized I needed more technical grounding than I had and pursued a Civil Engineering diploma in GIS, wherein I learnt ferocious amounts about all the things that had been somewhat mysterious up until then, and I learnt C programming. My earlier exposure to Pascal in university saved me from the pointer-madness many of my classmates suffered. I graduated from the program and went to work in the oil and gas industry.
After four years and some contracts that depended upon the price of oil for continued funding I decided to look around for other opportunities less dependent on resource prices. An opportunity knocked and I relocated to Texas for a startup company gig. That experience did not last very long, but I again learnt some very important lessons. After that I tried to make a go of it on my own again but unfortunately chose the wrong market to try and enter. I took a job with Dell to get out of that experiment (again, more lessons learnt) and found out what working for a very large company was like (Dilbert became even more applicable).
I left Dell for the greener pastures of a hedge fund wherein I helped them move their desktop applications to the burgeoning web platform and again got some schooling in human nature and the nature of technology projects. About four and a half years into that I fell victim to some maneuvering and again moved on. A brief foray into retail web apps for Pier 1 was followed by going into the pharmacy processing field. For the last few years that has been my new experience, both in terms of industry and moving from a team lead / senior developer into a management role.
I have approached full-on management (not just team lead / senior) like any other role change I've had. That is, a lot of research, reading and looking for ideas. A lot of my old courses bubbled back up into my consciousness (clawing through the layers of API calls, hacks to get around IE versions and tweaks to make SQL run faster) and have helped. It's been an interesting transition, and part of that experience is why I wanted to start to blog again. I think that managing developers is somewhat different than other direct reports, in particular as it is often harder to measure what's going on, and the conditions for good code to come into existence are very tricky. Maybe getting all the ideas out and working them over will help.
So far, so good.
Here we go again!
Apropos of nothing, I will once more put my thoughts to virtual paper, if only to give some place for my thoughts so that I can look back. Probably I will direct some people here also if I think something I've written is worth their time.
I started a blog in 2005 and made a couple hundred entries into it before petering out. The posts were a mix of random rambles and meticulous notes following the Hacker's Diet and my attempts to implement Getting Things Done. That blog fizzled for me, or at least my interest in it did, and had enough personal items in it that I decided to abandon it. It was also written with a pseudonym, and I think that encouraged me to be a bit more open with things I'd rather have kept to myself.
This time around I am going to be more "professional" in that I will not regale anyone with tales of my personal doings, and will stick to observations on technology, management, society, philosophy, etc. - bracing subjects, all.
As much as I'd like to be like Rands and have a cool hacker handle I am sadly lacking in that department. OK, I thought, I will use my real name. Alas, my name is far more common than I thought, so I went back to one of my first user account names and recycled it.
Despite not having a cool blog name, I am, however, going to take up some of his practices, including:
So, in case anybody reads this, welcome to the blog!
I started a blog in 2005 and made a couple hundred entries into it before petering out. The posts were a mix of random rambles and meticulous notes following the Hacker's Diet and my attempts to implement Getting Things Done. That blog fizzled for me, or at least my interest in it did, and had enough personal items in it that I decided to abandon it. It was also written with a pseudonym, and I think that encouraged me to be a bit more open with things I'd rather have kept to myself.
This time around I am going to be more "professional" in that I will not regale anyone with tales of my personal doings, and will stick to observations on technology, management, society, philosophy, etc. - bracing subjects, all.
As much as I'd like to be like Rands and have a cool hacker handle I am sadly lacking in that department. OK, I thought, I will use my real name. Alas, my name is far more common than I thought, so I went back to one of my first user account names and recycled it.
Despite not having a cool blog name, I am, however, going to take up some of his practices, including:
- The opinions expressed on this website are entirely my own. They do not represent the strategy/plans/thoughts of my employer, my family, my friends, my cat, etc.
- In some of my posts, I will refer to specific people as a means of telling the story... making a point. These people do not exist - they are fabrications that are specifically constructed to make a point. There are traits or quirks of former co-workers and friends that I borrow to construct my story persona, but these small slices of personality do not a person make.
- Lastly, I go out of my way to never borrow traits, ideas, or personalities from my current set of co-workers and managers. That would be bad form.
So, in case anybody reads this, welcome to the blog!
Subscribe to:
Posts (Atom)