3 ms·

If it was simple, they wouldn't be paying us for it. The people who want simplicity don't need experienced professionals to do those simple things. So we don't

If it was simple, they wouldn't be paying us for it. The people who want simplicity don't need experienced professionals to do those simple things. So we don't tend to hear about them, and we don't get to do them. I've been asked to do things so simple I don't even want to go to the trouble of negotiating a contract, I just recommend an off the shelf solution. I've been asked to do complicated things that should be simple, so I've recommended doing the simple thing. They just ask someone else to do the complicated thing instead. If someone reading HN is involved, so is complexity. The best thing we can hope to do is wrangle it into isolated and manageable little chunks.

jonahx 3y ago
The article is talking implementation complexity. Say a client asks for features A, B, C, D which reach the bar of complexity where someone from HN has to get involved. Now two things can happen, and in both cases the same feature set is delivered: 1. All of those features are implemented as a server side web app, with little to no JS a simple CSS stylesheet, and each page is under 100K and loads almost instantly. There is also a simple caching strategy (but not necessarily an obvious one) that speeds the application up further, and allows it scale. The DB design is good, proper indexes have been added, the queries have been thoughtfully planned, etc. 2. The features are implemented as a SPA, and a large framework has been pulled in. Many UI components also pull in other large dependencies. A CSS framework has also been added even though only 1% of it is used, and no attempt to tree shake the CSS or JS has been made. The page size is over 3MB. No DB optimizations or caching has been added, etc. Note this is far from a straw man. 2. is by far the most common approach, even among "professionals".
- sanitycheck 3y ago
  Option 2 would of course be a SSR React MPA these days, not a SPA, so we have to worry about NPM supply chain attacks server-side too. Option 1 can be done by one sensible person with intermediate PHP/Python knowledge, and maintained fairly easily and cheaply forever. They're different jobs. You can take the interview for that option 2, and you can push for doing option 1 instead. What will end up happening is that they employ someone else. (I speak as someone who spent a couple of months in the mid-2000s mostly writing a partial XPath implementation in Flash ActionScript, to be used in a single product to interface with one other 3rd-party system. It was a stupid idea from day 1 and definitely not mine, yet that was the job! The insanity is not new.)
  - jonahx 3y ago
    > Option 1 can be done by one sensible person with intermediate PHP/Python knowledge, and maintained fairly easily and cheaply forever. This a vast underestimate of the amount of knowledge it takes to do 1. well, for a project of any complexity. Doing the simple thing well is hard. Indeed, one of the reasons that option 2 has skyrocketed in popularity is because a larger number of mediocre devs can "get the job done" using that method. > They're different jobs. You can take the interview for that option 2 What you are saying is that there is a lot of non-technical pressure to do option 2. I couldn't agree more. It doesn't make it any less absurd.
    - sanitycheck 3y ago
      I agree to an extent, but a person who's managed to end up doing the simple thing (option 1) has a superpower! They're able to say "no". That makes simplicity much much more achievable. If you can't refuse to keep adding crap then yes, simplicity is very very hard. I honestly think most people who are currently doing an option 2, and are capable of some restraint, would find it easier to do option 1. And if they were allowed, and if it paid as well or better than option 2, and if their career prospects were improved by doing it, they would. Absurd is the right word, but that's just the world we live in. Why am I paid more than a doctor? Madness.
      - mattgreenrocks 3y ago
        Arguably, option 2 soft-caps their technical progression because their day is spent untangling things, keeping up with dependency updates, and other makework that can spawn from not corralling complexity. However, in some sense, they have consciously chosen this approach, and associated with like-minded people. Using a big brush here, but webdev has a LOT of this “just throw tons of libs at it and hope for the best.” I ran away screaming once I got a taste of that. It is antithetical to what I want out of my career. And it seems to breed a lack of rigor, exemplified by how many people complain of “slow tests” but refuse to refactor in such a way to make them faster. IOW, you don’t want fast tests as much as you want to bitch on Twitter. Plus, long-term I believe option 2 is somewhat dangerous: there’s a huge pool of applicants looking to employ the same approach. Why pay a premium for those skills? What’s your differentiator?
feoren 3y ago
You're just talking about a completely different thing than the article, and many of the commenters. You're talking about a simple problem. The rest of us are talking about simple solutions. The ability to come up with a simple solution to a complex problem is possibly the most valuable skill a human can possess, so of course they should be paying us for it. Bad developers write complex solutions for simple problems. Good developers write complex solutions for complex problems. Great developers write simple solutions for complex problems.
- sanitycheck 3y ago
  I think one of us has read the post. Points noted: * "17 javascript trackers" * "sacrificing complexity" * "control how a checkbox animates when you check it" * "adding an abstraction with thousands of lines of codes" * "whether you are able to remove things you have added" * "add even more stuff to fix it, or is it to remove and live with the loss?" * "learning to say no" It's not about simple solutions to complex problems. It's about avoiding complex problems and doing something simpler instead.
  - feoren 3y ago
    17 javascript trackers is a solution to a problem, not a problem in itself. You don't need 17 javascript trackers to creep on your users. In fact you don't need to creep on your users at all. So the real problem is the simplest possible problem: there's no problem at all. So the 17 javascript trackers are 100% accidental complexity in the solution to a nonexistent problem. Controlling how a checkbox animates when you check it is also a solution, not a problem. Problems are things like: users don't know whether they've selected this value or not. Users think our application is boring. Users are completing their tasks too quickly and we need to find ways to annoy them and destroy their productivity. All of those are the possible problems that micromanaging a checkbox's animation might solve. There are almost certainly simpler ways to solve those problems. Adding an abstraction with thousands of lines of code is, obviously, not a problem, it's a (probably poor) solution. I don't understand why I need to explain this one. The rest of it is suggestions on how to let go of your overly complicated solutions and find more simple ones. The article, and most commenters, are basically assuming a fixed, relatively complex problem. Your point seems to be that experienced professionals should not work on simple problems. Okay? And you should wear your seatbelt while in a car. That has nothing to do with finding simple solutions to a fixed problem.

