Thursday, October 13, 2011

Software Development Tips

Just some notes I pulled out of my ass, after years of swilling cold coffee, munching on stale donuts, rock-hard room temperature pizza chunks, half-empty bags of Skittles and Combos. 
Hopefully, especially if you are young and just getting started with writing software code in some new cool programming language (whatever it is), after doing copious amounts of drugs and sucking down bottle after bottle of cheap vodka until 5 a.m., and by the way, if you fit that template: I hate you... maybe these tips will help you in some way.
  1. Under promise and over deliver.  Whatever your gut tells you about estimating time or resources, pad the numbers a bit and calmy offer your estimate confidently.  Each time you come in sooner or cheaper, you will get a "hero" pin placed upon your chest and more good things will come your way.
  2. Draw, don't Type.  When you are in the absolute Genesis of a new project, barely able to envision what this new machine will become, don't put your fingers on a keyboard or keypad at all.  Pick up a pen/pencil/marker and a pad of paper and doodle.  Diagrams, models, flow charts, mock-ups, and so on are immensely powerful ways to let your mind wander without the distraction and tractor beam of a keyboard.  After you've crumpled up half the pad in balls strewn across the floor, you should eventually have a golden page of your master idea.  Then go to the keyboard and slay the beast, laughing meniacally all the way.
  3. Beg, Borrow and Steal.  DO NOT knee-jerk into writing every line of code on your own.  Reinventing the wheel might make you feel good, but it's like beating off to a Sears catalog.  The emptiness cannot be filled by self-gratification. Stand on the shoulders of others, especially public-domain, open source "others".  Seek out examples of key parts and fill in the gaps with your own inventiveness.  Artists don't typically crush their own organic materials and resins to make their own paints.  Musicians don't typically cut down trees to trim and bend the wood to make their instruments.  Artisans often start with the work done by others before them. I was going to use the house-building example where the workers don't cut down trees, dig up clay or smelt copper, but then I remembered we don't build houses in American anymore, we put them on the market and watch the weeds grow as the price falls every week.
  4. Take a Break.  Even if you have a magical brain and endless energy, and you like to glue your ass to your chair for hours on end... it's not the best way to write code.  Get up. Go for a walk (or a roll, if you're in a wheelchair).  Chat with colleagues.  Get your mind OFF of your work for a few minutes.  I'm not advocating an hour of bullshitting on the clock.  I'm saying 3-5 minutes a few times a day (you know, the same time expended by smokers, people taking a shit, and the time it takes a tier-1 technician to listen to some idiot asshole drone on and on about their latest eBay or Facebook drama).  Just getting your mind off of something for a few minutes brings a fresh batch of brain cells online when you return to your coding.  Try it sometime.
  5. Engage the Users.  It may be painfully dull.  It may be time consuming.  Don't be like the big corporate machines that have all but walked away from customer engagement.  Feedback forms, email, chat, bug reporting tools, PAIL in comparison with face-to-face contact.  You'll get exercise, a break from your phone and screen, a chance to check out the hot new interns, the newest snacks in the vending machine, AND... you'll get a chance to get a user to open up and share ideas, concerns, questions and comments.  GOLDEN NUGGETS for making your code better.  Also, you'll get a chance to explain things that users might never think to ask yet they will appreciate gaining the knowledge and YOUR willingness to help them.  It's called customer service and it fucking works great!!
  6. Be Consistent.  I can't stress this enough.  In code. In documentation.  In user interface design.  In format and syntax structures.  In shapes and color schemes. In life.  Everything: BE CONSISTENT.  It's funny that IT folks will freak out when a process fails without any apparent pattern to help associate the failures with a coincidental event or action.  When it fails with a clear pattern, we can find the root cause with much less effort.  Yet we don't see that example and apply it to ourselves.  Look at your work and ask yourself "is everything I see consistent?"  Formatting, indention, capitalization, naming standards, everything.
  7. Added:  Play Devil's Advocate.  Ask all the ugly questions:  Why would someone NOT want to use your product/service?  What are the vulnerabilities?  If you were working for your competitor, what would you say to discredit this product/service?  What works "as well" or better than this product or service, and why?  Don't let your ego creep into this discussion at all.  Act and think as if you have no stake in this project, how could it be picked apart?  Once you've asked the tough questions, develop a list of responses to it.  Not just "answers", but determine solutions to mitigate those vulnerable spots.
  8. Added: Accept Criticisms.  Invite one or two of your peers to look at your idea and your code.  Listen to their suggestions.  If they lay on acclaim and accolades, be thankful, but press them to offer some professional criticism.  If you don't work in an environment where you can trust your peers, you have other challenges to solve.  If you don't have any peers to seek out, fear not, there are alternatives:  Post  your ideas on StackOverflow.com (or one of it's many child sites) and seek input/feedback.  Any feedback is better than none.  Don't create in a vacuum.
Post a Comment