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

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?"

Comments

Two sides of the coin

[swm]

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

[scottnix]

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

[phantomfive]

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

[chuckinator]

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

[Anonymous Coward]

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.

Programmer Troubles

[girlintraining]

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.

[Anonymous Coward]

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.

Re:Making users happy.

[harperska]

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.

Understand existing code

[Anonymous Coward]

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

[CnlPepper]

...particularly physicists who think they can code.

Time Estimations

[Anonymous Coward]

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

[Jeremiah Cornelius]

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.

Getting requirements that conflict.

[darkwing_bmf]

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:Documentation

[Archangel Michael]

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.

Debugging??

[Tough Love]

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.