Do you have adblock enabled?
 
If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(IT World)   The hardest things programmers have to do - aside from talking to women   (itworld.com ) divider line
    More: Interesting, software engineers  
•       •       •

6014 clicks; posted to Geek » on 17 Oct 2013 at 1:16 PM (2 years ago)   |   Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



159 Comments     (+0 »)
 
View Voting Results: Smartest and Funniest


Oldest | « | 1 | 2 | 3 | 4 | » | Newest | Show all

 
2013-10-17 11:51:00 AM  
That slideshow is my entire job.

Naming products is the hardest until I figured out that strippers are already quite creative in how they spell common words. Take a name like BRANDEY or SPAZZLE and you can make the acronym fit. Naming methods and classes is easy.. just take the first line of your comments and camel case it. Future programmers will love you for it.
 
2013-10-17 11:58:24 AM  

Tr0mBoNe: That slideshow is my entire job.

Naming products is the hardest until I figured out that strippers are already quite creative in how they spell common words. Take a name like BRANDEY or SPAZZLE and you can make the acronym fit. Naming methods and classes is easy.. just take the first line of your comments and camel case it. Future programmers will love you for it.


Yeah, that's a terrible list.  Unless you're looking for a list of Best Practices.

Possible exception for "other people's code" when they don't follow best practices.
 
2013-10-17 12:01:56 PM  
Never fark with the IT guy or gal, they can make your life a living hell.
 
2013-10-17 12:03:23 PM  

Diogenes: Possible exception for "other people's code" when they don't follow best practices.


I've had to maintain 30 year old code that was fine because of a strict process and that the language didn't allow for too much stupid to make it in. With all the boilerplate and such you had 58 characters per line to work with. I've also worked on code written 4 years ago that was insane... not dumb but too smart... the original programmer decided every OO pattern had to be used and that even 1:1 relationships needed an interface or 6 between them.
 
2013-10-17 12:10:24 PM  
Deslided

I note with complete lack of surprise "Design and write secure code" was not on this list. Must be because it's so dang easy!
 
2013-10-17 12:15:02 PM  

Generation_D: Deslided

I note with complete lack of surprise "Design and write secure code" was not on this list. Must be because it's so dang easy!


They'll get it on the next update cycle.
 
2013-10-17 01:22:29 PM  
"Clicking through slideshows while at work" conspicuously absent.
 
2013-10-17 01:22:31 PM  
5. Working with someone else's code
The task: Having to maintain, debug or enhance an application or piece of code that was written by another developer(s).
The challenge: Trying to understand how a piece of legacy code works and divine the intentions of the original developer. This is even harder when that developer isn't around and the code is poorly written, commented or documented.



It's all poorly written, commented, and documented. Yes even your own. Besides any code that is all ready written is legacy code and should be treated as such.
 
2013-10-17 01:22:33 PM  

Tr0mBoNe: That slideshow is my entire job.

Naming products is the hardest until I figured out that strippers are already quite creative in how they spell common words. Take a name like BRANDEY or SPAZZLE and you can make the acronym fit. Naming methods and classes is easy.. just take the first line of your comments and camel case it. Future programmers will love you for it.


Comments?  What are those?  ;)

/kidding
//mostly
///but the comments generally come AFTER the code so this method still wouldn't work
 
2013-10-17 01:22:41 PM  

Tr0mBoNe: That slideshow is my entire job.



yeah, my take from it is 'basically their job'
 
2013-10-17 01:29:15 PM  
Gonna take a few guesses before I read TFA:

1) Comment their code
2) Write documentation (anything from requirement specs, to design docs, to user docs)
3) Read documents (such as requirement specs and design docs)
 
2013-10-17 01:31:58 PM  
3. Estimating time to complete tasks
I actually had a PM ask me "what problems will you encounter and how long will it take to fix then?"
 
2013-10-17 01:32:04 PM  
How about have to do a real minor fix which takes forever due to mundane processe?
 
