Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Submission + - The Hardest Things Programmers Have To Do (itworld.com) 6

itwbennett writes: Software development isn't a cakewalk of a job, but to hear programmers tell it (or at least those willing to grouse about their jobs on Quora and Ubuntu Forums), what makes programming hard has little to do with writing code. In fact, if the list compiled by ITworld's Phil Johnson has it right, the #1 hardest thing developers do is name things. Are you a software developer? What's the hardest part of your job?
This discussion was created for logged-in users only, but now has been archived. No new comments can be posted.

The Hardest Things Programmers Have To Do

Comments Filter:
  • I agree that this used to be a big problem for me. Then I got a job outside of academia, and they made me learn to use an IDE (oh how I miss the days of doing everything in gedit and command-line gcc...), so now renaming a variable (and getting all its references) is a matter of one right-click. What this means is that if I can't figure out what to name something, I can just name it "blah," "stuff" or "temp" and then refactor when the inspiration strikes.
    • by rwa2 ( 4391 ) *

      Word. Another naming convention I've worked with that I like that was stolen straight from perl : prefixing your variable names with its ctype. So you'd have double d_num , int i_counter , const string cs_blurb . It was a great reminder to have around to always make sure you were treating your variables right. Of course, it's also something better tracked by the IDE or better yet a high-level language compiler, but with C/C++/Java I'd certainly make this part of the coding stardard again.

  • 1. Working with others you don't agree with. VERY hard to implement something you know is wrong, then stay away from the "I told you so" when you have to fix it later.

    2. Dealing with managers who do not understand the implications of their decisions, then refuse to accept the inevitable results of their choice, even when you tried to warn them.

    Yes, the two are related at times. But it points to the most difficult part of my past jobs, interpersonal relationships. Programming computers is the *easy* part

  • The hardest part of software development is the schedule. Managers and so forth want to have the comfort of knowing when some piece of code is going to be finished. The ugly truth is that it's all guesses. That's why almost any significant software project is usually late. You can't tell ahead of time what is going to bite you. The whole thing may have to be redesigned because of problems you couldn't see at the beginning. The requirements may change. And then there is the debugging, which is really u

  • And that the machine doesn't. The hardest thing is understanding the human part of the system.

    Most programmers miss the core fundamentals of humans, to whit:

    1) Software is a coversation. BE POLITE.

    2) Machines and software exist ONLY to serve humans. They have no other purpose. To the extent that they serve they are a success. When they don't, they're a fail.

    3) Users (i.e. humans) anthropomorphize: Whether they know it or not, when users look at the computer, they don't see a machine, they see a little guy.


  • I don't agree with that list at all. It sounds like it was written by people who are just whining about unpleasant tasks, not difficult ones. Writing documentation and tests isn't so much hard as tedious. Dealing with other people isn't so much hard as demanding of patience. Behind many but not all of these things, however, is a common thing we do that's very difficult: maintain self-discipline in our work. That old code is ugly and hard to understand? I'll just rewrite... wait... no... that's just t

"Let every man teach his son, teach his daughter, that labor is honorable." -- Robert G. Ingersoll