Cuelogic Blog Icon
Cuelogic Career Icon
Home > Blog > Product Development > Technology > Code to love it – Ways to make programming a better experience

Code to love it – Ways to make programming a better experience

Code to love it – Ways to make programming a better experience

I would like to dedicate this post to all my buddies who by their mystic punching of codes go about to create virtual world.

Too much of a drama? Ahh! actually this topic seeded within me watching my colleagues working for so long hours trying to meet deadlines and get those irritating issues cleared and yet not happy with their job. So why are they slogging on with this? Isn’t it what they wanted when they enrolled for this course?

Angry Developer

Why are they finding faults in their profile when one day they bragged it on being placed? Something somewhere is definitely not going right. Let’s try analyzing things slice by slice.

  1. The base of all the software is the code. So if you are having no clue how you are progressing towards building your code block there is no use, right? Keep your SCNs updated and well maintained and you would never get yourself in this mess.
  2. What do my dear programmer friends do with these SVN or the version control? They create builds. So how long does it take you to create a dispatch able build? If you are merely playing with the source structure and finding it difficult to create a screenshot of what takes to mute the client’s how-long-will-it take rhyme. Remember the number of stages to create a build is going to be directly proportional to your intensity in craziness. This paradigm would definitely make you laugh now but it all matters who has the last laugh!
  3. Now if you are creating a build does not mean you stop working. The development is a continuous incremental process so you definitely will make changes. And in such a process if you do a major change disturbing the build almost to the extent of breaking it then I can see Katrina coming. I can visualize the aftermath that is going to collide on you by your colleagues. So best way you could make it a habit to create a build say hourly if not possible at least in few hours or even if that is going to make you scorn make it once a day. This way you do not interrupt anybody’s work who can work on a stable version if you folly somewhere.
  4. To err is human. This applies in the programming world too. And those wrongs in technical terms are called bugs. When you encounter a bug how do you actually deal with it? Is it like-Ok so this is the little one disturbing; so I am going to clear this mess and move on with my work? The first part of the action is apt the second is not which I will speak in few minutes. You got to clear the bug at the very first place when you are fresh with the way the code works. You just leave this tiny rogue in the code and pack your bags fly off to Maldives. What a feeling if you get a call asking you what is wrong while you were soaking in the sun? I can expect you would feel you’re struck with short term memory syndrome or something. So get your mess cleared before somebody else comes behind you with a broom.
  5. Believe me you cannot keep everything in your head forever. By the time you progress towards weekend you have forgotten the some of the bugs you have solved. Nobody can keep all those tiny errors completely in the brain. No even Einstein can't.  So make a journal of all those bugs you encountered their buggy nature, what you did to get rid of it or is it still waiting to be solved. This will not just be beneficial to you but to any newbie in your project.
  6. “When will it be done?”, “How long?”, “Where are we?” Do you twitch your nose on reading any of the questions? If yes then you are a true die hard programmer. If given a choice the awesome developers would never like deadlines and release dates. I understand their part of perception but in business this does not wedge in right. So there has to be some discipline in the programmers regarding the schedule as well. Take it this way- if you get the work on time done the company will make money and in turn you are going to fill your pocket as well. So we are looking at the sunnier side and actually moving there too.
  7. Another thing that the programmers find it difficult is to get into their space where they are actually working in the best performance zone. Personally have seen companies try to have their locations away from the hustle bustle of the surrounding. But just outside noise is not enough if you place all the sections of your company at a single place it is no less than a fish market. The tele-marketing team, the back office department and the sales marketing department are mostly vocal with their work. While the devs and testers do not mostly talk unless they have calls. Giving developers the calm and soothing environment makes it favorable for them to be performing the best.
  8. All work and no play. You guessed my point. Programmers are glued to their screens almost the whole day in office. Even the big shots have been following the 30% work time rule. This lets the creators do what they wish to apart from the project. And it has shown that actually these me-times have bought the best of the ideas that have benefitted those companies today.
  9. You are a programmer. You love to express your thoughts by code. You beam at the prowess you have with the scripts. But when it comes to documenting-Error 404! Having a proper structured description of the code not only makes you go in proper flow during development but also gets the tenacity of bugs reduced to a large extent. If you cannot then hire someone apt in doing this.
  10. Underpowered tools not only handicap the capability of a programmer but make him grouchy and complaining. They are spending precious hours doing those chores that could be done in seconds using some of the newly available tools in town. You have to spend where there is real necessity. Saving here is going to drain you somewhere.
  11. The grass is always green on the other side. But we do not know the real story right. If you make a developer, make and test the code he will do it but there is going to be degradation in his interest and finally in his performance. Get in testers, let them do the fidgeting while the developers take care of the issues.

Some strings pulled up some reins loosened and you do not get the spaghetti programmers surrounding you. This works well for both the people who create stuff and also for people dealing business with it. What say?