4 ms·

If you have never designed or developed software before, by all means try that. Once you have reached at least junior level, start learning about how to split

If you have never designed or developed software before, by all means try that. 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. The business doesn't give a shit about the implementation. Very true... that's why they hired you so that you fucking do. Just do your job. 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. If you decide to follow a business career path, you will find that they also have to care about their job, have attention to detail and care about good practices and compliance. In fact, that will also be the case for every occupation in every sector.

bradleyjg 5y ago
Systems divided up into subsystems include microservices architectures but that’s not the only way to get there. Like so many fads in our industry microservices solve a problem that giant, famous companies have and are aped by thousands of companies that don’t, and will never, have those problems.
- 29athrowaway 5y ago
  OK, then if not microservices, then the problem will be programming paradigms, programming languages, data structures and algorithms, interviews... everything that forces you to think will be a problem. We have to stay mediocre and keep the bar low, to lower the entry barrier to software and depress wages.
  - bradleyjg 5y ago
    Yes, we need to lower the barrier to entry. There are not enough programmers to go around. Mediocre programmers are much better than no programmers. Hiring managers at companies that can’t afford to get into bidding wars with FAAMG need to realize that. You might prefer that they try anyway just to push up your salary a bit more, and I can’t blame you for wanting that, but all of us in this conversation aren’t going to strategically tailor our thoughts to help you achieve that goal.
bob1029 5y ago
> 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. How is explaining the way to build actual working shit "ruining it" for others? Do you want to live in some fantasy where Netflix's approach to engineering is applicable everywhere? I don't understand what some of you are trying to get out of this, but it sounds suspiciously like you want to have your cake while simultaneously having consumed it.
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 ago
  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. 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 ago
    All 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".

bradleyjg 5y ago

Systems divided up into subsystems include microservices architectures but that’s not the only way to get there. Like so many fads in our industry microservices solve a problem that giant, famous companies have and are aped by thousands of companies that don’t, and will never, have those problems.

29athrowaway 5y ago
OK, then if not microservices, then the problem will be programming paradigms, programming languages, data structures and algorithms, interviews... everything that forces you to think will be a problem. We have to stay mediocre and keep the bar low, to lower the entry barrier to software and depress wages.
- bradleyjg 5y ago
  Yes, we need to lower the barrier to entry. There are not enough programmers to go around. Mediocre programmers are much better than no programmers. Hiring managers at companies that can’t afford to get into bidding wars with FAAMG need to realize that. You might prefer that they try anyway just to push up your salary a bit more, and I can’t blame you for wanting that, but all of us in this conversation aren’t going to strategically tailor our thoughts to help you achieve that goal.

bob1029 5y ago

> 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. How is explaining the way to build actual working shit "ruining it" for others? Do you want to live in some fantasy where Netflix's approach to engineering is applicable everywhere? I don't understand what some of you are trying to get out of this, but it sounds suspiciously like you want to have your cake while simultaneously having consumed it.

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 ago
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. 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 ago
  All 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".