(Best read while listening to AEnima by Tool, loudly)

Dear Current Workplace,

Fuck you, for the reasons enumerated below.

Fuck your enterprise grey blue offices, the stifling warm air of a hundreds of bodies and sub par "development laptops".

Fuck your shitty carbonated water machines which were a cost saving measure over decent drinkable water.

Fuck your fake "flexi time", "you can do home office whenever you want" bullshit. You're still inviting me to mandatory meetings at 09:00 regularly.

Fuck your shitty, in house, third part IT provider sister company. They're the worst of all worlds. If it was in company, we'd get to give out to them, if it was an external company we'd fire them. And yes, when I quit I will quote the dumpster fire that is our corporate VPN as a major factor.

Fuck your cheery, bland, enterprise communication. Words coming under the corporate letterhead seem to lose all association with meaning. Agile, communication, open are things you write and profess to respect, but it seems your totally lack understanding of their meaning.

Fuck your client driven development. Sometime you actually have to fix the foundations before you can actually add new features. And fuck you management who keep on asking "why are there so many bugs and why is it always taking longer to deliver new releases". Because of you, you fucknuts, Because you can't say "NO" to the customer. Because you never listen to your own experienced developers.

Fuck your bullshit "code quality is important to us" line. If it's so important, then let us fix the heap of shit you're selling so that it works like a quasi functional program.

Fuck you development environment which has 250 projects in a single VS solution. Which takes 5mins plus to compile on a quad core i7 with 32 gb of ram.

Fuck this bullshit ball of mud "architecture". I spend most of my time trying to figure out where the logic should go and the rest of the time writing converters between different components. All because 7 years ago some idiot "architect" made a decision that they didn't have to live with.

Actually, fuck that guy in particular. Yeah, that guy who was the responsible architect for the project for 4 years and not once opened the solution to look a the code.

Fuck the manual testing of every business process. Manual setup of the entities takes 10mins plus and then when you run, boom either no message or some bullshit error code.

Fuck the antiquated technology choices which cause loads of bugs and slow down development. Fuck you for forcing me to do manual tests of another developers code at 20:00 on a Friday night because we can't get our act together to do this automatically.

Fuck you for making sure it's very clear I'm never going to be anything but a code monkey in this structure. Managers are brought in from outside.

Fuck you for being surprised that it's hard to hire competent developers in this second rate, overpriced town. It's hard to hire anywhere but this bland shithole would have anyone with half a clue running away at top speed.

Fuck you for valuing long hours and loyalty over actual performance. That one guy who everyone hated and was totally incompetent couldn't even get himself fired. He had to quit.

Fuck you for your mediocrity.

Fuck you for being the only employer for my skill-set in the region; paying just well enough that changing jobs locally doesn't make sense, but badly enough that it's difficult to move.

Fuck you for being the stable "safe" option so that any move is "risky".

Fuck your mediocrity.

Fuck you for being something I think about when I'm not at work. Not only is it shit from 9 to 5 you manage to suck the joy out of everything else in my life as well?

Fuck you for making me feel like a worse developer every day I work here. Fuck you for making every day feel like a personal and professional failure. Fuck you for making me seriously leave a career I love for something, anything else.

Fuck you for making the most I can hope for when I get up in the morning is to just make it until the night.

Last week, the team lead told me that he can't merge because my code has code smells and going forward, can't have that. We use Sonar and well the way to "fix it" according to him is to mark the line using //NOSONAR.

Most of the issues are minor like Unused imports and for me incomplete TODOs.

And before the "verbal" rule was only need to fix Major + issues. And well the reason I use TODOs is to mark code that probably needs changing in the future. I know there's going to be some feature that these lines have to be changed. But the requirements are fully defined yet from business.

But I sort of blew up on him. YOU WANT TO ENFORCE ZERO CODE SMELLS NOW?!?!?! AND THESE MINOR ISSUES? MARK THEM WITH NOSONAR?

HERE'S WHAT I THINK FOR THE LAST X YEARS... THE CODE DESIGN IS SHIT, MINOR CODE SMELLS AND MANUALLY MARKING THE ONES U NEED TO KEEP... ARE THE LEAST OF OUR PROBLEMS...

THE OTHER PROBLEMS I'VE MENTIONED BEFORE EVER. MOS YEAR BUT YOU DIMWITS NEVER LISTEN.

YOU THINK MY TODOS ARE BAD... 90% OF THE CODE AND FEATURES (THE ONES NOT DONE BY ME) LOOK AND SMELL LIKE MONKEY SHIT. UNDOCUMENTED, MESSY, FULL OF BUGS.

AND GUESS WHAT? NEW FEATURE, SOME DEV FORGETS TO CHANGE SOME COMPONENT THAT DEPENDS ON IT. WOULDN'T IT BE GREATE IF THERE WERE BOOKMARKS... O WAIT...

i just was catching up on comics again and saw this one... with triggered my memory and this rant... My first thought was to forward it to him...

I work slow and my work is delayed all because you keep on changing the design and the UX, adding more features and yet keeping the same deadline

