Design documents are my bane now

Design documents are good: they force one to think about what they're doing before they do it. Too bad they've gone out of style, since they directly contradict the "agile" approach where you just fix it in the next sprint...

My issue with this is that there's a lot of times when it's faster for me to just build the thing. And building the thing is going to uncover problems a lot faster and a lot more accurately than me sitting down and trying to imagine all the problems that may possibly occur, and then missing problems anyway because it turns out reality is way more complex than you can plan for.

Design documents are great in situations where risks are high, or where code changes take a long time to do (usually because every code change requires a design document).

I don't know how much is required of you but I find it very valuable to take my iPad to a coffee shop and flesh out my idea on "paper" before I code anything. Then it becomes a lot easier to code the right thing.

Design docs don't contradict agile at all. If you had said scrum then I might agree.

I meant "scrum." I have worked in "scrum" shops that would leave team for design, but it is a rarity.

It's common knowledge that documentation bugs most people i guess. Congrats on building stuff!

Not sure if my answer qualifies but I make iPhone and Android apps (I am the developer of HACK for hacker news) and part of it also involves me designing the App Store metadata (screenshots, writing the description, researching keywords, app icon design etc). I find it very boring.

Documentation!

Keeping them updated especially. We have UI components that people tend to make duplicates of because they don't know "dialog screen with two buttons" exists, but the docs are always out of date, and cause more harm than help.

Honestly, I think everything from coding to documentation to testing to setting up the dev environment, and infrastructure very boring. I just want to create products that solve problems!

How do you expect to create a software product without doing any of those things?

By having someone else do it all for me :)

Keeping up with 1000 slack notifications per day.

Agree. Where do you find the majority of notifications coming from?

Alerts? Github notifications? Internal questions?

Over discussion over mundane things .

Product managers that basically do nothing. Know nothing. Then push it onto the engineers to do their job. Its rife. Analysts much the same (depends on the job of course, but very common).

What would be a better workflow? Would it be useful if Dosu took a first pass at clarifying tickets with PMs?

In line with this, Product and Customer Success folks who fundamentally don't know how customers are using the product/what their specific use cases are. Really makes further development/problem solving a challenge :)

That's why I want to be PM. No actual work, no deadlines, no hard interviews, no leetcode grind, no system design. And get paid the same

(I am considering this to be lighthearted so I will continue in the same vein) .. No estimating how long each individual piece of their work takes, no tracking their work items on a board, no saying what they did yesterday, everyday, no knowledge sharing or training, no upskilling, no being the expert of anything, no questions being asked of stuff they did 5+ years ago

Status meetings

Agreed! The status meetings we've thought about are:

- Status of project - Summary of weekly work (retro) - Breakdown of work by project

Any status meetings we are missing?

Daily standup.

I work alone, on software that supports my main business. I have fewer collaboration and scaling issues.

I find ops tedious. Simple things like serving a website or monitoring uptime and builds is slow and annoying. However if I don't automate those things I have to do them myself. I find it hard to get all the important messages pushed to me instead of checking a bunch of different things.

Sometimes it feels like there's a bunch of yak shaving involved in making your code run in production.

Rituals that are there because some manual says so... Dailies that turn into micromanagement... Anything that has no meaning.

I feel this one. I think there is a ton of room for automation in daily/weekly reporting and status updates

Writing tests, making configurations, CI/CD setup, DevOps (Docker, Kubernates), Systems Admin, Designing schemas, debugging.

Anything that doesn't have anything todo solving the core problem.

I suspect this is why NoSql & serverless platforms have become so popular.

The fact that I don't have to think about schemas & systems admin so much made them so attractive to me.

Code documentation and overall project documentation are boring to do, yet required for long term success of any software project. It helps with on-boarding new engineers as well as maintaining a log of what transpired over the previous months and years and why certain choices were made. I would also include all team communication over slack, jira, bug trackers etc into this documentation. Writing it, Organizing it, Enhancing it, Updating it and sifting through them is extremely boring work. I have to dig out old e-mails or messages from the ERP from old colleagues if the documentation does not match the actual features, now that is really boring.

Dealing with customers and managers.