Ask HN: What's likely to suck in any development job? | Hacker News Reader

Ask HN: What's likely to suck in any development job?

13 pointsPopeDotNinja38 comments

Also, every tech stack sucks, and if your tech stack doesn't suck, either you haven't worked with it long enough to get disillusioned or you're not doing anything particularly hard.

The grizzled old guys who say that something "doesn't suck" and mean it as high praise aren't just understated cynics; if anything, they're getting swept up in a wave of irrational exuberance.

Edit: Also, there are never enough conference rooms.

Upvoted just for the conference rooms.

Ha, I don’t even think about tech stacks sucking, I just deal with their suckage as part of the job. If I had the time to make my own stack I would, and it would be amazing initially but probably suck a year or two into it.

Kudos to the sucky stacks that managed to stick around.

You will get excited by some new technology, but eventually burn yourself out on programming, from doing it all day, to the point of never getting to use that new exciting technology for anything personal.

It is very hard to break this cycle, but not impossible.

There will always be ugly legacy code. There will always be competing interests between departments / stakeholders, etc (Development vs Marketing vs Sales vs Executive). There will always be some shitty person that makes your life difficult.

Tech debt. You’ll never have time to pay it all down and even when you do, it starts accruing again quickly. If you can’t live with a certain baseline level of imperfection, you may want to look for another career.

Tech debt is like real debt. In business it should be leveraged for growth, but beware of interest payments.

Everybody, including yourself, will always underestimate the complexity of your tasks.

The worst is when you're in a meeting with a non-technical manager and another developer is like "this task is trivial, I could do it in X hours".

It's becomes like a weird intimidation thing where people don't want to argue back because non-technical managers might think you're just slow at development or don't know what you're doing.

Touche. Don't want to lose the reverse auction!

Being too good. There’s nothing worse than being an amazing developer, with bosses without clear visions of what to build.

Every project you’re assigned takes you 3 days instead of the slotted 3 weeks and you start getting board out of your mind.

Eventually, you start making silly and fun side projects to alleviate the boredom. Eventually your silly side projec turns into a real product, and maybe you have a customer or two.

Maybe you quit your job to jump right into it. Maybe it succeeds or fails.

The moral of the story: a boring job is the worst but can also be the best.

Some projects never ends. i can't work on long projects i sort of lose interest after some time.

In the same sense, some projects never end because your PO/manager won't let you finish them. I've had a handful of projects that were supposed to make it at least to MVP phase that were just killed at the 60-70% mark.

Contracting is a good option for this. You move around every 6 months or so which means you don't really spend enough time to get burned out by any single project.

>> 80% of programming jobs will have you work on something that is not meaningful to you personally or address big problems like climate change, corruption or other significant miseries that plague the world.

(It's of course possible to get a job that doesn't have this problem!)

Sometimes working on the smaller problems can be more rewarding than being a drop in the bucket for bigger problems.

Yes, hence the "or" :)

Your “or” referred to significant maladies. By smaller projects, I’m referring to something smaller than that.

Creating a government website as a contractor, allowing folks to communicate across great distances, programming accounting software for a hospital, building test hardware for a racecar... none of these will save the world, but there is plenty of meaning in each, depending on the person.

Which would clearly fit the part before the or: "meaningful to you personally"?

Fair, my point was only that there are ways of being gratified without succumbing to the cliche of changing the world.

In my experience: issue management, because every company has required JIRA for some strange reason.

What is your preferred alternative?

Not sure yet. Asana seems much better. Basically anything that doesn't encourage upper management to enforce unnecessary process. The fact that 2 of the 5 companies I've worked with have had full time jobs dedicated to "JIRA administrator" suggests that it's a majorly overcomplicated solution.

yeah... as someone that has used both. Asana sucks.

I feel like Asana is too unstructured last time I used it for a job.

For example if I remember it has no issue numbers like JIRA making it hard to reference tasks succinctly.

You mean administrating JIRA processes or administering the software itself? Any web app you install on your network is going to need to have someone managing it.

So far I have been pretty happy with Trello, actually. You can configure it as you want.

That said, at this point just use the bug tracker that is built-in to your git hosting solution.

I never really get the hate for JIRA.

When configured & used properly, it's a lovely tool. When interviewing with companies, them using JIRA is a huge plus for me personally and I would definitely rank them higher than those using something else.

Agreed. Admittedly I've only used JIRA at a couple of smaller places with small teams, and perhaps it fails if you have massive dev teams, but so far it's been pretty great.

Every other tool I’ve seen used would be an even bigger clusterfuck with massive dev teams. I can’t even start to imagine trying to manage tasks for 500 people in Trello or Asana or that rinky dink tool that I can’t remember what it was called. None of them have enough structure to keep track of the work of 5 people, let alone 100 times that.

Criticizing JIRA is easy, because it has enough rough edges that people get unhappy with it and, while it’s highly configurable, configuration is hard and odds are the way your JIRA workflow is configured doesn’t quite match the way you would configure it if it were up to you, because it manages the organizational concerns of what needs to get done and by whom in a consistent way independent of the personal concerns of the people doing the work.

Jira is like C++ or representative democracy or capitalism: compared to your internal mental model of things, it’s a needlessly complicated and shitty system, but try to find an alternative that sustainably works for as many different use cases before writing it off.

(Also, much like these things, Jira takes a lot of heat for things that are just part of the human condition but only seem that way because it’s a mechanism for addressing facts about the world that are inherently annoying to us, especially the fact that a lot of people want dumb shit that you may not personally agree with.)

My issue with JIRA is not that it's bad. As you've rightly said, it's a lovely tool that does everything you might need for project-based work.

My issue is that JIRA takes a long time to set up in an optimal way. I've worked at places with great JIRA setups, but burnt-out PM's that would spend ages setting their sprints up. The time either came from working late, or neglecting other duties to get stuff done for the devs, which isn't ideal for a project that needs management.

The secondary problem is when you work with someone that really knows JIRA, it becomes the tool for everything. They've invested a lot of knowledge into the platform, so why wouldn't they push it for everything? It's no different to a developer gaining a ton of WordPress knowledge and deciding that WP can be a data store for every software product.

JIRA gets a lot of hate from people because they have experienced colleagues/managers trying to use it to manage everything when all that is needed is a bug/feature tracking system. So basically it gets turned into a 'task tracker' when all the devs want is a 'bug tracker' with the result being that a) reporting on tasks becomes more important than doing the tasks, and b) the bug/feature tasks get lost in the noise.

If you work at my employer, having to write secure code seems to be the bane of these developers existence.

People much less smart than you will manage your project and will try to tell you what to do.

I would say the tech envy and the closely related “if we use this new technology X we will solve all our problems” instead of actually doing the hard work to be able.

Meetings, bosses, limited independence, severe time-drain.

The tech is always behind, what should take 1 minutes will take two days.

Legacy code and legacy architecture :)

Reply on news.ycombinator.com