• Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.

MrChocolate

The Fallen
Oct 27, 2017
1,413
Sorry I just want to vent. I'm in a huge software migration process and I have never felt so fucking miserable in my life. It's been like 3 weeks with little to no sleep. As a Manager you get slapped from the customer, from your team and from the support team. No matter how accurate you try to schedule, how many contingency plans you design, everything goes south for the most insignificant crap. In this case a database user that is encrypted and can't be changed easily because "something"
It blows so hard that I want to hang myself.
/rant
 

Vir

Member
Oct 27, 2017
59
Western Australia
I feel you mate, working in/on software can be one of the most unrewarding and frustrating jobs.

Everything is your fault and when things are running well and you've bent over backwards to help there is no thank-you.

Keep grinding man, it will hopefully get better :)
 

Pat

Member
Oct 27, 2017
612
Moved from software engineering to infrastructure engineering, no regrets.
 

Chaos2Frozen

Member
Nov 3, 2017
28,026
I made a huge mistake coming to programming. Went through 2 months crash course of 4 different languages and I barely understood jack shit.

I felt so thankful to be placed in the business analysis stream after that
 

sweetmini

Member
Jun 12, 2019
3,921
Few thoughts from my corps days ...
Slapped from your team ? Gather them for an idea round up theming on how they see the internal structure and methods could be bettered.
Support team slap ? Expose your actual challenges to their boss and get some support documents done to help dilute pressure if it s intensive peaks... maybe some solicitations could be directly answered by support if they get the tools/procedures.
Slapped by business ? Maybe Have a key business correspondent join the team as liaison.
You are there to steer the thing, you are not a punching bag, never let the pain set in. There has to be solutions out there. Your mental health is too precious to ruin on a friggin migration.
If you are unwell, the project cannot be well.
 

Horp

Member
Nov 16, 2017
3,708
As a programmer/system architect, CTO etc. for 12 years I have this theory:
Creating Software is too hard.
Programs are hard enough to get completly right when you implement a simple, single sorting algorithm in 25 lines.
The idea that we're using programming to create these gigantic, asynchronous systems that runs incredibly fast, with connections to other systems, human-computer-interfaces etc - it's pretty preposterous.
And, we build them in teams of people. We all know how much harder it is to perform tasks as a team.
Then you have the fact that hardware and other systems change over time; so systems have to kept up to date.
Then add the fact that new technologies and tools come out all the time, requiring software developers to keep learning and implementing new stuff.
Add to that that software developers in general are overworked and don't sleep enough; and probably a lot of them don't eat very well - all things that reduce mental capacity and increases the odds that you will introduce errors in your code.

I think this is why 99.9% of all applications out there are shit. I mean think about it; we're probably only exposed to the top 0.5% of all applications out there, in terms of quality, and still most of them are buggy or unintutivive or both.

Creating software is too hard.
 

Temp_User

Member
Oct 30, 2017
4,697
Handling development crap from within and from your clients is indeed terrible but personally-speaking do you know what's its even more frustrating than that? Handle development crap coming from your partners (ie. framework providers, data-providers, tool providers etc.). At least with the former you could start fixing the problem right away. The latter you have to wait . . . .
 

Deleted member 5028

User requested account closure
Banned
Oct 25, 2017
9,724
Mate. Whatever you're working in you'll be the legend that solves it for years to come.
But hey at least you're not working on PlayStation Network or anything.
 

MrKlaw

Member
Oct 25, 2017
33,038
Don't forget when you're the delivery manager and the sales guys have just dropped a series of undeliverable promises on your lap that they've already made to the client.
 

Silav101

Member
Oct 26, 2017
730

tenor.gif
 
Oct 28, 2017
3,644
I feel you MrChocolate.

My favorite is: Having to develop an interface between two different (barely documented and shitty) systems of two different bigger companies who basically hate your guts.
 

Disorientator

Member
Oct 27, 2017
388
Cyprus
...and the sales guys have just dropped a series of undeliverable promises...

THIS. ALWAYS.

My god I hate sales people. (no offense if any of you here)

I mean I understand their purpose, and without them we would probably be in trouble, but my god they are so full of s***.
S*** that more often than not we (system designers/implementators) have to clean/beautify.

To the OP: Not much advice from here my friend, sorry - I guess hang in there!?
 
Last edited:
Oct 27, 2017
2,902
Scotland
After many years in software development, I got used to situations like you described and don't let my emotions engulf me. Comes with the job really. I just work to the best of my ability and raise any concerns that may hinder my performance. If it gets too much I just move jobs (no shortage of dev roles). Life's too short to give a shit about why X process sucks or why things are done in such a shitty way.

