Wednesday, February 18, 2009

On being a GIS Developer, Part 2

Here is this week’s entry on being a GIS Developer. For Part 1 click here.

21. You must be able to think abstractly at one point and with great focus and precision at another point. GIS is by its very nature an abstract proposition. We are always dealing with representation of one form or another. On the other hand, when writing code you must be able to switch to the more logical side of your brain.

22. You should be able to reason and also listen to reason. Pay attention to what people are saying and how they are saying it. Develop your emotional intelligence as well as your rational thinking abilities. Learn to read between the lines. Learn how to spot logical fallacies and effectively respond to them.

23. You should understand that others don't understand GIS like you do. As a developer you understand GIS from a completely different level than most others. When they see a GIS they see a fancy map but you see points, polylines and polygons, vertices, and other complexities.

24. You should be willing to mentor others. Once you’ve gained some experience be willing to help others grow. Not only does this help your team it helps you hone your knowledge and skills because it forces you to really know what you’re talking about.

25. You should understand that your personal gains must sometimes be sacrificed for the goals of the project. Sometimes you’ll have to let your skills lag so that your organization can keep a customer. This is hard one for developers because we’re always trying to stay ahead of the curve.

26. Understand that pride and ego have can be an impediment in this field but are often a great driver behind the motivation of GIS developers and others. Take joy in the benefits you bring to a project. Also, realize that you will work with people that are smarter than you. Don’t feel threatened; learn from them.

27. You should be able to communicate to your superiors how realistic something is or isn’t. You don’t ever want to promise something you can’t deliver. Also, try to help your team not promise something they can’t deliver.

28. You should be fair in your criticism and try not to take something personal when someone else criticizes your work.

29. Always try to improve but also don’t re-invent the wheel just because you can - code reuse, knowing what's already developed, etc.

30. You should be familiar with your organization, its culture, the people and their knowledge, and how you can utilize it in your efforts. Learn the history of what's been done, what was cast aside, who the players are, etc.

31. You should know your customer and/or users. Learn why they do things and what their issues and frustrations are. Gather as much written information as possible but also talk with everyone involved so you can get feel for their views on the project. What do they expect? How do they work? What’s their culture?

32. You should realize that building a new app or new tool isn't always the solution. Sometimes it's just a matter of changing the data or changing the business process.

33. You should always be prepared. Always know the purpose of a meeting and why you're going to be there.

34. You should try to work as closely as possible with the end user. They will be the ones that actually use your software so they should be your focus.

35. You should avoid the politics of the organization if at all possible. There is nothing more corrosive to a successful GIS than politics.

No comments:

Post a Comment