The Grass is Greenest on Your Side
I just read an interesting message posted by Pi Guy on Joel Spolsky's site. This fellow works as a developer but does not like any of the non-coding aspects of his job:
I'm a "programmer" at a small web development company. We do web design, asp/asp.net/sql server applications.
I generally like my job when I just stick to coding behind the scenes. I'm one of those people that can code for 8 hours straight, and it feels like I've only been working for 4 hours -- I really like coding. The problem is that my job is shifting more and more away from coding:
Things I don't like:
- I have to go on sales calls as the technical person
- I write 90% of the content of proposals (defining the scope of a project -- the sales people say they aren't capable of writing this part).
- I'm required to tell my boss exactly how many hours a project will take before we've fully gathered requirements. They base the cost of a project on these hours * an hourly rate. So, it becomes my job to really gather the requirements because it's my tail on the line if the hours are wrong.
- I have to give out my business card to clients with my direct phone number. So, they end up calling me first if they think there's a problem.
Basically, I hate being involved in the sales process in any way. I feel that the sales people could learn to do what they're making me do, but they are too lazy. Before I came here, I had ideas of just coding all day and being left alone. I end up not developing my coding skills because I feel like I'm wasting my time on other areas that won't help me to become a better coder.
Are programmers just programmers at other companies in general? I'm just trying to figure out if the grass really isn't greener on the other side of the fence.
NOTE: I understand that I have to work with people. I totally accept that, and I really enjoy working with a team of developers. My dream job is one where I work with a team of 3 to 4 programmers. Another team would be responsible for gathering requirements them handing them off to us.
I am of the opinion that his job sounds great. He gets to code AND be involved with the sales process AND have significant say-so in project estimates AND hear feedback directly from customers. That, my friends, is a great recipe for being promotable and less likely to be laid off. True, it would be nice if there were at least one layer of tech support between the customers and the developers, but in a small development shop it is not unusual for the developers to BE the tech support.
His message reminds me of my article Repeat After Me - I Am Not In The Software Business. Pi Guy doesn't appear to have the "I am an artiste attitude", but he certainly does seem to be blind to the incredible opportunities that come along with being involved in the business side of the house. Due to the huge (and often fragile) egos that inhabit our industry, no developer on earth wants to admit that writing the code is the easiest part of what we do, but it is. Developers who are able to add value beyond coding by performing functions that translate the business needs into a technical context and back again are the ones who will remain employed in the near future.
Pi Guy, I say you should embrace the non-coding parts of your job. I've been out here for 11 years, and trust me - the grass appears to be greenest on YOUR side this time.
Non-Technical Workers Managing Technical Projects: 3 Keys
Working with small businesses, I often find that the person designated to be my point of contact on a given project is made responsible internally for the success or failure of the project, but has no technical knowledge whatsoever. I am accustomed to mitigating this kind of situation by translating a lot of the technical aspects of the project into business-speak and by keeping the project sponsor well informed. But in many cases no matter what I do, the poor fellow just seems overwhelmed, scared and unprepared to communicate with a technical professional. Over time I've come to notice a few things that the best-prepared and most successful non-technical workers have in common when it comes to dealing with technical professionals like myself.
I'm sure this will all seem obvious to any technical worker, but this article isn't for you; it's for the non-technical guy whose boss makes him responsible for getting a technical project done, who finds himself besieged by a bunch of geeks speaking a different language and doing things he doesn't understand. Hopefully this little bit of advice will help alleviate some of the pain that often accompanies working with a technical service provider.
1) Know Your Business
Before undertaking any technology project, you must know two things: a) How the portion of your business that will be impacted by the project works now, and b) How you want that part of the business to work post-project.
This may seem so elementary as to not merit mentioning, but it must be said. I am always amazed at how few businesses have a clear picture of their internal workings. On more than one occasion I've been in a requirements gathering session with clients who are arguing amongst themselves about what their processes are. Make no mistake - you absolutely cannot get underway with any technology project until you know what is happening today and what you want to happen tomorrow. This is not to say that you should not also allow your technical service provider to map your processes your own business process knowledge is a supplement to the provider's discovery process, not a replacement for it. A third-party analysis of your business can often reveal subtleties that you miss due to the classic forest/trees effect.
If you yourself are a project sponsor, make sure you know your business backward and forward. And if you are the manager responsible for delegating oversight of a technical project to one of your non-technical employees, make sure you delegate it to someone with good domain knowledge.
The best case scenario is that you select a competent enough provider to simply turn over the entire project without dedicating any of your employees to oversight. However, this is sometimes not realistic, so be certain to do your homework on your own business. If nothing else the perspective will enrich your performance at work.
2) Select a Provider Carefully
It can be hard - very hard - to reliably select a technical service provider. The ubiquity of PCs and computer books have produced a glut of self-described "developers", "consultants" and "network administrators" who are not truly qualified to do any project that has the operation of a business relying upon it. This leads to an environment of considerable uncertainty when you area non-technical worker who is tasked with making a technical project happen in your workplace - how do you know who to trust when you don't have sufficient technical knowledge to verify a potential provider's competency?
A few months back I wrote an item entitled The 5 Laws of Choosing a Software Developer; in truth, those Laws could apply to choosing a web designer, network admin, or any other type of technical service provider. I suggest you read the whole 5 Laws article, as each Law is described in depth, but the basic 5 Laws are:
- Demand Experience
- Demand References
- Demand Value
- Demand Communication Skills
- Demand Availability
I cannot overstate how important it is to select the right technical service provider. Not the cheapest one, not the best-dressed one, not even the most talented one, but the right one. It is very much a matter of fit. Once you've chosen a technical service provider, trust and listen to that provider - if you did your due diligence before making a choice, this should be easy.
3) Demand Outcomes, Not Technologies
I recently saw a discussion on this very topic at Joel on Software. I am always suspicious of non-technical clients who call me up and say "We need a Java application" or "We need a SQL Server database", and with good reason - when you visit the local car dealership, do you ask for a car built by an ABB industrial robot? When you buy a computer, do you ask for one whose hard drive heads were cut by an MTI machine? Of course not - you ask for a car that gets better than x miles per gallon, or that has heated leather seats and a navigation system. The means and the outcome are two distinct issues, and should be treated as such.
For maximum results, your focus should be on your business and what business-enhancing outcomes you want from your technical project. You are the expert on your business - the technical service provider you select is the expert on making technology support business needs. Talk to your provider about your desired outcomes, and then trust the provider to determine the most appropriate means to achieve these outcomes. Obviously, if you are in a company that has already heavily invested in one particular kind of technology (whether you're a UNIX and J2EE shop or a Microsoft shop), you'll need to make this known and it will certainly factor into your service provider's recommendation.
Once you have communicated a set of desired outcomes, stand by them. If you have chosen your provider wisely, they will be able to understand your business and deliver the results you've asked for. There is no acceptable excuse for nonperformance.
There are undoubtedly many other things that a non-technical worker can do to be prepared to handle a technical project; the three I've listed here seem to be the most common denominators of success amongst the clients I've worked with. Feel free to eMail me with your own stories or suggestions with regard to non-technical workers having to manage or oversee technical projects.
Marcus Tucker Believes in the 5 Pitfalls
I see that Marcus Tucker has posted some complimentary words about my article, The 5 Pitfalls of Estimating a Software Project. Marcus appears to be a smart guy, and it's nice to see the gospel of effectiveness being embraced by people who are sharp and know what works and what does not. Thanks, Marcus!
A Time For Change
Can you say "redesign"? I knew you could.
I've been having a great time playing around with CSS! The web is filled to the brim with great tutorials, templates and code snippets, so there was really no excuse for not having a deeper understanding of CSS-based design than I had previously. I spent about 15 minutes Googling for tutorials and templates, found a simple template at the SSI-Developer site to get me started, and a little while later I had my redesign. It was almost too easy.
To date, the bulk of my web work has been for corporate intranet applications, where a fast network and standardization around IE could be taken for granted. Now that Firefox is catching on and I am getting more and more requests for public web work, it's time to get more deeply into the CSS movement.
The new design is not complete by any means, so please, spare me the eMails lambasting me for not being standards compliant (I'm not even convinced that standards compliance is all it's touted to be, but that is a rant for another day). I'll be using this page as my personal CSS experiment. It has been tested against IE and FireFox, which represent 95% of my traffic. I will tackle the task of making the site look nice to the other 5% as time goes on. For now, this is a project for my own fun and education. Fun is something that can easily end up missing from your work if you don't watch out for it.
11,457 Readers Can't Be Wrong
In other news, my readership has been steadily increasing since I launched my blog. In September I had 11,457 visits to this site. Unfortunately, my site stats are not able to tell me how many distinct visitors made up that 11,457. Is it possible that I have 11,457 distinct readers? I doubt it. Still, I have to wonder - how many actual readers do I have? And with that many visits, why weren't there more posts in the discussion forum before I phased it out?
Speak up, readers! I'd like to get to know who you are - post a link on your own blog and I'll find you via my referral logs.
MicroISV.com Discovers My Blog
I noticed a few referrals from MicroISV.com and went to investigate. Sure enough, they have discovered my blog, which is cool - I really like that site.
![]("image.gif")
