Hacker News Reader

Comment by b0rsuk | Hacker News Reader

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.

View on HN

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.

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.

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.

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...

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.

Reply on news.ycombinator.com