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


Forgot your password?

Ask Slashdot: What Are the Hardest Things Programmers Have To Do? 473 473

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 single hardest thing developers do is name things. Are you a software developer? What's the hardest part of your job?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Are the Hardest Things Programmers Have To Do?

Comments Filter:
  • by swm (171547) * <swmcd@world.std.com> on Friday October 18, 2013 @01:14PM (#45166571) Homepage

    The head and tail of the list

    9. Designing a solution
    1. Naming things

    are pretty much two sides of the same coin.

    If you have a design, you will know what call things.
    If you have names for everything, you will be able to build a design from there.

    And these *are* the hardest things on the list.

  • Estimation (Score:5, Insightful)

    by scottnix (951749) on Friday October 18, 2013 @01:15PM (#45166583)
    By far the hardest part of my job as a professional software developer is estimating how long a feature will take to develop.
  • by girlintraining (1395911) on Friday October 18, 2013 @01:17PM (#45166601)

    Easy: The hardest thing a programmer has to do is explain why what they're doing isn't a simple matter of programming.

  • by Anonymous Coward on Friday October 18, 2013 @01:17PM (#45166605)

    I build something exactly from their specifications.
    Someone wants something changed, I change it.
    Someone else wants something changed, I change that.
    Another person wants it back the way it started.

    The users are NEVER happy. It's maddening.

  • by Anonymous Coward on Friday October 18, 2013 @01:18PM (#45166625)

    Trying to comprehend other peoples code is, without a doubt, the hardest thing for me. Naming? That would have never occurred to me as a 'problem.' If you can't come up with a proper name fairly easily maybe you didn't really know where you were going.

  • Re:People (Score:5, Insightful)

    by CnlPepper (140772) on Friday October 18, 2013 @01:24PM (#45166715)

    ...particularly physicists who think they can code.

  • Users... (Score:4, Insightful)

    by cmeans (81143) <cmeansNO@SPAMintfar.com> on Friday October 18, 2013 @01:25PM (#45166737) Homepage Journal
    And their ever changing specifications, indecisiveness, lack of comprehension of the time it takes to implement, then re-implement something, and their general reluctance to pay once it's done.
  • Time Estimations (Score:5, Insightful)

    by Anonymous Coward on Friday October 18, 2013 @01:25PM (#45166739)

    Here's a spec that is incomplete and will keep changing over the life of the project. Tell me how long this will take and remember that your preformance will be measured against how well you meet your estimates.

  • Re:Maths (Score:5, Insightful)

    by Jeremiah Cornelius (137) on Friday October 18, 2013 @01:26PM (#45166753) Homepage Journal

    What is the hardest thing "coders" have to do? Based on the evidence that I have seen, over more than 20 years?

    Comment their code

    Either that, or produce relevant, well-defined logging.

    The other hard things they have to do are usually related to have a project to complex or ill-defined for producing a clear outcome. This is usually not the coder's doing, but a downstream problem derived from insufficient architecture role/guidance and probably a weak project management function.

  • by CQDX (2720013) on Friday October 18, 2013 @01:33PM (#45166863)
    Most of the other issues don't bother me if the project is really cool. Plus with my productivity ramped up management tends to stay out my way. OTH, with boring project, everything on the list is 10x more painful. Unfortunately, for the typical programmer, their entire life is spent working on the former.
  • Re:Estimation (Score:5, Insightful)

    by phantomfive (622387) on Friday October 18, 2013 @01:36PM (#45166909) Journal
    Here is something that I read in Mythical Man Month that helped me:

    An estimate that is accurate will decrease over time, as some parts of the project will get done ahead of schedule.
    An estimate that is inaccurate will remain the same until just before the deadline, when the time needed will suddenly jump up.

    A lot of people make their estimates based on what will happen when everything goes right. If you make your estimate based on what will happen if everything goes wrong, then your estimates will be a lot better. And with practice, if you pay attention to how accurate your estimates were, then you will get improve.
  • by darkwing_bmf (178021) on Friday October 18, 2013 @01:36PM (#45166911)

    The hardest part is when the person asking you to implement something new doesn't think through the implications of what they're asking for. Sure it looks great on powerpoint for one specific use case, but rarely are all of the relevant factors are taken into account.

  • Re:Estimation (Score:5, Insightful)

    by chuckinator (2409512) on Friday October 18, 2013 @01:37PM (#45166933)
    I agree wholeheartedly because this is the most visible departure point for people that aren't programmers. They want to know when your application will work, bug free, according to spec, and even handle the corner cases that no one thought about in the design meetings. They don't care about how to iterate over a list of elements in a collection or sort through config files or transition through states, but they damn sure want it to work within a reasonable amount of time even if they don't know how they think it should work.
  • Re:Estimation (Score:5, Insightful)

    by Anonymous Coward on Friday October 18, 2013 @01:40PM (#45166957)

    By far the hardest part of my job as a professional software developer is estimating how long a feature will take to develop.

    More often than not, it's the pointy-haired-boss who tells me how long a task is going to take. And since they're the ones signing my paycheck, I tend to figure out how to get the task done in the time allotted. Unfortunately with time and complexity fixed, that makes quality the variable.

  • by Anonymous Coward on Friday October 18, 2013 @01:41PM (#45166971)

    Nothing pains me more than seeing bad programmers make up fake problems they then "solve" with unnecessary complexity, no thought into the pattern applied (if applied at all) and using the loudness of numbers to silence a good idea.

  • Re:Documentation (Score:5, Insightful)

    by Archangel Michael (180766) on Friday October 18, 2013 @01:45PM (#45167031) Journal

    Documentation isn't hard. It is time consuming.

    To document something well, you have to know it very well. Once you know a system that well, YOU often don't need the documentation, because it is in your head. Much of documentation isn't for yourself, it is for whomever follows you.

  • by jasno (124830) on Friday October 18, 2013 @01:46PM (#45167059) Journal

    The hardest thing, consistently over the years, is to bridge the gap between the ideal and the practical. We've all faced problems that could be so easily solved if we could just rearchitect the code or omit a few requirements. Situations that would be so simple if only they were so simple. Crafting a beautiful algorithm and then being told that you have to add an exception here, or a special case there. I generally prefer driver-level programming because it tends to involve the lowest number of hacks and special cases(if you're laughing at this, you're probably a firmware guy that hasn't written an application or middleware in a while).

    Working on a commercial product that has limited logging ability and trying to reproduce and diagnose errors in the field is pretty high up on my list of hard things to do. Unfortunately it is nearly all I do nowadays.

    Working on unglamorous code or writing documentation is hard, but mainly because it's hard to stay focused.

  • by JazzHarper (745403) on Friday October 18, 2013 @02:01PM (#45167267) Journal

    I would rather write documentation all day long than write tests. Developing a good test suite is hard. (Putting together a crappy set of tests is easy, but of no value). As much as I hate developing a test suite, though, I love having it when it's time to make a release.

  • Debugging?? (Score:5, Insightful)

    by Tough Love (215404) on Friday October 18, 2013 @02:03PM (#45167291)

    Because debugging did not even make the list, I must assume that the author is only an armchair programmer, or only writes toy programs. And why is "choosing names" rated harder than "designing"? This opinion could only come from someone who is often required to choose names, but never to design.

  • Hardest thing (Score:4, Insightful)

    by sugar and acid (88555) on Friday October 18, 2013 @02:03PM (#45167303)

    From my experience, the hardest thing for a programmer that because code may look weird or ugly is NOT a reason by itself to change it. The only reason to change it is if it is buggy, or does not meet the current requirements.

    But some programmers just can't help themselves, dig in with both hands rip the guts out end up breaking everything because they have failed to understand why it was written in that weird ugly way. On the other hands I'm glad they are programmers and not surgeons:)

  • by nitehawk214 (222219) on Friday October 18, 2013 @02:11PM (#45167393)

    Could someone copy/paste the list from that site? I don't feel up to solving exactly what combination of allowing Javascript to run from 15 different domains is required to get the slideshow to work...

    The 10th hardest thing: Make their shitty javascript heavy site work.

  • by harperska (1376103) on Friday October 18, 2013 @02:39PM (#45167799)

    The key to good design, on the other hand, is making it work in the way the user expects it to work, not in the way the user tells you they want it to work. More often than not, those two are quite different.

  • by s7uar7 (746699) on Friday October 18, 2013 @03:14PM (#45168249) Homepage
    Don't document what your code does, I can (usually) tell that from reading it. Document why it does what it does.
  • Re:Users... (Score:4, Insightful)

    by sandytaru (1158959) on Friday October 18, 2013 @04:53PM (#45169611) Journal
    Get a good analyst to do that junk for you. They exist. Make them deal with the users, get your requirements, translate them from User Speak over to proper Dev Speak, dig out the required database changes and grind out the new data, and let you code away merrily from there.

    I do that for my team, along with the functional documentation and the bulk of the testing. That frees up more time for our coders to, you know, write code.

Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson