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?"
Maths
I actually agree with that list.
Like poverty, war, hunger. Oh, wait, no we don't solve those.
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.
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).
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.
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
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.
Explaining my work to laymen
Deal with clueless management.
Mod me down, my New Earth Global Warmingist friends!
The hardest part of my day is coming up with pithy replies to 'Ask Slashdot' questions.
So, like, is this meta or what?
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.
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.
Having to work on things like "Independent Development Plans", or touchie feelie things like personal objectives.
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
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.
There are only two hard problems in Software Development. Naming things, cache invalidation, and off-by-one errors.
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.
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.
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!"
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.
They promise things that can't be accomplished. Ugh.
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...
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.
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.
I often find myself in conflict:
Short, easy to type, but possibly ambiguous names
-or-
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
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.
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.
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.
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 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. .....
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.
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.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Nothing is harder.
For the love of fuck, anything involving iCloud.
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.
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
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The single hardest thing to do:
Interface with people and manage their expectations
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
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.
Getting up in the morning.
Find a mate and procreate
Hardest: understanding the actual requirements, fairly often the first part of that is distinguishing clients' (management, other departments, customers, whatever) proposed resolutions to situations they as a rule neglect to describe from the actual situations and the resulting problems that need solving.
Next hardest: naming is the easily-describable part of it, a prerequisite but not the purpose. What it boils down to is making it worthwhile to read the code, to follow the "if you can't teach it, you don't understand it" rule and not waste people's time.
After that, the stuff you can learn by ordinary study.
As always, all IMO. Insert "I think" everywhere grammatically possible.
What Are the Hardest Things Programmers Have To Do?
Dealing with incompetent project managers.
Yet Another Web Site
What is the hardest thing "coders" have to do? Based on the evidence that I have seen, over more than 20 years?
Find and keep a girlfriend.
Getting the proper requirements from people.
There are only two hard things in Computer Science: cache invalidation, naming things and off by one errors.
The hardest thing for programmers to do?
1)Remember that not everyone has a super super fast computer with tons of ram.
2)Remember not everyone is or should be Administrator on their computer.
1. Enumeration.
......
Wait. Strike that. Make it:
0. Enumeration.
Have gnu, will travel.
Hardest thing programmers have to do is to get a girlfriend. :P
Programming is a piece of cake. This is the reason why I do it rather than automotive repair or electronics technician, cable tv installer or any other labor intensive job.
The two hardest things to do every day, wake up and get out of bed. The rest of my day is just gravy.
Pretending I am doing something or look like I am doing something, with my head propped up on my hand with my arm on the desk, sleeping. That is tough to do.
If I need to stretch out a project, killing time, hiding in various peoples offices, having to sneak back in after a 2 hour or more lunch, pretending to be interested in meetings that have nothing to do with my project, to kill more time, are all tough to do.
If a clueless middle manager give you and your staff a month to complete a project and you know you and your team can do it in a week and a half, why tell him any different. Turn it over to QA 2 days early and look like a hero.
So, I would say killing time is the hardest thing to do.
Hardest thing for a programmer?
On Windows: Getting other people's shit to actually compile without spending hours fixing things.
Everywhere: Keeping things organized well. Even if you think you've planned ahead, there will be roadblocks that cause you to either rewrite huge chunks or slap something in wherever you can fit it.
Please a Marketing department.
--- Always remember. 99.36% of all statistics are inaccurate.
Who can talk to the customers /and/ the developers!
And get someone who can install a working printer.
And not waste time on Slashdot all day.
The technical stuff is all doable. Politics, management, etc. -- those are hard. Best part of the job is getting that stuff out of the way and designing/coding.
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.
The hardest part of being a Software Engineer is making management understand how valuable you are and making them assign to you interesting work.
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.
Comment removed based on user account deletion
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.
I think i speak for many, the hardest thing about my job is the expectation that i will work late or overtime without extra pay or work over family holidays such as christmas and the like.
Electronic Music Made Using Linux http://soundcloud.com/polyp
Dealing with established cultures working with outdated technologies and trying to drive change.
These things are not hard as in O(e^N) hard, and you won't learn about them in your CS class. But you have to deal with them every day in real world
Add "not using a slideshow" to that list.
Using the new TPS reports, this is by far the hardest task a programmer must do.
The hardest part is spending 6 to 8 weeks developing systems that someone decided were urgent and good to go, only to have them say "burn all the documentation we're redoing this from scratch".
When the issues were ones I pointed out were going to be there before this whole thing started.
After a while though, my Army days come back, and I remember nobody's shooting at me, so it's all good.
-- Tigger warning: This post may contain tiggers! --
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.
Having a conversation with a female is the most difficult thing your average programmer will ever have to do.
... was the hardest thing for me today. Is there any reason that Ghostery finds 16 various advertising and tracking widgets to block that apparently are required for the page to load? Also, why would you put a list of 16 items in a slideshow? Just to buck up advertising revenue for multiple page views?
I'll just guess what's on the list, and say it's 80% right, but that the hardest thing altogether for me is getting decent requirements from end users. Right after that it's explaining why is not only not Agile, but often not helpful by itself.
Last, and this is an ever present distraction for me, is to explain to some folks the definition of "priority" and why the phrase becomes meaningless once you have two or more #1 priorities for an individual.
(Btw, I did find a 'deslider' site, for example, this article can be 'deslided' here: http://deslide.clusterfake.net/?o=html_table&u=http%3A%2F%2Fwww.itworld.com%2Fslideshow%2F124383%2Farg-9-hardest-things-programmers-have-do-378834 )
Hence this post.
As a programmer, I've learned by long experience debugging to know exactly what I do and I do not actually know about the problem. And refreshingly but frustratingly, there is absolutely no bullshitting a computer. There is a distinct moment where you understand the issue well enough to solve it, and before that, you are just guessing or testing to find more facts about the situation. It's like doing science, properly.
It dismays me how little of real world human communication and problem solving is like this. Most people think and state that they know what's what about situations or problems, when most times, they simply haven't put the cognitive work in, and they actually don't know what they're talking about or they're chasing a red herring.
Diagnosing the content and likely better path in for example political debates, using debugging-quality logic and investigative method, is truly, truly painful. We're basically usually like a pack of chittering chimpanzees on these sorts of things.
So it's hard that programming has made me cast a baleful and profoundly skeptical eye on most other stuff I hear people discussing or asserting.
Do you know that? Are you sure? How confident are you, rationally? How good is your overall model of the situation? Then why the hell are you talking?
And answer this silly questions! also understand the client needs and make them look like what he wants....
So click that link, and it wants me to sign in to view answers? With my Facebook account? Holy shit, Experts Exchange came back from the dead! (And if you happen to do it on mobile, they'll also nag you to install their app.)
It's like someone took Stack Overflow and decided to add 100% more crap.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
I'm a developer and I would put this up as the hardest thing I have to do. Since I know the guts of why and how something works, I tend to have a really hard time writing particularly helpful User Manuals to other people. There is no group within us that spends time writing manuals (so I have to do my own) and it does require me throwing the manual at somebody somewhat unsuspecting and hoping it makes sense to them.
For those who seek perfection there can be no rest on this side of the grave.
Staying Focused. Anyone after years of programming is going to start getting pretty bored if your doing the same thing everyday. I think working bits on tons of projects and being able to stop and goto a new project when your bored would be more productive than having to sit there day after day staring at the same blocks of code.
Good Documentation is a bitch for any large project. As a developer things are frequently changing and being upgraded, you can usually add a bunch of features faster than you can write good descriptive documentation for the features explaining them in a way the average person will understand.
Race bugs are a nightmare, like ones where no matter what you do you cant seem to reproduce a bug that someone insists is there, or the ones where its some client thats running a setup nobody else does (or a really old setup) and you have to get the same features working.
Interpreting Client feedback/bugs/tickets/etc into something useful , most people are actually as stupid as humanly possible when it comes to using software they are not familiar with (despite most software all having common structures and layouts that should allow anybody to sit down and instantly know how to at least navigate a program and figure things out on your own)
Replacing or Removing features you spent a ton of time working on. For example spending a months working on a new feature Boss A requested, getting all the bugs worked out, tweaking that interface so it just screams sexy, and then Boss B tells you to remove it he doesnt like it or to replace it or redesign it his way , UGH
What's more real: the Bitcoins that you mine or the unicorns that you claim to raise?
People are the best part of my job...and the worst. Technical challenges can be a real PITA but they don't even come close to comparing to the difficulty of people challenges. And of those challenges, communicating clearly with people is perhaps the most difficult part of my job on a daily basis. (The second is dealing with "problem people", who have some kind of personality issue that makes them difficult to work with.)
How many times have you heard someone start a sentence with "I thought what you meant was..." or "I thought you knew..." or something similar. Or said the same yourself. Communication is hard, and if you think otherwise you probably don't realize how many assumptions are being made on both sides when you talk to people.
The other hardest thing is getting a story (requirement) to "done done". Writing unit tests and getting them to pass is easy. The hard part is making sure I update the design document, project wiki, and deployment doc; that I check the license agreement for the library/framework I just downloaded; that I don't have SQL injection problems; that I've added system tests; .... Of course having a checklist helps.
It all depends on the specific programmer. Some are good a design, some are good at coding, some are good at testing, some are good at debugging, and so on. Rarely is a single person good at everything. Everyone has they own unique strengths and weaknesses.
expects the Spanish inquisition
if i had to pick one it would be dealing with clueless managers.
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
You can only keeping a system maintainable by managing complexity. You can only manage complexity by laying solid foundations. Solid foundations require a solid architecture. A solid architecture anticipates future functionality. It's difficult to make predictions - especially about the future.
1) Naming things
2) Cache invalidation
3) off by one errors
Convince fellow programmers that it does not mean that if they can't do it, it is impossible. Then once I proved them wrong, they go and find faults with every little detail of the code like :
The naming convention is not correct
The code is not self explanatory
Add more Factories
Connection pool that thing etc
So I just showed you how to save a lot of hours by doing it my way, the least you can do is to help me improve it and not find faults. Just because I proved you wrong does not make you stupid and me smarter, it's just that for that particular module I have a better idea than you.
Not just revision control... that's not terrible. But trying to stage features/check-ins, etc so that they all line up with the release planning goo, etc.
I simply don't use it unless absolutely necessary because some fool did in a linked runtime library library; but only then to identify it as foreign cruft.
Fuck Charles Simonyi. Anyone who does use it is a shit-for-brains M$ droid. And I ALWAYS use integer variables i,j,k,and l for loop counters in the traditional Fortran way.
Maybe that's where the notion of a true name comes from.
Whenever I find myself having trouble naming a class or a method/function, it's typically a sign that something in my understanding of the problem (or the framing of the solution) is wrong. And I need to revisit the thought process that took me there. Usually, once I do so, names fall in place without much friction.
First off, let's define "hard". You could mean
a) absolutely hard: it takes lots of effort to make this work at all
b) hard to do well: it takes lots of effort to do this well even though I can do this somewhat acceptably with minimal effort
c) time consuming: this takes a lot of f-ing time, and it's unclear that the effort justifies the benefit
a) seems like the most appropriate definition, but judging by the list they seem to mean either b or c.
9. Designing a solution :
b. I can make you some working software based on your off-the-cuff requirements pretty easily. Anticipating what you really meant, what you will ask for next, and writing code that can be easily leveraged to do those things would be 'a'.
8. Writing tests
c. For small projects, automated testing way more time than it's worth. For large projects writing tests is the only way to make it work at all. Of course, all those medium sized projects and those projects that start small but may become large are a challenge. And weather or not the software lends itself and the programming team knows how to use a testing suites make a difference.
7. Writing documentation /ever/ reads documentation because we all learn the hard way that it's perpetually out of date. The UI and API /are/ the documentation. If, by "writing documentation" you mean "designing a good UI/API" that makes it obvious to the user what's going on, then this becomes 'a'.
c. No one
6. Implementing functionality you disagree with /., so I guess that's all of us.
WTF - If you're getting paid, do what you're told. If not, tell 'em to do it themselves. This is only "hard" in any sense if you're a pedantic a-hole. Oh, wait. This is
5. Working with someone else’s code
b - But if they instead had "writing code that isn't a PITA for others to work with", then it's an 'a'.
4. Dealing with other people
That's only because: http://www.dilbert.com/2013-10-10/
But I guess if we spent any time developing our social skills, we wouldn't have had time to learn how to program.
3. Estimating time to complete tasks
Okay, this one really is 'a'. On the other hand, you just shouldn't do this. Instead, you need to get good at getting customers/users on board with iterative development where they wait/pay a bit and get some incremental functionality as you work towards some end goal that neither of you can really predict up front.
2. Explaining what I do (or don’t do)
See #3.
1. Naming things
See #5. Naming things is easy. And my names make perfect sense to me.
Also, queue the penis jokes based on my use of the word "hard" in the subject.
The deadliest words ever spoken in IT: "All You Have To Do Is..."
It's compounded by the fact that they're not only spoken by clueless users and pointy-haired bosses, but by the software people themselves. Who should have learned better at some point.
One of the most perverse things I've discovered over the years is the parts of the project that incur the bulk of the time, pain, and suffering aren't the arcane complex gnarly things. They're almost always easier and less trouble than expected. But entire days can be lost on something as simple as a misplaced comma.
Years ago I was on a embeded proj for a process control instrument that would handle a variety of parameters, pH, temperature, etc depending on what the customer wanted. Each parameter would have its own module. I remember sitting in a meeting when our boss, a genius no less, told us each module should take about a week to code. 6 months later the first one was done. And it was a tough, nose to the grindstone 6 months.
People.
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.
If I had to deal with fleshy bugs, I would think programming were especially hard too.
Also, missing from the list: managing multiple projects. The "one interruption costs 20 minutes" is BS. Brief interruptions have little effect. The problem is the weeks-long "interruption" to work on a temporary emergency priority, and then afterward going back to the first project having to rebuild all the mental structures in your mind. Compounding the problem is that during the mental rebuild process, interruptions do hamper it during that time. Interruptions are like wind. The stronger and more established the mental structures, the more resilient they are against the wind. Even though mental rebuilds are a fragile time, still the fragility is overestimated and so it becomes the fear of interruption (interruptions are more painful than destructive) that leads to procrastination and delay -- worse than the interruptions themselves.
And that's not getting into the multiple project issue of dealing with multiple bosses in a non-linear org chart. I suppose that might fall under the overly broad "4. Dealing with other people."
I've been a programmer/aka software engineer/aka web developer/aka IT Director for 39 years and the hardest thing that programmers have to deal with are changing expectations which manifest themselves in scope creep and scope creeps (i.e. users who don't really know what they want or need but they need it like yesterday). I think Agile techniques have helped to channel this quite a bit but that requires the right corporate culture to be successful. The truth is that computational tools are still "magic boxes" to users and it's a rare project manager/agile team that can bridge the gap between the effort required in implementation and the user's perception of what they really need.
Be More, Be Manly, The Manly Geek Ubergeek Extraordinaire Blogger: www.manlygeek.com/blog Podcaster: podcast.man
It's naming things. Trying to keep in line with naming conventions that often conflict since you use multiple languages all with their own idea of how to capitalize, plurality / singularity, and libraries that pay heed to no man. Fuck yeh, naming is the hardest part.
Shut up and do your job.
Don't document what your code does, I can (usually) tell that from reading it. Document why it does what it does.
End of message.
apparently
Constantly educate them how much work something will be every time they request a new feature. Sometimes they are surprised at how easy things can be done and vice versa.
Explain that the software hasn't changed, so it's not likely to be a software problem.
No, writing a new device driver will not fix a broken input device sending thousands of spurious signals per second and no I will not write one 10 minutes before the device is due to be put on a van to be sent to the customer.
No, it's not "just typing." It has to be designed, implemented and tested. Just because it compiles I will not ship it to the customer.
Use Windows for real work. It's broken. Things that take minutes on a real OS take days or weeks on Windows, and 50% of that is getting fighting with license servers, virus checkers, broken user permissions and missing packages.
Using SAP for configuration control. It's broken by design. Why does it take weeks to do anything with SAP? Why does it go out to lunch for several minutes when you type a value in a box? Why does it randomly forget things you've entered? Why is the UI so crazy?
Fight with documentation in PowerPoint, Excel and Word formats. We have cross-platform tools and open documents for that sort of thing. Why should I have to go hunting on the Windows network for a file in a proprietary format to tell me what versions of things go into a package? Why isn't it in a plain text file in git or on a wiki?
No, I will not fix your broken Windows. Stop it. Buy a real computer and learn to use it.
No, it doesn't run on Windows. Life's too short.
Fight with libraries written in C++ and build scripts written in DOS batch files. Seriously, get with the 1990s.
Visual Basic, C# and .NET applications for configuring kit which can only be developed on WIndows and run under Windows. Oh, what do you mean that version of the development platform and evironment isn't supported any more? Do we have a license for it? Oh, it doesn't run? The environment, the platform or the app? Oh all of them? How much for a new license? Oh you can't get one any more? Right.
Stick Men
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.
Number 1 hardest thing to do... Keeping my job from going to Indians or Chinese that are advertising that they can do it for a fraction of the price. Well, once they get back to their native country after they have been here on their H1-B and stolen my job. Doesn't matter that the quality will be lower. It's cheaper.
The hardest thing is keeping myself from choking the living shit out of some corporate manager who desparately needs it due to changing the requirements every other day or so.
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.
In my experience the most difficult thing to do is to deal with people that have no idea about programming. Many of these so called "business users" are constantly changing their minds. The functional design documents (the documents that describe what the business need is for the program you are being asked to write) are almost universally incomplete. As I read through them I am forced to go back for clarification. The missing details are often critical to the programming approach taken so they must be resolved, otherwise I will have to rewrite sections later on.
I used to think these business people were just stupid. Now I think they are just lazy. They don't do the necessary research and just kick the can down the road to the developer. Unfortunately, these people are often in charge so it becomes a fact of life.
Nobody has requirements. What they have is problems, and it's the engineers job to build something that solves those problems. They may be able to offer some requirements or offer an idea what they want it to look like. The only way they have complete knowledge of what they want is when they already have it - when it's complete. It drives me insane when people put together a development process that shows requirements being complete at the start, or they show the "V" model of development and forget that a big circular arrow goes in the middle showing iteration (this is never accounted for in the schedule because it can't be).
If you expect complete requirements you don't fully understand your job.
when asking "What's the hardest part of your job?", I suppose that's the origin of the "Jeepers Creepers" movies. If they want, give the scarecrows good wireless and at least they could be playing all day, instead of not doing what you want.
No one will ever see this comment, I'm too late and it will be buried, but as a PROFESSIONAL software developer, I want to do things right, and build a solid code base. The trend now is to slop any kind of mess together as long as it works and just let it rot, as long as it it CHEAP. All that matters is cheap. Developers are "resources" who can't even have a career any more because the only jobs left are lowball paying jobs. I take great pride in my ability to construct robust, working, maintainable code - and it's something no one wants any longer. The downfall of civilization will be the rotting mess of code we're going to have in 10 years when people making $32k/year slop things together that barely work - all this code is going to collapse. We've already seen a hint of it with the Obamacare web site - that web site is like the software version of a bridge collapsing telling you your physical infrastructure is rotting.
For me, the hardest thing has been making users actually like and enjoy using your code. There is a lot of psychological science that goes into a program's usability, and my computer science degree didn't touch that topic.
NO the hardest thing to do is watch non-techy business TWATS overrule you on naming things, misapply standards and turn a perfectly good piece of code into something you're ashamed to have your name attached to. But hey they own the business so it's their decision. What other fucking industry do we do this in? You don't let the patient decide which surgical cut or stitch to use in a heart operation. You don't let someone who wants to build a home decide actually you to tell an architect or builder "actually we didn't want that fucking foundation, let's just leave it out".
This must be the end of the world.
This does not compute.
Hardest thing to do - not knowing what to do when you don't see a xkcd link after 300 comments in slashdot.
followed by documentation
Hardest part is running 16 bit software on Windows 7. Had to use a virtual machine to install Dos 6, Windows 3.1 and Windows 98. I'm not kidding. Visual C++ 1 and Visual Basic 4 to write old software.
i must be the only person who still uses old 16 bit software that runs on old versions of Dos and Windows. lol
Please don't tell me to download Visual Studio 2012 express or Mono. :p just kidding.
Talk to girls.
I 1st read that and thought:
"What Are the Hardest Things Programmers Have To Do? "
Hmmm... get a date?
Some would say: "Get a date."
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.
Some hard things seem easy to outsiders, and some easy things seem hard. When reality doesn't match up to preconceived notions, then tensions can often build and trust ruined. Us geeks often are not well adapted to deal with the potential frictions caused by the interaction of people with technology.
For example, some add-on feature requests are quite easy to write mostly independently and just "tack on" to the existing code set. Other "add-ons" require changing fundamental architecture, making them time-consuming and risky. End users and managers don't know which is which, and so judge it based on superficial estimations.
Even many semi-tech-savvy managers don't realize that you may have designed it different from how they would do it such that a particular change is a royal PITA, but they think you are fibbing, and seemingly don't have the time to listen to a fuller explanation.
Table-ized A.I.
just saying
Spending 80% of my time writing code to get data instead of writing application logic.
Not only do you have to understand the problem in hand, you have to understand how the prior programmer understood the problem.
Taking showers.
Get free satoshi (Bitcoin) and Dogecoins
is walking to the kitchen to grab another Dew. Each desk should have its own Dew dispenser.
"What are the hardest things programmers have to do?"
Find some scrap of motivation to will our insufficiently caffeinated carcases back into the code monkey meat grinder.
That and giving a damn about documenting a single arg function that's literally 10 lines long (binary). Soul sucking imbecilic totalitarianist managerial scum.
I take it all back; The hardest thing is not becoming a felon.
I know that not all programmers have to worry about that - some stop at some test environment and it is later client's problem to do actual implementation in final environment. But some programmers are working in companies where stuff is created and delivered for in-house needs - and what I have found the hardest in entire equation is to actually deliver the final result. Sometimes, there are so many dependencies, rules, noise introduced by other systems etc that it is really really hard to do the last step and to deliver the actual, tested solution to destination. Preparing the deployment scripts, overviewing that all db dumps were done at correct time in case rollback is needed, guiding hand of some poor chap from offshore location who sees your application first time in his life but has to do installation because you are not allowed to touch production machines - these things often take more effort and sweat than the coding.
Take responsibility for uncommented code.
deal with the fact that we aren't actually as exceptional as the people who pay us
keep saying
if we were we wouldn't be sitting in little boxes working every waking hour working
on ridiculously bad ideas to make someone else a whole lot of money.
1) Resist urge to kill coworkers
2) Wait for slow-ass software on slow-ass hardware connected by slow-ass networks to slow-ass databases
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.
In no particular order - dealing with management not interested in product quality - dealing with management who is biased towards their local site over product quality (Tel Aviv is full of ass-hats in this regard) - dealing with management that interprets "Agile" as being 30-45 minute "standups" every day that are nothing more than "I worked on Bug X today" rehashes. - dealing with management wherein the people hired by a particular manager are automatically given more credibility than people who are forcibly transferred in. Yes, I refer to AMD from direct experience.
What a waste of my effin time and bandwidth.
laid.
score balancing in games can be hard to get right to make fair so people can just do the same move over and move to build score with small risk.
'nuff said
If by naming things, you mean naming variables, classes, functions, etc... I could almost see that as a valid point. If you mean naming a product, that is silly, since software engineers rarely get to name a product. Way more often that not, marketing folks will provide the name.
However, how you name your classes and functions equates to how your document your code. This can be extremely tricky. Often naming those things is an integral part of your design as the name should imply what it does.
To me the hardest thing is working with people that don't understand basic concepts and are unwilling to learn them. Simple things like the single responsibility principle. It's a great pleasure when you work with people that know how to write good code and an absolute horror when you work with people who don't. I love teaching people, but programmers tend to be arrogant and unwilling to admit when they don't know things. I'm not sure why, but I have noticed this to be extremely common in the software engineering field.
I would add debugging to their list - especially 'fixing code that should work, that does work in theory and prototypes, but not in the finalized product or target platform'
That is probably their 'testing phase' item, but this is a bit different. There is nothing worse than thinking you are done and suddenly the requirements change, it doesn't work on the client's pc even though it worked on all the QA systems on the rack, or they want extra features the day before deadline.
Exercise
Deal with bullying managers that impose tight immovable deadlines in front of senior management, and then when I tell them to reset the client's expectation and blue sky renegotiate the entire contract with the client because the deadline is unachievable in front of senior management they get upset and then start bullying you and physically attacking you and I walked into a Police station and the Police officers refused to take my official report of a harassment incident. I wouldn't get any witnesses anyway because they were junior management and everyone's scared of their careers - they all have families to feed. That was in my old company, now in my new company my predecessor's predecessor had a breakdown and tried to commit suicide, but these get covered up by corporate management.
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
Hello developer. We hired you because your résumé said you wanted to do research and development. What we have here is a half-developed app that was developed by a guy we gave loose requirements to, but didn't do what we want. Your job is to research what he did, use as much of his code as possible, and develop the rest, in a better way, using the same loose requirements.
(excuse funky format. Slashdot fnorks up my Android kbd) For me... #1 is accurate time estimates. I can usually guess the time to write the code. What I fail to take into account is time for emails, meetings, documentation and training. New rule is best estimate +40%. #2 work/life balance. Putting in more than the basic 40/wk for any company is stoopid. The company *does* care if i work myself to death on their behalf -- it saves them the effort of RIFfing me. #3 juggling, aka task switching. all the studies indicate this is a time sink for jobs requiring concentration. I'm poster child (ok, poster geez) for multitasking deficiency syndrome.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
Is dealing with articles split up into 11 pages to try to sleaze more "pageviews" out of you. Presuming you bother to read them at all.
Having to answer the phone, being in an open plan office, with lots of noise and interruptions.
can trigger brain stroke
work with fins and not get as mad.
By far, the hardest thing is dealing with utterly unhelpful error messages.
"Error: an error occurred."
relax dude, it's all javascript
Change orders are job security. On a consulting gig, the customer was willing to fund changes and updates, but never willing to upgrade and port their old application to a standard database. Year end involved a good chunk of hours. I got over being annoyed and took the money. Eventually I got bored and left.
The hardest part of a programmers job is working with people that
1) don't understand programming
but
2) forces the programmers to work a certain way that doesn't fit the mindset or workflow of programmers and/or programming
with
1b) think they understand programming
as a worst case.
Or wasn't that was what meant?
bear their boss.
6. Implementing functionality you disagree with
Particularly difficult when the boss makes a decision like, 'I want it so you type one number into the program and it splits it into what the dealer needs to sell for commercial and passenger cars.'
Me: And you want this to split along the percentages of what they sold last year?
Boss: No, because they may not sell the same percentage this year. Just make it so you type in one number and it tells us exactly what they're going to sell!
I explained to him why it wouldn't work without some sort of way to split the numbers, such as the percentage, but he still didn't understand. He kept insisting it magically split it into exactly what they were going to sell. So I went and made it so the program split it along percentage lines anyway. Have no idea if it accurately predicted the 'exact' sales like the manager wanted, as I left a few months later.
5. Working with someone else’s code
One task I was given was when a guy who was not a programmer wrote macros in an excel spreadsheet for his Business Degree. He apparently got full marks at Uni, but his code lacked logic (no loops, everything written out to increment by the Cell numbers actually being typed in line after line etc). No documentation at all. I was then handed it at work to re-write to make it work and to maintain it, and just to make it more fun when I asked the guy to explain what his macros did, he told me I was a programmer and should be able to read the code and work it out myself. The guy also left shortly after. I rewrote it completely, so it was all my own code. Documented it, added features to it, and got it to work as the managers wanted it to. About a year later the guy returned and was pretty annoyed with what I'd done. He claimed two things, 1. that I was some sort of pretender, as he'd written the original program, so therefore my name shouldn't be in the code ( in the documentation I had myself down as the writer of Version 2.0 plus every time I made a change I listed myself as the programmer who made the change), and 2. I ruined his program, as he could no longer understand or debug it (note: there was never a need for him to debug it, but he liked to f*ck around with it every now and then; plus it was now completely documented all the way through so it actually told him what it was doing).
4. Dealing with other people
See above Plus, some of my favourites - manager who wanted me to press a button and have the database spew a report exactly the way he wanted it formatted without me writing a program to put it in that format (back in the 80' before GUI's). He claimed there was a magic button that I needed to press, and that I knew which button it was, but was being deliberately difficult. Another manager who claimed the internet was free and I knew the secret location where you could plug a computer network into it. A group of managers who think the internet was some sort of 'secret' network, and that anything they plugged into it didn't need a firewall or virus software, because no one knew their computer was attached to it if they didn't actively tell anyone.
3. Estimating time to complete tasks
I knew a planner who was given the job of implementing a similar sort of scheduling plan that they use in engineering, but for the developers at a large oil/gas mining company. His major complaint was he couldn't do it, as every time he asked a developer how long it would take to do a task, they never knew, not even a guestimate, and whenever he asked how far through a task percentage-wise they were, they never knew that either. I had to explain to him, it wasn't like a normal engineering problem, where if you knew how long it takes to erect 10 scaffolds and just doubled it if you had to erect 20, or if you knew it takes 1 day to dig X amount of metres of ditch to lay a pipe you could triple it for three times X amount of ditch. Two programs that are both 100 lines long might take different amounts of time based on the complexit
1. Figuring out the right problem to solve. Or the best problem (which problem will have the most impact when solved).
2. Explaining why something took longer than I expected it to.
3. Estimating the time to fix some random bug before I understand the bug.
4. Explaining why the work I've done over the past year is more important/difficult/better than the work done by a co-worker over the past year.
5. Balancing staying focused on task versus expanding the breadth of my knowledge about the system I'm working on (I naturally bias towards the former).
6. Understanding the forest when I spend all day looking at individual trees (related to 5).
7. Knowing when to ask a co-worker a question to get past an obstacle in five minutes versus spending an hour figuring it out on my own.
Most of the things the article describe sound like the easy parts.
Most of my challenges seem to revolve around communication.
Hardest things, ok, hardest things.. let's see:
1. Show up.
2. Show up on time.
3. Wear pants.
4. Shitchat with coworkers
5. Attend physical meetings to rehash shit everybody already knows
6. Avoid staring at HR tits
7. Avoid staring at HR ass
8. Not overcaffeinate
9. Not undercaffeinate
10. Schedule shits for off-hours
11. Allow time for others to catch up
12. Answer the same question over and over and over again
The hardest thing is dealing with the same avoidable process failures over and over and over again which make work take substantially longer, make delivery dates unpredictable (which risks death marches), and otherwise makes life unpleasant.
Other types of engineers know that feedback produces the highest fidelity with the least effort. It takes less energy to make adjustments near where an error is made which requires detecting it as soon as possible.
You fire a rocket at the moon and it takes just a little fuel to correct a fraction of a degree worth of error leaving earth orbit, but you'll be out of luck when you wait until the moon passes the cockpit window.
The big feedback implementation in software is achieving good automated test coverage early in the process, ideally via test driven development where tests of fine-grained functionality precede the code they test thus influencing its APIs and other design aspects to favor ease of testability and making thorough coverage likely.
Developers run the relevant automated test suites following small work increments, the problems detected must be in constrained code area, the context is usually still in their minds, and the fixes relatively easy.
You also automatically run those tests plus longer running ones including system tests from QA engineers whenever the head of the branch is untested and the tests aren't currently running so you catch it when people screw up and do even better.
In practice that's usually not what happens - we get poor test coverage late in the game at which point problems are slow and difficult to fix and a series of release candidates pushes back release dates and ramps up the stress level as fixes introduce new regressions and let the process go farther uncovering others.
At one company I dealt with a CEO who insisted that software developers writing unit tests early in the process and hardware guys validating their designs was a waste of time and that must be done by an off-shore group months after everything was built.
I presented papers and personal anecdotes to no effect. I got other executives on my side making their own arguments. The CEO didn't change his mind and most of the group did what he wanted. The software was late. The VP of engineering got demoted. The hardware never worked and was abandoned. The company went out of business after a lot of pain.
At another I dealt with a director who abandoned the existing unit test and automation practices when a pivot was necessary. Logic didn't work there either so I escalated to the VP level. That got everyone a book on the subject but didn't change anything. We had quality issues and had to abandon schedules in order to avoid killing our friendly beta customers and the company with them. While that sucked less than the usual panic it was still painful.
At another engineers carried pagers 24x7 with a 15 minute response time to deal with the software quality which exists when you don't have good test coverage up front.
I'm far enough along in my career that when system test which isn't automated for years finds a bug in my code months after I make it (100X more automated test cases more than your co-workers make such failures much less likely for you than them, although they still happen) I can get away with telling the team if they find the version which introduced the regression I'll fix it but I would really prefer not to need that coping mechanism.
Being able to make aggressive realistic schedules is also a lot better for business than when people need to fall back on software engineering estimation rules of thumb like
1. Estimate
2. Double
3. Increase the units one notch
where 1 day becomes 2 weeks, 2 weeks becomes 4 months, etc.
This can be done right. I personally ran a software group which did the right things and it was awesome. Unfortunately that's the exception not the rule.
Recurrent similar horror stories from other developers let me know I'm not alone, but I want a fix not people who share my pain to commiserate with.