One thing to point out, you're at the bottom of the pecking order when you're in IT. Sadly...Sales people and Staff Managers are - undeservedly - king. You either come to terms with this and make sure you get financially/beneficially compensated and highly rewarded for your work or you move to a working environment/department/job where IT are taken seriously and are represented by a hands-on CTO. Worst thing you want to do is be managed by an incompetent non-IT manager.
 

azeke

Member
Oct 30, 2017
1,220
Astana, Kazakhstan
Instead of hating the responsibility and high stakes of your job -- cash in on it.

During a next crisis ESPECIALLY when superior starts demanding shit to be finished ASAP -- simply stand up and leave the building. Enjoy nature, read a nice book, watch a movie.

Then return a few days after the BS "deadline" came and enjoy the view of them scrambling like headless chickens without you. Demand a raise right then there.

Works every time.
 

tokkun

Member
Oct 27, 2017
5,400
As a programmer/system architect, CTO etc. for 12 years I have this theory:
Creating Software is too hard.
Programs are hard enough to get completly right when you implement a simple, single sorting algorithm in 25 lines.
The idea that we're using programming to create these gigantic, asynchronous systems that runs incredibly fast, with connections to other systems, human-computer-interfaces etc - it's pretty preposterous.
And, we build them in teams of people. We all know how much harder it is to perform tasks as a team.
Then you have the fact that hardware and other systems change over time; so systems have to kept up to date.
Then add the fact that new technologies and tools come out all the time, requiring software developers to keep learning and implementing new stuff.
Add to that that software developers in general are overworked and don't sleep enough; and probably a lot of them don't eat very well - all things that reduce mental capacity and increases the odds that you will introduce errors in your code.

I think this is why 99.9% of all applications out there are shit. I mean think about it; we're probably only exposed to the top 0.5% of all applications out there, in terms of quality, and still most of them are buggy or unintutivive or both.

Creating software is too hard.

I've worked as a systems software engineer for the last 5 years, but prior to that I had worked in electrical engineering and computer architecture. I do not view creating software as being fundamentally more difficult than creating hardware.

There are a few unique elements to software engineering that I think lead to many of these problems that are not as pronounced in other engineering fields:
  • There has been a long-time talent shortage, which has contributed to a number of issues. There is less focus on formal training and mentorship. There are high turn-over rates, since engineers can often get paid more to job hop, leading to loss of institutional knowledge in projects. People are often willing to take design shortcuts because they know they will not be around to deal with the consequences 5 years down the road.
  • For a variety of reasons, there is much more focus on velocity and time-to-market in software. It tends to use Agile rather than methodologies like Waterfall. There are fewer design reviews and they are less rigorous. The concept of "technical debt" is much more normalized.
  • There is a perception that it is OK to ship with bugs and then patch them later with relatively little cost. What costs there are tend to be harder to quantify in monetary terms (e.g. reputational damage).
Now, a lot of these problems are offset by the fact that the breadth and pace of innovation in software is tremendous. I can get a feature from conception to production in a matter of weeks in software, whereas it is difficult to do anything in less than a year in hardware.

I'm reminded of the instances of building collapses in China. The incredible pace of construction is often accompanied by weaker standards and more corner-cutting. I wouldn't look at those instances and conclude "it's too hard to build a high-rise."
 

Firebricks

Member
Jan 27, 2018
2,128
The breadth and pace of innovation in software is tremendous. I can get a feature from conception to production in a matter of weeks in software, whereas it is difficult to do anything in less than a year in hardware.

That's because there can't be any bugs in hardware (there are, but hopefully they are software fixable via chicken bit).
 

Horp

Member
Nov 16, 2017
3,708
I've worked as a systems software engineer for the last 5 years, but prior to that I had worked in electrical engineering and computer architecture. I do not view creating software as being fundamentally more difficult than creating hardware.

There are a few unique elements to software engineering that I think lead to many of these problems that are not as pronounced in other engineering fields:
  • There has been a long-time talent shortage, which has contributed to a number of issues. There is less focus on formal training and mentorship. There are high turn-over rates, since engineers can often get paid more to job hop, leading to loss of institutional knowledge in projects. People are often willing to take design shortcuts because they know they will not be around to deal with the consequences 5 years down the road.
  • For a variety of reasons, there is much more focus on velocity and time-to-market in software. It tends to use Agile rather than methodologies like Waterfall. There are fewer design reviews and they are less rigorous. The concept of "technical debt" is much more normalized.
  • There is a perception that it is OK to ship with bugs and then patch them later with relatively little cost. What costs there are tend to be harder to quantify in monetary terms (e.g. reputational damage).