2013-10-17 01:32:41 PM  
I'm a BA/QA in the midst of a major project so I am getting a kick out of this slideshow.

/I'm a people person
 
2013-10-17 01:33:20 PM  
Probably the hardest is all the farking business process busy work - reporting hours, doing status reports, filling out forms, etc. I don't have time for that shiat - make a PM do it...

/ on-time, under budget for the last 15 years
// work for a Fortune 100
 
2013-10-17 01:35:21 PM  
There are only two hard things in computer science:

1) Cache invalidation
2) Naming things
3) Off-by-one errors

/quoting some guy who was quoting some other guy
 
2013-10-17 01:36:01 PM  
Every code I've ever met thinks that every other person's code they come across is terrible and the programmer was an idiot.

I've never once heard a programmer compliment somebody's code.
 
2013-10-17 01:37:50 PM  
Of all of the issues dealing with software development, it's always the people who are the worst. End users aren't too bad. Yes, the often have no clue what they want and change their minds a lot but you can work with them on discovering what they really need. In the end, they really want tools that make their jobs easier and aren't out to bust your balls. Have a bit of empathy and you can usually work things out to the satisfaction of the users and the developers.

The worst thing I've seen in most jobs is middle management politics. The manager that oversees six people wants to oversee a dozen and is quite happy to screw up project after project to make someone else look bad or to get into another manager's space. I had one manager who completely bypassed the requirements process because he didn't like the manager of the business analysts. So project after project ended up being not what the end user needed but what this middle manager imagined they needed. People ended up constantly working nights and weekends with cancelled vacations to completely redo projects to meet the original deadline because of stupid turf wars. I can see why so many companies try to become flatter organizations. Bad middle management is like bathing in a tub filled with ticks.
 
2013-10-17 01:37:55 PM  
4. Dealing with other people
My was dealing the managers of the group I was developing for, as they generally had no idea of the workflow within their department.
 
2013-10-17 01:38:35 PM  

Cybernetic: Gonna take a few guesses before I read TFA:

1) Comment their code
2) Write documentation (anything from requirement specs, to design docs, to user docs)
3) Read documents (such as requirement specs and design docs)


Now that I've read TFA:

My first point (Comment their code) is one of the main things that makes TFA's 5th point (Working with someone else's code) such a pain in the ass.

For one job, I inherited about 50,000 lines of C code that contained approximately three comments. And it was designed and written by someone whose way of analyzing and breaking down problems was almost exactly the opposite of mine. I spent days and days doing what amounted to archaeology, just trying to figure out how the damned code worked so that I could maintain and enhance it.

On the flip side of that, my first job out of college was working on the AN/BSY-2 Submarine Combat System (for the Seawolf Submarine). That project had a Software Standards and Procedures Manual (SSPM) that was the single most anal-retentive programming document I have ever come across. It specified the formatting of source code down to the level of requiring a space before and after any parenthesis or bracket, and a space before a semicolon at the end of a line. You could fail a code review for code formatting. There were also commenting requirements at the file level and for individual functions and procedures.

The upside of that was that if you had to pick up a piece of code that was written by someone else, it looked exactly the way it would look if you had written it yourself. That actually made the process of getting into a new piece of code and figuring it out significantly easier.

/And to this day, I still put a space before a semicolon.
 
2013-10-17 01:39:23 PM  
I like writing tests.  Majority of client related issues can be cleared by setting nice comfy price & requirement boundaries.  Not dealing with those that don't want to respect them.  If you comment regularly, documentation and naming is pretty easy.  Would have to be insane to not like testing.

Nothing will resolve crazy personalities except avoiding them altogether, but most client issues can be avoided by being pretty honest and forward and setting pretty solid boundaries.
 
2013-10-17 01:40:13 PM  
It should be noted that most of those things aren't really hard, the problem is when someone wants  you to do all of them 100% of the time for 20% less time and for 20% less than you think you should be getting paid.

Writing really good code takes time and energy.
 
