How to waste time and overcomplicate things | Hacker News Reader

How to waste time and overcomplicate things

ryanwarnock.me

203 pointsscrappydew54 comments

Note that in this case it happened when the author had the full context of what as needed to get done.

In business, the situation is usually even worse. The customer needs some problem solved. They assume the easiest way there is to get a different problem solved. They ask a customer support-type person about that. The CS person assumes a solution is best, and then go to a project manager. The PM assumes a particular implementation is best, and goes to a developer.

By the time the developer is trying to solve the customer problem, it has been transformed into a different problem at least four times, by mere assumptions that rarely have anything to do with reality.

Always, always ask "Why am I doing this? What evidence do I have that suggests this specific thing absolutely needs to be done?"

One of my favourite quotes is "It ain't what you don't know that gets you in trouble, it's what you know for sure that just ain't so."

----

It's not a small effect either. I've heard serious, well-reasoned estimates ranging between 50 % and 99 % of our work being completely unnecessary busywork.

Imagine that. In the most pessimistic (optimistic?) case you could spend half the year sipping drinks on a beach and still get just as much truly useful work done.

Without trying to make it sound too profound - Since I had the realisation of the mistakes I made in the process I wrote about, I have actually been going over other times I had found myself frustrated and most of them could have been prevented by doing as you suggest. Simply asking "why am I doing this?" and I think more importantly "what is the evidence supporting that this needs to be done?".

I had a good reason to write those scripts because I thought I had a problem, if I had tried to find evidence that I actually had that problem and I needed those scripts (by just doing a test run) I quickly would have realised it was all unnecessary.

I think I'm hitting this issue right now, do you happen to have any links to studies or processes or methodologies that address this?

The scientific method. Don't look at the world through the lens of your knowledge. In fact, forget about the word knowledge. Replace it with "hypothesis".

The world is a lab. Shape it in ways which you think will prove your hypotheses false.

I was more thinking about how to get the people around me, who don't think like that automatically, to work with me on that process.

I can see and understand the pointlessness happening, which is a bit alienating when other people think they are doing hard important work and I think/know they aren't, and I need their buy in to avoid them asking me to also do things I know are pointless.

If I wanted to do pointless things (and I'm not sure I'm even capable of that) I could probably get paid a lot more by changing job, but I'd rather change my job to be less pointless, as it seems better for my mental health.

Aha. To some extent I think it's a hiring and/or organisational values thing. You need the right people to congratulate each other on the right types of work for it to be a long-term sustained thing.

There are also some more formalised versions of the scientific process applied to the workplace. Mike Rother's Improvement Kata come to mind.

Edit: also get good at negotiation! People are complicated and refuse help even when they obviously need it. Being a good negotiator ideally helps everyone.

Second edit: another thing is leading by example. That's been very powerful in my experience.

When you discover they’re solving the wrong problem after they’ve invested in their non-solution, people can get pretty defensive, too.

You’ve described about half of the tyre swing comic :)

https://m.imgur.com/gallery/mFWSFNP

I have this problem where I work in IT.

I get handed a task which has been decided by layers of several people, I complete the task and then the client comes back to me, wondering why what they want doesn't work, the problem, the task I was asked to complete doesn't solve the original client problem or only partly solves it because many people that did not understand the issue or do not have the technical understanding defined what needed to do and the issue is I had no visibility of the original issue, which I could of easily advised or sorted had I been involved in that.

What happens is they decide what needs to be done and then send me the task, I have no idea of the original problem or what this task does in relation to the chain of everything else.

Instead it's me looks bad and me the client is upset with, while the others that decided this have long gone and moved onto something else.

This is why I no longer do things when people tell me to "do X". I want to know the context: which problem do we think we are solving with X? Why do we think that is the right problem to solve? What other problems could we solve instead?

It makes me a pain in the ass, of course, but a highly effective pain in the ass, I hope, and it seems also one that customers appreciate.

Edit: Oh, and whenever someone says "the customer needs X and Y" the important follow-up is "what makes you believe that?"

Sometimes there's a good reason. Often it's "they said during a meeting that so-and-so, which makes me think that maybe so-and-so, which, if so-and-so, implies that so-and-so."

> Oh, and whenever someone says "the customer needs X and Y" the important follow-up is "what makes you believe that?"

Yeah, that. If possible, the right thing to do is go to that customer and ask "hey, a quick question, what are you trying to achieve when you use that X or Y feature your asked for?"

In my experience, the odds of they answering your question are about as large as the odds of they saying "what are you taking about? I have no need for X or Y and never asked for them." While if you keep talking to the PM, that second answer will never come through.

I'm quite fortunate that leadership at my job (IT) has a very strong "don't let the customer tell you how to solve the problem" mentality. Even stating directly that at times.

Why?

Because this is exactly what happens. IT-adjacent business customer comes and says they need X. Often via a couple conversations we can figure out that Y will do a much better job solving their problem, we develop it, and everyone goes away happy.

