Slashdot Mirror
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?"
I actually agree with that list.
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.
By far the hardest part of my job as a professional software developer is estimating how long a feature will take to develop.
Easy: The hardest thing a programmer has to do is explain why what they're doing isn't a simple matter of programming.
#fuckbeta #iamslashdot #dicemustdie
Apparently where I work, it's documentation. It's so hard, we don't have any.
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.
Their laundry
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.
Deal with clueless management.
Mod me down, my New Earth Global Warmingist friends!
I name all of my classes and variables "George." Problem solved.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
i mine as well tell them that I raise unicorns.
That was hard. I loved that dog.
Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
Deal with people....
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.
Infuriate left and right
There are only two hard problems in Software Development. Naming things, cache invalidation, and off-by-one errors.
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.
Give a hand, not a hand-out.
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.
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.
"Flyin' in just a sweet place,
Never been known to fail..."
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.
to /. about inane flash-based articles when I should be working.
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
"Don't blame me, I voted for Kodos!"
They promise things that can't be accomplished. Ugh.
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...
Why did the chicken cross the road? Because Elon Musk put an AI chip in its head.
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.
Coders have probably spent far more time helping wars, real and simulated, than solving them.
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.
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.
Communicate effectively with less intelligent people
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.
http://www.masturbateforpeace.com/
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.
http://martinfowler.com/bliki/TwoHardThings.html
What Are the Hardest Things Programmers Have To Do?
Dealing with incompetent project managers.
Yet Another Web Site
I would rather write documentation all day long than write tests. Developing a good test suite is hard. (Putting together a crappy set of tests is easy, but of no value). As much as I hate developing a test suite, though, I love having it when it's time to make a release.
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.
When all you have is a hammer, every problem starts to look like a thumb.
From my experience, the hardest thing for a programmer that because code may look weird or ugly is NOT a reason by itself to change it. The only reason to change it is if it is buggy, or does not meet the current requirements.
But some programmers just can't help themselves, dig in with both hands rip the guts out end up breaking everything because they have failed to understand why it was written in that weird ugly way. On the other hands I'm glad they are programmers and not surgeons:)
For me, I think the hardest part is often "figuring out what to build in the first place". Sometimes that starts from a product idea. Sometimes it starts from an imperfect requirements document. (I have never seen a perfect requirements document.) Going from that to "what do I build?" is the hardest part.
If you are the sort of programmer who works on big projects and is handed a clear and unambiguous spec... then sorry, I have absolutely no idea what your hardest problem might be.
Dealing with established cultures working with outdated technologies and trying to drive change.
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...
The 10th hardest thing: Make their shitty javascript heavy site work.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Well, "not going to war" could be considered an excellent solution to conflict
So.. it has come to this
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.
It's hard to develop a strategy when your boss comes running in screaming "The sky is falling" because your biggest competitor just released a new version that adds feature X and you are now tasked with implementing feature X into your product by tomorrow and it has to be on all the install media that has already shipped as well.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
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.
If you need web hosting, you could do worse than here
Does "Posting on Slashdot" come under "Design" or "Development"?
I suppose its better if 100,000 people from each side ran at other with swords until one side is dead?
“You mean, you'll put down your rock and I'll put down my sword and we'll try and kill each other like civilized people?”
They can take my LifeAlert pendant when they pry it from my cold dead fingers.
it makes me happy to see this:
words are our tools...well alpha/numberic symbols arranged in groups to form instructions for a machine to execute
typing a word is the same as 'naming' the thing you are creating when you type...ha! this certainly gets us into a Mobius Strip of language after awhile
as I've learned programming, I've found that 2nd Order Cybernetics concepts to be incredibly helpful
you start with the 'Social Construction of Reality' which has become a convention almost like the Big Bang more than a theory from any one scientist...it is broadly accepted across the Social Sciences
essentially, they idea is: humans communicate meaning and construct our individual brain's concept of the 'universe' based on language
to see what I mean, now dig in to some Cybernetics theory to see how theorists define 'cybernetics'...Norbert Weiner is my favorite
notice the parallels the author draws between controlled and autonomous systems in machines and in nature on the definitions table on page 1
I believe we can push computing languages further by applying these concepts to coding, precisely because they are founded upon and grounded in the truth that you hit upon when you say this:
if we *start* there and continue with a 'cybernetic' approach programming becomes more inviting to noobs, new languages are easier to learn for experience programmers, skills transfer across any system or domain in programming better, and coding starts to resemble network topology
I'm not doing the best job explaining things, cybernetics is a tough concept to just bat around in conversation...but if this interests you have a look at the paper I linked above...the first thing they do is discuss what cybernetics is and why it is useful
its kind of my mission to push computing towards a more cyberntic model and away from a Turing model
Thank you Dave Raggett
I'm surprised nobody's mentioned this. I work on a project that's spread across eight countries. The lingua franca is English, which makes me one of the lucky ones as a native English speaker. As you might guess, it's a pretty big project, so things like push-button refactoring aren't any use when someone misspells a variable name, or inadvertently names something after a swear word or a racial slur. (Or, more to the point, did so in acquired code that's now 12 years old and really shouldn't be touched if it's been working fine, and there's no staff for cosmetic changes anyway.)
People have talked about commenting and documentation. It's that much worse when someone's writing in their third language, or they write in their native language and you hope you can translate it well enough to get what they're really trying to say.
And then you've got all the cultural issues surrounding hierarchy, face and the loss thereof, egos, power, seniority, communication formats, and all that.
I'd love to have the luxury of being the lone cowboy, even if the PHBs were constantly jerking me around about what I'm supposed to be doing.
Don't document what your code does, I can (usually) tell that from reading it. Document why it does what it does.
Hands down, the most difficult thing I've had to do is start a new job. New technologies, new software, new people, new environment, new policies, I'm two weeks into a new job and the anxiety is driving me bonkers. It's more stressful than the worst deadline crunch I've ever experienced... and here there is no deadline here!
It's really quite a simple choice: Life, Death, or Los Angeles.
We were coding with Simulink (diagram based thing). When things get complex you take a group of blocks and group them into a subsystem so you get a hierarchy of block diagrams. Each subsystem displays a name under the box, and everyone tries to give each block a name. People choose names of varying quality, but we had one guy leave the default name on every block "subsystem". To avoid name collisions it adds a counter as a suffix. I expanded the tree-view on the left side of the screen once and was able to fill it top to bottom with "subsystem2" "subsystem3" nested 5 levels deep. There is no way to navigate the code except by looking at the diagrams, but those consist of basic blocks (mostly math operators) and bigger boxes named subsystem. Fortunately some of the signals are labeled.
And of course the guy quit right after delivering this piece of shit to production.
one of the hardest things i do is sit in front of a computer most of the day.
would prefer to be more out and about
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
All right, but apart from thinking like others, not goofing off, pushing back on the schedule, and paying the technical debt, what have the Romans ever done for us?
(Wait, what were we talking about again?)
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
My List:
1. Estimates
2. Legacy code / huge uncommented code
3. Designing the features correctly
4. Over/under designing the code
5. Estimates
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.
I've fallen off your lawn, and I can't get up.