Ask Slashdot: What Are the Hardest Things Programmers Have To Do? 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?"
Two sides of the coin (Score:5, Insightful)
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)
Programmer Troubles (Score:5, Insightful)
Easy: The hardest thing a programmer has to do is explain why what they're doing isn't a simple matter of programming.
Making users happy. (Score:4, Insightful)
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.
Understand existing code (Score:4, Insightful)
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)
...particularly physicists who think they can code.
Users... (Score:4, Insightful)
Time Estimations (Score:5, Insightful)
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)
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.
Working on boring projects (Score:3, Insightful)
Re:Estimation (Score:5, Insightful)
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.
Getting requirements that conflict. (Score:5, Insightful)
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)
Re:Estimation (Score:5, Insightful)
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.
Work with bad programmers (Score:2, Insightful)
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)
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.
Dealing with reality... (Score:4, Insightful)
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.
Testing, testing, testing (Score:4, Insightful)
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)
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)
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:)
Re:Copy paste the list please (Score:4, Insightful)
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.
Re:Making users happy. (Score:5, Insightful)
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.
I disagree slightly on the documentation (Score:4, Insightful)
Re:Users... (Score:4, Insightful)
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.