Now, a lot of these problems are offset by the fact that the breadth and pace of innovation in software is tremendous. I can get a feature from conception to production in a matter of weeks in software, whereas it is difficult to do anything in less than a year in hardware.

I'm reminded of the instances of building collapses in China. The incredible pace of construction is often accompanied by weaker standards and more corner-cutting. I wouldn't look at those instances and conclude "it's too hard to build a high-rise."
Your points aren't wrong but I simply think that there are more major problems with how we create software.
Even though we use existing libraries and API:s, pretty much all applications created are still hinging on every single line of code created specifically for this project being correct. A & sneaked in instead of && somewhere? Application can potentially be worthless. My experience with hardware (the company I'm working at right now is actually a hardware company, but I'm mostly involved in software still) is that it is by nature not quite as sensitive. The physical existence of materials just lends itself better to how we humans view the world. An incorrectly assembled object? Many chances this will be discovered by someone somewhere down the line because so many people will view this. That & instead of && will by the nature of things not be as exposed.

And empirically, I'm correct. Most hardware projects seems to work well enough; but it seems almost EVERY large software project, no matter how much money or time or senior people are put into it, will have bugs - and will likely never be free of bugs. Even most smaller scale projects will have bugs and problems.

I have no suggestions for improvements, but I do think that we need to rethink how we create software in the future.
 

Roxas

The Fallen
Oct 28, 2017
3,551
Buenos Aires, Argentina
I've been working on a massive project for the past three years, and while I've gone up the chain rapidly, I have to echo everything said here, crunch on weekends, nights, depression, anxiety, stress, I lost my partner due to the fact I was working too much. This industry is extremely unhealthy for the people in the middle of the process.
 

CrankyJay

Banned
Oct 25, 2017
11,318
Sorry I just want to vent. I'm in a huge software migration process and I have never felt so fucking miserable in my life. It's been like 3 weeks with little to no sleep. As a Manager you get slapped from the customer, from your team and from the support team. No matter how accurate you try to schedule, how many contingency plans you design, everything goes south for the most insignificant crap. In this case a database user that is encrypted and can't be changed easily because "something"
It blows so hard that I want to hang myself.
/rant

Always take your initial estimate and add a multiplier on it.

Software is a thankless job.
 

Xando

Member
Oct 28, 2017
27,292
If life as a consultant taught me anything it's that you always calculate a buffer of 5-10 days into a project because there is always someone delaying shit.

It also gives you extra $$$ for your revenue.
 
Last edited:
OP
OP
MrChocolate

MrChocolate

The Fallen
Oct 27, 2017
1,413
Thanks to everyone. Reading your replies made my night easier to digest. The great news is that we were able to complete the migration!

Long quote ahead!!

There is always something. The older the company, the worse it gets. A lot of shit has been growing over the years and most of the time it's "never touch a running system". They are usually right with it, too.

At least you have a database. My current company uses excel spreadsheet for fucking everything and some special fancy asshats even went with Access.

This "software" was designed to be updated monthly. The problem was the customer didn't want to pay for the monthly migration, and waited (over 2 years) until it was deemed mandatory by the "product owner". Which is a huge corporation and will give no fucks about your issues, after you are in their ecosystem.

I feel you mate, working in/on software can be one of the most unrewarding and frustrating jobs.

Everything is your fault and when things are running well and you've bent over backwards to help there is no thank-you.

Keep grinding man, it will hopefully get better :)

I actually tried to quit a few weeks ago. Boss didn't let me and offered me to fire whoever was making my life miserable. Of course, I didn't say who it was, but I promised to wait a few months

Few thoughts from my corps days ...
Slapped from your team ? Gather them for an idea round up theming on how they see the internal structure and methods could be bettered.
Support team slap ? Expose your actual challenges to their boss and get some support documents done to help dilute pressure if it s intensive peaks... maybe some solicitations could be directly answered by support if they get the tools/procedures.
Slapped by business ? Maybe Have a key business correspondent join the team as liaison.
You are there to steer the thing, you are not a punching bag, never let the pain set in. There has to be solutions out there. Your mental health is too precious to ruin on a friggin migration.
If you are unwell, the project cannot be well.

Support team is technically deficient compared to us the "migration team". The huge problem is we cannot fix anything related to the Production Database from our side. The support team has all the privileges because, of course, there has to be a segregation of duties.



This hit right home ;____;

