My Photos

www.flickr.com
This is a Flickr badge showing public photos and videos from coogle. Make your own badge here.

Quicksearch

Making your boss like you more..

Monday, November 19. 2007

I've seen this about a million times at various clients working in the services business, so I thought I might take a moment to mention it on my blog -- perhaps someone will find it valuable. From where I stand, there is a huge portion of the development community in general (not only PHP really either) that seem to think their job is nothing more then to write code without consideration for anything else in the organization.

Guess what? Your boss doesn't care how awesome your code is, or how slick your super-duper AJAX auto-complete wiz-bang thing is if you write something which doesn't support the business needs of the company.

Here are some of the classic blunders I've seen:

* Spending two days refactoring a piece of code which not only were they not asked to refactor, but it was working just fine before (no, the fact it was ugly is NOT always a good enough reason to refactor)

* Trying to be the developer version of Vincent Van Gogh -- code can be art, but it is always a means to solve a real business need. Over-architecture doesn't make you look cool, it makes you look like an idiot when the next guy shows you how to solve the same business need in 30 lines of code instead of 400.

* Not understanding you are responsible for your own time lines. I don't care if you have a project manager or not working in the group -- ultimately at the end of the day as the guy writing the code if you say it's going to take 3 weeks to develop something and it takes you 3 months that is entirely your problem. What does that mean? It means when your boss comes over and constantly changes the scope or features of what you are trying to build if you don't push back and make him decide between getting the project done in 3 weeks or his feature that's your fault.

* Know your business - its amazing how many developers are out there writing code without having any idea what-so-ever why they heck they are getting paid to write it. If you can't speak intelligently about the business your company is in and why your application is going to benefit that business for at least 30 minutes then you aren't being a very good developer. We all sometimes like to imagine that the world revolves around us, but let's face it -- you're working in a company and that company is trying to do something which you probably should understand before you try to write the code to do it.

I'm sure there are more if I had more time, but that's good enough for now. Bottom line: Code is not the most important thing in business, even though it might be in OSS. If you want to be a successful professional OSS developer you need to understand both and react accordingly!

Bookmark Making your boss like you more..  at del.icio.us Digg Making your boss like you more.. Bloglines Making your boss like you more.. Technorati Making your boss like you more.. Fark this: Making your boss like you more.. Bookmark Making your boss like you more..  at YahooMyWeb Bookmark Making your boss like you more..  at Furl.net Bookmark Making your boss like you more..  at reddit.com Bookmark Making your boss like you more..  at blinklist.com Bookmark Making your boss like you more..  at Spurl.net Bookmark Making your boss like you more..  at NewsVine Bookmark Making your boss like you more..  at Simpy.com Bookmark Making your boss like you more..  at blogmarks Bookmark Making your boss like you more..  with wists Bookmark Making your boss like you more..  at Ma.gnolia.com wong it! Bookmark using any bookmark manager!

Trackbacks

No Trackbacks

Comments
Display comments as (Linear | Threaded)

John,
The funny thing about what you just posted is that I was thinking about posting a blog entry about this same subject.

It is such a common downfall of programmers. The biggest problem in my point of view is that programmers typically do not understand business or how a business functions.

Primarily they see it as they are the masters of what can go in and what comes out with little regard to what business actually knows is going to produce results or where they are going long term.
#1 Mike Willbanks (Homepage) on 2007-11-19 17:40 (Reply)
I'd have to say I agree with most of this - but I've ran into issues with #4. There are times when I've been put into positions - especially with working with the System-i (as/400) where I'm just supposed to 'know' that I get these values... and then display them on a website 'like this - so its useful' There wasn't a lot of information explained to me about what I was doing. It was a good year of poking and prodding around until I began to understand what was going on in the business. At any rate, I totally agree - don't be adverse to learning about the business - but sometimes you'll actually have to look for opportunities (and I just wanted to make sure that was clear here!) :)

-aaron
#2 Aaron Saray (Homepage) on 2007-11-20 00:21 (Reply)
"...you look like an idiot when the next guy shows you how to solve the same business need in 30 lines of code instead of 400."

Perhaps, but later, when the 30 lines of code are found out to have trimmed corners and demonstrated lax security policies, and someone has to go fix it (with no documentation), was it really worth the short cut? You did say "over architecture," so perhaps what you say is true, but there is definitely a fine line between cutting corners and being efficient.

Overall I agree with your post. A lot of developers do not see the importance of business goals and process and how that eventually translates to them getting paid. That's why it's critical for developers who are responsible for a company's software development to become familiar with the business's goals; it gives you the ability to evaluate not only what is possible, but what is practical.
#3 Brian Dailey (Homepage) on 2007-11-20 13:10 (Reply)
30 or 400 lines of code, if it's junk it's junk. I'm by no means suggesting that it is better to write crap and get it out the door.. A good architect/developer will be able to create a really solid architecture, an experienced business-minded developer will know not only how to create the really solid architecture, but how to develop just enough to solve the business need and still leave himself enough breathing room to enhance/refactor/improve it later without a huge issue.
#3.1 John Coggeshall (Homepage) on 2007-11-21 17:59 (Reply)

Add Comment


To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA