Jackie Chan's Best Advice | Hacker News Reader

Jackie Chan's Best Advice

weedonandscott.com

90 pointsoDot62 comments

I'm afraid lots of comments are missing the key point in the original post: Do not conflate “the best you can” with “perfect”.

The advice is not about perfection, but challenge YOURSELF to do the best you within the constraints such as budget, deadlines, available resources, etc.

One thing I got from the Bhagavad Gita is the quote “you are entitled to your actions but not the results”. To me this means you should do your best but should into expect specific results. Once you have done your best you did all you could do. The results are out of your hands.

I might have learned an instance of this. I repeated a Beat Saber song over and over until it was perfect but it lost tracking for a note in the middle and I didnt notice until the end, aargh. I did it again and then the left controller battery died on the third last note. It didn't matter.

Don't let the perfect be the enemy of the good.

Something I keep having to remind myself, and other engineers in teams I work on is "Good enough is good enough".

There are plenty of projects they're working on that could be better if they could spend another week or two working on it. But is it sufficient to actually justify that time vs working on other projects? Can we quantify how much difference that extra polish will make several months down the line?

I find it hard to fight myself, because no small part of me sees my work in the same way Durnik does:

> "Always do the very best job you can," he said on another occasion as he put a last few finishing touches with a file on the metal parts of a wagon tongue he was repairing.

> "But that piece goes underneath," Garion said. "No-one will ever see it."

> "But I know it's there," Durnik said, still smoothing the metal. "If it isn't done as well as I can do it, I'll be ashamed every time I see this wagon go by - and I'll see the wagon every day!"

I landed a huge improvement on a product at work about 9 months ago, after months of work on it. Cut execution times down by a huge amount and made the customer experience more consistent. Managers look at it and see what I achieved. I look at it and see all the things I don't like about it, all the ugly hacks and things that make it work.

I have a pretty pessimistic approach to programming nowadays. I like Rust language because it gives a very good result "on the first try" - meaning, the compiler does a very good job making the program bulletproof. I don't believe any company will give me a chance to write good, polished software. They just want whatever works. There is no refactoring, only maintenance.

The alternative is programming as a hobby rather than a profession. But I would need to find a comparably well paying and stimulating profession first.

Exactly. You will have ridiculous deadlines, you will have to implement stuff in an extremely shitty way because you have no time for higher quality code, and you will spend the rest of your time there unfucking the code, or other people's code that has been made as quickly as possible because of deadlines, and this is just an example.

> I don't believe any company will give me a chance to write good, polished software.

I do not believe it either, especially due to my experiences. I do not work in IT for a reason.

Any company that wants to survive long-term doesn't do that. So go work for those instead. Companies who treat code this way aren't software companies, and they ain't gonna stick around for the long-run. They just use software for some end, and given their apparent lack of attention to detail, they will go out of business pretty soon. That is the majority, unfortunately.

This is basically a red flag for mismanagement. Even startups can't work this way. You either need to hire engineers who have enough experience to make the right trade-offs under high pressure, or you will likely not survive the long race after initial MVP and funding. However, a lot of startups are not funded for the long run either, but rather to quickly make money for founders and potentially be bought by some large fish, who stamps out competition and replaces the product anyway. So there is that.

> Any company that wants to survive long-term doesn't do that. So go work for those instead.

You would be doing valuable service to the community by naming a few names

> Any company that wants to survive long-term doesn't do that.

I have a list of at least 6 large corporations who do just that. When I worked at Polaris, they re-developed all of their sites on a six month rotating basis so if some new fangled tech came up, it was easy to take advantage of it. They were one of the first companies I knew who were running full-stack JS apps in prod before most people were even considering it.

Even where I work now, its all about speed to market. Get it working, release it, and then all the execs and upper management types pat themselves on the back about how awesome they are because they got a janky ReactJs app for users to use in less than 6 months. Several months later of fixing all the problems, they start talking about just scrapping the whole thing and starting over.

Its maddening to think these people believe what they are doing is somehow groundbreaking in software development. When in reality, they're just releasing a really poor version of their software, spending more months fixing it than the time it took to get it released and then killing it or transitioning to some new shiny framework they want to use instead.

OP was spot on in what my experience has been the last 10 years of my working in large corporations and small agencies.

Obviously I'm not going to name my past employers or even hint by saying what industry it was. But people are skilled in presenting the next software trend as a cure-all. Agile, micro-services etc can be used as just distractions to avoid doing anything serious about present problems.

Yes and no. A lot such things are fads indeed but as you yourself noted, Rust gives you a lot of runtime stability just by the mere fact that the program has compiled.

There are some cure-almost-alls. Most are fashion. Sadly it's how it is in software and it doesn't seem like it's ever going to change.

> Any company that wants to survive long-term doesn't do that. So go work for those instead. Companies who treat code this way aren't software companies, and they ain't gonna stick around for the long-run.

I wish this was true, but in my experience it's not. The company I currently work for has an old crufty codebase, large areas of which are not understood by anyone but the few remaining early hires. This codebase is going on 20 years old and is getting more complex with every release. And yet our revenue grows year after year because our competitors are far, far worse.

Another company I worked for years ago has by far the worst code and development practices I've ever seen. I'm talking about having the actual Visual Studio solution running live on the production server, and development was done by opening it in Visual Studio and hacking on it while it was running. I have never seen such towering incompetence before or since. I left partly because I was convinced the company would implode within a couple of years due to a developer accidentally nuking the production database or because the cost of developing new features would exceed any new revenue they could possibly bring in. Five years later, somehow they're still going strong.

> Companies who treat code this way aren't software companies, and they ain't gonna stick around for the long-run. They just use software for some end, and given their apparent lack of attention to detail, they will go out of business pretty soon

Most large companies in the world (e.g. banks) have appaling code and coding standards. As far as I know, none of them has yet gone bankrupt because of bad code.

I think we probably overestimate how important code is. The business world, esp. large companies, is very far from perfect (more of a big fat mess that somehow still works and produces money without its products killing people etc.) and it doesn't need perfect code, the same way it doesn t need perfect accounting or perfect product design. In most cases, mediocrity will do, because the competition is just as mediocre.

If you want perfect (or even very good), become a hobbyist instead.

> I think we probably overestimate how important code is.

Or maybe the cost of swamp code is distributed over many people and non-programmers have difficulty understanding how much it slows down programmers. Programming is hard enough as it is because we need to translate human to very abstract, and work with very abstract on a daily basis. I think it's borderline genius to be able to do the translation both ways. That is, to make non-techies really understand the cost of messy code.

The problem with perfection in software is that you need to deliver in a certain timeframe to be useful. Very rarely you can have perfect code delivered at the perfect time.

The problem with your comment is that it's responding to something I didn't say. When there's a mess in a warehouse, it slows the work down and causes mistakes. Somehow people understand that an orderly warehouse means you need less space and lose less time moving things around. This is how ports used to look:

https://drek4537l1klr.cloudfront.net/geewax2/v-10/Figures/ch...

It's all how you look at it. The devil is in the detail. What does "good polished software" really mean? Is it code that is understandable, efficient, and reusable ... or does it mean trying to achieve some personal ideal of perfect software.

Does refactoring provide a business advantage or just a pathway to attempting code perfection?

If you are in it for the art, then you need to find that shop that is in it for the art. Many aren't. I'm sure some are.

If you are in it for providing outstanding code because it provides personal satisfaction or meets your world view, then great. It sounds like you need to find a way to provide what you want to provide in a timeframe that is almost as quick as the alternative.

If you want to achieve personnel perfection and can't find a way to be almost quick at delivering a viable product as the alternative, then either you change, accept it, or move on.

You sound like you are competent and have a world view. I would figure out ways to speed up your output (through templates or language choices that match who you are). If your code is great and you develop it fast, the people who are rushing you won't have a leg to stand on.

If you are good, you can have it all.

You're spinning a false dichotomy and frankly I don't need to respond to that. There's a spectrum between "code is not touched unless there's a new feature/bugfix ticket" and "code needs to be perfect". It's annoying and time consuming to keep tripping over code that does five similar things in five different ways, and has dependency graphs looking like a giant hairball. Don't try to make me say what I didn't say.

Yes I've been learning F# recently, and I definitely can tell all the .Net documentation was created by people who's job it was to create it. Not "good, polished" documentation.

Stark contrast to things like Elixir where there's a labor-of-love aspect to it.

Bad documentation SUCKS. My experience with open source software is that the projects that are most successful are those with great documentation. Documentation greatly lowers the barrier to using a tool and makes people spend less time getting the hang of it.

Software doesn't live forever. Good enough and soon enough is enough.

With experience, you realize that minimum effort in the key places that bring maximum result is the name of the game.

Obviously "minimum" differs from situation to situation. Just enough effort, but not more than needed, but not too little either.

For years I've been mystified how certain people who make bad software engineering decisions over and over --but do so quickly and with commitment-- rise up in the leadership ranks. I'm talking about people who join projects like a hurricane, don't pull in all the relevant data before making a technical call, and their work /always/ has to be replaced or cleaned up 6 months later.

