8 ms·

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 compile

by b0rsuk 6y ago

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.

johnisgood 6y ago
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.
jmann99999 6y ago
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.
- b0rsuk 6y ago
  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.
marta_morena_28 6y ago
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.
- srean 6y ago
  > 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
- at-fates-hands 6y ago
  > 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.
antoineMoPa 6y ago
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.
- b0rsuk 6y ago
  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/ch11-shipping-before-containers.png https://drek4537l1klr.cloudfront.net/geewax2/v-10/Figures/ch...
natchy 6y ago
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.
- b0rsuk 6y ago
  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.

by b0rsuk 6y ago

johnisgood 6y ago

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.

jmann99999 6y ago

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.

b0rsuk 6y ago
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.

marta_morena_28 6y ago

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.

srean 6y ago
> 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
at-fates-hands 6y ago
> 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.

antoineMoPa 6y ago

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.

b0rsuk 6y ago
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/ch11-shipping-before-containers.png https://drek4537l1klr.cloudfront.net/geewax2/v-10/Figures/ch...

natchy 6y ago

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.

b0rsuk 6y ago
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.