While writing up this quarter's performance review, I re-read last quarter's goals, and found one my boss edited and added a minimum to: "Release more features that customers want and enjoy using, prioritized by product; minimum 4 product feature/bug tickets this quarter."

... they then proceeded to give me, not four+ product tickets, but: three security tickets (two of which are big projects), a frontend ticket that should have been assigned to the designer, and a slow query performance ticket -- on top of my existing security tickets from Q3.

How the fuck was I supposed to meet this requirement if I wasn't given any product tickets? What, finish the monster tickets in a week instead of a month or more each and beg for new product tickets from the product manager who refuses to even talk to me?

Fuck these people, seriously.

Ticket: Allow merchants to customize how their Wallet Passes look! It’ll be super easy, just add these nine merchant-modifiable strings (they support vars) and use their contents for text instead of what we use now. Simple!

Reality: There need to be 24 strings, there are some rules I can’t convey to the merchant (because the system literally does not include instructions, only a name and a textbox), the code to generate the wallet pass is inefficient, uncommented, branching spaghetti that I’ll need to rewrite (it seriously generates every possible field, and then only uses the ones it needs), the specs are so much worse, and half the default values they want aren’t even possible. As in, I don’t know if it’s a car loan, let alone the exact make and model of the bloody thing.

And no, sorry, we have no way of knowing what their fucking “vertical” is, either, so we can’t display that. Fucking sales.

Asdhkjfsjfads

WHY MUST EVERYTHING SUCK