2013-10-17 01:40:30 PM  

MethylTryp: Every code I've ever met thinks that every other person's code they come across is terrible and the programmer was an idiot.

I've never once heard a programmer compliment somebody's code.


I just retired a FoxPro 2.5 application written in Basic that was a piece of cake to work with. Every function, every variable, every tricky bit of code was commented. The guy who wrote it did a great job with it. Thing function with out a hitch for 16 years, only moving to 64 bit Windows 7 caused it to fail.

It was rewritten as a web application by a consulting group who did no analysis and only tried to duplicate the functionality. It mostly works, but is the most complicated Spring/Hibernate POS I've ever seen.
 
2013-10-17 01:41:15 PM  

simplicimus: 3. Estimating time to complete tasks
I actually had a PM ask me "what problems will you encounter and how long will it take to fix then?"


Hell, I'm not in programming (well, it isn't the main function of my job), I am in CAD (mainly support, installation, but I do get some design work every now and again) and I hate the "give me how many hours you think it will take you to accomplish something you have never done before".  If I am lucky, I get to at least do a short test (at least a days worth of research) on what I need to do, but most of the time it is asked without any piece of data given to me.
 
2013-10-17 01:41:28 PM  

simplicimus: 3. Estimating time to complete tasks
I actually had a PM ask me "what problems will you encounter and how long will it take to fix then?"


simplicimus: 4. Dealing with other people
My was dealing the managers of the group I was developing for, as they generally had no idea of the workflow within their department.


Project Manager? Isn't that supposed to be their job?

I hate when people call themselves Project Managers simply based on their ability to use Microsoft Project like a fancy spreadsheet and graph generator.

/developer AND PMBOK certified
 
2013-10-17 01:42:31 PM  
9. Designing a solution.

This should be number one on the list, not 9.  It sucks.

8. Writing tests.

Lulz....People actually write tests?

7. Documentation

We have a tech writer for that

6. Writing functionality you disagree with.

Oh gods yes, this sucks.  No matter how much you, the engineers, and others protest that this feature is functionally useless, it never fails that a salesman will get someone above you that says "Implement it" because and I quote "Our competitor has this feature".  Nevermind the feature the competitor sells doesn't function as advertised, causes their customers to lose product value, and generally slows them down;  nope, gotta have a new selling point.

5: Working with someone else's code.

This is a fact of life, deal with it.

4. Dealing with other people.

This is my favorite part of the job, and I usually hate to deal with people.

3. Time Estimates.

Lately, I estimate time, then multiply by 1.5.  I consistently underestimate how much time it will take to get things done.

2. Explain what I do.

Again fun, but I stop when people's eyes start to glaze over.  I get to play with lasers though! (sounds more fun that it is)

1. Naming things?

This is hard?  Seriously?  In this day and age when the 80 character line limit is long a thing of the past?
 
2013-10-17 01:43:03 PM  

divx88: I like writing tests.  Majority of client related issues can be cleared by setting nice comfy price & requirement boundaries.  Not dealing with those that don't want to respect them.  If you comment regularly, documentation and naming is pretty easy.  Would have to be insane to not like testing.

Nothing will resolve crazy personalities except avoiding them altogether, but most client issues can be avoided by being pretty honest and forward and setting pretty solid boundaries.


I've worked with a few good QA people who liked writing tests, were good at it, and just plain excelled at finding bugs in other people's code.

They are worth their weight in gold.
 
2013-10-17 01:43:07 PM  
Developing applications is part art, part science.

We can apply good policies in writing code, we can manage projects with tools like Microsoft's TFS, we can run analysis tools.

What can't be done without some "art" is designing a useful system. Bad or mediocre designers can sometimes get by with ruthless application of UI guidelines, and heavy reliance on user stories, but it is a reliance on prior art. Designing good applications is often an exercise in creative thinking, no matter how explicit user stories are.

