Comment by sdnlafkjh34rw | Hacker News Reader

Comment by sdnlafkjh34rw | Hacker News Reader

Parent Full thread

There is a con to being a product minded software engineer. When you are in organizations that do checkbox driven development (i.e. build features so it looks like your product has the widest feature set), it can be disheartening. You will ask why build this? and will get a believable answer. However, once it get's built you will notice that no one pays attention to the feature (no analytics, no reports, no iteration, etc.). At some point in the future, maybe a year or two down the line, you will notice a huge bug raised with the feature. Whoops for 20% of the users, it didn't work. You feel bad at first for your bug, but then realize, that no users even noticed the feature gone. Your suspicions that you were building something that didn't even matter are confirmed.

This has happened to me a lot. I was on a team that was on one of the "most important" projects to the company. We had the CTOs daily attention. You felt important and we had a large team who worked hard to ship it in one year. It was deemed a success by the CEO and myself and many of the team members got staffed on other teams (basically the next highest priority project for the company). Some other engineers got put on legacy duty for maintaining the project. After a year, I barely heard about the project (we had so many new projects) but we still maintained it and it was still on our website. 1.5 years later, I get a p2 bug that basically shows the whole product had stopped working for 3 months due to a front end bug. I got pulled to fix the bug and worked hard to find it and fix, but at the end I was demoralized because I realized my team had wasted a year on a feature no customer cared about enough to complain until 3 months after it stopped working.

Basically, it can be really demoralizing to be product minded engineer if your organization is not. This happened in an org that heavily talked the talk about product market fit and testing, but the truth was we were checkbox driven. We just wanted the widest feature set among competitors (even if they didn't always work).

> You feel bad at first for your bug, but then realize, that no users even noticed the feature gone. Your suspicions that you were building something that didn't even matter are confirmed.

Having been in a position where I was talking a lot to users, I can assure you that they do notice. But they won't report it, just shrug and have a slightly decreasing opinion of your software.

Says a lot about software developers and IT in general doesn't it? That users would rather just work around the problem and continue doing their job than even bother telling us about it.

Well, it does says a lot about users too. The typical user would have a hard time describing a software problem beyond 'I don't know, it is just not working anymore'.

That is a terrible attitude IMHO - why should they have to have to learn how to talk to developers? Your cynicism towards “typical users” probably harms you and your career.

I find that the vast majority of people are not stupid: they have learnt that trying to get things fixed is usually a waste of time. As a developer I truly understand this from when I’ve tried to get others to fix their software, and I am very good at describing problems.

Regularly I am the one that created the software problem, and if I were a better developer I would have avoided making the problem in the first place (or had ways to detect it, or easy ways for my clients to tell me).

Edit: simplified.

> That is a terrible attitude IMHO - why should they have to have to learn how to talk to developers? Your cynicism towards “typical users” probably harms you and your career.

I think I'm sensing a bit of anger in your tone, looking how you move the subject on my person. Sorry if I offended you in any way, it was not my intention to offend anyone. Me and my career are ok so far, if that's of some relief to you.

We are surely not working in the same area then. Mine is as a vendor of enterprise stuff, for Big Corps. In my place, not relying in users' proactive and qualitative feedback is a pretty decent attitude in my eyes, it tends to deploying more reliable software, thus to invoices actually collected, which finally leads to having an actual paycheck.

Which would have been sufficient, probably. But they think it's so obvious that someone must have reported it already.

I usually try to make a point of educating the users that, when it comes to software, there is no such thing as "it is not working". Software always works; it might work incorrectly, unexpectedly or confusingly, but the only way for software to "not work" is that the hardware never switches on at all.

Says a lot about people tbh. I've had frontend dev's work around backend issues instead of reporting them.

I have two points for you.

1. There are many extremely important features that may only be needed once or twice a year. For example I work in developing cost estimating tools. The tools I build are extremely important, but some of them may not be used for 8+ months out of the year and new bugs could go unnoticed for quite a while. Unless you are familiar with the internal processes of customers this could easily be true for your product features as well for reasons that might not make immediate sense and you wouldn't even know.

2.I would argue that being a product focused engineer requires you to go the extra mile and learn about customers business processes. Product Owners should include engineers in some meetings for use case analysis and voice of customer interviews. I also find it extremely valuable to personally provide support directly to some of the highest value customers because you will learn what you need to know in order to implement features better and requiring fewer updates/changes down the road.

That scenario is common even at product driven environment.

As an engineer, I try pushing back to reduce the scope of a product down to a MVP that can be released earlier with analytical data monitoring its usage.

As an engineer, you can identify the features that take the most time to implement and can see about pushing back to a version 2 release. If it is a critical feature, then try to find alternative solutions that can be implemented in less time.

That way if a product is a flop, you didn't waste all your time. Even if it is a success, the MVP is often good enough and they still deprioritized the extra bells and whistles.

I relate to this hard. I joined a company a while back where everyone below a product manager (there was little real 'engineering' management) was a line on the factory floor to delivering features, and fixes.

PM would hold a monthly sprint planning/refinement, 'senior' engineers would participate in breaking each piece of work into tiny, tiny tasks, and then split them up into streams of designer, developer, tester.

Each tiny task would take an hour-half a day and you wouldn't even necessarily be working on the same code base across tasks, just continually turning out tiny 1-3 point tasks.

That was by far the most soulless job I ever had, weeding these companies out is my number one priority when interviewing.

What are some questions or flags you use to weed those out? How well have they worked?

Would a UI test have cought the bug?

Reply on news.ycombinator.com