As I've mentioned before, I used to try my hardest to
avoid contact with the customer, and as software developers, I think
we don't spend enough time concerned about the business aspects of what we do.
In
My Job Went to India, Chad Fowler says he thinks so too.
To combat code monkey syndrome, Chad suggests we have lunch with business people and read trade magazines for our business domains as often as we can.
Working for a tiny consulting company, I get the benefit of being close to all the business decisions, but not in many specialized domains. However, since I made the decision to stop being a "code robot" (Chad's term), I've always taken the opportunity to talk with clients or meet them for lunch to discuss
their domains. Even more recently, a couple of us here have taken to reading trade publications related to a product we're building.
Doing so helps you understand why some of those "crazy" requests are made, and what you can do to make them work in the system while still accomplishing the client's goals. And things just seem to work
better that way. Nowadays, I'm no longer getting any "that's a nice system, but it's not what I wanted" comments due to keeping myself stuck in a walled garden. Instead, I'm building software customers want and will use. And the purely selfish benefit: I'm adding to
my value as an employee or contractor in those domains.
As an aside, last week I was on vacation, so that's why you didn't see this then. I'll try to make up for it and post two this week.
So are you a code monkey? Are you trying to evolve into a code human?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Sam, this is something that I have a personal struggle with. I love being a code-monkey. I love solving problems in code and figuring out new ways to do things or rediscovering ways of doing things that lots of people already knew about (but I did not). To me, it's all about the hunt and the joy of the proverbial "kill."
Like you, I work at a small company, and as such, I do have a tremendous amount of contact with the clients including daily phone calls and the occasional face-to-face meeting. I enjoy this aspect of the job, but I am afraid to move into a position where I have more face time and less code time. The coding is what really makes my day fun - the joy of client-relationships is really just a bonus on top of that. Right now, I am not letting one sacrifice the other... but everyone I ever talks to seems to think that this is not a good position to be in.
Not sure how this will play out in the long run.
Posted by
Ben Nadel
on Jul 31, 2007 at 06:30 AM UTC - 5 hrs
Ben - I think the fact you said "I love solving problems in code and figuring out new ways to do things" pretty much disqualifies you as a code monkey. Code monkeys take solutions that have already been figured out and type them into the computer. =)
I like to code too (well, I sure do spend a lot of time trying to code less!), but I definitely like my relationships with clients, and learning the business domains. Sounds like you are doing it right!
Of course, I think Chad was really talking about specializing in domains more than gaining detailed knowledge of particular aspects of many domains.
What is the rationale they use to say "this is not a good position to be in," by the way?
Posted by
Sam
on Jul 31, 2007 at 03:19 PM UTC - 5 hrs
When people tell me that this is not a a good place to be (in the coder's mindset) they mean that it is a position that does not evolve. That to progress in my career I have to start being more of a manager which will require moving away from the coding aspects of life.
It's funny, though, cause when I think about "Value" that someone can bring to a company, I don't necessarily see managers and architects as more valuable. People tell me that I should aim to become less a coder and more a system architect, but how can I possibly do that until I have mastered coding?
I used to think it was possible - that understanding the big picture was doable without mastering the nitty-gritty of code implementation... but lately, I am not so sure. An architect, I think, is only as good as his ability to guide others; and, even with understanding the overview a system, how well can you guide people if you do not have a rock-solid understanding of implementation??
Sorry, maybe not the most coherent of thoughts :)
Posted by
Ben Nadel
on Aug 05, 2007 at 04:35 PM UTC - 5 hrs
Thanks for the clarification, Ben.
Like many people, I too am skeptical of the "ivory tower architect." It's one thing to see the big picture. It's quite another to design a system without being aware of the constraints pulling on you.
Posted by
Sam
on Aug 05, 2007 at 07:37 PM UTC - 5 hrs
