Since you're all on DEV - I think it's safe to assume that you probably like development, or at the very least are interested in it... but if you're one of those who are lucky(?) enough to do it as a career - which parts of the job do you really dislike?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (32)
For me, I really dislike:
Oh... and React
What's the reason to diskike React?
I second this. I'm genuinely curious as to whether people who hate React think it's "easier" or "better" for large dev teams to build modern, complex web apps—which, at any given moment, could exist in a near-infinite combination of states and state transitions—in vanilla JavaScript?
Or maybe I'm on the wrong path here, and said React-haters come from traditional CS backgrounds where anything that doesn't strictly adhere to OOP and its 4 attendant pillars is seen as the work of the Devil. In which case, I'm gonna put my career on the line here and say I hate OOP and would choose alternate paradigms (e.g. FP) without blinking an eye.
Or maybe I should stop generalising and accept that there's likely a multitude of reasons people may dislike React, many of which I might not be aware of.
LMAO, same as Structured process .
But I like React🤣
JIRA is a poorly designed piece of software. You're forgiven for ever having to use it. Whoever thinks JIRA, Confluence, Salesforce, Dayforce, and other commonly deployed enterprise solutions is good software is only kidding themselves. It's also rather expensive to license those products - the per-seat cost is astronomical (i.e. the "call us" variety).
Having goals in life is a good thing. HR means for the best. But the method of execution always seems to come off rather awkwardly in a semi-disconnected-from-reality sort of way. They are fine folks but they have to toe the line between the business/financial side and the personal side.
Freelance web developer here. Looking for a client and handling negotiations.
If it has to be a technical aspect, it's probably dealing with the security of an application.
I've never really freelanced that much, and when I did I was lucky enough to have clients who were happy to pay by the hour - so there was little negotiation involved. I can't imagine I would enjoy that part of freelancing very much either
My first work was freelancing and client negotiations were the worst.
I sort of feel like having had enough time away from this kind of work, I'd probably only re-enter if I knew I had a really strong game plan on how to set boundaries and handle all of this stuff systematically. It seems like this can be 80%+ of the work at times, when I'd prefer 80%+ being on the work itself.
yeah, spending most of my time looking for clients and negotiating with them is one of the things I dislike about freelancing. I just want to do actual work instead of social legwork.
yeah it's a pain
Overengineering. I didn't knew before is possible to spend so much time on discussing how to reinvent the wheel. Some people may tell it's ensuring the quality but for me, for QA responsible are tests and code review.
I think this does indeed happen a lot. I think most developers, given the choice, would prefer to build as many things as possible themselves - there's more of a feeling of learning and accomplishment in this - you feel more like an actual architect/developer than a manual labourer. Obviously not the best approach in a business setting though :)
Code review is for the birds.
If you're in the customer projects business:
Luckily I got out of this business, I'm doing product development now. Others:
I'm not a full-time developer anymore — which I mostly miss. One thing I definitely don't miss from my particular career (mostly small startups) is the severe on-call needs. I really felt like I could never be too far from my computer, and would have a lot of "unknown unknowns" anxiety.
Interesting - even in very small companies I've always managed to keep a very clear separation between work and life
On call is dreadful
Never experienced that. Can't be fun
Unnecessary meetings
One company I worked for actually told employees that if they found themselves in a meeting that they thought was not relevant to them - to simply say so, and leave
Support Rotations
As a concept, I don't mind support, but I switched from IT into Engineering to get away from the bottom tier of support after performing the duty for the entirety of the 2000s.
Having Sunset projects pulled off the shelf
In 2018 the company I was working for was acquired. The project I had been leading was discontinued in favor of a competing project with a more favorable tech stack. Personally, I was relieved because it allowed me to dodge the tech debt that had begun to pile up in the project, and I used the opportunity to dictate what I wanted to work on next. Unfortunately, the CEO decided to pull the project off the shelf a few months later to appease one of the company's largest customers.
Thankfully, leadership opted to hire contractors to pick up on the discontinued project, but it was a few stressful days before that choice had been decided.
Customers
Simply put, some customers end up being assholes, either taking up a disproportionate amount of time or by belittling those who they communicate with. When you're just a member on a team and not in charge of the product, you can't fire the customer for their bad behavior.
Poor Performers
It can be very frustrating when you have team members who are poorly performing and impacting your workflow. This could be a fellow engineer, but it could also be a product manager, customer support, or QA. I've nudged leadership on more than one occasion in the past to hold poor performers accountable in order to stabilize the team and manage expectations.
Designing the app 👨💻, sometimes one design seems nice but once the styling is applied i think this could look better and keep on changing the styles endlessly.
Iam talking about web apps, i do not have much experience with mobile app development
The only thing I really dislike are meetings where nothing is decided and nothing happens as a result. The best meetings have at least one action step because that means there is some forward momentum even if it is just one little baby step.
The only thing I dislike more than the above is the next meeting where those who had something to do from the previous meeting did absolutely none of the action steps. The outcome of such meetings is the exact same set of action steps from the previous meeting. And tends to lead to no forward progress made for multiple meetings in a row.
I also somewhat dislike how some people see they have a meeting later that same day and start blasting out a bunch of emails to get their previously assigned tasks done in advance of the meeting. I'm pretty sure those people are the sort of folks who waited until the last minute to do their homework for school (sometimes 5 minutes before the next class started). I understand that sometimes it's not possible to do due to a very busy schedule but it should be rare rather than a constant. The behavior also indicates what those people think about the priority of the project. They might say the project is important just to sound good but it's clearly not a priority for them.
On a software development front, the only thing I dislike is spending 6 hours on a bug only to find I mistyped a variable name by one character - or something equivalently braindead that I should have spotted immediately but didn't. Sure I get paid for those 6 hours but it's a massive waste of time and money. It happens but I don't have to like it.
Disagreements in approaches where there aren't necessarily "right answers" — just lots of heuristics and pet approaches.