I finally realized that there's usually not a "perfect" engineering solution, and you can spend weeks or months going back and forth on a plan. So the people that just plow ahead --even if not great-- wind up delivering "something", which is better than nothing. And put another way, they land 2 failures and one moderate success in the same amount of time the rest of us are busy landing our one single success... which also winds up being only a moderate success at best because writing good software systems is hard!

Look up "satisficing". It's a wonderful concept.

Sometimes even a wrong decision is better than no decision, and that is so antithetical to how I want things to be it took a lot of pain events to beat that through my skull. But it is true nonetheless.

Often the decisions aren't wrong, but they are sub-optimal decisions. That's what I've found at least.

Sub optimal can move the needle and that's what a lot of people are looking for.

There the tragedy of the commons. You see it in software, where individual teams or people can make decisions that seem overall correct for them but have an overall negative result overall. I've seen this when you have shared components that require core platform updates. One group working for one customer needs a new features without considering the other customer that uses the same platform or may want the same feature but with a slightly different configuration or interface. It adds to technical debt and reduces overall productivity in the long run.

You see this in open source projects too where code gets forked and then it becomes difficult to adopt features from mainline or the other forks etc...

I find that to be almost entirely untrue. I am far more amazed by how long things I have written stay around. Websites I helped create in 2005, integrations that just hummed along without anyone paying attention to them for over 10 years, and tiny utility desktop apps that people just keep using 'cause they do the job. I've definitely decided that I'd better put some spit and polish on things because it almost certainly is going to last longer than I expect.

There's a really big power law for this though. Some of my code has been running for close to 15 years now and I fully expect it to run at least that long into the future. At the same time I also have written software that got decommissioned after a year because the business division was spun down.

The highest value code I ever wrote was probably a 50-100 line script that collected some data requested for due diligence and which eventually clinched a >200 million USD investment round for the company. That script was never used again after that.

Hah. Same experience here. When I get asked at interviews "what is your recent work you are most proud of?" and I can't bring myself to cite my Elixir or Rust work (even if I did some pretty solid work there in the last years) and the first thing that immediately springs to mind is how I actually invested two days in a shell script that did a job (making PDF invoices in a system that wasn't meant for that but the data was in the DB) that the management thought is going to take 3 months.

Since then I changed my LinkedIn headline to: "Solving problems with technology".

That's what people care about. Not which language we use.

Probably depends on where you work? I've worked in startups for most of my career (15 years) and I find the GP's comment more true. 2 companies I've worked for no longer exist (including my own startup), and 1 company I worked for turned into a unicorn -- I left that co 7 years ago and I'm fairly certain none of the code I wrote during my 6 years of work there is still operating anymore now.

which is fine if there's not competition (e.g. internal software).

Add competition to the mix and "good enough" might put you in the ground.

Interactions are more than just about the software. It what separates Disney parks from Six Flags.

I think this great if you have the luxury of not doing certain things. I often envy people who can focus on one thing and if they are good at it then they are set. People like athletes, artists or actors. A lot of normal workers don’t have that luxury. In a lot of jobs it doesn’t really matter how good you are as long as you fulfill some minimum requirements. Or you have a ton of tasks you aren’t good at but can’t get rid of. I became tech lead because I am a good programmer but now I have to do a lot of stuff I don’t like and am not good at as much as I try. Focusing only on programming would unfortunately cause a significant pay cut because you are not paid by excellence but by job title.

Life is too short to not really apply yourself in the things you choose to do - and if you're not doing your best, choose something else. Unfortunately I learned this lesson quite late in life.

I understand where you're coming from, but you don't have to pursue your absolute best in everything you do. It's fine to just "do" things casually. I think people would be much happier if they prioritized participation over mastery.

Yeah, you will soon burn yourself out if you try to do the best in everything. It's really a matter of choosing a few key place to focus your energy and put in extra effort there, but to make sure you leave enough to do other things in life.

There is the main course meal in life. But I still enjoy the side dishes.

How late? Late 20s? 30s, 40s, or 50s? I think that, having come to the realization, you're already probably far ahead of the curve.

I've been very inspired by Mandelbrot's life, lately. Reading "The fractalist", his memoir, it's possible to realize two things: 1) how incredibly resilient he and his family were; 2) how he worked from his own definition of success: the fact that he ended up achieving what most people define as undisputed success was almost incidental. He was, to use Joseph Campbell's words, following his bliss.

Mandelbrot was born in 1924. The Mandelbrot set was discovered in 1980. Of course he worked on important things before that, but having his major discovery in the mid 50s puts things in perspective.

Who cares about best in Software Engineering? Time and again I've wanted to do the best, to be asked to just provide a "workable solution" because either the best costs time or money. And I get it, business is all about tradeoffs. I do the best in domains where I have the complete freedom to do so.

I agree. As well as for most jobs.

