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.

Re:Two sides of the coin

[Anonymous Coward]

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

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

[networkzombie]

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

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

Re:Estimation

[bunratty]

Why not quadruple and add four instead? Oh, right, you learned this from an assembly programmer.

Re:Estimation

[wavedeform]

But this violates Hofstadter's Law

Re:Estimation

[bill_mcgonigle]

Why not quadruple and add four instead? Oh, right, you learned this from an assembly programmer.

assembly programmers always shift, they don't multiply by powers of 2.

shl ax, 2
add ax, 4

if memory serves...

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.

Re:Programmer Troubles

[garcia]

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

Documentation

[gabereiser]

Apparently where I work, it's documentation. It's so hard, we don't have any.

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.

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.

Easy solution.

[aardvarkjoe]

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

I had to put down my 15 year-old dog.

[kumanopuusan]

That was hard. I loved that dog.

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:Time Estimations

[phantomfive]

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.

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.

following a changing spec list

[bugnuts]

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.

Re:Solving real world problems

[SJHillman]

Coders have probably spent far more time helping wars, real and simulated, than solving them.

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:explaining to others what i do

[SJHillman]

I'm one of those guys who do a bit of sysadmin, a bit of desktop support, a bit of coding, etc. It got to the point where if someone not in IT asks what I do, I just tell them "I run the Internet". Sadly, most of them take it seriously.

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.

Re:Maths

[man_of_mr_e]

The hardest thing programmers have to do is think like non-programmers. Or maybe even think like someone other than them.

None of these things are rocket science. Some of them are computer science, but that's kind of the point.

Programmers are typically forced to develop software to demanding schedules which leave no room for the things in the list. They CAN do those things, they are just never given the time to do them.

Yes, many programmers won't do them even if given the time, or will goof off if given the time until they have to write crap code to meet the deadline, but that's a different story. Or maybe not.

The hardest thing a programmer has to do is Think like someone else, Not goof off when you think you can get away with it, and to push back to have the time to do the things that are necessary to write AND MAINTAIN good code.

Of course, circumstances vary. The difference between a startup succeeding and failing may in fact require being first to market with crap code. But at some point, you have to pay back the technical debt you build up.

Ok, so lets add that to the list as well.

Oh, and making end users understand the impact of their crazy changes.

Re:Amazing

[Anonymous Coward]

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.

OS Vendor

[fyngyrz]

The most difficult thing *always* turns out to be programming to some API that the manufacturer says does X, but either really does Y, or simply crashes -- and then finding out that they're not going to fix it, except or unless in some later version of the OS, thereby doing all the current, stable customers out of whatever it was I was trying to accomplish. I mostly program for OSX these days, so my examples are all Apple-centric.

1) I was writing a POS application for a Chinese restaurant owned by friends. I had an old mini core 2 running 10.6.8 I wasn't using, and I wanted to make the app around this unit. So I spent a couple of days writing it, using UTF-8 for the Chinese parts, and everything was going swimmingly. I ordered some receipt printers (one for the counter, one for the kitchen to print orders, and one for the to-go/delivery table.) English? No problem. Everything worked. Put characters -- I mean actual Chinese -- in the file to be printed via CUPS, and the print process would crash. The problem? CPU-specific bug in a CUPS filter (Apple owns CUPS now.) They have no intention of fixing it in 10.6.8. They told me, "Upgrade the mini to Lion." So I ordered Lion on a stick and stuffed it in there, and the Lion installer informed me "CPU not supported. Core 2 duo or above required." So the fix is in, but I can't run the fix. So I ended up buying a new mini. Yeah, that "fixed" it. At a cost of $600. Thanks a whole f'ing lot, Apple.

2) Qt 4.x: Full of bugs. Fixes? Sure. In 5.x. But 5.x is full of new problems. I'll spare you the details, other than to point out that if they'd just bloody fix the stuff they claimed as working in the first place, rather than constantly surf forward and expect you to follow them, I'd a darn sight happier.

I feel that if the manufacturer says "here's an OS, and here are the features it offers you (API list, UI operations, etc.), then they are obligated (because I have invested time and/or money based on what they claimed) to make it happen. I accept that first out the door, there may be things that are not working right. What I don't accept as "ok" is this attitude that it's ok to leave it that way. You get a straight up bug report you can verify (print high UTF-8 characters crashes your printer filters) by Ada, you should fix the thing YESTERDAY. It's more important than your new OS, because it's about the reliability and honor and ethics of what you do. You don't fix it -- Apple -- and you go from respected vendor to the opposite (both lose respect and that much less likely to vend anything to me.)

Same thing goes for apps. You sell a paint program that is supposed to draw rects and circles, but won't draw circles, you bloody well need to FIX it so it DOES, and make sure that fix is available to every poor bastard who bought your paint program WITHOUT requiring them to change anything else.

It's NOT acceptable to say "You must upgrade to the next OS" or "That's fixed in the latest version, but that only runs on a 4 core CPU so you're screwed" When you say stuff like that, some people, somewhere, are getting red faced, ramping up blood pressure, and contemplating ways to deliver a clutch of rabid wolverines to your development team in a box marked "live strippers, schedule party immediately."

Related to that, I've learned to stay well clear of other people's frameworks and libraries. If I wrote it, I can almost certainly fix it. There's nothing more disheartening than writing in about a bug and hearing back that it's been upon some list, while your stuff remains broken, etc. Might as well have written it yourself anyway. Assuming you have time, of course.

Everybody's in such a damn rush to move forward, they're unwilling to see to it that current efforts are made to represent fine craftsmanship instead of a harried dash to ship at any cost in reliability and honor.

I've got a lot of older software because my reaction to "you gotta upgrade to get that fix" is "you're not getting more of my money until what you sold me in the first place works as you told me it would." I can't always stick to that rule, but I assure you, I try.