As a programmer/system architect, CTO etc. for 12 years I have this theory:
Creating Software is too hard.
Programs are hard enough to get completly right when you implement a simple, single sorting algorithm in 25 lines.
The idea that we're using programming to create these gigantic, asynchronous systems that runs incredibly fast, with connections to other systems, human-computer-interfaces etc - it's pretty preposterous.
And, we build them in teams of people. We all know how much harder it is to perform tasks as a team.
Then you have the fact that hardware and other systems change over time; so systems have to kept up to date.
Then add the fact that new technologies and tools come out all the time, requiring software developers to keep learning and implementing new stuff.
Add to that that software developers in general are overworked and don't sleep enough; and probably a lot of them don't eat very well - all things that reduce mental capacity and increases the odds that you will introduce errors in your code.

I think this is why 99.9% of all applications out there are shit. I mean think about it; we're probably only exposed to the top 0.5% of all applications out there, in terms of quality, and still most of them are buggy or unintutivive or both.

Creating software is too hard.

I agree with everything you wrote, and also I might add, it is harder to implement and modify a huge piece of software that belongs to another company.

Handling development crap from within and from your clients is indeed terrible but personally-speaking do you know what's its even more frustrating than that? Handle development crap coming from your partners (ie. framework providers, data-providers, tool providers etc.). At least with the former you could start fixing the problem right away. The latter you have to wait . . . .

That's the highest quality of BS and I learned to not take it anymore. Everytime a framework/tool/etc provider starts blaming my team, the fucker better be prepared to justify their accusation or I'll go medieval in their ass. Never again after a shit experience I had with a 3PL provider.

Mate. Whatever you're working in you'll be the legend that solves it for years to come.
But hey at least you're not working on PlayStation Network or anything.

Hopefully after this I can take some days off ____@

I feel you MrChocolate.

My favorite is: Having to develop an interface between two different (barely documented and shitty) systems of two different bigger companies who basically hate your guts.

Been there. The only way to improve your current situation is to make them fight with each other. Find a common enemy and they will leave you alone.

After many years in software development, I got used to situations like you described and don't let my emotions engulf me. Comes with the job really. I just work to the best of my ability and raise any concerns that may hinder my performance. If it gets too much I just move jobs (no shortage of dev roles). Life's too short to give a shit about why X process sucks or why things are done in such a shitty way.

One thing to point out, you're at the bottom of the pecking order when you're in IT. Sadly...Sales people and Staff Managers are - undeservedly - king. You either come to terms with this and make sure you get financially/beneficially compensated and highly rewarded for your work or you move to a working environment/department/job where IT are taken seriously and are represented by a hands-on CTO. Worst thing you want to do is be managed by an incompetent non-IT manager.

My issue is that I care too much for this particular customer and I want them to succeed. It is definitely something to improve.


Found this funny because this usually means something the company keeps off the books tee hee

My sentiments OP, this too shall pass

No no, it is not related to the customer but to the "product owner". They encrypt their database users so we can't handle them from our end, even if we have access to their VM.

Always take your initial estimate and add a multiplier on it.

Software is a thankless job.

