30 Common Reactions Programmers Have When Things Go Wrong

http://videohive.net/?ref=gimmegfx



Developing applications can be a very stressful job. Nobody is perfect, and running into buggy code is reasonably commonplace within this career. Some programmers get angry, frustrated, upset, discouraged even, while others play it cool. How we handle the operation of fixing bugs is worthy of scrutiny.



I need to share an accumulation of phrases and ideas you’ll hear from programmers struggling when fixing their source code. It is all light-hearted humor, triggered when things become stressful. Generally the application will (eventually) figure out and you will begin the next great task.

Learning Programming: 10 Misconceptions That Are Not True

I am sure many web-developers and software engineers can relate to these programming hardships, while still laughing in hindsight.

1. “I don’t know if they should delete this or rewrite it”

Going to old source code out of your past brings a temptation metamorph larger block clusters. Ugly logic statements with verbose syntax is extremely hard to read! But then again, if it ain’t broke, don’t correct it. This is often a struggle I often face and yes it surely plagues all kinds of other software developers.

2. “I should check Github for a starting framework”

I think most developers find out about Github along with the amazing open source projects being published each day. Programmers dabbling in every languages join the network to branch off existing projects, add wiki discussions, or make their very own code repo. It is surely an excellent resource for cool plugins and templates for use on various projects.

3. “Why does this script need a lot of libraries?”

Moving particularly into bigger languages like Java and Objective-C, the amount of libraries can be fierce. It can be very noticeable when building off a framework which takes a lot of grounding. Even some plugins for JavaScript will be needing a myriad of additional files. Sometimes the clutter can get annoying - but no less than it works!

Read Also: How To Remove Unnecessary Modules In JQuery

4. “There have to be a solution somewhere on the Internet.”

My first reaction to a difficult concern is to check the Internet. Lots of programmers will post forum threads relating to issues, and they're going to eventually be solved and archived. Google is fantastic at picking up keywords associated with your issue and pointing you inside right direction of such helpful discussion threads. Unfortunately, sometimes there just isn’t much information available on a particular issue.

5. “Is there a plugin with this functionality?”

Why reinvent the wheel? Plugins are a fantastic resource for expanding the consumer interface of the program or website. Additionally they can provide some customization and unique alternatives for the developers to work with. Plus if there isn’t already a plugin available, why don't you build one yourself?

Read Also: WordPress Search: Useful Plugins And Snippets

6. “The site works, but I’m dreading Internet Explorer.”

I don’t need to mention the trials and tribulations which may have come from the history of rendering webpages within Internet Explorer. From version 5.5 up to about IE9-IE10 there's been a constant struggle for greater browser support. Web developers may fear the debugging of a webpage, opening within IE6 to a rendering nightmare. Thankfully those days are slowly being a thing from the past.

7. “For a logic statement this doesn’t seem very logical.”

There are logic statements for if/else loops, for loops, while loops, do loops… the list is reasonably lengthy. When looking over sample code I have relapses racking your brains on how my logic really should work. The sheer number of NOT operators and comparison signs may have your head spinning. I frequently go returning to update my personal logic for good practice inside the future.

8. “I spent 30 minutes writing a function and 2 hours configuring it to work.”

Isn’t this the programming story with the decade? You are humming along just fine building everything you know, when all of your sudden the function is outputting a fatal error. So now you have to go back removing blocks of code looking to pinpoint the faulty line number. It can be exhausting yet a relief once you finally find to blame and solve the case.

9. “After reading several blog articles, I now recognize that I’ve been achieving this completely wrong without interruption.”

I often want to dive head-first into topics with my personal programming ideologies but this leads to trouble as time goes on when things don’t go as outlined by plan. There have been often where I’ve started a project and ran into trouble, seeking blogs and also other articles for support. Then I learn the whole strategy is practically wrong and yes it’d be easier to just start over! Doing a bit of research first is sure to save time inside the long haul.

10. “The nice people on Stack Overflow can probably assist me.”

I couldn’t start to count how frequent that I have solved a challenging problem through Stack Overflow. The community is stuffed with nice, intelligent people who find themselves willing to help invest the the first step. Out of all the online forums this has to be the most widely supported network for software programming and frontend/backend web design.

