Laws of Source Code and Software Development

I’ve worked in a variety of projects, in a myriad of languages, and have learned the following universal truths about software development the hard way.

  • Commented out code are not comments – Use version control, don’t track code changes by commenting them out. Commented out code is schizophrenic code.
  • Let your reputation and code precede you – If you work on open source projects, blog, and work your network, you will get more job offers even when you aren’t looking for a job than people that are looking for a job and just email out resumes.
  • Don’t make excuses for code, let it speak for itself – You are paid to find solutions using code, not find excuses for your code. ‘It worked on my machine’ is not a solution. You will not ship out your computer to the client with the application.
  • Don’t take code personal – Don’t take code reviews personally, it is not about you but a business feature and the overall performance of the application.
  • Your code is your career legacy – For years after you leave, those that will maintain your code will either curse you or thank you.
  • Coding does not equal programming – Writing code is not the same thing as software development, one requires thought while the other does not. Just like playing with your iPod does not make you a musician.
  • Code is about learning – Moore’s Law states that technology doubles every 18 months, you should keep up. If you are not learning you are doing it wrong. Every project is an opportunity to learn.
  • Code is communication – People will read the code you write. Use best practices and common design patterns and idioms. Strive for simplicity over impressing the monkey on your back. Your code should communicate clearly and concisely it’s intent. Code talks, bugs walks!
  • It is not the tools that make a developer – Know your tools and use them to their full power but don’t use them as a crutch! Switching between IDEs should not stop you on your tracks because you can’t find the correct code generation wizard. Michelangelo was a great artist with nothing more than a chisel and a slab of marble.
  • Don’t trust your code – Trust in your coding abilities does not replace repeatable testing. Don’t trust your code, assumptions, or users.
  • Code is not written in Latin – Code is not dead once the application ships. Code is always refactored, modified, re-used, and evolving. Your greatest strength is not writing mountains of new lines of code but maintaining, refactoring, and herding existing code into performing business requirements as per an agreed specification.
  • Respect the API – Your API is a contract others will depend on. Keep the API clean and explicit! The least amount of methods you expose is less testing and maintenance and documentation that you need to maintain.
  • Code outlives its intention – As much as you would like, writing your application from scratch in the latest programming language or framework will not benefit the number of end users that for one reason or another are stuck with the current version of the software. Code can outlive it’s original intention, design for extensibility and adaptability.
  • Code means different things to different people – In the end, to end users code simply means the ability to do what they expect.