I’m 2 months into my current job at a startup, and I’m starting to lose it. My PM doesn’t have any background in tech, features keep changing every week, and more requirements are added every other day.

To make things worse, I’m the only dev on board right now, despite the company burning ~$80k on a sweatshop to deliver code that’s barely half working.

When I asked if they’re getting another dev onboard, the co-founders said they couldn’t justify another dev since they blew a fat load on that sweatshop…

Time to get on the leetcode grind again 🙃

rant="""
It's too many features for me to keep up with. And the client just bounces between this matrix of all the possible permutations of them, refusing to admit that he is asking for mutually exclusive behavior in more than one place. I have mentioned to him at least 12 times a year that there is too much going on, not organized, we need to simplify, prioritize, or we will have 100 half baked untested features.

Of course it is more or less made it out to be that this is all my fault, or at least it's hard not to feel that way when I say:

It will be a long time before X will be working, we need 25 other things first.;

Next day he asks:
Have you made any progress on X;

I reply: Now we need 24 things to be done at this rate it will be a month.;

He replies:
Ok but I need this yesterday. How about if you add a new feature Y that does everything X does without those 24 things?;

I reply: That will not work at all like X. Y is just X + 1 more feature.

He replies: Ok well I need Y so when you're done with X I need a way to do it like Y also. I just thought it'd be easier.

EASIER TO ADD MORE FUCKING FEATURES YEAH SURE THATS EASY AS FUCK YOU FUCK FUCK FUCK. He's a nice enough guy, pretty smart compared to my first few paying gigs, but wtf really? How do I come out and tell you I need 25 days and you ADD more work? This was one example.

IN TWO days he has added 12 features. And during the week has asked for 29 UI interfaces to be COMPLETELY different. This is becoming COMMONPLACE. Every week there is either a huge change, or a conversation like about that finds its way into the entire business flow inside an dout.

The worst thing is: I TOTALLY understand what he needs. I feel that HE doesn't. This weekend I spent literally HALF of his retainer on getting equipment into my hands to bring it back to find out it DOESNT WORK. Why aisn't HE doing this so I can finish the features from NOVEMBER that HE NEEDS in order to PROCESS SALES.

I've tried and tried but I just can't get through to this client what a tremendous waste of time his \"process\" is, for lack of a better word. Constant changes, contsant additions, lack of clarity, needless repetition and contradictions, constantly adding moonshot ideas to compete with every industry in the region, and not beta testing anything until something goes wrong.

Fuck this guy! His business is failing and I felt responsible for the longest time but it is clear to me that if I wanted to save his business I would have to ignore 95% of his feature requests. I ignore 50% now because of the stress in trying to determine which of the 3 different paradigms he is talking about changing. I will lose this client, and I feel like he will sue me to get all of his money back. He holds me to very little honestly - BUT WEEKLY reminds me that he won't be able to pay me next month if feature XY and Z arent ready!

If a developer is CLEARLY overwhelmed, it makes NO sense at all to continue to PILE ON feature after feature
"""
try:
while true:
rant+=", after feature"
except DevHeadExplodes as inevitable:
raise YourDevsRatesOrLookElsewhere(inevitable)

My team and I are working on a huge project that's been in development for years.

First deadline was in the fall last year. We were never going to make that.

Then we were supposed to be ready just after the summer holidays (months ago). We didn't make that either.

Then we were supposed to launch last week. Didn't happen, still too many critical errors and unfinished, untested features.

Now we are having daily meetings to discuss whether we'll be ready to release... that day!

Meanwhile, stability issues and other critical errors keep popping up. The product is barely finished and has not been through rigorous testing with all the latest features and bug fixes. Not to mention that we don't really have a deployment pipeline either.

And here's the kicker: The customers don't know this is coming. It's highly anticipated, but only internally. It is a replacement for an existing product, which strives towards not changing the frontend too much.

Why do we rush it so? I get that a deadline can help motivate you to reach your goal, but how motivated will we be if the launch fails and we get buried in bugs and missing features?
Would it not be better to launch it with at least the confidence of knowing that we've tried to test it properly?

(Warning: This rant includes nonsense, nightposting, unstructured thoughts, a dissenting opinion, and a purposeless, stupid joke in the beginning. Reader discretion is advised.)

honestly the whole "ARM solves every x86 problem!" thing doesn't seem to work out in my head:

- Not all ARM chips are the same, nor are they perfectly compatible with each other. This could lead to issues for consumers, for developers or both. There are toolchains that work with almost all of them... though endianness is still an issue, and you KNOW there's not gonna be an enforced standard. (These toolchains also don't do the best job on optimization.)

- ARM has a lot of interesting features. Not a lot of them have been rigorously checked for security, as they aren't as common as x86 CPUs. That's a nightmare on its own.

- ARM or Thumb? I can already see some large company is going to INSIST AND ENFORCE everything used internally to 100% be a specific mode for some bullshit reason. That's already not fun on a higher level, i.e. what software can be used for dev work, etc.