11. “All that trouble for any missing closing parenthesis.”

Debugging is focused on the steps you take. Two steps forward, one step back, two more forward etc. The feeling of looking at code for hours just looking for a few mistake in function names or variable scope, only to find a missing parenthesis, is a weird feeling. All that time lost more than a minor syntax error. The feeling for being both a genius and fool as well.

12. “Welp, coffee break!”

Sometimes you just have to get up and from the monitor. After hovering in the keyboard all day at a time, it will be helps to break up the routine. Most health guides recommend an escape every 30-60 minutes. But it all depends on your needs of course, if you get annoyed more from stopping for any break in the middle of the program today.

13. “I should put this project on hold and handle it later.”

An alternative to be effective breaks is walking away from the project rather than just your computer. Maybe there is certainly other work that should be done, so continue over and appearance that one out instead. This would be a better allocation of your time and resources, in comparison to fretting away while attempting to solve an issue that you’ve been looking into for 5 hours straight.

14. “I wonder if classical music will stimulate my programming abilities.”

There is surely an idea that classical music could promote plant growth during the early stages of life. I personally love classical music to the intricate notes and complex musical theory. Jazz, piano, big band, classy music has a place in human culture world wide. So could paying attention to smart music while programming actually make you smarter at debugging? Probably not, but hopefully it wouldn’t make you more clumsy either.

15. “Maybe now can be a good time for testing the thought of Ballmer’s Peak.”

I think many readers find out about Ballmer’s Peak that was coined by a particular xkcd comic. To simplify, the thought states that programmers hit a peak of coding ability after consuming a specific amount of alcohol. It was due to Steve Ballmer for his wacky antics which may be construed because ramblings of an drunkard eventhough it is somewhat ironic, as Ballmer wasn't truly a programmer at Microsoft. Guess we willl need to wait for some other person to give this theory an effort run.

16. “Was somebody fiddling with my source code?”

It seems like delusion and paranoia, but sometimes you just have to wonder that is writing this stuff once you are busy catching up on sleep. Looking over projects from weeks or months inside past can leave you with a sinking feeling. Sometimes you will find items that you never remember adding - even from projects you merely looked into yesterday! I write it off as crazy but you never know…

17. “I have no idea what any one of this means.”

The worst situation you can have is looking into source code with absolutely no idea what direction to go. This may arise from a own projects, or some other person’s project, but it's all the identical problem. Now you will need to decide whether it be worth spending more time searching for an alternative solution or dissecting the script to learn how it really works.

18. “I’m gonna need to Google that error message.”

After doing work in PHP for a long time I must say that Google is my mate when debugging problems. This is definitely the same case with Objective-C, C++, Java, Python, as well as other major languages. Error messages make an effort to help but if you do not have memorized just what the different codes mean, it reads much more translated computer language. Thankfully there's a lots of support online for determining just precisely what these error messages really mean.

19. “I should stop and refer to it as a day… but I really wanna figure this out!”

We are all aware that a sense utter frustration where you wish to call it quits, nevertheless it just feels like giving up isn’t the right choice. You need to keep pushing forward and try new solutions for debugging. But what whether or not this turns into a waste of some other hour? I am no stranger to this particular circumstance and it can be awfully disheartening.

20. “Oh dear, why didn’t I write any comments?”

When it comes to more basic frontend HTML/CSS/JS there isn’t always a should leave comments. But more difficult scripts and programs will require some type of organization for when you need to look back in some months, or perhaps after a couple of years. Sometimes you will forget to comment about functions along with their parameters, the output format, as well as other essential data. This will no doubt lead to confusion in the future when bugs start appearing and you need to debug your entire script for any solution. If only there were some helpful comments.

21. “This was working twenty minutes ago…”

Possibly the most frustrating section of building a course is when it's going from working to not working - without ANY updates to ANY part of the code! I swear it takes place. And it doesn’t make any sense - maybe one other program was building a cached version? Then there are occasions when updating one tiny bit of code will cause the entire program to crash on error and simply stop working entirely. Revert time for the most recent working copy whilst moving forward after that.

