Probably nothing sets me apart from other programmers more than the fact that I have managed profitable (and not profitable) businesses for decades at a time, through thick and thin.
Making payroll for as many as 30, once close to 50 people at a time, keeping costs in line with billings, etc, has a way of disciplining one's self beyond what one might imagine before undertaking such a silly thing.
2005 - 2010 virtually every project I have worked on, I have also answered to the owner or management as the principal product lead responsible for direct bottom line costs and productivity.
Marketing is not the same as sales, marketing is getting the message out there, and I have been a practiced and recognized marketer since 1985.
Sometimes polished, sometimes rough, but always effective for my target market, I established a very well known brand in my small market segment in the 1980s.
For the decade between 2000 and 2010 I have carefully avoided all forms of marketing other than user groups due to having consistently more work than I wished to take on as a one man firm.
Negotiating may seem to be a curious thing to put in an IT resume, but it is an IT skill that I find useful every day, no matter if I am negotiating scope on a win-win basis with the customer, or negotiating which technology to use with a peer.
It didn't start out as an IT issue, from 1975-1988 I negotiated dozens and dozens of building contracts totalling over 5 million dollars, and found that generally, the record showed that I did not excel at this task during this period. When I learned there were actually courses I could take, I attacked the study of negotiating with the zeal that comes from having one's butt handed back to one'self on a platter. I didn't let go until i proved to myself that I had developed excellent negotiating skills.
Negotiating is all about win-win, and at first I negotiated too well, it was me winning and others losing. But over the years I have matured and grown in this practice, and now am fairly good at it, at least I am when I want to be.
I negotiate every day. I negotiate with team-mates on best tasks for each to tackle. I negotiate with bosses and owners on approaches and goals. And on and on through every aspect of my life. Good skills in this area allow me to use my best talents where they do the most good, and the same with others I deal with.
Since you are reading an example of my communication skills, perhaps you could tell me as much as I could tell you.
Sparing you of false claims about the quality of my communications, I have been an active and sometimes articulate communicator in many different media throughout my life.
Have tried to keep up with all the latest fads and styles, seem to be as capable as the next guy at:
If there is an achiles heel, I am not the best long-meeting attendee you have ever met. Meetings that I run are typically over very quickly, unless I can get it down to a couple or three attendees and then I'm a little more relaxed because the meter isn't running on as many bodies...
I have been managing projets and personell consistently since 1976, before I even finished my first trades apprenticeship. I have a;most always worked with small companies and teams, which where the manager is not just the leader, but also the provider of whatever element was missing from the team.
From 1975-1997 I managed millions of dollars of construction work, most of which I also estimated, sold and contracted with both customers and vendors.
From 1995 to current I have menaged many projects in the IT world, though typically this has only been my own work, or the work of a very small team.
In the IT world which often shuns management as a general rule, my management role has often has to be undeclared or de-facto. This is usually a more comfortable role for me, as it's easier to get co-operation from peers than subordinates.
EDS once advertised it's work as herding cats, which for me as often been to spread out the facts to those on the team, and asking them how they wished to address them. Often that is all that is requierd to keep a project on track.
I have sometimes worked with customers to engineer or re-engineer projects to make them fit the customers needs better and make the sale.
It is a role that I feel comfortable with, though I have rarely worked in this role for more than a few hours or days at a time.
This is almost always a win-win for both customer and producer, as it is rare that an initial design concept perfectly nails the most efficient way to produce software, or anything, for that matter.
I have been teaching formally and informally since 1977, when I began several years as an instructor for several different modules of the local carpenters apprenticeship program.
1986-1990 I ran my own formalized training program of sorts to facilitate the crewe I was running in my own shop - Pete Carepenter Company. We met weekly, and covered every relevant topic. Attendance was equal to crew sixe, usually 8-20.
2001-2004 I co-founded and ran or co-ran (depending on the year) the local users group "Hands On Java". We met at different periods, sometimes bi-weekly and sometimes monthly, and covered a wide variety of topics. I presented about 10% of the sessions myself, volunteers or my partner presented the rest.
Much is made of the Horatio Alger type story where the guy starts at the bottom, but it doesn't always have to end up in wealth.
Having started at the bottom and working my way up in both programming and previous careers, I have always found it easy to build the best teams. This is something I also learned from my Father and GrandFather, as I watched them as choral directors build brilliant choirs from otherwies undistinguished participants.
Whether working with a titled lead role or as a peer, I have always found it possible to encourage, lead by example, raise expectations and compare notes, building strong teams as a natural result. I have always found that a strong team is more than just efficient, it is much more fun to work on a strong team for all players.
Several times throughout my career I have performed an analysis of work flow situations, and come up with a solution for improving efficiency.
The interest is far from academic, see Bottom Line.
As it relates to the programming/development profession, several of these analysis and prescriptions resulted in new architecture, re-distribution of tasks, usage of new technologies, and other.
This is a field which requires both analysis and diplomacy. I have always been better at the former, but have learned a great deal about the latter in recent years.
It has always helped that I was willing to tackle whatever the hardest jobs that came out of such tasks.