Volumes have been written, trying to frame code development as a pure science, and they ultimately fail. Developers will never be able to honestly give time estimates. Often times, the best solutions for a coding problems will also defy attempts to unit test or apply coding "standards" (also a hard thing for a developer to do - code less efficiently so proper and useful unit tests can be written).
 
2013-10-17 01:44:28 PM  

Fubini: It should be noted that most of those things aren't really hard, the problem is when someone wants  you to do all of them 100% of the time for 20% less time and for 20% less than you think you should be getting paid.

Writing really good code takes time and energy.


Hence the importance of:

9. Designing a solution

Requirements gathering and modeling are lost arts.  And it doesn't matter how many studies show that doing that up front, while seemingly time-consuming on the front end, saves you project time and redevelopment on the back end.

"Stop asking me how it should work!  Why can't you just show me something?!"
 
2013-10-17 01:45:00 PM  

Cybernetic: The upside of that was that if you had to pick up a piece of code that was written by someone else, it looked exactly the way it would look if you had written it yourself. That actually made the process of getting into a new piece of code and figuring it out significantly easier.


A lot of that is what programmers hate, but what actually makes business work well.

http://en.wikipedia.org/wiki/Capability_Maturity_Model

From a business point of view, it's really nice to be able to make accurate estimates on software development time and cost.
 
2013-10-17 01:45:23 PM  

Elzar: Probably the hardest is all the farking business process busy work - reporting hours, doing status reports, filling out forms, etc. I don't have time for that shiat - make a PM do it...


A few years ago I worked with a time reporting process that was so convoluted that they had to include a line item to report how much time it took to track and report your time. It usually came up to at least two hours a week.

MethylTryp: Every code I've ever met thinks that every other person's code they come across is terrible and the programmer was an idiot.

I've never once heard a programmer compliment somebody's code.


Reading someone else's code is often like reading a book written in stream-of-consciousness. Until you can understand that person's way of thinking, it's often difficult to understand why they did things in what appears to be a rather convoluted way. That's why so many programmers want to rewrite the code they touch. It's easier to program in the way your brain thinks rather than the way someone else's brain thinks.

I have complemented people's code before. Some of the nicest code I've ever seen was oddly VBA modules in a Microsoft Access database. Since Access is often used by people who would have trouble programming 'Hello World', it was a pleasant surprise.
 
2013-10-17 01:46:38 PM  
for me, its guessing what the requirement Really are.  When a user says "I want pigs to fly" in the end its "If i click here, I want my name to turn green."  I just spent 2 weeks writing a function dealing with the "pigs have no wings" problem, and they end up not even caring that pigs can't fly.
 
2013-10-17 01:47:17 PM  
The worst part about being a programmer is that it's mundane, tedious, abstract, high cognitive, dreary work  ... even when you love it.
 
2013-10-17 01:50:50 PM  
The hardest thing for me at my last job was that the political environment meant we had aggressive deadlines and constant feature creep, to the extent that a project couldn't be properly plotted, built, documented or tested. It was maddening. The simplest web form would take months because the user would come back with an urgently needed requirement that they initially forgot to include in the specs, usually something that required going back and redesigning parts of the database. We didn't have time to build unit tests do proper UAT or stress testing. It was just accepted that the first few weeks of release would be spent fixing bugs as thy cropped up because the users would put in one test submission and go "It's good. Push it out, we have a campaign starting next week and we need this up for that. Oh, we also need you to get this URL and have the app set up on it by tomorrow because our mailers have already been sent out with the URL on them. THAAAAAAAANKS!"

As much as I learned some really cool stuff at that job, the wild west nature of the environment also taught me a lot of bad coding habits that I'm attempting to rid myself of.
 
2013-10-17 01:50:55 PM  

bart2puck: for me, its guessing what the requirement Really are.  When a user says "I want pigs to fly" in the end its "If i click here, I want my name to turn green."  I just spent 2 weeks writing a function dealing with the "pigs have no wings" problem, and they end up not even caring that pigs can't fly.


This has been bouncing around Fark the last few days