22. “You forget one lousy semicolon and the whole program comes crashing down.”

Almost every programming language I have used will demand a symbol for line termination. Not all of them do, but it's definitely common within the C/C++ family. When you forget to provide one terminating semicolon it is an honest mistake! But the parser doesn’t understand this and throws out a fatal error. Now you will need to spend another twenty or so minutes scouring code to get a technical fault, when the whole time, it had been just missing a semicolon. Ah, the thrill of debugging software.

23. “I wonder the amount it would cost to spend someone to fix my mistakes?”

The overwhelming regarded hiring another developer is tempting, but obviously nowhere near financially viable. Plus how does one learn from all of such mistakes if you aren't getting your hands dirty? It can feel good once you finally understand a programming concept, after failing multiple times. But it doesn’t stop this thought from crossing my head ever so often.

24. “A quick holiday to Hacker News will improve my productivity.”

A lot of programmer’s favorite option for social news on software & startups is the Hacker News frontpage. It has a large amount of great information regarding freelancing, time management planning, software development, plus new startup launches and raising capital. Although HN can emulate the feeling of being productive by educating yourself, it is also a drain on your own time. Taking a quick recess to evaluate up on news every few hours couldn’t be everything that bad.

25. “How can this API haven't any documentation?!”

The most frustrating part about by using a plugin or framework with bad documentation is that you have to look deep in to the source code yourself. I simply adore projects the location where the developers will require the time especially design a usable documentation page. All the parameters and option is explained, perhaps even used within some example code snippets. But sadly this isn't always true. It is easiest back off from poorly-documented work and save yourself the grief.

26. “I sure hope I’ve saved a backup copy of that database…”

Backups are not always on my head when writing and debugging code. However, data backups give a stepping stone to go back in time before certain changes were made. This is especially useful on a live server environment where changes are implemented immediately. Remember to keep local copies of the website files and databases in case of an emergency! It can be a taxing task, however, not as annoying as rebuilding a corrupt SQL database.

27. “What is the quickest solution to get this functional?”

After hours of turmoil looking to get a custom solution it becomes very clear that you can need a new approach. Programmers desire to get the functionality working first before designing a reasonably interface around it. Determine the easiest, most accurate solution and implement this to get working at best 100% from the time. Then it is easier getting to the pretty aesthetics.

28. “I bet updating my software will fix the issue.”

The teams who manage dependencies and plugins for programming languages do not have to push releases often. Sometimes updating your PHP/Ruby/Python/SQL version may solve debugging issues when transferring files from your computer onto a live server. Local updates will very rarely help with fixing a bug in your source code, unless your version is hopelessly outdated. Hey it’s worth a shot!

29. “I ought to be more organized and focus Git… But I’ll check into it in the near future.”

The open source version control package Git is very popular among programmers. It offers a simpler learning curve than other competitors, plus it is utilized in many online repos such as Github and Bitbucket. Developers will postpone the idea because its has a steep entry-level curve for novices. However once you understand the essential commands then Git is a cakewalk. And it makes all the practice of debugging with version control a lot clearer, too.

30. “Scrap this, I’m starting over over completely from scratch.”

Sometimes after trying hours of solutions, you just ought to move your working files with an archive directory (or delete them) and start again over completely from scratch. The decision is tough considering the way the previous hours have been toiled away for little payoff. But when I am in a very rut, receiving a fresh start can often be just what I need to see a project right through to completion.

Related posts:



  1. Learning Programming: 10 Misconceptions That Are Not True

  2. 15 Websites To Test Your Codes Online

  3. 10 Most Common WordPress Errors (With Solutions)

  4. 30 Cheatsheets & Infographics For Software Developers


Title Post: 30 Common Reactions Programmers Have When Things Go Wrong
Rating: 100% based on 99998 ratings. 5 user reviews.
Author: SharedTutor

Thank you for visiting sharedtutor.com, If there is criticism and suggestions please leave a comment


thumbnail
About The Author

Someone who always wanted to know about the beauty of the world :)

0 comments