Ask HN: What are the boring parts of software development? | Hacker News Reader

Ask HN: What are the boring parts of software development?

8 pointsdevstein30 comments

Hey HN, we are building Dosu (https://dosu.dev/) to help software engineers with all the boring, "engineering knowledge work" that happens outside the IDE.

Everything from fielding technical questions from sales to helping product groom the backlog.

What types of boring "engineering knowledge work" would you like to see automated?

View on HN

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.

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

Keeping up with 1000 slack notifications per day.

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

Alerts? Github notifications? Internal questions?

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.

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.

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.

Over discussion over mundane things .

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

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.

Dealing with customers and managers.

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.

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.

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 :)

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

Reply on news.ycombinator.com