i457.photobucket.com
 
2013-10-17 01:52:56 PM  

bart2puck: for me, its guessing what the requirement Really are.  When a user says "I want pigs to fly" in the end its "If i click here, I want my name to turn green."  I just spent 2 weeks writing a function dealing with the "pigs have no wings" problem, and they end up not even caring that pigs can't fly.


I had to completely redo an Excise Tax Compliance system.  The legacy abortion they had in place was awful on every level.

I kept asking the end users how the specific taxes were calculated.  "Well, I go into the legacy system and put in this value and hit this button."  They couldn't calculate the taxes with pen and paper.  I had to derive the formulae by reading the tax regs myself.

Which amusingly enough showed me that the company had been underpaying those taxes for a long, long time.  They didn't like that I fixed it in the new system.  The manager in charge of the tax department wanted me to either redesign, or give him unaudited access to fudge the numbers.  The ultimate "exception process."

I should have been a whistle-blower.  But I shortly took another job far far away from tax systems.  What bloody awful boring subject matter.
 
2013-10-17 01:55:34 PM  
We should also point out the huge gap between "computer programmers" and "software developers".

Something like 90% of the computer code in this country is written by people who are *not* formally trained in programming or computer science. These are primarily people who do programming for business or science, e.g. excel spreadsheets, database scripts, data analysts, scientific modeling and simulation, etc.

We are facing a huge computer education crisis in this country, and I don't mean stuff like Word and Powerpoint. I mean people who are actually doing real honest-to-god programming without really having the training or experience to know what they're doing. We need expert programmers who build reusable and efficient infrastructures for non-programmers or weak programmers, and we need lots of tech-savvy domain experts who can bridge the gap between the expert programmers and the applications domains.

//Just spent a weekend talking to mechanical engineers about software standards
 
2013-10-17 01:56:42 PM  
Dealing with other people isn't bad as long as they aren't the ones making you implement functionality you disagree with, or are completely incapable of communicating clearly, or are fighting you on a technical point they don't understand, or think they are the best when the entire rest of the team has to fix their bad code every week. Basically the quality of PM and lower-to-middle management can make life pleasant or utter hell.

Most of the others, maybe difficult, mostly just time consuming, and not the parts the developers are interested in or should be responsible for.
 
2013-10-17 01:56:58 PM  

SlothB77: Tr0mBoNe: That slideshow is my entire job.

yeah, my take from it is 'basically their job'


Same thought.

/as usual, stupid list is stupid
 
2013-10-17 01:57:12 PM  
3. Estimating time to complete tasks

Based on the current requirements ... I estimate this task can take anywhere from 1 hour to 6 months.
 
2013-10-17 01:59:42 PM  

lordargent: 3. Estimating time to complete tasks

Based on the current requirements ... I estimate this task can take anywhere from 1 hour to 6 months.


It really depends on the phase of the moon, doesn't it?
 
2013-10-17 02:00:08 PM  

LesserEvil: Developing applications is part art, part science.

We can apply good policies in writing code, we can manage projects with tools like Microsoft's TFS, we can run analysis tools.

What can't be done without some "art" is designing a useful system. Bad or mediocre designers can sometimes get by with ruthless application of UI guidelines, and heavy reliance on user stories, but it is a reliance on prior art. Designing good applications is often an exercise in creative thinking, no matter how explicit user stories are.

Volumes have been written, trying to frame code development as a pure science, and they ultimately fail. Developers will never be able to honestly give time estimates. Often times, the best solutions for a coding problems will also defy attempts to unit test or apply coding "standards" (also a hard thing for a developer to do - code less efficiently so proper and useful unit tests can be written).


No they don't, nothing defies unit tests. Integration tests on the other hand can be a right biatch. Usually when programmers say they can't unit test what they are really doing is integration testing. For some reason a lot of programmers get those two confused.
 
2013-10-17 02:00:39 PM  
It's hard not coming back to this thread every 10 minutes.
 
