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!

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

Soulskill posted about 10 months ago | from the moderate-their-criticism dept.

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

cancel ×


Sorry! There are no comments related to the filter you selected.

Maths (0)

Anonymous Coward | about 10 months ago | (#45166541)


Re:Maths (5, Insightful)

Jeremiah Cornelius (137) | about 10 months ago | (#45166753)

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.

Re:Maths (-1)

Anonymous Coward | about 10 months ago | (#45166761)

how could you even think about doing this to me?
                                                                                                                    TESTICLE RUSSIAN

Re:Maths (1)

Pino Grigio (2232472) | about 10 months ago | (#45166987)

That's one of them. The other is getting everyone to agree on what to do and how to do it.

Amazing (2, Informative)

Murdoch5 (1563847) | about 10 months ago | (#45166565)

I actually agree with that list.

Solving real world problems (0)

Anonymous Coward | about 10 months ago | (#45166569)

Like poverty, war, hunger. Oh, wait, no we don't solve those.

Re:Solving real world problems (4, Interesting)

SJHillman (1966756) | about 10 months ago | (#45166885)

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

Re:Solving real world problems (0)

Anonymous Coward | about 10 months ago | (#45166921)

I guess that depends are what you consider a solution to conflict.

Two sides of the coin (5, Insightful)

swm (171547) | about 10 months ago | (#45166571)

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 (2, Interesting)

Anonymous Coward | about 10 months ago | (#45166913)

If you have names for everything, you will be able to build a design from there.

You think the inventor of the mouse pad started with the name? What's a "mouse pad"? Sounds like a feminine hygiene product for mice...

Re:Two sides of the coin (1)

JustOK (667959) | about 10 months ago | (#45166955)

At the time, maaaan, like a mouse pad was a groovy place for mice to like hangout and live, you know?

Re:Two sides of the coin (0)

Anonymous Coward | about 10 months ago | (#45167013)

But on the other hand, X was always called X. It is derived from eXpermental window system.

Estimation (5, Insightful)

scottnix (951749) | about 10 months ago | (#45166583)

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 (4, Interesting)

networkzombie (921324) | about 10 months ago | (#45166683)

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 (1)

Cazov (722114) | about 10 months ago | (#45166795)

my coworker increases the time increment (minute becomes hour, hour day, etc) and doubles the value.

Re:Estimation (5, Funny)

bunratty (545641) | about 10 months ago | (#45167053)

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

Re:Estimation (1)

Inzkeeper (767071) | about 10 months ago | (#45167123)

Estimating continues to be the bane of my existence.
But the most lost I every was involved trying to estimate a full database data conversion process from an old non-rdbms system.
"Oh but our data is clean", they said.
I spent over a week just fixing / coding for bad date formats.
I asked a senior guy for advice. He suggested something similar:

Come up with a number. Multiple by an arbitrary single digit. Double it. Double it again.

Eventually I learned not to fix bid data conversion. Ever.

Re:Estimation (1)

Anonymous Coward | about 10 months ago | (#45167131)

Begin with your best estimate of how long the project will take and double it. Add two, and then double it again.

you might also consider adding one and quadrupling it

Re:Estimation (4, Insightful)

phantomfive (622387) | about 10 months ago | (#45166909)

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 (4, Insightful)

chuckinator (2409512) | about 10 months ago | (#45166933)

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 (5, Insightful)

Anonymous Coward | about 10 months ago | (#45166957)

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 (2)

travdaddy (527149) | about 10 months ago | (#45167015)

By far the hardest part of my job as a professional software developer is estimating how long a feature will take to develop.

How much time will that take to estimate?

This whole thing is B.S. (-1)

Anonymous Coward | about 10 months ago | (#45166587)

There's no nobility in it anymore. You just watch some lame (recently promoted) manager take credit for your work while she was crumbling under pressure!

Estimates (1)

Anonymous Coward | about 10 months ago | (#45166591)

Estimates, and filling out my time sheet. The stuff I do doesn't fit into neat little categories that the PMs want (unless they're really vague).

Programmer Troubles (5, Insightful)

girlintraining (1395911) | about 10 months ago | (#45166601)

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 (4, Interesting)

garcia (6573) | about 10 months ago | (#45166847)

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

Re:Programmer Troubles (2)

sconeu (64226) | about 10 months ago | (#45167065)

At least she was aware that it wasn't as easy as it looked... you were ahead of the game.

Documentation (4, Funny)

gabereiser (1662967) | about 10 months ago | (#45166603)

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

Re:Documentation (0)

Anonymous Coward | about 10 months ago | (#45166697)

It's not that it is hard, just not important when compared to getting the code done.
Although good up front documentation will make the coding easier and faster.

Re:Documentation (0)

Anonymous Coward | about 10 months ago | (#45166799)

That invariably comes from management and the bean counters. Despite being counterintuitive, the money people want code yesterday. I've worked in most market sectors as an AP for over twenty years, mostly freelance, and only one site wanted documentation. Everywhere else was man-the-pumps attitude, even with greenfield projects. Even trying to have clients sign off on functional requirements proves futile.

When there has been documentation, it's alway years out of date, never updated, invariably plain wrong, has no ERD et al.

Re:Documentation (4, Insightful)

Archangel Michael (180766) | about 10 months ago | (#45167031)

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. (4, Insightful)

Anonymous Coward | about 10 months ago | (#45166605)

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. (0)

Anonymous Coward | about 10 months ago | (#45166943)

It is more like marketing:

Joe Salesdroid goes and sells Blarfmatic 1.0.2 to a customer, saying that it has this cool feature, XYZ in the next rev.

Well, Blarfmatic has XYZ nowhere in the source tree in any, shape, or form. Joe Salesdroid lied, and now two things are going to happen, the sale gets lost or some programmer writes the feature, however buggy, to be in the program.

Since Joe Salesdroid is in the golf foursome with the CxOs and the lead devs are not, it is almost certain which way this is going to go. Obviously the next things that will happen is that said feature which gets coded up by an unmeetable deadline has flaws in it, support gets hammered hard, which causes dev to get hammered hard by both support and the marketing people.

Moral of the story: Management is the career path to take, or perhaps it isn't too late to hit law school (no such thing as an unemployed lawyer) and be on that golf foursome with a reserved tee time.

Re:Making users happy. (1)

Archangel Michael (180766) | about 10 months ago | (#45167071)

I call this "pick a lane".

This is also a place where customizations settings can come from. If you design well, your design becomes more flexible, and users will start using things in ways that you couldn't imagine before starting the project.

Documentation (0)

Anonymous Coward | about 10 months ago | (#45166607)

Documentation. In particular, the kind you know nobody will read. They have to have binders of documentation to show the acquiring company though. They won't read it. They'll just look at the size and number of binders. An equal candidate for first place is estimates. I kept having to tell people that it's not like laying pipe. There are no standard estimates. It's like they want you to lie to them. The whole thing has no purpose other than to put the programmer on the spot. If your estimate is too long they push back. If it's too short, they have what they want--a reason to blame you. OK, yep. It's estimates. Much worse than documentation.

Reading other people's crappy code is bad too; but nowhere near as bad as PHB shit like estimates and docs that you know won't be read.

Their laundry (3, Funny)

Anonymous Coward | about 10 months ago | (#45166619)

Their laundry

Understand existing code (4, Insightful)

Anonymous Coward | about 10 months ago | (#45166625)

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.

The hardest part? (0)

Anonymous Coward | about 10 months ago | (#45166627)

Explaining my work to laymen

PCLoad Letter? WTF does that mean? (3)

binarylarry (1338699) | about 10 months ago | (#45166629)

Deal with clueless management.

Re:PCLoad Letter? WTF does that mean? (1)

tutufan (2857787) | about 10 months ago | (#45166977)

This might sound like a wisecrack, but it is in fact the answer. You can be a Michaelangelo of programming, but if your boss comes in and tells you that from now on everyone will be using six-letter variables names, programming in Visual Basic, and using nothing but Perforce for version control, the quality and power of your results will be so-limited. Some people imagine that a really good programmer can overcome any set of such constraints, but it's easy to see that that's not the case.

Answering questions on Slashdot (0)

Anonymous Coward | about 10 months ago | (#45166637)

The hardest part of my day is coming up with pithy replies to 'Ask Slashdot' questions.
So, like, is this meta or what?

Second to estimation (1)

scottnix (951749) | about 10 months ago | (#45166643)

A distant second to development time estimation is when I'm working for a place that requires class and or worse, pseudo code level design. I would almost always rather do a functional spec or similar higher level design then just start cranking out code, making changes as needed.

Easy solution. (4, Funny)

aardvarkjoe (156801) | about 10 months ago | (#45166655)

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

Re:Easy solution. (1)

brainboyz (114458) | about 10 months ago | (#45166713)

You must've gone to the same school my coworker did. He names everything "My".

Re:Easy solution. (0)

Anonymous Coward | about 10 months ago | (#45166899)

I most likely had to do with starting with Perl as their first language.

Re:Easy solution. (3, Funny)

Hatta (162192) | about 10 months ago | (#45166901)

Ah, a perl user. my $my;

Re:Easy solution. (0)

Anonymous Coward | about 10 months ago | (#45167007)

So he's the guy who came up with that "My Computer," "My Documents," "My Pictures" crap? Slap him for me!

I worked with a programmer who learned the "correct" way to label those iterators was:

foreach (listItem as anItem) ...because it supposedly makes the code more "English-like." I pointed out to him that you never say "hand me that anItem"!

Re:Easy solution. (1)

nschubach (922175) | about 10 months ago | (#45167117)

He doesn't name it that way. He copy pastes it from a tutorial site...

Re:Easy solution. (2, Funny)

Anonymous Coward | about 10 months ago | (#45166871)

And your namespace is "Jungle", right?

explaining to others what i do (2)

kcmastrpc (2818817) | about 10 months ago | (#45166657)

i mine as well tell them that I raise unicorns.

Re:explaining to others what i do (4, Interesting)

SJHillman (1966756) | about 10 months ago | (#45167045)

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.

Management (0)

Anonymous Coward | about 10 months ago | (#45166677)

Having to work on things like "Independent Development Plans", or touchie feelie things like personal objectives.

I had to put down my 15 year-old dog. (5, Funny)

kumanopuusan (698669) | about 10 months ago | (#45166699)

That was hard. I loved that dog.

Re:I had to put down my 15 year-old dog. (1)

jbeaupre (752124) | about 10 months ago | (#45166729)

Next time use a Python script.

Re:I had to put down my 15 year-old dog. (0)

Anonymous Coward | about 10 months ago | (#45167051)

Emacs has a macro for that

Re:I had to put down my 15 year-old dog. (0)

Anonymous Coward | about 10 months ago | (#45167095)

Or an actual python.

People (2)

CnlPepper (140772) | about 10 months ago | (#45166701)

Deal with people....

Re:People (4, Insightful)

CnlPepper (140772) | about 10 months ago | (#45166715)

...particularly physicists who think they can code.

Re:People (0)

Anonymous Coward | about 10 months ago | (#45166853)

Agreed. Dealing with people is the single most difficult thing about my job (which consists of database programming, system adminstration, and tech support), and consequently, the reason why I've gone absolutely nowhere after 15 years of a "career" (in terms of both respect AND compensation). The one thing I'm proud of is that I've learned a shitload in that 15 years, even if I have nothing to show for it.

Re:People (1)

EmagGeek (574360) | about 10 months ago | (#45166949)

That's why you give the "dealing with people" job to Tom Smykowski.

Marketing, product managers (2)

A nonymous Coward (7548) | about 10 months ago | (#45166703)

It's the clueless marketing and product spec types who don't have a clue how computers work, don't have even the most superficial knowledge of how the current systems work, can't decipher what customers say they want, and write product specs which are so devoid of reality as to soak up more time straightening out than everything else combined.

Naming Conventions (1)

sfm (195458) | about 10 months ago | (#45166845)

I often find myself in conflict:

Short, easy to type, but possibly ambiguous names
Clear detailed names in 26+ characters

The choice depends on the audience I believe will be reading, and if I am having a good/bad day

Say No (1)

colonel landers (1321743) | about 10 months ago | (#45166705)

I get more requests than I can physically accomplish. Usually requests come from higher ups or people that really need something to make their jobs easier. I'd like to help everyone, but keeping up is impossible.

only two hard problems (2, Funny)

Anonymous Coward | about 10 months ago | (#45166721)

There are only two hard problems in Software Development. Naming things, cache invalidation, and off-by-one errors.

Testing and Rollout (1)

IronAmbassador (2008886) | about 10 months ago | (#45166733)

The hardest thing i do on a daily basis is testing my code properly so that it won't break any of the 100 or so applications that it interacts with, any of which may also have change and impacted how they interact with my application.

Users... (3, Insightful)

cmeans (81143) | about 10 months ago | (#45166737)

And their ever changing specifications, indecisiveness, lack of comprehension of the time it takes to implement, then re-implement something, and their general reluctance to pay once it's done.

Time Estimations (5, Insightful)

Anonymous Coward | about 10 months ago | (#45166739)

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 (4, Interesting)

phantomfive (622387) | about 10 months ago | (#45166837)

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.

following a changing spec list (4, Informative)

bugnuts (94678) | about 10 months ago | (#45166771)

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:following a changing spec list (1)

careysb (566113) | about 10 months ago | (#45166883)

+1. My last place was so ridiculous in this regard that I decided to take early retirement.

The hardest thing is not posting snarky comments (2)

paramour (110003) | about 10 months ago | (#45166781)

to /. about inane flash-based articles when I should be working.

Deployment logistics (2)

curunir (98273) | about 10 months ago | (#45166789)

The hardest thing for me is that there are so many different environments and the code needs to work in all of them. There's integrated dev, qa, staging, end-to-end testing and production and each of them are subtly different. When deploying code, the logistics around how to get it to the right place at the right time in a working state can be really hard. A simple Google search for branching strategies will show that there's numerous ideas on the best way to shepherd a team through the code freeze, regression, deploy and MR phases.

Things get even more complex in an elastic environment where you have to autoscale. A simple call to a database can then require service discovery, master election and a whole host of other technologies/techniques that adapt to the fluid conditions of an elastic environment.

So from a code perspective, you always have to built abstract interfaces to non-specific infrastructure. A simple file loading turns into loading a URI that loads via the proper strategy (file://, s3:// or even something custom that reads from a db). A caching layer may be distributed in production and a simple in-memory hash in development, so that has to be abstracted too. Making sure your db queries are performant can also be difficult when your local database is nowhere near the scale that exists in production.

We've had some limited success using vagrant/chef for development environments to make them more similar to the downstream environments (i.e. developers actually run multiple VMs with individual functions as we have in our prod environment), but there's a limit to how much you can run on an individual machine.

Naming is the easy...just get a thesaurus and understand that it's important. Though it does remind me of one of my favorite quotes about software development (credit to whoever said it originally...I'm too lazy to look it up):

Half of programming is naming; half is figuring out responsibility boundaries; and half is rewriting because you named your god-object wrong

Designing things (1)

sigmabody (1099541) | about 10 months ago | (#45166791)

I agree with the list, generally-speaking.

I would expand on the designing things point: it's not just matching requirements with implementation, but also designing something which will still work 10 years and 20+ design and technology iterations from now. It's designing something to anticipate future changes, and code in flexibility where appropriate. It's making something which doesn't just perform the function, but doesn't have subtle flaws which will cause very hard to diagnose issues down the road. It's building code which will still be maintainable, even after various future iterations. The ability to design code properly is what differentiates between a "normal" developer, and and extraordinary one.

IMHO, anyway.

Re:Designing things (1)

darkwing_bmf (178021) | about 10 months ago | (#45167041)

The key thing I've found that helps with all of those things (though certainly not completely) is taking the extra time to drive a requirement/design/implementation down to it's essential elements and separating the high level logic from the low level implementation details. Reducing complexity today while still meeting the design goals will pay dividends down the road.

Fight with Sales (2)

darrellg1 (969068) | about 10 months ago | (#45166793)

They promise things that can't be accomplished. Ugh.

Copy paste the list please (0)

Anonymous Coward | about 10 months ago | (#45166801)

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

GPU Programming is a PITA (2)

dryriver (1010635) | about 10 months ago | (#45166807)

I'm still trying to find a way to use the GPU for computations without having to jump through crazy hoops to do it. Also, multithreading in general is often a PITA to get right...

Electrical Engineers (0)

Anonymous Coward | about 10 months ago | (#45166841)

I'm a firmware developer. For me, I'd say it's explaining to electrical engineers and managers from electrical backgrounds that tasks aren't quite as simple as they say.

"Oh, just read this register", they say, "It's easy, I can do it from U-Boot".... In Linux, this is not super hard, but it's not trivial either, because you can't generally simply do it from user space. That's just one example.

Preventing feature overflow (1)

EmperorOfCanada (1332175) | about 10 months ago | (#45166861)

Preventing a steady rain of feature requests that vastly exceed the development capacity. Often these features will take longer in programming time than the time they will save.

Another hard one is to use an older programming technology when you have been using a far newer one for some time.

Working on boring projects (3, Insightful)

CQDX (2720013) | about 10 months ago | (#45166863)

Most of the other issues don't bother me if the project is really cool. Plus with my productivity ramped up management tends to stay out my way. OTH, with boring project, everything on the list is 10x more painful. Unfortunately, for the typical programmer, their entire life is spent working on the former.

Build systems. (0)

Anonymous Coward | about 10 months ago | (#45166887)

The code is the easy part. Compiling from a wide array of libraries on different embedded hardware is not a trivial undertaking and no every programmer is capable of doing it.

Unit Testing (1)

BlueMonk (101716) | about 10 months ago | (#45166893)

Testing is often the hardest part of writing any feature or fix because often times it takes a relatively long time to set up an environment and a test scenario. It's also particularly difficult to narrow down a problem to its source when integrating with software for which no source code is available and support is sketchy. I've seen problems in Microsoft and SAP software that take a long time to work out and sometimes leave me SOL.

Naming things (0)

Anonymous Coward | about 10 months ago | (#45166903)

Naming things is the single most hardest thing humans have to do....

6 months to figure out a name for our unborn.....

3 hours making up a cool name for Skyrim character, instead of playing the damn game. .....

Getting requirements that conflict. (5, Insightful)

darkwing_bmf (178021) | about 10 months ago | (#45166911)

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:Getting requirements that conflict. (0)

Anonymous Coward | about 10 months ago | (#45167115)

This. Nothing in programming is as difficult or important as when you have to take mutually exclusive requirements from two different people - or sometimes just one person - figure out what it is they really need, and convince them that yours is the right solution. Users generally come to you with a solution instead of outlining the problem, and they tend to have really stupid ideas for what constitutes the correct solution.

Looking at this from the wrong direction (1)

roc97007 (608802) | about 10 months ago | (#45166915)

Math? Math is fun. Naming things? Very entertaining. Designing a complicated algorithm? It's what I live for.

Had you asked me twenty years ago what was the hardest thing about programming, I'd say, interfacing with non-technical management, for a variety of reasons.

As me today, and I'd say offshore infrastructure admin. Doing my job is fun. Somehow convincing someone else with few communication skills and little training to do their job so I can do mine, that's probably the hardest part today.

Not the answer you may be looking for, but the difficulty of the problem at hand is generally under your control. A balky environment managed by an undertrained call center is not. That's where the real pain originates.

WTFM. (1)

jzu (74789) | about 10 months ago | (#45166917)

Nothing is harder.

iCloud (0)

Porkwich (2958199) | about 10 months ago | (#45166919)

For the love of fuck, anything involving iCloud.

This one's easy (0)

Anonymous Coward | about 10 months ago | (#45166931)

The number one most difficult thing for developers to do is to act like civilized adults who are members of a team of people concerned with the success of the team as a whole instead of just themselves.

Work with bad programmers (2, Insightful)

Anonymous Coward | about 10 months ago | (#45166971)

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:Work with bad programmers (0)

Anonymous Coward | about 10 months ago | (#45167127)

I feel this. I recently re-wrote something that was 3000 lines, a dozen files, didn't make a scrap of sense, crashed randomly, used too much memory, and used horrible practice and naming everywhere, and exposed dozens of API functions when it should have been 2 or 3. (think separate functions for setLED1(state), setLED2(state), etc.)

My solution used no memory allocation other than a few bytes on the stack, was less than 300 lines, and my co-workers could actually understand it.

This was a process which was responsible for blinking LEDs. I am not fucking kidding.

Communicate effectively (2)

thatDBA (2626877) | about 10 months ago | (#45166973)

Communicate effectively with less intelligent people

Where did it go? (1)

SuperKendall (25149) | about 10 months ago | (#45167035)

Nowhere on the list did I see cache invalidation [] . What gives?

I guess it's the third item on the list at work, only the other way.

People (0)

Anonymous Coward | about 10 months ago | (#45167037)

The single hardest thing to do:
    Interface with people and manage their expectations

Dealing with reality... (3, Insightful)

jasno (124830) | about 10 months ago | (#45167059)

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.

2 hard things in comp science (2)

Aviancer (645528) | about 10 months ago | (#45167091)

This was eloquently described by Phil Karlton, and extended by Martin Fowler:

There are only 2 hard things in computer science: Cache invalidation, the naming of things, and off-by-one errors. []

Data Structures and Algorithms (0)

Anonymous Coward | about 10 months ago | (#45167103)

Choosing the best data structure to represent a problem and the best algorithm to manipulate it. In OOP, defining the best set of classes to do the job.

The hardest thing? (1)

DJCouchyCouch (622482) | about 10 months ago | (#45167113)

Getting up in the morning.

Hardest thing a programmer has to do is ... (1)

vivek7006 (585218) | about 10 months ago | (#45167133)

Find a mate and procreate

Idiots (-1)

Anonymous Coward | about 10 months ago | (#45167139)

The hardest thing is having to deal with idiots who think C#, Java, Ruby, Python, et. al. are real programming languages.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

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>