And now, the stunning conclusion to Part 1…
I used to work for a guy who had a script for everything. Really, he had two big boxes of floppy discs that he would go to whenever he needed to do anything. At the time, I was really impressed. On some level, I still am. I’m a firm believer in hanging on to what you build (as long as it’s legal) so that you can reference your own work again later. But, on the other hand, this particular guy never stretched. He never looked for alternate ways to solve a problem. Frankly, he was lazy. New functionality can be intimidating until you get comfortable with it. Look for opportunities to use new features and functionality whenever you can. A caveat… don’t be that guy who overuses every shiny new toy Microsoft throws at you. Don’t sacrifice your database or your project for learning opportunities. Sometimes, what I’ll do is solve the problem using the way that is comfortable for me, and then go back later and see what other alternatives I could have tried. Call it homework.
7. Document, document, document.
Oh, Audrey’s running out of things to say, so she’s repeating herself now. No, I’m really not. #2 up there is about keeping good notes. This is about formal documentation. Build time into your estimates to document your database. There are three things that are must-have’s for me:
- Data Mapping – if you’ve got data moving around, document each stopping point. The most simple method is to use an Excel spreadsheet and put a column for each phase of the data. Start with your source and work your way through to the final destination.
- Entity Definitions – define each entity (table) in your database. Hopefully, the name should give a solid hint, but put a few sentences together about what kind of data is in there, how it’s being used, and any things that aren’t totally obvious at first glance.
- Attribute Definitions – define each attribute (column) in your database. This is the hardest one to stick to, but it’ll save you hours and hours of interruptions from developers coming by to ask you what a particular column is for or where a particular piece of data lives.
Good data modeling tools like ER/Studio (my personal favorite), ERWin, and even Visio give you places to store this kind of information. If you’ve ever walked onto a project midway through where you have to pick up a database without any supporting documentation, you’ll realize how important this is.
8. Don’t be a trend whore.
Sorry, I know that’s harsh, but I have to say it. Some new trends in database development are good, and will stick around. Some aren’t. Remember when everyone thought that XML would take the place of the relational database? Did it happen? No, it didn’t. XML found its place, but it wasn’t as a replacement for every database. Relational databases have been around for so long because they work. I’m not being a C.J. Date here (let’s face it, he’s kind of a jerk), but I do believe in the power of relational databases. Learn your fundamentals and start there. If you can extend the database’s power through new functionality, go for it.
9. Try to not be the smartest chick in the room.
One of my personal career goals is to try to surround myself with people I think I can learn from. This advice sort of summarizes most of what I’ve said above. If you’re too comfortable or you always have the answer ready without having to think too hard, you’re in the wrong place. We learn when we’re overwhelmed and pushing ourselves. You do not want to be the crusty old veteran who knows everything about the product but breaks out in a sweat if someone mentions an unfamiliar concept. If you are, try to figure out how to challenge yourself. If this means looking for a new job, try to find a place where there are people who can mentor you. It is fun to be the hero and the expert, but you’ll be a lot happier in the long run if you’re working with people who are teaching you something.
10. Finally, remember that it’s a small world out there.
I’m in the Atlanta area. I am regularly amazed at how small this development community is. Chances are, if you’re talking to another developer, they know someone who knows you. Your reputation is critical. You think people don’t remember that time you blew off the weekend even though you had a big deployment on Monday? Think they don’t remember the time you didn’t bother to unit test your work and caused the whole team a world of hurt? Or that time you threw a hissy fit in the middle of a meeting? Trust me, people remember, and people talk. We all screw the pooch from time to time, and that’s okay. But remember your image. Be a Natalie Portman, not a Lindsay Lohan.
Develop on, my friends.