Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

jonasbn
  reversethis-{gro.napc} {ta} {nbsanoj}
http://e-diot.dk/
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Thursday January 31, 2008
05:27 PM

Working Alone

[ #35545 ]

Sometimes I wonder if it would be easier if you were the only programmer around.

I tend to fight with a lot of code that does not adhere to my standards and perception of good practices, simply because I am in a environment with more than one programmer.

This could be stuff like:

  • Forgetting to put or update things in CVS
  • Not tagging things in CVS to get a clear indicatication of a release or similar
  • Lacking documentation
  • Lacking build system
  • Lacking tests
  • Stupid mock-up left-overs so the users get weird or impolite messages

And I have mentioned stupid mans version control in a previous journal entry.

I fully understand that we sometimes forget things and we make mistakes, we are only humans and often we are under at lot of pressure and time constraints.

But I regard many of the things I mention as things that help us to overcome stress and might even help us when facing time constraints.

  • Put things in CVS, so you do not loose code and you can go back to see what you have previously done, gives you courage to try out things and experiment
  • Tag things when you are done, supports the above point, but the sense of closure when you are able to make a release is good for clearing your brain, write the remainders in the TODO, document the caveats and move on
  • Write documentation, before your start and after you are done. It gives you good reflection of you code with out letting you being focused on syntax and coding, prose is also good for the mind. And it is good for maintenance, when you revisit your code in the future
  • A build system helps and supports your development
  • Write tests, I do not want to go into details, try it and see for yourself
  • Do not write stuff that never should see production, because it might not be removed prior to deployment because you forget

There are plenty of other good practices and I am working on my own list and one of the easiest ways to identify good practices seem to be by evaluating bad practices.

So if you are disciplined and work alone things might work really well, but there is the danger of becoming your own worst enemy, since you will not have the feedback from other programmers, using, evaluating and maintaining your code.

And the pair-programming when debugging something really weird.

Yes, you sometimes look really bad, you sometimes have to buy cake to all of your colleagues, but you will survive.

And you will not adopt new and better practices as rapidly if you are not driven by the fear of the repercussions mentioned above. You will make many of the same mistakes over and over again.

Well even whole teams can have bad practices etc. but at least they have them in common.

So a word of advice to programmers: write you code so others can use it, evaluate it and maintain it - define and follow your own best practices or practices for your team.

I am working with a new freelancer and the joy of working with a colleague really can make me forget all about all the bad code and bad practices I also have to deal with, after all all of the above things can be fixed in due time, since most of the stuff is just irritating when you are stuck in the middle of it and it is just code, it can be changed or even deleted.

But in my ideal place of work, we would not even get in a situation where we would deal with bad practices like that, no - I would only be left with the joy of working with others following good practices and spitting out the most beautiful code for the world to see.

So working alone might seem like a perfect world, but I do not think it is. Since we are social creatures and why not be social about what we do instead of becoming cranky the moment somebody mentions our personal work.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.