19 Responses to “Laws of Source Code and Software Development”

  • Albin Joseph Says:

    Good list.

    Don’t trust your code – This is one of the biggest mistakes I often make. I always think that my code will work as expected in all the conditions. :-)

  • Steven Klass Says:

    Nice!! Well stated!

  • ibnu triyono Says:

    Commented out code are not comments – Use version control, don’t track code changes by commenting them out. Commented out code is schizophrenic code

    that’s my mistake.

    anyway thanks for sharing

  • Cristina Says:

    Great blog though it would be nice if there was a line-height to this. Seeing all the information smashed together makes me a bit claustrophobic. But good job. +1

  • Laws of Source Code and Software Development « Juixe TechKnow « Webtrails Says:

    […] leave a comment » Laws of Source Code and Software Development « Juixe TechKnow. […]

  • Niczar Says:

    «It is not the tools that make a developer»

    A developer that knows his tools well is always better than a developer that can’t be f’d to learn them. Always.

    Like that guy who was a “senior developer” and couldn’t merge+branch if his life depended on it; because he was too proud to ask for help, the dumbass.

    As for your analogy, great artists knew their tools well. Go paint a Sistine Chapel w/o an intimate knowledge of plaster, pigments, grinding, and eggs.

  • matt Says:

    “Code outlives it’s intention”
    Its (possessive)

    Don’t take it personally. It’s not about you, but about pedantry.

  • TechKnow Says:

    @Niczar – You are right, a developer that knows his tools inside out will be more productive if, and only if, he is working with said tools. People should not use tools as a crutches. This observation came from numerous times when I’ve seen engineers stopped in their tracks debugging and trouble shooting a problem because the problem was in a perl script, or a batch file, or visual basic script and not their programming language of choice. Along similar lines, I’ve seen engineers rework, almost from scratch, a large portion of a project for no other reason than because it didn’t fit their tools, mindset, or how they did it in their previous company.

    A tool should not be a crutch, a developer should be more versatile than just what his IDE can auto-generate for him. A programmer should be the computer scientist equivalent of MacGyver, a programmer should be able to fix a bug equally well with either Eclipse or notepad or hex editor or by soldering the computer with a paper clip and a lighter.

    To be honest, I think we are addressing the same ‘dumbass’ senior software engineer. I think I’ve worked with that guy, and it wasn’t he couldn’t merge+branch, it was the he only knew the mechanics of how to do it in a specific tool. Guys like this get stuck if you move them out of their box, into a different box, and then ask them to think outside of the new box. That said, the first day of training for any new employee should be all about the tools and development environment, including commonly used short cuts, build scripts, etc.

    I will disagree with you, it is not that an artist knows his tools well that makes him a great artist, it is that he knows his media! As computer programmers, what is our media?

  • TechKnow Says:

    @matt – Thanks for that helpful comment…

  • Matt Doar Says:

    “Commented out code are not comments”

    Oh yes, I agree. Comments should be the only thing that use the comment syntax. Disabled code should use another syntax, preferably by not being there.

  • TechKnow Says:

    At first sight, some of these laws will seems contradicting, for example ‘Your code is your career legacy’ and ‘Don’t take code personal.’ As a programmer I am always learning. I am proud of my code but I know that I am always learning from my team, picking up new idioms, leveraging new libraries, and expanding my tool set that I’ve realize that code can always be improved. In peer reviews I don’t take criticism negatively, I’m willing to learned from senior and junior developers alike.

    I like to think that a open source project, running code can say more about your programming abilities than a self aggrandizing cover letter with an alphabet soup of technology abbreviations for a resume. That is what I mean in ‘Your code is your career legacy.’

  • links for 2009-05-21 « My Weblog Says:

    […] Laws of Source Code and Software Development « Juixe TechKnow (tags: tips) Possibly related posts: (automatically generated)links for 2006-09-27links for 2008-03-14links for 2007-02-15Tags Comments (0) […]

  • Jim Hickstein Says:

    I can’t resist underlining “code outlives its [developers’] intentions”, with slogan #1 on my own list: All software is permanent.

  • Jim Hickstein Says:

    While we’re being pedantic, myriad is an adjective: “in myriad languages”. And don’t get me started about “comprise”. :-)

  • Haymo van Wyk Says:

    I’ve enjoyed this lot! As a programmer from ancient times, my experience was : To get a program to work was about 10 – 20% of the job. The remaining 90 or 80% was to try to make it idiot proof. (A plotting program of mine ran for 8 years, before a user hit the one condition I had not allowed for.)

  • Pinderkent: Keeping commented-out code is justifiable. Says:

    […] commented-out code is justifiable.Posted on Sunday, May 24, 2009 at 12:10 AM. Today I read an article that suggested the […]

  • Parag Shah Says:

    Very nice post. I especially liked: ‘It is not the tools that make a developer’ – after working with Eclipse for several years, I have restarted working with vim. It’s taking me a while to get used to it, but I am persisting. Even though my productivity may have dropped, I feel like it is helping me get closer to ‘regular expressions’ and similar stuff, which is always a good thing. And not to mention that it is also getting me used to working in a command line environment.

  • TechKnow Year In Review 2009 Says:

    […] Laws of Source Code and Software Development […]

  • Software Development Outsource Says:

    Code will be very critical and undue …@Parag Shah

Leave a Reply