×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Hardest Things Programmers Have To Do

itwbennett (1594911) writes | about 5 months ago

6

itwbennett (1594911) 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 #1 hardest thing developers do is name things. Are you a software developer? What's the hardest part of your job?"
Link to Original Source

6 comments

Easy enough to refactor/rename these days (1)

barlevg (2111272) | about 5 months ago | (#45164659)

I agree that this used to be a big problem for me. Then I got a job outside of academia, and they made me learn to use an IDE (oh how I miss the days of doing everything in gedit and command-line gcc...), so now renaming a variable (and getting all its references) is a matter of one right-click. What this means is that if I can't figure out what to name something, I can just name it "blah," "stuff" or "temp" and then refactor when the inspiration strikes.

Re:Easy enough to refactor/rename these days (1)

rwa2 (4391) | about 5 months ago | (#45165161)

Word. Another naming convention I've worked with that I like that was stolen straight from perl : prefixing your variable names with its ctype. So you'd have double d_num , int i_counter , const string cs_blurb . It was a great reminder to have around to always make sure you were treating your variables right. Of course, it's also something better tracked by the IDE or better yet a high-level language compiler, but with C/C++/Java I'd certainly make this part of the coding stardard again.

The hardest thing? Two are at the TOP of the list (1)

bobbied (2522392) | about 5 months ago | (#45165105)

1. Working with others you don't agree with. VERY hard to implement something you know is wrong, then stay away from the "I told you so" when you have to fix it later.

2. Dealing with managers who do not understand the implications of their decisions, then refuse to accept the inevitable results of their choice, even when you tried to warn them.

Yes, the two are related at times. But it points to the most difficult part of my past jobs, interpersonal relationships. Programming computers is the *easy* part that I greatly enjoy, but interpersonal relationships I find much more problematic because what worked yesterday, may not work today.

scheduling (1)

kiick (102190) | about 5 months ago | (#45165285)

The hardest part of software development is the schedule. Managers and so forth want to have the comfort of knowing when some piece of code is going to be finished. The ugly truth is that it's all guesses. That's why almost any significant software project is usually late. You can't tell ahead of time what is going to bite you. The whole thing may have to be redesigned because of problems you couldn't see at the beginning. The requirements may change. And then there is the debugging, which is really unpredictable.

My theory about why open source code can be better than commercial code is because FOSS is released "when it's done", not on some arbitrary date. The worst kind of scheduling is when you start with the end date and work backwards. Inevitably something (quality, features) gets lost.

The rule for estimating time to write code is this: take your best guess, double it, add one and convert to the next higher units. So if you think you can code something in 3 days, tell them it will take 7 weeks. By the time you flush out the design, write and comment the code, debug it, write the tests, test it, document it and deliver it, you'll be lucky to meet the deadline.

And over-estimating doesn't do you any good either. All it takes is finishing early ONCE, and from then on your estimates are considered "inflated".

"Everything takes longer than you expect -- even when you expect it to take longer than you expect."
        - Ashleigh Ellwood Brilliant

Hardest thing is understanding that people matter (1)

gestalt_n_pepper (991155) | about 5 months ago | (#45165557)

And that the machine doesn't. The hardest thing is understanding the human part of the system.

Most programmers miss the core fundamentals of humans, to whit:

1) Software is a coversation. BE POLITE.

2) Machines and software exist ONLY to serve humans. They have no other purpose. To the extent that they serve they are a success. When they don't, they're a fail.

3) Users (i.e. humans) anthropomorphize: Whether they know it or not, when users look at the computer, they don't see a machine, they see a little guy.

4) Computers are servants. Ultimate servants. You can yell at them, kill them, torture them, put Windows on them. They can't complain and merit no regard. They serve and are useful, or they go the way of Windows ME and Clippy.

So, connect the dots. The computer and it's software are the waiter. The waiter shows you a menu. You select something. You have a dialog with the waiter, narrowing down and specifying your order. You say OK when the waiter has it all down, and then you wait for your tasty order of data to arrive.

So imagine a waiter, who while you were ordering, continually interrupted you by telling you that the menu was updated, and did you want to look at a new one? Or a waiter who simply stood there after he took your order for a minute or two.... thinking. Or a waiter who decided to unexpectedly and without explanation, "refreshed" the table linens and silverware while you were trying to butter your bread, grabbing the bread, butter and knife from your hand. Or a waiter who simply told you you ordered wrong, refused to take your order and wouldn't suggest any alternative. Or a waiter who simply said, "Order not found." and just stood there like an infuriating idiot.

Except for some of Apple's offerings, this pretty much describes *every* user interface on the market today.

I have heard programmers in meetings explicitely tell me that it "doesn't matter what we put on the interface." I have seen dialogs that not even the original programmer understood after a few month's absence.

Programmers are experts at WHAT to do, but clueless as to WHY, and it shows.

None of the above (1)

kemosabi (659932) | about 5 months ago | (#45166001)

I don't agree with that list at all. It sounds like it was written by people who are just whining about unpleasant tasks, not difficult ones. Writing documentation and tests isn't so much hard as tedious. Dealing with other people isn't so much hard as demanding of patience. Behind many but not all of these things, however, is a common thing we do that's very difficult: maintain self-discipline in our work. That old code is ugly and hard to understand? I'll just rewrite... wait... no... that's just taking the easy way out. That old code has been deployed (successfully) for years and I'll go through the pain and grousing of understanding why it is as it is before I make any assumptions based on my own aesthetics - as if code assessment were a beauty pageant. Writing docs? Writing tests? Crap I hate doing that... hey, maybe there's this trivial little implementation detail that I could... no... I'm going to make myself do the right thing and plow through the parts of it that I don't like and I'm going to make a sticking point of doing a good job, because I know I can. As for design, yes some designs are difficult and understanding what you're trying to do is a key part of doing things right (and not just for software). Yet I've seen the problems of design more of be a lack of self-restraint: framework building and trying to build "the perfect system" are pernicious. Behind it all, there's an imperative to know yourself and keep yourself honest: when something you write can reach hundreds, thousands, or millions of people at once, there's no forgiveness for self-delusion.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...