Of course, sometimes this results in curious escalations where the customer is frustrated that they aren't getting X, but this is becoming more rare, because aforementioned leadership knows that what the customer wants isn't always what they need (nor best for the company).

I work for someone that will pick apart your every idea and make sure you are solving the right problem. The number of times I've been convinced we had to do something for him to figure out the problem is actually in another part of the business is embarrassing. It's a skill I hope to develop myself. It's much easier to just sign off on something and say that's a great idea go for it. To make sure you understand the problem down to the smallest detail and clearly assess if it's the best solution requires a dedication and focus that many managers lack.

In the [Japanese] company that I worked for, they had some serious process around evaluating proposals.

Basically, you had to have the project designed, before pitching it. After that, it had to go through a lot of folks, flinging poo at it (They called these meetings "Design Review" meetings, or "DRs").

It certainly resulted in relatively successful outcomes (and I saw failures, where managers let stuff pass without that level of detail), but I think it also killed a lot of good stuff. Some ideas are worth approaching, even if the approach has not been fully mapped-out.

I'm a huge fan of "Evolutionary Design"[0-1]. It has served me well, but is not for the faint of heart (or the inexperienced). If you don't have a lot of experience (as opposed to intelligence and/or education), then I do not recommend this approach.

I am also a fan of "biting off more than you can chew"[2]. Again, I would only recommend this for experienced people, if it is for shipping projects.

If not for shipping projects, then go for it. Knock yourself out.

[0] https://littlegreenviper.com/miscellany/forensic-design-docu...

[1] https://littlegreenviper.com/miscellany/evolutionary-design-...

[2] https://littlegreenviper.com/miscellany/thats-not-what-ships...

I agree. A complete up-front design is basically a way to guarantee that you will get several key parameters wrong.

That said, even a very rough outline of an idea should be subjected to an appropriate amount of high-level criticism.

> I work for someone that will pick apart your every idea and make sure you are solving the right problem.

Caveat: One may have to reframe the problem to really solve it http://www.azarask.in/blog/post/the-wrong-problem/ | https://archive.is/uLlkx

>pick apart your every idea and make sure you are solving the right problem

Can you give some examples? Have you identified any specific methodology/process at play here which can be learned?

> The customer needs some problem solved. They assume the easiest way there is to get a different problem solved.

This is why I made it a habit to (almost) always ask my customer for a use case.

Yes. "Could you walk me through the entire process where this would fit in as one of the steps, from when you learn about the need to when it is satisfied?" is one of those questions that often open up the big picture more.

Working with someone else’s assumptions without first reviewing them inevitably leads to new problems. Because someone had a _faster_ way…

The best is that when it comes full circle and the customer doesn’t even recognize what is being proposed as an answer to the same problem, accepts it with the understanding that it’s going to advance the product in a different direction, but is still quietly waiting for you to solve the first problem they asked about.

No the best is when you sweat for weeks or months delivering something you have to shoehorn into the product design, only to discover that what they really wanted was something that would take three days, but they thought would be harder to do so they didn't ask.

This is where the internet sucks. I'm sure I could treat us both to beverages of choice and enjoy the story behind your comment.

Hi everyone,

I'm the author of this post. I'm not sure who shared it and it is a little bit embarrassing that my first blog post which ends up on hacker news is about how I stuffed something up. I'm sure we've all had similar experiences at one point or another.

Cheers to learning from our mistakes.

Probably because it's so relatable. It's nice to see we're not the only one making mistakes that, in retrospect, seem avoidable. :)

Man... I clicked on the link and skimmed the headings... for a moment I was convinced this will be about geopolitics.

How did you know it ended up on hacker news?

I've notified people I know when they end up on HN. Also, maybe some analytics thing?

I got a text from a friend saying he had seen a post on the HN front page from a site with my name. He wasn't even sure it was my site.

I hadn't spoken to him in around a year so it was actually a nice way to start a little chat :)

Have you looked at the much simpler to use tool Unmanic?

https://hub.docker.com/r/josh5/unmanic

Wow thanks for linking this, in my search for media management tools this actually never came up. It looks like it does exactly what I would like while having a much nicer UI than Tdarr. I'll check it out sometime soon.

The project lead is very good at DevOps and has done an amazing job of bundling everything up in one easy to use package.

Making things overly complex seems to be very typical among developers who are trying to move beyond the beginner stage. You'll grow out of it as you gain experience. There's a saying about how experienced developers write code that looks simple and straightforward like a novice's, but is correct.

Thankyou, this post resonated a lot with me.

I hope to save some you a click and let everyone know that this article is not, as you may have assumed from the title, about React.

Throwing shade /s

I thought it's going to be a more general guide to self-inflicted pain and suffering, not limited to a specific case. Dan Greenburg has a book on the former: https://www.goodreads.com/book/show/598825.How_to_Make_Yours...

