Software Developers

Software developers are cunts. There are a myriad of reasons why this is so, but I will restrict my venting to just 3.

This nomination is a bit specialist, so I’ve edited it multiple times to make it as concise as I could and understandable to non-IT folk. Here goes…

1/ Because they trade off non-IT people’s insatiable desire to see something ‘cool’ and ‘amazing’ on a computer screen.

IT infrastructures which are well designed, engineered, maintained and documented and which are also secure, scalable, resilient and highly performant don’t happen by accident. It takes much time, effort and no little skill to create these platforms. But to software developers, it’s boring. Nobody really sees it, so to them it doesn’t matter. However, Little Johnny Programmer creates a new pull down menu option on the Accounts Payable screen and everyone whips their dicks out and wanks over his keyboard. That’s where the real IT skill is, right? FFS! The systems, network, storage, database and security administrators all collectively shake their heads, roll their eyes and think to themselves, “If we hadn’t done our jobs properly, Little Johnny Programmer WOULDN’T HAVE A FUCKING JOB”!

It’s a bit like an architect and construction company which designs, plans and builds a beautiful mansion. Then some spotty 17 year old intern shows up 5 minutes before its unveiling, attaches a front door bell and promptly wins an industry design award.

2/ Because they get away with fucking murder disguised as (a lack of) productivity and progress.

IT professionals with top skills, knowledge and experience are in short supply. The demand for new software systems has outpaced that supply by some margin for many years. The IT industry’s answer to bridging that gap was to dream up a new approach to software development called Rapid Application Development (RAD). RAD has evolved and mutated many times over the years. A current incarnation of its bullshit is known as Agile. Agile is NOT a software development methodology. It’s a manifesto and anyone who says different is an ignorant cunt. Agile does away with the traditional phases of software development (Analysis, Design, Development, Testing and Implementation). Instead, it focuses on just writing software in short bursts called sprints. A sprint is often just 2 weeks long!

Capturing end user requirements has always been a challenge. Users lie, mislead and leave out important details about how they do their jobs and what they need a new computer system to do. One technique which can help flesh out user requirements is called Prototyping. It pre-dates RAD and Agile by decades. With Prototyping a dumbass programmer with a paper thin understanding of a business process will quickly code some basic screen layouts with minimal field validation, process flow or interfaces to other systems. Once a user can actually see something working on a screen, it’s more likely they’ll be able to provide greater detail about what they actually want and need from the finished software. In the Agile universe, that first bare bones prototype IS the finished software. Detailed user requirements documented, validated and verified? Nope. All data elements with their validation rules defined? Nope. All business processing and interface rules defined? Nope. System and integration test plans designed and executed? Take a fucking guess!

To the IT Manager it looks like progress because Little Johnny Programmer wrote 1000 lines of code in the last 2 weeks. The follow up question should be, how much of that work adheres to the coding standards (if they have any), is reusable and won’t need to be re-done over and over again as new requirements emerge or evolve? Try 10% and you’re being optimistic. It’s a bit like some arse clown making all the doors and windows for a new house without knowing how many walls or rooms it will have. Too few? Too many? The right size? The right style? Who fucking knows? It’s all guess work and a perfect example of simply making it up as you go along. You just couldn’t make this shit up!

3/ Because they’re fucking lazy.

In over 30 years of working within the IT industry, I have yet to meet a programmer who actually gives a shit about efficiency and performance. Once a programmer solves a problem, they move onto the next one. They never take an objective look at their code and ask themselves if there’s a more efficient or faster way to achieve the same thing. The result is crap and inefficient code which causes system bottlenecks, slow downs and in some cases, whole systems to just freeze up once they go live. While all the Little Johnny Programmers are high fiving each other in the break room celebrating a job well done, the system, network, storage and database administrators are trying to figure out why a process which should be sub-second is actually taking an hour to run. After all, it’s THEIR problem now!

So stop calling yourselves Software Engineers because you’re not. You’re all lazy, incompetent and bullshitting cunts.

 

Nominated by: Imitation Yank 