So I am at the client's location for onsite consultation of their projects.
The HoD asked me to create an application to accept feedbacks from multiple points urgently. Although I was there just for consulting, I thought why not, I am anyway getting bored here.
So after explaining the functionality, she asked me, when can she accept a working app. I told her that it would depend upon a lot of factors, so give me till evening to figure it out.
When she insisted I told her, that it can take at least a month with all the APIs, logins, UI, QA etc. She was surprised and told me that she expected it in 4 days since the requirements can be fit into a single page of her notebook. (That's how she measures project duration).

I told her it's impossible, given that I am the only one working on it. So she told me that her team can do it in two days. I probably have more experience than her entire team combined, but still I thought they might know some simple magic or faster way, that I might not, so I asked her to discuss with the team and then decide.

After explaining the requirements, when she mentioned that it should be done in 2 days, everyone was kinda frozen. One of them said that it's going to take at least 4 months.

I couldn't hide my smirk 😉

Me: junior dev

Assignment: build a REST search service that also does (thing x)

Me: gosh I just can't figure out how to make (thing x) work! Nothing I try works and there are no online resources!

*goes to meeting with client*

Client: (thing x) is impossible in our application, so we are expecting (much more manageable thing)

Me: awesome! I think I can build that

Manager who can't code: what are you talking about, (thing x) is clearly better and it should be possible to do

Manager: *sends email outlining shifted requirements after the meeting, including (thing x)*

Working in the embedded systems industry for most of my life, I can tell you methodical testing by the software engineers is significantly lacking. Compared to the higher level language development with unit tests and etc, something i think the higher level abstracted industry actually hit out the of park successfully.

The culture around unit testing and testing in general is far superior in java and the rest.

Down here in embedded all too often I hear “well it worked on my setup... it worked at my desk”.. or Oh I forgot to test that part.. or I didn’t think that perticular value could get passed in... etc I’ve heard it all. Then I’ve also heard, you can’t do TTD or unit tests like high level on embedded... HORSESHIT!

You most definitely can! This book is a great book to prove a point or use as confirmation you are doing things correctly. My history with this book was I gonna as doing my own technique of unit testing based on my experience in the high level. Was it perfect no but I caught much more than if I hadn’t done the testing. THEN I found this book, and was like ohh cool I’m glad I’m on the right thought process because essentially what they were doing in the book is what I was doing just slightly less structured and missing a few things.

I’ve seen coworkers immediately think it’s impossible to utilize host testing .. wrong.

Come to find out most the of problems actually are related to lack of abstraction or for thought out into software system design by many lone wolf embedded developers.. either being alone, or not having to think about repercussions of writing direct register writes in application or creating 1500 line “main functions” because their perception is “main = application”. (Not everyone is like this) but it seems to be related to the EEs writing code ( they don’t know wha the CS knows) and CS writing over abstraction and won’t fit on Embedded... then you have CEs that either get both sides or don’t.. the ones to understand the low level need but also get high level concepts and pariadigms and adapt them to low level requirements BOOM those are the special folks.

ANYway..the book is great because it’s a great beginner book for those embedded folks who don’t understand what TDD is or Unit testing and think they can’t do it because they are embedded. So all they do is AdHoc testing on the fly no recording results no concluding data very quick spot check and done....

If your embedded software engineers say they can’t unit test or do TDD or anything other than AdHoc Testing...Throw the book at them and say you want the unit test results report by next week Friday and walk away.

Lol

"Impossible deadline experience?"

When product owners promise delivery dates.

One day, I came back from a two weeks holiday, relaxed. I noticed a teammate missing. "Yes, he took the week off". Sure, why not.

We were working under a bastardized enterprisey version of Scrum (didn't we all at some point?). So we didn't just have a product owner, we had three and an additional "Head of PO". Because enterprises can't live without hierarchies or something. Barely an hour after I came into office, she entered the room and came straight to me. "Your coworker was almost done implementing feature X. You need to finish it immediately. No worries, though, coworker said the rest is a piece of cake".

It wasn't. There was *a lot* left to do, the JIRA task wasn't entirely clear, and the existing code for the feature was so-so (obviously WIP code). I estimated two weeks for the implementation, plus some time to clarify the requirements. When telling "Head of PO" she lost her shit. Screaming things like "this feature is due the end of this week" and "I signed this with my blood!". Well, I didn't, and I made it clear that I hadn't been consulted on this, thus I would not accept any blame in case we missed the deadline.

So I gave my best that week, getting pestered by "Head of PO" all the time. "Is it done yet?", "why does it take so long?" and "your coworker would've been done by now!". Yeah fuck you, too. Not only was I not relaxed any more, I was even more stressed than before my holiday! Thanks, you stupid bitch.

Well, her arbitrary deadline came and the feature wasn't ready. And what happened was... exactly nothing. The following week my coworker returned, who gave me an apologetic smile. "I told her the feature was nowhere finished. And even me, being familiar with the task, couldn't make it in time". We finished the feature together that week, and that was the end of it. So... "Head of PO" either didn't listen or lied to me. She then stressed me to the max right from the day I came back from my holiday. And in the end it didn't even matter.

Again, thanks you stupid bitch, for creating a toxic work environment. Should you ever read this, I'm happy I quit and I hope you miss every single deadline for the rest of your life. Screw you.

This was not exactly the worst work culture because the employees, it was because the upper level of the organization chart on the IT department.

I'm not quite sure how to translate the exact positions of that chart, but lets say that there is a General Manager, a couple of Area Managers (Infrastructure, Development), some Area Supervisors (2 or 3, by each area), and the grunts (that were us). Anyway, anything on the "Manager" was the source of all the toxicity on the department.

First and foremost, there was a lack of training for almost any employee. We were expected to know everything since day-1. Yes, the new employees had a (very) brief explanation about the technologies/languages were used, but they were expected to perform as a senior employee almost since the moment they cross the door. And forget about having some KT (Knowledge Transfer) sessions, they were none existent and if they existed, were only to solve a very immediate issue (now imagine what happened when someone quit*).

The general culture that they have to always say "yes" to the client/customer to almost anything without consulting to the development teams if that what was being asked to do was doable, or even feasible. And forget about doing a proper documentation about that change/development, as "that was needed yesterday and it needs to be done to be implemented tomorrow" (you know what I mean). This contributes to the previous point, as we didn't have enough time to train someone new because we had this absurd deadlines.

And because they cannot/wanted to say "NO", there were days when they came with an amount of new requirements that needed to be done and it didn't matter that we had other things to do. And the worst was that, until a couple of years (more or less), there was almost impossible to gather the correct requirements from the client/user, as they (managers) "had already" that requirement, and as they "know better" what the user wants, it was their vision what was being described on the requirements, not the users'...

And all that caused that, in a common basis, didn't have enough time to do all this stuff (mainly because the User Support) causing that we needed to do overtime, which almost always went unpaid (because a very ambiguous clause of the contract, and that we were "non-union workers"**). And this is my favorite point of this list, because, almost any overtime went unpaid, so basically we were expected to be working for free after the end of the work day (lets say, after the 17:00). Leaving "early" was almost a sin for the managers, as they always expected that we give more time to work that the indicated on the contract, and if not, they could raise a report to HR because the ambiguous clause allowed them to do it (among other childish things that they do).

Finally, the jewel of the crown, is that they never, but never acknowledge that they made a mistake. Never. That was impossible! If something failed on the things/systems/applications that they had assigned*** it was always our fault.

- "A report for the Finance Department is giving wrong information? It's the DBA's fault**** because although he manages that report, he couldn't imagine that I have an undocumented service (that runs before the creation the report) crashed because I modified a hidden and undocumented temporal table and forgot to update that service."

But, well, at least that's on the past. And although those aren't all the things that made that workplace so toxic, for me those were the most prominent ones.

-

* Well, here we I live it's very common to don't say anything about leaving the company until the very last day. Yes, I know that there are people that leave their "2-days notice", but it's not common (IMHO, of course). And yes, there are some of us that give a 1 or 2-weeks notice, but still it's not a common practice.

** I don't know how to translate this... We have a concept called "trusted employee", which is mainly used to describe any administrative employee, and that commonly is expected to give the 110% of what the contract says (unpaid overtimes, extra stuff to do, etc) and sadly it's an accepted condition (for whatever reasons). I chose "non-union workers" because in comparison with an union worker, we have less protections (besides the legal ways) regarding what I've described before. Curiously, there are also "operative workers", that doesn't belong to an union, but they have (sometimes) better protections that the administrative ones.

*** Yes, they were in charge of several systems, because they didn't trust us to handle/maintain them. And I'm sure that they still don't trust in their developers.

**** One of the managers, and the DBA are the only ones that handle some stuff (specially the one that involves "money"). The thing that allows to use the DBA as scapegoat is that such manager have more privileges and permissions than the DBA, as he was the previous DBA

Well , this isn't a rant or a joke , so I just thought I should post it here in case people are going through a similar situation . So I know this guy , who works at this startup , so he had just joined the company and made a huge impression on the boss ( My friend is fantastic in developing ) , so as great as that sounds , it doesn't . After a year or so , he's been promoted and is now kinda a face for the devs of the company and this made his boss very cocky , like he would take so many projects or requirements of his top clients and place them on the shoulders of my friend and give a bad time limit , which is impossible but he always managed to just finish completing it . Naturally it affected his sleep cycle , his daily life and as a result , his mental health . As time went on and as more and more projects were being placed on him..........he finally broke , he used to miss so many days of work , not return any of my calls or texts , miss lunches , have breakdowns . I became very concerned and didn't want him to end it , I went to his place , spoke to him , found out that he had suicidal thoughts . Fast forward a year later , he's still going to a shrink , everyday but he's better now and after forcing him to talk to his boss and now his boss gives him plenty of time to finish the projects and said to be straightforward with how he feels and so on . I know this isn't what you would expect to find here but I just wanted to say after having this experience , please do not keep quiet , be straightforward with your boss and don't overburden yourself , if you're an introvert , tell it to someone you know , to tell your boss , and if you know anyone in a similar situation , do be out there for them . I'm sorry if this kinda spoils your mood , but people have to be aware . Be careful , lots of love people

I've heard about some of the ridiculous requirements that some companies have in job postings and always thought that they're probably over exaggerating a bit.

Holy shit was I wrong.

I've taken a look at the positions that they have posted for my coop program and while I understand that my college was not the only one posted to for these, they seem pretty extreme at times. There were a few postings that required several mountains of web frameworks and experience that unless you did a lot of self study prior or had previous professional work experience would have been impossible.

We're students, a lot of us have never touched an IDE prior to our program so to ask us for in some cases years of experience in a language or tool that I have never even heard of, nor have even been even vaguely mentioned by profs, seems a bit much. I have had years of experience in a fair variety of tools and languages but even for me this seemed a tad bit unreasonable. Not all of the postings require this much prior experience in the field so I can apply to some.

The professor teaching the preparation course says they can't understand why people apply for the coop program then don't apply to positions. While I understand there are people who might not apply due to laziness or an overflow of assignments, I feel like a good chunk just can't find any positions that they may be partially qualified for.

It's funny how you start feeling bad for the next dev taking over your project because it turned into a total spaghetti code shit show that will be impossible to maintain in the future with new features coming in.

Honestly... if a projects starts out with a certain scope which then gets extended EVERY FUCKING WEEK with requirements that can't even be met in the initial timeframe it's no wonder the code quality will decrease over time.

This just reminds me daily how important good project management (and I'm not talking about suit wearing pain-in-the-ass-managers) and the inclusion of devs in the planning process really is.

It's so fucking crazy that companies run like that with people up front that have NO FUCKING CLUE what they are doing, nor do they understand the mechanics, tech and effort that go into certain features. They're like "beep, boop, it's done by Friday you fuck!".

The funniest part of this stupid charade is that the closer we get to a new "deadline" (we will not meet the deadline anyways) the more nervous the "managers" get. WHY didn't you properly plan this shit in the first place? WHY didn't you care for the last six months where all this fucking bullshit could still have been prevented?

Meanwhile I'm just so sick and tired of this shitty project and this sucky company that I just don't have any motivation left to keep on working. It's so fucking hard and painful to work on projects that suck ass, are poorly designed. I just got to the point where coding is no fun any more. Thank god I'm out of here soon... fml

Hello all,

I am an apprentice, 19. I joined this software developer apprenticeship to leave college as it was not particularly great for my mental health, and programming is the only thing I can do reasonably well.

The company that I find myself in is a strange one. It has about twenty or so employees, but we all instructed to operate as if we are a giant company—our sales person, for example, will tell our clients that we have hundreds.

The development team is a collection of software developers. There is no database administrator, network administrator, software engineer (not in name only), test engineer, requirements engineer, etc. There are just several software developers. Of these developers, one has left by now. When he joined, he was promised to be working on a new system: he left after spending seven years on an old system. A new developer has just arrived to replace him: he was told he would be working with Raspberry Pis; it was interesting to see his face after we informed him that we do not use Raspberry Pis.

The codebase is fourty-years-old and written in Delphi, which is some kind of cousin of pascal, from what I understand. Code is not peer-reviewed. Instead, it is self-reviewed, and you just push whatever changes you make. The code is very much spaghetti, and there is a whole array of bugs that, at least to me, look impossible to track down and fix. I have a bug assigned to me at the moment were someone appears somewhere when they are not supposed to. After asking seniors about this, I learn of this huge checking mechanism and all of its flaws: a huge, flawed checking mechanism... for toggling a single boolean value. This isn't a complicated boolean value, by the way, this is just a value to say whether someone has clocked in or clocked out of a building, via a button.

In terms of versioning, we have several releases, and we often do development work in older releases (or new releases and then write them into older releases) because our clients are larger than us and often refuse to upgrade, and the boss does not want to lose any contracts. We also essentially have multiple master branches.

With the lack of testers, bizarre version control, what appears to be unfiffled promises to staff, etc. I must ask that, since this is my first gig as a software developer, is any of this normal?

Describe one instance when you thought, "Fuck this shit, I'm done with this client". Preferably when the client came up with stupid/impossible requirements

I want to quit. I don’t feel like writing code anymore. I feel burnt out. As fuck. People keep changing requirements leaving me to do the impossible. And honestly do their dirty work.

Ok ok ok, I will preface this by saying I am still a student so you can assume my complete and utter lack of experience.

There is all this fuss about unit testing and TDD but i still have my doubts about it. How is it that if your code works for certain inputs you can be sure that it will work for whatever can happen after deployment?

I mean, to my understanding testing can assure that some business requirements are cared for but as far as actual code correctness goes I don't see how that is achieved.

As far as i am concerned the closest it comes to complete code correctness is a mathematical type of proof but that should be impossible to be done effectively in an OO language.

How can you be sure that your code is what you think?

(If i have this all wrong please correct me)

I hate reactive management.

It's when your boss instills fake urgency every time a client asks for something close to impossible, or <x> competitor is doing something in a different way he deems the best.

Everything must be dropped, the sprint put on hold, fuck requirements, everybody has to do overtime, why are you not contributing?, why are you going home when you have to?, fuck do I care you have a 1 hour commute - this <y> thing has to be made by sunrise tomorrow or it's a showstopper.

And it's never a showstopper. 90% of the time the feature gets dropped one-two months down the line.

Business people are so fucking stupid. What is their job really, other than asking us to fill out bullshit paperwork and make up requirements that are either impossible or unnecessary.

Hello everyone, once again I’m asking for your help, for the first time I’m working as a counterpart for an external development company, this project already has a few months of work but there are not any technical documentation or quality metrics.

Would you suggest to ask all the necessary stuff with times, quality and requirements or it’s already impossible to do that?

So being in ops, I have certifications in networking and Linux, and am currently working on my Certified Kubernetes Administrator exam.

I've been talking to a few "professional" (they have jobs) devs that I personally know, and with the exception of 1, it seems like version control, automation, networking, and server related tasks are beyond them.

As I want to get into the dev side of things (devops preferably), I feel somewhat overwhelmed at some of the requirements of the job, especially knowing that I cannot take too much of a pay hit as I have a family to support.

My question is this, based on real world experiences with hiring, how much weight do you think knowing your way around networks, cloud, virtualization, servers, and all of the other things ops does when it comes to getting your foot in the door for a dev job?

I've casually looked around, and it seems that getting the foot in from this side is almost impossible.

#Suphle Rant 3: Road to PHP8, Flow travails

Some primer: Flows is a feature that causes the framework to bypass handling the request now but read it from cache. This cache entry is meant to be populated without warming, based on the preceding request. It's sort of like prefetching but done on the back end

While building Suphle, I made some notes on some chapters about caveats and gotchas I may forget while documenting. One such note was that when users make the Flow request, the framework will attempt to determine who user is, using authentication mechanism defined on the first module (of the modular monolith)

Now, I got to this point during documentation and started wondering whether it's impossible for the originating request to have used a different authentication mechanism, which would result in an empty entry for returning user. I *think* it's possible cuz I've got something else called "route mirroring", where web based routes can be converted to API routes. They'll then return JSON, get served under defined API path, use JWT, all automatically. But I just couldn't connect the dots for the life of me, regarding how any of this could impact authentication on the Flow request

While trying to figure out how to write the test for this or whether it was even necessary (since I had no use case), it struck me that since Flow requests are not triggered by an actual user, any code attempting to read authenticated user will see nothing!

I HATE it when I realize there's ambiguity or an oversight, after the amount of attention and suffering devoted. This, along with a chain of personal troubles set off despondency for a couple of days. No appetite for food or talk. Grudgingly refactored in this update over some days. Wrote some tests, not all passed. More pain. May have to convert them to unit tests

For clarity, my expectation is, I built this. Nothing should be impossible for me

Surprisingly, I caught a somewhat lucky break –an ex colleague referred me to the 1st gig I'm getting in 1+ year. It's about writing a plugin for some obscure forum software. I'm not too excited cuz it's poorly documented and I'll have to do a lot of groping, they use arrays instead of objects etc. There's no guarantee I'll find how to implement all client's requirements

While brooding last night, surfing the PHP subreddit, stumbled on a post about using Rector to downgrade a codebase. I've always been interested in the reverse but didn't have any incentive to fret over it. Randomly googled and saw a post promising a codebase can be upgraded with 3 commands in 5 minutes to PHP 8. Piqued my interest around 12:something AM. Stayed up all night upgrading it, replacing PHPSTAN with Psalm, initializing the guy's project, merging Flow auth with master etc. I think it may have taken 5 minutes without the challenge of getting local dev environment to PHP 8

My mood is much lighter than it was, although the battle is not won yet –image tests are failing. For some weird reason, PHP8 can't read generated test images. Hope I can ride on that newfound lease on life to study the forum and get the features working

I have some other rant but this is already a lot to digest in one sitting. See you in rant #4

Everyone here rants about clients, and as far as I understand frustration, I understand client's side too.

For 2 years I have developed a tool for our company, my manager was responsible for outcome and was directly accountable to company's management, which made him a client for our product. Of course requirements changed many times, he pressured us much, but he is nice guy and gave us knowledge why we had to change things again. We had meetings with him, HRs, PMs and others to gain requirements for features to implement and that made me better understand client's point of view.

My point is that when you work for external companies, you only see changing requirements, pressure, deadlines, etc, but don't think that your work is just a part of process - your client is responsible for your delivery, wants to make good impression on superiors or company needs some feature ASAP. He does not have to know tech stuff, he wants outcome to be good and to be fast and cheap - that is business.

And yes - we had to tell people that X is impossible many times, had to tell Y people how things work over and over. It may seem easier when it is your own company, but note that every single employee knew that you developed that tool and you have answers for his questions.