2013-10-17 02:01:09 PM  
Strangely absent is "Show up sober".
 
2013-10-17 02:02:15 PM  
Diogenes,

Yes, this is what i deal with daily. many times i have changed code to make it correct, and other apps have exploded.  Boss comes running, "why did it explode?", me "because the code was written by a 3 year old, and now it works as it should."

my middle name should be exception process.

//could be better at commenting. I usually say im going to when its done,  never do.
 
2013-10-17 02:04:42 PM  

Fubini: Cybernetic: The upside of that was that if you had to pick up a piece of code that was written by someone else, it looked exactly the way it would look if you had written it yourself. That actually made the process of getting into a new piece of code and figuring it out significantly easier.

A lot of that is what programmers hate, but what actually makes business work well.

http://en.wikipedia.org/wiki/Capability_Maturity_Model

From a business point of view, it's really nice to be able to make accurate estimates on software development time and cost.


Yes, the business needs that... but that doesn't make it any more possible to correctly estimate how long it will take to do something you've never done before.  Especially if outside influences come into play.  For instance I was pretty close to my estimate on my last big project, then I needed a port opened on a firewall for user testing... at which point the network team decided that no, they can't open that port so we need an entire separate network for that testing.  A month later...
 
2013-10-17 02:04:52 PM  

MethylTryp: Every code I've ever met thinks that every other person's code they come across is terrible and the programmer was an idiot.

I've never once heard a programmer compliment somebody's code.


I've only worked with three people in my career who I thought were actually justifiably good developers. Even if I would have written it a different way, their code always, at least, made sense under the circumstances.

The other several dozen people with whom I've worked directly or have had to direct and review for were hacks. Some of them were not 'bad' devs. But all of them were hacks.

//NEVER use println as a method response without a return.
///seriously wtf
 
2013-10-17 02:06:48 PM  
Pretty good list is pretty good.

I really am terrible at estimating time.  So I start with how long I actually believe a task will require, then double it and increase the time increment.  One hour?  Say two days.
 
2013-10-17 02:07:51 PM  

Fubini: We should also point out the huge gap between "computer programmers" and "software developers".

Something like 90% of the computer code in this country is written by people who are *not* formally trained in programming or computer science. These are primarily people who do programming for business or science, e.g. excel spreadsheets, database scripts, data analysts, scientific modeling and simulation, etc.

We are facing a huge computer education crisis in this country, and I don't mean stuff like Word and Powerpoint. I mean people who are actually doing real honest-to-god programming without really having the training or experience to know what they're doing. We need expert programmers who build reusable and efficient infrastructures for non-programmers or weak programmers, and we need lots of tech-savvy domain experts who can bridge the gap between the expert programmers and the applications domains.

//Just spent a weekend talking to mechanical engineers about software standards


That's because producing software isn't a science, it's a business.   Software makes the most money when it's treated as a disposable product.    There's no more urgency in the industry to produce what you describe as there is an urgency in the automotive business to design a car that last 750,000 miles.
 
2013-10-17 02:07:55 PM  
For as much as I'm biatching in this thread, I have to say I REALLY miss being on projects.  I'm a support manager now.

When I was a consultant, I loved the work but hated my life (100% travel - a younger man's game).  In support I hate the work but like my life.

In support I'm barred from telling my customers, "You could have avoided this situation completely by doing X better."  It's just one sporadic issue or problem after another.  I feel like Newman.  "The mail just keeps coming!"

I need to get back into custom development project work.
 
Displayed 50 of 159 comments


Oldest | « | 1 | 2 | 3 | 4 | » | Newest | Show all


View Voting Results: Smartest and Funniest

This thread is archived, and closed to new comments.

Continue Farking
Submit a Link »
On Twitter






In Other Media


  1. Links are submitted by members of the Fark community.

  2. When community members submit a link, they also write a custom headline for the story.

  3. Other Farkers comment on the links. This is the number of comments. Click here to read them.

  4. Click here to submit a link.

Report