- Backwards compatibility. Most companies either over-embrace change and nothing is guaranteed to work at any given time, or become so set in their ways they're still pulling Amigas and 386 machines out of their teeth to this day. The latter seems to be a larger portion of companies from what I see when people have issues working with said company, so x86 carryover is going to be required that is both relatively flawless AND fairly fast, which isn't really doable.

- The awkward adjustment period. Dear fuck, if you thought early UEFI and GPT implementations were rough, how do you think changing the hardware model will go? We don't even have a standard for the new model yet! What will we keep? What will we replace? What ARM version will we use? All the hardware we use is so dependent on knowing exactly what other hardware will do that changing out the processor has a high likelihood of not being enough.

I'm just waiting for another clusterfuck of multiple non-standard branching sets of PCs to happen over this. I know it has a decent chance of happening, we can't follow standards very well even now, and it's been 30+ years since they were widely accepted.

Is the past repeating itself? Am I in that situation again where I, as a junior developer, is left to my own devices on a project, with no code reviews, and with features being added/changed as they wish? 😟

The chief came with a new idea.. something that runs ‘a side’ of our main project as some sort of manager. The database wasn’t designed with that in mind..

Now I’m wondering if I’m having issues because I could’ve designed the database better so that this wouldn’t be an issue or if I shouldn’t “blame” myself, because that wasn’t the initial idea. 🤷🏻‍♂️

We had to do a lot of migrations to keep adding and changing for the “new ideas” and now the database is a mess.. but it’s like.. too “big” to just start a new clean database structure, but it could optimize everything and make the backend easier/cleaner instead of dirty hacks/queries to combine all the different features.

As a ‘bad’ example, but the idea started as a todo list, migrated to a social network and is now migrating to something like smartschool to be able to manage users and groups, but with different features than the ‘social network’ had... I’m wondering what’s next..

Hi there!

I've been worrying about the following problem for months now and I don't find any solution. Maybe anybody of you can lead me the way.

We are developing a software suite which consists of a number of desktop applications:

* 12 applications written in C++; all over 20 years old; further development by 5 or 6 guys (one man armys) - mainly bugfixing, changes of law implementations, small features
* 2 applications we are currently writing in C#; completely new developments of existing C++ applications; scrum teams with at least 5 guys; this is, where we put our focus in

These applications (C++ and C#) are sharing some core assemblies and are interacting with each other. So they are not independent.

We organize them in a mono repository in one huge solution, which consists currently of about 500 projects.

Advantages:

* With all projects in one solution and through project references, Visual Studio takes care of the right build order
* Code navigation is superb - every single line of code is accessible - this makes refactoring easy
* Every developer can map the branch and build the whole suite locally
* Debugging on the local machine is easy
* DevOps pipeline is straight forward - it just have to build a single solution

Disadvantages:

* The huge solution is extremely slow.
* If you want to build the solution or you want to debug (which does essentially the same as a pre step) Visual Studio is building a lot of projects, although they haven't been changed. Their detection is buggy. So sometimes you wait 2 minutes until it starts the app. That slows us down a lot.
* Full builds need about an hour, because its building the same projects (even if they haven't been changed) over and over again (with ready made nuget packages this could be improved a lot I think)
* If a core team member changes some core apis, he is changing the calling code too, although he doesn't know the calling code, because another team has written it. I don't think, that's best practice and it doesn't scale.
* Often, a C# developer has to mess around with C++ building problems, because the C++ projects are in the same solution
* It gets more and more confusing and frustrating, because there is no clear organizational seperation between apps and nobody can't just focus on his app alone.

Idea:

I was thinking about putting the whole framework and core projects in a new solution (around 100 projects). Then we could take all old C++ projects and put them also in a new solution (around 200 projects). This would leave the newer projects (new applications - C#) in the existing solution.

This should speed up things, and would be a first step to better seperation, BUT:

How should the integration process look like?

Scenario: Core team is changing an API in our framework

Current process: Because all projects are in the same solution, they change the calling code too. So it's immediately integrated and the app developers just have to do "get latest".

New process (?): Core team is providing the changes through a nuget package (new version). So does every developer now has to keep track of if there is a new package version and if yes, do the integration? And how can we coordinate the different teams, so they are upgrading all at the same time? Because we ship our applications as a suite, all apps has to use the same versions. Or should we automate the integration process? Is there a best practice?

I have to add, that our core team is making changes very frequently, so the integration process will have to happen often.

Any ideas/feedback/inspiration?

Thank you so much in advance!

So........ My employer want me and another senior to complete 2 mobile applications on Qualcomm's CSRMESH both in Android (Java) and iOS (must use objective-c) to complete in 3 months time with 198 complex functionality. Some of them are hidden features(employer want us to find out our self) (this app is from Hong Kong)

The problem is , the library is shit and the sample code is messy. CSR still use Grade 2.1.1 for the project. Boss want us a new UI for the app, I should not code it but design it first in figma, because boss keep changing things from second to second.