I think Jackie's perspective makes a lot of sense as a creative artist though. The extra effort has a tangible reward and is appreciated by those around him.

You can consider reframing the problem: what's the best I can do, given the constraints (time, money, resources, etc.)

I find that I'm most creative when I'm constrained. And these types of mindset hacks allow me to enjoy whatever I work on.

There's an argument I believe that the best art comes when the artist has to deal with constraints. The lack of freedom in certain directions forces them to go deeper in the other directions.

yup, just like in society where you're not allowed to talk about or question things that haven't been approved for conversation, but you can dive infinitely deep in areas that are approved.

> "Who cares about best in Software Engineering?"

Systems and low-level software such as compilers, operating systems, platform software. A bug in the kernel affects billions of devices, a bug in AWS/Azure/GCP affects millions of VMs.

'Best' is something that ought to be defined otherwise it can mean anything.

In any business the bottom line is king and time and resources are limited (in fact that's the way it is for about everything in life). You can still do your best while delivering a "workable solution". In fact being the best at delivering workable solutions is a very good and fulfilling aim. You can strive for quality with sensible design, least number of defects, etc. while delivering on time and within budget.

I think this kind of advice is a symptom of the real issue. Which is that when you think you can’t do something your brain is often lying to you. You want to be lazy and find a way around the problem, but often you can complete the task, it is just challenging and thus parts of your brain wish to avoid it. The solution for me is to identify that my brain is lying to me and doing the things it tells me I can’t do. Alternatively sometimes this manifests as fear and all I have to do is to follow my fear.

>> I try to follow it with everything I do.

I mildly disagree (commenting mostly on the article, less on JC). I certainly don't treat every aspect of my life "the best I can", but rather my time is precious and I try to be smart about my time. Where is it best allocated? Folding laundry to my best ability? I could certainly research it and become an expert, but is this good use of my time? Is this how I want to be known as? Is this this how I want to define myself?

Time is precious. Know where to spend it.

The article's basically saying do the best you can to achieve the goals you really care about.

In your case, one of these goals seems to be making efficient use of your time. So, the article would advise you do the best you can at that.

Making efficient use of time is rarely an end goal, but necessary to achieve most other goals.

"A delayed game is eventually good, but a rushed game is forever bad" - Shiguru Miyamoto

*distributed on cartridges

I can think of multiple examples of rushed games that are good, or became good - though Miyamoto's quote here may have been before the era of internet updates.

I always said if you do something do your best at it. If you find yourself not doing your best, then choose not to do it. If you can't choose not to do it, that means this is essential, and so go see #1 again. Do your best.

I think of it from the same perspective of business. Instead of doing OK support do your BEST support. If you are struggling, then choose to do no support - if your customers leave because support is critical, then guess what, you will probably get more benefit from doing your best.

So I think that advice works well as a way to really minimize your engagements, and figure out which ones are essential, by not just doing them just cause, by trying to cancel them entirely otherwise.

With all the respect I have for Jackie Chan, his quote is IMO just trying to tell you: "Try harder! Hustle more! No excuses!".

No. I disagree.

The world finally started noticing that mental health actually exists and it deteriorates when you are being treated as an assembly line robot that can barely (if ever) stop.

We don't exist only to keep trying harder until our bodies cannot take it anymore. There has to exist a better way to be productive, useful, fulfilled and successful. But almost nobody is looking for that another way.

In terms of current modern economics and ways of treating workers, we are in a local maxima and seldom anyone cares looking around for a taller hill.

Yes, it's not clear to me that we have a moral obligation to be "best" or do the best we can, even if there was no mental/physical price associated with it.

(Let alone "best" is not clearly defined but I take it as quality/performance/output - frequently materialized in money or professional advancement).

Sadly nowadays there is no real incentive to try harder for most people -- except maybe "don't stop or all the money you poured into mortgage will evaporate and you and your family will be evicted".

That's not motivational, that's being threatened with a big stick for a huge chunk of your adult life.

Jackie Chan's advice definitely applies to his work -- movies and stunts. I can see how his words are true in that area. What many successful people keep missing however, is that their advice is very far from universally applicable.

The difference is that a lot of software is forever unfinished. I was about to say "if you work on a game, or a desktop app maybe" but even that is not true anymore. Games are patched almost weekly nowadays.

This advice can absolutely be applied to making a movie, writing a book, painting a picture, etc, but not to software.

I'm ok with trying to be excellent at a few things and good enough at everything else.

This is depressing. I always like to think "people will understand" but no, no-one cares. They only care about the end result.

This is exactly it. Excuses are only for you. Other people don't care if you're sorry, only if you're good at what you do. So be good.

Follow this advice by left-aligning your text please :)

Reply on news.ycombinator.com