Hacker News new | past | comments | ask | show | jobs | submit login

> incompatible programming philosophies

This really hits home for me. I'm at my most miserable when working with people who value doing things fast more than doing them well. I suspect those people are also at their most miserable when working with me. I see them as creating work that I'll have to do eventually to clean up their mess, and I suspect they see me as an insufferable gatekeeper.




Do you enjoy cleaning up their mess? If so, is it not the perfect environment, where everyone is doing something they do best and enjoy?

Or do you dislike cleaning it up? In this case, why do you do it? Noblesse Oblige?

Asking because I love refactoring. I also love pushing features fast. But I absolutely dread having to do "perfect code" in the first try. I keep trying to push this idea (inspired by Mythical-Man-Month) here in HN that a perfect team would have people "working fast and breaking things" with people working behind them that love refactoring everything cleaning it up.


> Do you enjoy cleaning up their mess?

Of course not. I may enjoy cleaning up my own messes, but not one that someone else has foisted upon me. The problem with teams like this is that the fast-movers are long gone by the time the impact of their expediency is being felt. They benefit from the accolades of a launch while shirking the responsibility of operating a product.

> In this case, why do you do it?

Because the product sucks and needs to be improved, but it is an unimprovable mess because everything was done expediently instead of well, some of which needs to be fixed in order to move forward. A lot of the hard work at this point is in figuring out the best pragmatic balance of what to fix vs. what to leave alone. A little forethought could have saved a lot of post-facto toil.

I do like iteration, doing things in small iterative chunks. But that is not the same as putting out a huge mess and hoping someone comes along who enjoys cleaning it up.


> The problem with teams like this is that the fast-movers are long gone by the time the impact of their expediency is being felt. They benefit from the accolades of a launch while shirking the responsibility of operating a product.

Yes, :100: :100:

I have seen this happen so many times. It's a vicious cycle of horribleness. The same people always seem to get the new development also because they were "so successful with the last launch" and the people maintaining it are perceived as slow and ineffectual because it takes so long to iterate (ironically because of the person who looks like a rock star).

I feel very lucky in my career that I don't have to put up with this anymore. If I could go back in time I would just tell myself to quit and find a more compatible company instead of suffering for years under a self-destructive system that punishes people like me. Since breaking free from that and starting my own projects, I've been very successful.

I don't mean to imply that I always write perfect code, or even great code, because surely I don't. I do expect some things to be throwaway that end up staying around. But doing something correct rather than fast in general is a much better long term strategy. Vary as necessary (but only when necessary).


I'm not the GP but I fully agree with what he said, so here is how I would answer your question:

I HATE cleaning up people's messy code. It's 10x easier to do it right the first time. Messy code to me is most messy because it's unclear what is being done. It often comes with insufficient tests, which makes refactoring dangerous.

To me it's a lot like walking into a messy house vs. a clean house. If the house has clutter everywhere, or has a smell from being dirty, then it's not comfortable to be in. If I have to work in it, or clean it, I'd much rather start with a well-organized clean house.

Refactoring is also not fun at all for me. I also LOVE pushing features fast. I don't obsess over "perfect code" but I do obsess over following best practices and stopping for a few minutes to think through a design.

My workflow is:

1. Get it working, minimal effort, PoC

2. Get tests written and passing.

3. Refactor to good code. Perfect is the enemy of good, but it doesn't get committed until it's readable, maintainable, tested, documented.

Sometimes I probably am a little slower than I otherwise could be, but people are often blown away at my ability to iterate and add features quickly. This is because my code is well organized, modular, DRY, and well tested. It takes a little longer the first release, but it more than pays for itself speed-wise as tech debt stays minimum and hackability is high. With over 10 years experience now with this method I'm convinced that it's the only sane way to do things. Anything else is sabotaging your own future.

If I really don't have time to do it right the first time, I know it will be hard to iterate on, it will have bugs in prod, and it will never be pleasant to work in. It takes 10x longer to refactor an existing app to be good code than it does to do it during development when it's all fresh in mind. The best hope is that it has a good spec so it can be re-written from scratch.


Maybe you should switch to a different programming domain. For example, embedded systems and security software tends to value correctness a lot more than e-commerce does.


This is less a current problem than a phenomenon I have seen over time. I do agree that different technologies attract different kinds of philosophies and it's definitely something I keep in mind when thinking about what to work on.


You're not alone friend. I am in this boat as well. Hopefully some day we'll work together and we can admire each other's beautiful code :-D


I should say: I have worked with lots of people who have a compatible philosophy, I would even say most of the people I've worked with do. But it really is the quickest and most severe way for me to become deflated by my work, when I come across someone who is constantly pushing against me to cut corners while I argue for them not to. I really think it makes us both miserable; they could usually have fixed whatever I'm asking them to fix in the time they spend debating me about it, but they don't want to, because it's the principle of it or something, and they think I'll go away. But then I don't, so we both waste tons of time without a very positive outcome.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: