Are You Smart or Dumb?
Join the DZone community and get the full member experience.
Join For FreeWhat's the difference in smart and dumb? I've come to believe it's two things. How far ahead you can think into the future and how quickly you can do that thinking.
When someone is playing chess, pool, or poker, their skill is determined by how many moves ahead they can think. How much history can they remember, and then factor in to the next move.
In software, how far ahead can you see? Are you using destructive practices because you're so busy "getting work done"? Are you ignoring great practices that could save you time?
Think of this like cutting a road through the woods. You're working very, very hard. Everyone on the team is breaking their backs, sweating, getting blisters, the whole nine yards. No one can possibly question your loyalty or dedication.
But...
When's the last time you stopped cutting down trees on this metaphorical road, and climbed a tree... or checked a map... or sharpened your axe? The problem with most software teams cutting these roads through the woods is that they never check to see if the road is headed towards the town that needs the road. They never check that the road is straight. They never check to see if they can buy a few chain saws to replace those ancient axes the team is using today.
Obviously this can be abused. We don't want to spend all day in the hardware store looking for new tools, but we do need to stop from time to time, take a look around, and see if we're headed in the right direction. Make sure we're using the right tools for the job. See if the blades are sharp.
Here are a few suggestions for tools I'd strongly encourage you to check out.
I could type these all day... what's worked for you? Has Groovy and Grails been a great new tool in your arsenal? How about Resharper? Tell us what's worked for you.
One last observation... when we're under too much pressure to deliver something yesterday, we stop looking around. Instead we work harder, not smarter. We tend to skip opportunities to clean up code, try out new tools, and improve the process. Instead we make more and more short term decisions. We use the tools we have instead of trying out new ones. Instead of taking 10 minutes to sharpen our saws, we cut for an extra two hours with the old, dull blade.
Don't let the demands of your job make you stupid.
When someone is playing chess, pool, or poker, their skill is determined by how many moves ahead they can think. How much history can they remember, and then factor in to the next move.
In software, how far ahead can you see? Are you using destructive practices because you're so busy "getting work done"? Are you ignoring great practices that could save you time?
Think of this like cutting a road through the woods. You're working very, very hard. Everyone on the team is breaking their backs, sweating, getting blisters, the whole nine yards. No one can possibly question your loyalty or dedication.
But...
When's the last time you stopped cutting down trees on this metaphorical road, and climbed a tree... or checked a map... or sharpened your axe? The problem with most software teams cutting these roads through the woods is that they never check to see if the road is headed towards the town that needs the road. They never check that the road is straight. They never check to see if they can buy a few chain saws to replace those ancient axes the team is using today.
Obviously this can be abused. We don't want to spend all day in the hardware store looking for new tools, but we do need to stop from time to time, take a look around, and see if we're headed in the right direction. Make sure we're using the right tools for the job. See if the blades are sharp.
Here are a few suggestions for tools I'd strongly encourage you to check out.
- Continuous Integration From AntHill Pro to Cruise Control for Java to Cruise Control for Dot Net, these team wide automatic compilers (and test runners!) can do wonders for your team. It keeps your team writing code instead of fixing compiles, keeps the product clean, and catches problems fast.
- Frequent demos Whether they're internal, or for your client, these public demonstrations help others understand what you're doing and suggest course corrections. If you're cutting the road in the wrong direction, how much time do you want to continue wasting? Show people what you're doing and find out what they think as soon as possible.
- Time boxed iterations Provide your team a more effective way to box in their efforts and ensure they're building the right thing. This also provides you a faster stopping point when someone is stuck in the ditch, and can't finish something.
- Automated testing When you encode your product knowledge in a coded test (run in a continuous integration server, of course), it becomes impossible for you anyone else on the team (or you) to break that code without it being caught very quickly. It's the best way I know to keep everyone on track, catch mistakes quickly, and fix bad habits before they become engrained.
- Defect Driven Testing Find a bug? Add a test. Always. This extremely focused approach to test automation provides coverage exactly where you need it first. Also, never add just one test... aim for a "Baker's Dozen" of one off derivative tests.
- Test Driven Development Writing a test before you write your code provides a completely different type of code. It's smaller, more focused, and (big surprise!) tested. A lot of very smart people love TDD... give it a chance.
- Daily Stand Ups The daily meeting gets everyone together to talk and see each other's faces every day. Answer the three (or sometimes four) questions to help share information as well. How often have you worked on a team where everyone talked to everyone else every day?
I could type these all day... what's worked for you? Has Groovy and Grails been a great new tool in your arsenal? How about Resharper? Tell us what's worked for you.
One last observation... when we're under too much pressure to deliver something yesterday, we stop looking around. Instead we work harder, not smarter. We tend to skip opportunities to clean up code, try out new tools, and improve the process. Instead we make more and more short term decisions. We use the tools we have instead of trying out new ones. Instead of taking 10 minutes to sharpen our saws, we cut for an extra two hours with the old, dull blade.
Don't let the demands of your job make you stupid.
teams
Opinions expressed by DZone contributors are their own.
Comments