React isn't the problem. The React ecosystem is. You can build literally anything with one dependency (react) and four functions (createElement, render, useState, useEffect).

People spend months messing around with all sorts of ridiculous bullshit and then go and post on HN about how complicated React is. But somehow it was just fine in 2016 when the API surface was like twice as big. The only difference is that in the last few years everyone has somehow become convinced that the "best practices" are to spend 6 months inventing a 3D printer at the start of every project while your competitor builds your product in a weekend with just a chisel.

Had to scroll back up to reread the title. This is an excellent joke.

I encounter this issue many times a week. A client encounters a difficulty, decides on the spot what needs to be done to solve it; and then goes on to request the solution is implemented.

Taking that solution, and running with it, will often be a disaster.

Not because the client is an idiot, or uninformed .. but because the client often won't be in a place to understand the greater context.

'Greater context' here involves functionality in macro sense (new features need to live within the landscape of current features), as well as the technical constraints and costs associated with carrying out any work. It's information a client most likely won't have access to.

How can it be solved?

Research problems, not solutions.

Ask for a description of the problem; refuse any solutions. Understand what needs to be improved.

Solutions come later.

Been there a few times, plan to keep visiting. Hopefully those scripts you wrote and threw away were designed and written at the highest level of professional competency.

IIRC the solution steps should be Step 1: make it work, Step 2: refactor, Step 3: optimize. I think you did Step 1: unoptimize, Step 2: undo

They were, of course, the most professional scripts :)

I think you've managed to describe my development process fairly accurately and gave me a good chuckle. Thanks for that.

Author’s scale is too small. I would argue he learned a few thing, did not waste a lot of time, and it was just another not-so-complicated approach.

In a setting with many people and departments, and each having their own agendas, things get really complicated. Information is misunderstood, twisted, biased and acted differently when it reaches actual person who does the work.

I feel like the title for this post is my biography, the minute I saw it, I felt personally attacked.

Sadly the article really doesn't live up to that title in terms of what I was hoping it would do as it's just a personal antidote about someone setting up a video encoding system but something I gotta work on I guess!

Completely off-topic, but the first thing that came to mind reading this title was Microsoft. I dare say that this one company is dragging all humanity behind in technological progress. You can't imagine how many people take hours performing simple tasks that should not last more than a few minutes. I see it every day: "Office" applications, new but slow [asf] laptops and many others. Those machines are supposed to get things done, but instead they end up being an excuse for miserable people.

I hate talking politics but it angers me so much I just can't get over it. The money-capital system supposed to drive innovation is exploited by big corp just to make more money, dominate markets, or just make people feel safe doing almost absolutely nothing wasting time and getting payed for it.

A sad world.

I see it as a violation of WET principle[1]. I have a long history of violating it myself, and with scripts it is basically the same: do not write script for any task, before you solved this task at least once. Moreover writing a program to do something oftentimes longer that just doing it. But I constantly fall into this trap and writing programs to run them once when it would be faster to do just the task at hand without any complications.

[1] https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-ev...

In contrast, when I heard the problem statement, I thought that this is probably something I could do with ffmpeg and a little bit of shell scripting. No need to download, install, and configure and learn (or not...) another application. Then again, my media setup is also likely to be far simpler than the author's, and my usual way of thinking when problem-solving is "do what you can, with what you have, where you are."

I actually did consider just using ffmpeg or the HandBrake CLI but I was pulled towards Tdarr because it offered a web accessible GUI which means I have easy access from all of my devices like my phone to check on the health of the process and make changes from that.

The first assumption I make is,“I’m wrong.”

Rather than assume the veracity of my thoughts or approach, or my memory of how things work or how I previously implemented something or solved a problem, I remind myself that I’ll save time and effort if I stop, review and consider what I’m planning to do.

Do I need to do this? Of course not. But when I don’t, I sometimes find myself wasting time, and inevitably returning to check my assumptions.

Hello, maybe a stupid question but why complicate your setup with Infuse? I've only tried to use jellyfin once, but it seemed like a complete media center that takes care of transcoding. What am i missing?

The Jellyfin app can't save videos for offline playback. In addition to that, I regularly run into random hiccups and playback issues which I haven't had happen with infuse. The web interface for Jellyfin and the overall experience is incredibly good in my opinion however.

> The Jellyfin app can't save videos for offline playback

That's unfortunate indeed. Is it planned to be implemented at some point?

> I regularly run into random hiccups and playback issues which I haven't had happen with infuse

Could it be that Jellyfin buffers are too tiny? Or that it's using a higher framerate? In any case, it sounds like it's worth reporting to the Jellyfin project.

Have fun

I think a lot of the app's issues arise from not being a native app. There is work to develop a native iOS app[1] which looks really promising. Unfortunately that doesn't have an option for offline playback just yet but it is in the works.

[1] https://github.com/jellyfin/Swiftfin

Hindsight is 20/20

Reply on news.ycombinator.com