77 thoughts on “Software Developers

  1. I have yet to meet a programmer who actually gives a shit about efficiency and performance. Once a programmer solves a problem, they move onto the next one. They never take an objective look at their code and ask themselves if there’s a more efficient or faster way to achieve the same thing.

    There’s the essence of the problem. I lost (amateur) interest in software when the Mororola 68000 series failed to keep up with Intel (the machine code was lovely) and Forth fell out of fashion. I am now a coding ignoramus, but have the impression that today’s bells-and whistles obsession requires programs to write programs to write programs and that what’s actually going on in your code is completely opaque, even if you wrote it yourself. Right? Wrong? Tell me, please.

    Also that management will unhesitatingly accept shit code so long as it is only the peasants they are managing who suffer thereby.

    • I was taught M68000 assembler. Loved it. It made Z80 assembler look like machine code by comparison.I tried getting into 6502 assembler (old Commodore machines like the Pet), but the software interface wasn’t all that. I did enjoy assembler overall. It really felt like you were in control of the hardware. Good times.

      You’d have to speak to a developer, Komodo, to get the low down on today’s code. My impression is the flavour of the week language comes with a ton of libraries and the developers just make calls to standard library routines. I don’t think anyone codes everything from scratch anymore.

    • …and I so wanted to talk about CPUs, and the war between AMD and Intel!!

      I soooo want to talk about the beautiful AMD Ryzen 9 3900X, and its sexy 12 cores, 24 threads and a clock speed of almost 5.GHz.

      Mmmmm, so sexy!!!!

  2. Another bugbear of mine with coders was their total disinterest in writing follow-up documentation for their app releases.

    It was as if we were trying to get them to reveal state secrets or something, because they were so reluctant to reveal how their application worked. Perhaps they were paranoid about losing their job thereafter, but they failed to realised that any application they wrote for the company belonged to the company – including the coding, and hopefully the documentation!

    As a consequence, when one of these cunts left, and the application they wrote subsequently broke, we had little idea (other than getting a 3rd party in) why it failed and how to fix it because there was no documentation, and the guy was uncontactable.

    Admittedly, writing documentation for anything is a pain in the arse. Just like Business Continuity and Disaster Recovery – I hated writing docs and flowcharts for those because they were time-consuming, and had to be written in such a way that non-techie cunts could understand them.

    But its only when you do have a power outage, an application bug, a DDoS, or a hardware failure that you appreciate the importance of documentation and how it can get you out of the shit, especially when you have managers from other parts of the company ringing you up saying “How much longer will we be down for? This downtime is costing us money!” (Like, no shit Sherlock! Just get off the fucking phone and let me do my job, arsehole.)

    • I see the value of external documentation and always have. I quite like writing it. I’m sure this sounds a bit cunty, but I think of it as a form of immortality. Your documentation lives on long after you’ve left a company. I know for a fact documentation I have left behind has saved people’s arses when something went tits up. It’s a good feeling knowing you’ve done a good job and your name has been lauded long after you moved on.

      Anyway….

      I’m a big fan of internal documentation as well. Trouble is, fucking developers can’t be bothered to do that either. Or if they do, they fall into the trap of commenting what the code is doing. WE KNOW WHAT THE CODE IS DOING YOU PRAT – WE CAN READ!!! You’re supposed to document WHY it’s doing what it’s doing. What is so hard to understand about that? Jeez!

  3. You will be happy to know the world is computer world changing because companies like Apple are going away from spy infested Cpu’s like Intel and other shit chips to good old ARM (British) Cpu’s made under licence. Lets hope the West doesn’t insert their spying op shit into them like they accuse Chinese of doing.

    It’s all bullshit really, The internet was never designed for secure commerce, especially Windows operating system. No wonder mega bucks are spent to make something into it’s not.

    Did you know the Sky programmers set the display colours on set top box to ones that some people could not read because as you get older you can not define red on a black background very well, recall cost them shit loads because young programmers with 20/20 vision thought they knew it all.

  4. I spent 20 years as a freelance software tester. Developers – or coders as they should be correctly called – are cunts.

    The bigger cunts are Project Managers. They make the same mistake every time. Step 1 on the plan = write the spec then before they have a spec they decide everything else that follows. How. The fuck do you know it will take 6 coders 8 weeks to write the program before you have a fucking spec?!?!?!

    Japanese coders are the worst. They break the job down into little chunks and give each coder a definition of the inputs and outputs required with no idea whatsoever what the overall job is or how it all fits together. Then guess what? When they put it all together the fucker doesn’t work.

    All freelancers know this but does any cunt listen? Do they fuck…

    • The so-called “project managers” used in my old place, had little or no experience in the IT field. They just used their existing skills taken from other areas to “manage” the IT projects, and quite often failed dismally.

      They didn’t even bother much with the consulting side, thinking that their own knowledge would see them through. That is, until someone pointed out a number of missed facets in their timelines – not least one of QA, DR and rollbacks.

    • Spot on, Dio.

      In my experience, Indians are the some of the worst offenders. Their culture doesn’t encourage saying no or disagreeing. So they’re given a spec by some cunt analyst who couldn’t find their own arse with both hands. The spec doesn’t make sense either on its own or in the context of other software modules. What do they do? Instead of assessing what they’ve been given and providing feedback on the basis the spec is wrong or incomplete, they code it exactly as per the spec. Some time later in testing it’s revealed the code is wrong/doesn’t do what it should and has to be re-written. Impact analysis then highlights several other pieces of software will also need to be changed…..you know where this is going.

      Ask an Indian IT person what’s on page 72 of the technical documentation manual and they’ll tell you word for word. Ask them to think, extrapolate and apply reason to something…..deer in the headlights.

Comments are closed.