Forgot your password?
typodupeerror
Programming

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

Posted by Soulskill
from the moderate-their-criticism dept.
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:
  • Amazing (Score:3, Informative)

    by Murdoch5 (1563847) on Friday October 18, 2013 @01:14PM (#45166565)
    I actually agree with that list.
    • Re:Amazing (Score:4, Funny)

      by Anonymous Coward on Friday October 18, 2013 @02:34PM (#45167737)

      I actually agree with that list.

      I don't.
      The most difficult task for a programmer is Personal Grooming, followed closely by eating Healthy and getting enough Exercise.

  • 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.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

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

      You think the inventor of the mouse pad started with the name? What's a "mouse pad"? Sounds like a feminine hygiene product for mice...

      • by JustOK (667959)

        At the time, maaaan, like a mouse pad was a groovy place for mice to like hangout and live, you know?

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

      "there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors"

    • it makes me happy to see this:

      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.

      words are our tools...well alpha/numberic symbols arranged in groups to form instructions for a machine to execute

      typing a word is the same as 'naming' the thing you are creating when you type...ha! this certainly gets us into a Mobius Strip of language after awhile

      as I've learned programming, I've found that 2nd Order Cybernetics [wikipedia.org] concepts to be i

    • The head and tail of the list

      9. Designing a solution

      1. Naming things

      are pretty much two sides of the same coin.

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

      While I agree that these items are closely related, in my opinion, these were the *easiest* thing on the list. After all, this is what programmers are trained and paid to do, and for me this is the most enjoyable part of programming.

      Of all the items on the list, the one I'd put closest to the top is 'time estimates', since in anything other than the most trivial cases it is an exercise in predicting problems yet unknown.

      But the one that would be on the very top of my list isn't there: Interfacing with

    • one of the hardest things i do is sit in front of a computer most of the day.
      would prefer to be more out and about

  • 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.
    • Re:Estimation (Score:5, Interesting)

      by networkzombie (921324) on Friday October 18, 2013 @01:21PM (#45166683)
      I use IT Time. Begin with your best estimate of how long the project will take and double it. Add two, and then double it again. That is how long it will take. I cannot remember what colleague I learned this from (an Assembly programmer I think), but is has been fairly accurate (for me) for almost 20 years.
    • 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.
    • 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 travdaddy (527149)
      By far the hardest part of my job as a professional software developer is estimating how long a feature will take to develop.

      How much time will that take to estimate?
  • 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 garcia (6573) on Friday October 18, 2013 @01:32PM (#45166847) Homepage

      I once had a non-technical manager and she told me what I did was simply "magic" to her and others and while she knew the results provided weren't as simple as it seemed to them, others in the organization felt it was.

      It's a very difficult concept for non-technical people to understand and part of the life of any developer to deal with. It's the same thing many developers feel about management and administration and we all need to share in the responsibility of not assuming it's easy and/or "magic".

      • by sconeu (64226)

        At least she was aware that it wasn't as easy as it looked... you were ahead of the game.

        • by PRMan (959735) on Friday October 18, 2013 @02:58PM (#45168039)
          Yeah. I had a boss that after watching Independence Day couldn't figure out why we couldn't just wirelessly connect to anything without any setup or passwords like they do on the movie. And when we told him it was impossible, he thought we were just being difficult. I hate that movie.
          • by psithurism (1642461) on Friday October 18, 2013 @09:50PM (#45171651)

            Yeah. I had a boss that after watching Independence Day couldn't figure out why we couldn't just wirelessly connect to anything without any setup or passwords like they do on the movie. And when we told him it was impossible, he thought we were just being difficult. I hate that movie.

            Oh, but it is very possible, but security doesn't permit it for one obvious reason: so our primitive enemies can't connect to our space age equipment and turn off whatever vital systems keep them from blowing up our space ships or other valuable infrastructure.

            But if he ignore the lessons that could have been learned from the villain's mistakes, then you can still use it to your advantage. Explain that what they did in the movie is commonly termed "infiltration and hacking," and if he wants me to fly into our rival competitor's headquarters and install viruses on their computers; well, that's not my specialty and is illegal, but I'm pretty sure I could do that faster and derive more excitement from it than converting the tabbed based interface we have to whatever interface paradigm was in vogue this morning that you'll change your mind about this afternoon.

    • by dubbreak (623656)
      Definitely. No matter where I've worked that has been an issue with someone at some level in the organization. "Oh that should be easy."

      That also goes hand in hand with estimation. With proper estimates non-technical people will often think you're sandbagging. "There's no way it can take that long!"

      I'm lucky with my current clients. They've been through a successful project and a few failed ones and have a much better grasp on how long it takes to develop reliable software and why it's best to get it a
  • by gabereiser (1662967) on Friday October 18, 2013 @01:17PM (#45166603)
    Apparently where I work, it's documentation. It's so hard, we don't have any.
    • 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 Garridan (597129)
        Documentation is a skill. If you think it's not hard, you're either ignorant to your own failings, or those downstream of you are very lucky. Lots of people try hard and spend a long time on documentation and still fail to make it good. It *is* hard for most people to think of the many ways documentation needs to be used, the many mindsets of its users, and balance those two into concise, readable documentation.
      • by ArsonSmith (13997)

        I find it just the opposite. I document everything for my self. I know the next time I come to do something I will forget the intricate switches and options needed to get it to work the way I did last time. Of course the documentation is only completely readable by me. I keep it all in a wiki so others can view and modify it as needed and I can see what I wrote and how it was changed by others. It also helps to get things formatted in a normal way.

  • 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.

    • I call this "pick a lane".

      This is also a place where customizations settings can come from. If you design well, your design becomes more flexible, and users will start using things in ways that you couldn't imagine before starting the project.

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

    Their laundry

  • 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.

  • by binarylarry (1338699) on Friday October 18, 2013 @01:18PM (#45166629)

    Deal with clueless management.

  • by aardvarkjoe (156801) on Friday October 18, 2013 @01:20PM (#45166655)

    I name all of my classes and variables "George." Problem solved.

    • by brainboyz (114458)

      You must've gone to the same school my coworker did. He names everything "My".

    • Re: (Score:2, Funny)

      by Anonymous Coward

      And your namespace is "Jungle", right?

    • I name all of my classes and variables "George." Problem solved.

      We were coding with Simulink (diagram based thing). When things get complex you take a group of blocks and group them into a subsystem so you get a hierarchy of block diagrams. Each subsystem displays a name under the box, and everyone tries to give each block a name. People choose names of varying quality, but we had one guy leave the default name on every block "subsystem". To avoid name collisions it adds a counter as a suffix. I expanded

  • i mine as well tell them that I raise unicorns.
  • by kumanopuusan (698669) <goughnourcNO@SPAMgmail.com> on Friday October 18, 2013 @01:22PM (#45166699)

    That was hard. I loved that dog.

    • by jbeaupre (752124)

      Next time use a Python script.

    • by krray (605395) on Friday October 18, 2013 @04:11PM (#45169113)

      I'm not sure why you got flagged funny.
      Off-topic, sure, but FUNNY?

      I'm with you though. Had to do the same not too long ago. 15 years and 10 months my black lab made it to. Hardest day of my life was putting him down.

      And then shortly after... My uncle went ape-shit crazy. Killed his wife. And was shortly thereafter murdered himself by S.W.A.T. No joke.

      And there sat the dog. So I got on a plane and drove the dog home +2,000 miles.

      Probably the best dog I've ever had yet...

    • That was hard. I loved that dog.

      I would have marked this as "insightful" versus funny.

      For me:

      1. -- Watching the love of my life marry someone else because I was too cowardly to ask her out in time.
        -- Explaining to my nephew that he'd never see his dad again.
        -- I still don't know what to say/do around my niece that was raped.
        -- I don't know if I'm proud of myself or self loathing for not having killed the rapist yet.

      Most of these fall into "communication with people"; one falls into "planning and plan execution."

  • by CnlPepper (140772) on Friday October 18, 2013 @01:22PM (#45166701)

    Deal with people....

  • by A nonymous Coward (7548) on Friday October 18, 2013 @01:22PM (#45166703)

    It's the clueless marketing and product spec types who don't have a clue how computers work, don't have even the most superficial knowledge of how the current systems work, can't decipher what customers say they want, and write product specs which are so devoid of reality as to soak up more time straightening out than everything else combined.

    • I often find myself in conflict:

      Short, easy to type, but possibly ambiguous names
          -or-
      Clear detailed names in 26+ characters

      The choice depends on the audience I believe will be reading, and if I am having a good/bad day

  • by Anonymous Coward

    There are only two hard problems in Software Development. Naming things, cache invalidation, and off-by-one errors.

  • 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.
    • 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.
  • 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:Time Estimations (Score:5, Interesting)

      by phantomfive (622387) on Friday October 18, 2013 @01:32PM (#45166837) Journal
      Increase your estimate to longer than it will take, even with changing requirements. Tell your boss, "this part of the spec is undefined, but in the worst case, it will take X days." When you find out a spec change will increase your estimate, tell your boss immediately.

      Estimation is definitely a skill, but it's one that can be developed.
  • by bugnuts (94678) on Friday October 18, 2013 @01:28PM (#45166771) Journal

    The most annoying and maddening thing I've ever had to do was follow a changing spec list from a manager who thought it was some iterative process, instead of giving me an actual complete task description to work on.

    Even though it was his nickel, it sucked the enjoyment out of that job.

    • by careysb (566113)
      +1. My last place was so ridiculous in this regard that I decided to take early retirement.
  • by paramour (110003) on Friday October 18, 2013 @01:28PM (#45166781)

    to /. about inane flash-based articles when I should be working.

  • by curunir (98273) * on Friday October 18, 2013 @01:28PM (#45166789) Homepage Journal

    The hardest thing for me is that there are so many different environments and the code needs to work in all of them. There's integrated dev, qa, staging, end-to-end testing and production and each of them are subtly different. When deploying code, the logistics around how to get it to the right place at the right time in a working state can be really hard. A simple Google search for branching strategies will show that there's numerous ideas on the best way to shepherd a team through the code freeze, regression, deploy and MR phases.

    Things get even more complex in an elastic environment where you have to autoscale. A simple call to a database can then require service discovery, master election and a whole host of other technologies/techniques that adapt to the fluid conditions of an elastic environment.

    So from a code perspective, you always have to built abstract interfaces to non-specific infrastructure. A simple file loading turns into loading a URI that loads via the proper strategy (file://, s3:// or even something custom that reads from a db). A caching layer may be distributed in production and a simple in-memory hash in development, so that has to be abstracted too. Making sure your db queries are performant can also be difficult when your local database is nowhere near the scale that exists in production.

    We've had some limited success using vagrant/chef for development environments to make them more similar to the downstream environments (i.e. developers actually run multiple VMs with individual functions as we have in our prod environment), but there's a limit to how much you can run on an individual machine.

    Naming is the easy...just get a thesaurus and understand that it's important. Though it does remind me of one of my favorite quotes about software development (credit to whoever said it originally...I'm too lazy to look it up):

    Half of programming is naming; half is figuring out responsibility boundaries; and half is rewriting because you named your god-object wrong

  • They promise things that can't be accomplished. Ugh.
  • by dryriver (1010635) on Friday October 18, 2013 @01:30PM (#45166807)
    I'm still trying to find a way to use the GPU for computations without having to jump through crazy hoops to do it. Also, multithreading in general is often a PITA to get right...
  • Preventing a steady rain of feature requests that vastly exceed the development capacity. Often these features will take longer in programming time than the time they will save.

    Another hard one is to use an older programming technology when you have been using a far newer one for some time.
  • 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.
  • Testing is often the hardest part of writing any feature or fix because often times it takes a relatively long time to set up an environment and a test scenario. It's also particularly difficult to narrow down a problem to its source when integrating with software for which no source code is available and support is sketchy. I've seen problems in Microsoft and SAP software that take a long time to work out and sometimes leave me SOL.
  • 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.

  • Math? Math is fun. Naming things? Very entertaining. Designing a complicated algorithm? It's what I live for.

    Had you asked me twenty years ago what was the hardest thing about programming, I'd say, interfacing with non-technical management, for a variety of reasons.

    As me today, and I'd say offshore infrastructure admin. Doing my job is fun. Somehow convincing someone else with few communication skills and little training to do their job so I can do mine, that's probably the hardest part today.

    Not the

  • by Anonymous Coward

    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.

  • Communicate effectively with less intelligent people
  • Nowhere on the list did I see cache invalidation [martinfowler.com]. What gives?

    I guess it's the third item on the list at work, only the other way.

  • 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 Aviancer (645528) on Friday October 18, 2013 @01:49PM (#45167091) Homepage Journal

    This was eloquently described by Phil Karlton, and extended by Martin Fowler:

    There are only 2 hard things in computer science: Cache invalidation, the naming of things, and off-by-one errors.

    http://martinfowler.com/bliki/TwoHardThings.html [martinfowler.com]

  • by foistboinder (99286) on Friday October 18, 2013 @01:52PM (#45167147) Homepage Journal

    What Are the Hardest Things Programmers Have To Do?

    Dealing with incompetent project managers.

  • Getting the proper requirements from people.
  • 1. Enumeration.
    ......

    Wait. Strike that. Make it:

    0. Enumeration.

  • And not waste time on Slashdot all day.

  • The technical stuff is all doable. Politics, management, etc. -- those are hard. Best part of the job is getting that stuff out of the way and designing/coding.
  • 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.

  • The hardest part of being a Software Engineer is making management understand how valuable you are and making them assign to you interesting work.

  • 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.

  • I really haven't had the issues the writer mentioned, maybe here and there early on in my career. Overtime I have come to a comfortable ease controlling those points.

    The problem I have is technical debt that grows under mounting pressure from those that see programming more as an assembly line than an art. This is where, largely due to budget or time constraints, design corners are cut. Over a period of time, all of these short-cuts led to a huge debt that forces a new re-design. At first I could not art
  • 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 DdJ (10790) on Friday October 18, 2013 @02:05PM (#45167319) Homepage Journal

    For me, I think the hardest part is often "figuring out what to build in the first place". Sometimes that starts from a product idea. Sometimes it starts from an imperfect requirements document. (I have never seen a perfect requirements document.) Going from that to "what do I build?" is the hardest part.

    If you are the sort of programmer who works on big projects and is handed a clear and unambiguous spec... then sorry, I have absolutely no idea what your hardest problem might be.

  • 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.
  • Starting a new job (Score:4, Interesting)

    by mendax (114116) on Friday October 18, 2013 @03:29PM (#45168485)

    Hands down, the most difficult thing I've had to do is start a new job. New technologies, new software, new people, new environment, new policies, I'm two weeks into a new job and the anxiety is driving me bonkers. It's more stressful than the worst deadline crunch I've ever experienced... and here there is no deadline here!

If A = B and B = C, then A = C, except where void or prohibited by law. -- Roy Santoro

Working...