4 ms·
> Once you have reached at least junior level, start learning about how to split the system into subsystems and putting some additional thought into it. Before
by Zababa 5y ago
> Once you have reached at least junior level, start learning about how to split the system into subsystems and putting some additional thought into it.
Before learning about how to split something into multiple parts, you should start by learning about why you would want to do that.
> If you want to work in finance, accounting, sales, investor relations, partnerships, business development or whatever, go do that. If you want to work creating software, start caring about how software is created, or at least don't ruin it for people that do.
Again, before that you should learn about the why. You are writing software for someone. Why? For most people, especially when doing "web stuff", the why is going to be way more important than the how. Carefully crafted software is useless if it doesn't fit what the business wants. Better than that is bad software that still fits the use case. Even better is carefully crafted software that fits the use case.
- 29athrowaway 5y agoRight, then let's create spaghetti code where everything is coupled together so that no other developer can understand each other's code, with comments in Klingon. That is certainly a deliverable a company can use to grow a team of multiple developers and focus on making progress without being constantly interrupted by incidents, defects, downtime as customers roasting and demoralizing customer support representatives and leaving bad reviews online. Those slow requests in your logs mean a human is looking at a spinning wheel asking why the fuck they bought your software. That is good for the business. Your product being affected by a security breach is excellent for the business. Your company infringing licenses because everyone is copying and pasting shit from the Internet is great for the business. The mythical, romantic image about "business" is just the place where lazy developers run to when they want to stop caring about work. Real business people want software that does not break everytime a sales person is giving a demo, want a good reputation and do not want to create opportunities for competitors to have a superior product. Talking about business is not a valid replacement for doing the things that are actually favorable for the business.
- Zababa 5y agoAll of your post is one long strawman. I could copy your structure by replacing "bad code" with "no business utility" but I don't see the point, as it would be a strawman too. > Right, then let's create spaghetti code where everything is coupled together so that no other developer can understand each other's code, with comments in Klingon. I reject the idea that you need to split your code into services as soon as multiple developers are working on it. I also reject the idea that everyone needs well-encapsulated piece of code to be able to work, with careful comments explaining everything and a great documentation. That's the ideal case, but life is not always ideal. Some code that you will have to work with is not perfect, and you have to understand it and modify it. Deal with it, that's your job. Sometimes the business needs one small feature delivered in a few days, not a month-long refactor to make "clean code".
- deleted 5y ago[deleted]
- 29athrowaway 5y agoIt only takes a month if you have a lot to change. If you keep things in order it should not take as much.
- Zababa 5y agoI work on a codebase of 16 millions lines of code. In general it's a relatively good codebase, but it's far from perfect. Some things are easy to refactor, so we try to do it. Some other would require big architectural changes. Sure, I would love for the product to be perfect, but perfect evolves with time, and the codebase is 35 years old. You just have to live with imperfect code.