jonahx 3y ago

The article is talking implementation complexity. Say a client asks for features A, B, C, D which reach the bar of complexity where someone from HN has to get involved. Now two things can happen, and in both cases the same feature set is delivered: 1. All of those features are implemented as a server side web app, with little to no JS a simple CSS stylesheet, and each page is under 100K and loads almost instantly. There is also a simple caching strategy (but not necessarily an obvious one) that speeds the application up further, and allows it scale. The DB design is good, proper indexes have been added, the queries have been thoughtfully planned, etc. 2. The features are implemented as a SPA, and a large framework has been pulled in. Many UI components also pull in other large dependencies. A CSS framework has also been added even though only 1% of it is used, and no attempt to tree shake the CSS or JS has been made. The page size is over 3MB. No DB optimizations or caching has been added, etc. Note this is far from a straw man. 2. is by far the most common approach, even among "professionals".

sanitycheck 3y ago
Option 2 would of course be a SSR React MPA these days, not a SPA, so we have to worry about NPM supply chain attacks server-side too. Option 1 can be done by one sensible person with intermediate PHP/Python knowledge, and maintained fairly easily and cheaply forever. They're different jobs. You can take the interview for that option 2, and you can push for doing option 1 instead. What will end up happening is that they employ someone else. (I speak as someone who spent a couple of months in the mid-2000s mostly writing a partial XPath implementation in Flash ActionScript, to be used in a single product to interface with one other 3rd-party system. It was a stupid idea from day 1 and definitely not mine, yet that was the job! The insanity is not new.)
- jonahx 3y ago
  > Option 1 can be done by one sensible person with intermediate PHP/Python knowledge, and maintained fairly easily and cheaply forever. This a vast underestimate of the amount of knowledge it takes to do 1. well, for a project of any complexity. Doing the simple thing well is hard. Indeed, one of the reasons that option 2 has skyrocketed in popularity is because a larger number of mediocre devs can "get the job done" using that method. > They're different jobs. You can take the interview for that option 2 What you are saying is that there is a lot of non-technical pressure to do option 2. I couldn't agree more. It doesn't make it any less absurd.
  - sanitycheck 3y ago
    I agree to an extent, but a person who's managed to end up doing the simple thing (option 1) has a superpower! They're able to say "no". That makes simplicity much much more achievable. If you can't refuse to keep adding crap then yes, simplicity is very very hard. I honestly think most people who are currently doing an option 2, and are capable of some restraint, would find it easier to do option 1. And if they were allowed, and if it paid as well or better than option 2, and if their career prospects were improved by doing it, they would. Absurd is the right word, but that's just the world we live in. Why am I paid more than a doctor? Madness.
    - mattgreenrocks 3y ago
      Arguably, option 2 soft-caps their technical progression because their day is spent untangling things, keeping up with dependency updates, and other makework that can spawn from not corralling complexity. However, in some sense, they have consciously chosen this approach, and associated with like-minded people. Using a big brush here, but webdev has a LOT of this “just throw tons of libs at it and hope for the best.” I ran away screaming once I got a taste of that. It is antithetical to what I want out of my career. And it seems to breed a lack of rigor, exemplified by how many people complain of “slow tests” but refuse to refactor in such a way to make them faster. IOW, you don’t want fast tests as much as you want to bitch on Twitter. Plus, long-term I believe option 2 is somewhat dangerous: there’s a huge pool of applicants looking to employ the same approach. Why pay a premium for those skills? What’s your differentiator?

feoren 3y ago

You're just talking about a completely different thing than the article, and many of the commenters. You're talking about a simple problem. The rest of us are talking about simple solutions. The ability to come up with a simple solution to a complex problem is possibly the most valuable skill a human can possess, so of course they should be paying us for it. Bad developers write complex solutions for simple problems. Good developers write complex solutions for complex problems. Great developers write simple solutions for complex problems.

sanitycheck 3y ago
I think one of us has read the post. Points noted: * "17 javascript trackers" * "sacrificing complexity" * "control how a checkbox animates when you check it" * "adding an abstraction with thousands of lines of codes" * "whether you are able to remove things you have added" * "add even more stuff to fix it, or is it to remove and live with the loss?" * "learning to say no" It's not about simple solutions to complex problems. It's about avoiding complex problems and doing something simpler instead.
- feoren 3y ago
  17 javascript trackers is a solution to a problem, not a problem in itself. You don't need 17 javascript trackers to creep on your users. In fact you don't need to creep on your users at all. So the real problem is the simplest possible problem: there's no problem at all. So the 17 javascript trackers are 100% accidental complexity in the solution to a nonexistent problem. Controlling how a checkbox animates when you check it is also a solution, not a problem. Problems are things like: users don't know whether they've selected this value or not. Users think our application is boring. Users are completing their tasks too quickly and we need to find ways to annoy them and destroy their productivity. All of those are the possible problems that micromanaging a checkbox's animation might solve. There are almost certainly simpler ways to solve those problems. Adding an abstraction with thousands of lines of code is, obviously, not a problem, it's a (probably poor) solution. I don't understand why I need to explain this one. The rest of it is suggestions on how to let go of your overly complicated solutions and find more simple ones. The article, and most commenters, are basically assuming a fixed, relatively complex problem. Your point seems to be that experienced professionals should not work on simple problems. Okay? And you should wear your seatbelt while in a car. That has nothing to do with finding simple solutions to a fixed problem.