Always have done that, my estimations are accurate up to a 95%. This particular issue arose because the support team (which we don't "own") didn't install everything we required.
 

strang

Member
Oct 27, 2017
109
Man I'm about to leave a cushy but kinda dead-end job to go back to school for computer science and this thread is making me nervous...
 

Chikor

Banned
Oct 26, 2017
14,239
Sorry I just want to vent. I'm in a huge software migration process and I have never felt so fucking miserable in my life. It's been like 3 weeks with little to no sleep. As a Manager you get slapped from the customer, from your team and from the support team. No matter how accurate you try to schedule, how many contingency plans you design, everything goes south for the most insignificant crap. In this case a database user that is encrypted and can't be changed easily because "something"
It blows so hard that I want to hang myself.
/rant
The only way to know how long a software project will take is to actually do it.
You can guess, but it's always gonna be a curve of probabilities really. I think the way most software companies do scheduling pretty much push you for just being super conservative with your estimates. I personally think it's a stupid way to go about things and people need to recognize that there are shit that are outside anyone's control, but it's easier to manage projects like that so fuck it.
 

Horp

Member
Nov 16, 2017
3,708
But hey.
We're relatively well paid, we dont ruin our bodies during work like many occupations, we dont risk our lives, we dont have to handle toxic or disgusting materials or substances, we can drink coffee and listen to music a lot of our work time and we are well prepared for the future compared to a majority of occupations.
 
Oct 27, 2017
4,919
As a programmer/system architect, CTO etc. for 12 years I have this theory:
Creating Software is too hard.
Programs are hard enough to get completly right when you implement a simple, single sorting algorithm in 25 lines.
The idea that we're using programming to create these gigantic, asynchronous systems that runs incredibly fast, with connections to other systems, human-computer-interfaces etc - it's pretty preposterous.
And, we build them in teams of people. We all know how much harder it is to perform tasks as a team.
Then you have the fact that hardware and other systems change over time; so systems have to kept up to date.
Then add the fact that new technologies and tools come out all the time, requiring software developers to keep learning and implementing new stuff.
Add to that that software developers in general are overworked and don't sleep enough; and probably a lot of them don't eat very well - all things that reduce mental capacity and increases the odds that you will introduce errors in your code.

I think this is why 99.9% of all applications out there are shit. I mean think about it; we're probably only exposed to the top 0.5% of all applications out there, in terms of quality, and still most of them are buggy or unintutivive or both.

Creating software is too hard.
What's the solution? We're not at the point where it's like Star Trek and you can tell it to create a simulation of the best path to take through a nebula.

Machine Learning is billed as the black magic that will solve everything yet most people don't realize that it has a very, very specific scope where it makes sense to use.
 

Lionheart

Member
Oct 26, 2017
2,840
I tried my hand at software development. It's literally impossible and I don't know how people do it. Its endless and ...impossible.

It totally destroyed my confidence as a human.
 

Poltergust

One Winged Slayer
Member
Oct 25, 2017
11,821
Orlando, FL
In my current project I noticed an issue that broke basically everything as of last Friday and only now we were able to actually identify where the problem lies.

At least it wasn't I who broke it lol.
 

Horp

Member
Nov 16, 2017
3,708
What's the solution? We're not at the point where it's like Star Trek and you can tell it to create a simulation of the best path to take through a nebula.

Machine Learning is billed as the black magic that will solve everything yet most people don't realize that it has a very, very specific scope where it makes sense to use.
I honestly dont know. Not ML, thats for sure. When it comes to system reliability and implementation simplicity ML just makes things worse. It's a brilliant tool for specific, data related problems though.
I'd say higher abstraction, probably.
The reason most applications can get sound to play and can write a file without crashing these days is because these things are abstracted and no longer require virtually any coding.
But we have to limit scopes, too, otherwise this wont help. And that likely wont happen.
 

Lcs

Member
Aug 9, 2018
268
I think in a couple decades most old companies will have legacy systems resembling lovecraftian horrors.
 

ImaginaShawn

Banned
Oct 27, 2017
2,532
I feel you OP. Last year I was working on a migration from procedural PHP 5.2 to Laravel with PHP 7. I wanted to kick the original Dev in the head every time I saw him for letting it get so bad.
 

Krauser Kat

Member
Oct 27, 2017
1,700
What's the solution? We're not at the point where it's like Star Trek and you can tell it to create a simulation of the best path to take through a nebula.

Machine Learning is billed as the black magic that will solve everything yet most people don't realize that it has a very, very specific scope where it makes sense to use.
High quality UX and Project managers getting all the work done prior to trying to code?
 

mugurumakensei

Elizabeth, I’m coming to join you!
Member
Oct 25, 2017
11,320
Famous last words inheriting a project from someone else

"All you have to do is X" with X being something super simple like "enable the feature". It will not be X, but, instead, it will be a months long project since you have to enhance the design and system while having to learn its current implementation.
 

elenarie

Game Developer
Verified
Jun 10, 2018
9,799
Now try to add on that the requirement to find and prove the fun. Not just the functionality. :)

This is great! Everything is great!
 

Exellus

Banned
Oct 30, 2017
2,348
First thing I like to do when inheriting someone else's code: Clean the code.

Balance the brackets. Rename the variables and methods to things that properly describe them, etc. That being said, I work on smaller teams on smaller projects. But this helps me make sure the code is readable and I'm more familiar with it.

I can't stand variables called x, c, t, etc. Or functions called RdBldPld01. I refactor without changing functionality, just for readability. Sometimes you even identify bugs after doing this. Dead code, or redundant sections.

Working on bigger teams is always a pain. I think this has more to do with collaboration in general though - the bigger the team the more likely someone is bad at coding.
 

mxbison

Banned
Jan 14, 2019
2,148
Instead of hating the responsibility and high stakes of your job -- cash in on it.

During a next crisis ESPECIALLY when superior starts demanding shit to be finished ASAP -- simply stand up and leave the building. Enjoy nature, read a nice book, watch a movie.

Then return a few days after the BS "deadline" came and enjoy the view of them scrambling like headless chickens without you. Demand a raise right then there.

Works every time.

And then you wake up and realize you don't have a job anymore