5 ms·

> then you will have, by necessity, built something which could be called a framework. What they call "building your own framework" is simply what I think of a

by jseban 4y ago

> then you will have, by necessity, built something which could be called a framework. What they call "building your own framework" is simply what I think of as programming. You design a program, it will have a structure. Why is that "forbidden" and something that programmers are thought of as unable to do?

codedokode 4y ago
Because if you move from one project to another you want to see a familiar implementation of Request class or ORM from a framework rather than reverse engineer custom-built undocumented untested replacement for this. It may make sense if custom framework is a magintude order better, but if it is the same as a standard framework or worse then it is not worth to spend time on it.
codedokode 4y ago
> What they call "building your own framework" is simply what I think of as programming. If you want an analogy, this is like a builder claiming that he is going to make all bricks and nails himself. You don't usually write your own standard library, why would you write your own framework?
- jseban 4y ago
  Except it's not like that, software is not standardised, it's custom made. And software engineers already have their toolset. The real analogy would be telling all the builders that they now have to use those shitty multi tools that are 10 screwdrivers and a hammer all in one.
  - delusional 4y ago
    The analogy is now officially making the argument less clear
    - deleted 4y ago
      [deleted]
    - deleted 4y ago
      [deleted]
  - jprd 4y ago
    you are limiting yourself to typing out code, rather than what is amazing about a human brain, the ability to see coherence in random shit and improve it. If you feel your job is to find neat ways of writing Java or C# or wtfever, you are limiting yourself. You should be looking to offload any repetitive/tedious task to automation, and from there figuring out how to leverage ML to make it efficient. The "work" you speak of is going to be obsoleted in the next decade, if it isn't cutting edge CS theory it should be done by the machine.
  - cornel_io 4y ago
    For 90% of SWEs (and closer to 99% of anyone doing front-end web stuff) it really isn't that custom. You're not solving problems that are difficult except those which your team creates for themselves by making bad choices as they service the fairly routine and unexciting feature requests that come in from product. And that's not to say that is a bad thing, all teams make bad choices and have to improve them over time, even when they are using highly opinionated frameworks. It's an unavoidable part of software development, even incredible teams and devs need to refactor. The point of using frameworks is that you can be sure that many of the bad choices the people who wrote it made early on have by now been tidied up. You don't have to worry that Dougie the intern's custom HTTP router is actually all sorts of ballsed when you go to set up your first DELETE endpoint, because Dougie didn't get to touch anything that fundamental to the stack. I do get off the boat when it comes to leftpad and stuff like that, don't ever pull external dependencies for trivial things. But an ORM or a UI framework? Those problems have been solved hundreds of times, absolutely no need for anyone to solve them again unless you're that good that thousands will move to using your solution instead of the existing ones.
    - deleted 4y ago
      [deleted]
- CuriousCosmic 4y ago
  I think there's a very prevalent and very real difference between "building your own framework" and "building your own bricks and nails". Programming isn't exactly equivalent to a construction worker. Rather your team are the construction worker, the structural engineer, and the architect all at once. The framework isn't bricks and nails. It's a prefab house plan. You follow the instructions and you get a house out on the other end. If you need to go outside what the prefab covers, you have to fight the framework because now you are drawing over top of an already printed out structural plan to try and do something different. The equivalent of bricks and nails in SWE is using libraries. Use a library to do a thing. You still need to design the program (drawing the floor plan), formalize how the parts interact (drawing the structural plans), and actually put the pieces together (building the actual house) but you don't need to worry about the small details like how to perform X algorithm (make the bricks), write a messaging standard (make the nails), or handle the intricacies of concurrency, distributed data structures, or drawing to a user interface (making the concrete and mortar). Your libraries do that for you. All you need to do as a developer is focus on writing neat functional kernels that do "the hard stuff", wrapping all your "hard stuff" and libraries together in some OO class to implement a certain functionality, and then stringing the bits together with some imperative glue to tell all the pieces to work together. Past that is orchestration & administration and that's Ops' responsibility. Unless all you need is cookie cutter, don't use a cookie cutter. Fighting the cookie cutter will be far harder than using the tools for the job(cleanly separated, well documented, and interoperable libraries) to solve specific problems.
mattgreenrocks 4y ago
Because many (not all) devs use frameworks to cover for their own weaknesses in software design. There’s something deeply comforting in the faith that a few Very Smart Framework Authors have laid a gold-plated path of success for them to follow. What they overlook is the time and energy wasted in the framework cottage industry: making dependencies talk to one another, aligning version numbers, major version upgrades being forced on them (or risk being insecure) and the time spent searching Google, SO, and GitHub issues for support.
- ryanbrunner 4y ago
  This really doesn't ring true to me. The biggest value of frameworks in my mind is that I don't have to waste time doing software design for things where my solution has no reason to be unique. Directory structure, how I interface with the database, how I write to logs, how I route HTTP requests to endpoints in my code are all certainly things I could solve, but I'd rather spend time on things that are unique to the problem I'm solving, and accepting a perfectly suitable standard for everything else. As a bonus, I know that every dev I hire with experience with that framework is also going to know how these things are set up, and they can focus their onboarding time on what actually needs to be unique to the problem we're solving. Regarding the downsides: - a framework doesn't necessitate additional libraries any more than rolling your own does (arguably this is worse without a framework, because unless you don't use libraries altogether you have a hodgepodge of libraries to solve common problems that don't have a lot of incentive to be cross-compatible, and a framework really can't be incompatible with itself) - Any half-way popular framework is going to ship security updates for past major versions (and again, if you're using libraries this is more of a headache than updating a single framework)
  - nh23423fefe 4y ago
    Agree. I've never seen a poor dev reach for a framework to solve a problem. Poor devs do nothing for days and then ask a bad question at a stand up.
- scarface74 4y ago
  I would much rather waste my time on a well documented industry framework that I can use when I leave than learning a framework written by the architect astronaut because he thought his problem was a special snowflake.
hadlock 4y ago
Because someone else is going to come along behind you and need to maintain what you wrote. If you're using a standard, just about anybody can sit down and pick up where you left off within an hour or two
- Handytinge 4y ago
  This may have been true at one point, however new frameworks are the "standard" every few years, and the pool for anything > a junior dev depletes quickly. Documentation or (preferably and) built in language convention are the winners here as frameworks come and go.
- jseban 4y ago
  > If you're using a standard, just about anybody can sit down and pick up where you left off within an hour or two Yeah it just doesn't work that way, you need to understand the domain and understand the system, and it takes a while to learn in a new job. This is just a fact, for every job, also software engineering. Stop this weird fantasy of replaceable cogs on the assembly line, you are not henry ford.
scarface74 4y ago
Because your framework eventually becomes a badly written, not as widely tested version of a known framework. When you leave, it will be a lot easier to hire someone who knows React than someone who knows jseban.js. I’ve had to come in before and deal with someone’s custom ORM or logging framework. I’ve made the mistake myself of writing something that was a cross cutting concern and then later found out that there was a popular third party package. I replaced my implementation as soon as feasible.
- jseban 4y ago
  > Because your framework eventually becomes a badly written, not as widely tested version of a known framework. When you leave, it will be a lot easier to hire someone who knows React than someone who knows jseban.js. Why are you assuming that everything a software engineer creates will always be bad? That's an unbelievably deprecating attitude. Do you ever see any other professions do this? UX? Product? Writers? "everything we always try to do will always be bad" and we have to try to safe us from ourselves? What? And this "framework" would be custom made to solve exactly the use cases at hand, and nothing else by definition would be better at those specific use cases. And why would you optimise so much for onboarding and hiring anyway, at the expense of so much continuous wasted time and less output? When my product owner quit, the new guy was working in parallel for three months, because "of course, they have to learn the ropes". That's normal for every single job basically, except software engineering. Why not just spend a couple of days, or a week, to give an introduction to your new hires, so that they understand and learn how you have structured your program? The only "problem" with that, is that you have to stop acting out this farce of the computer genius with the superior intelligence, in your hiring and onboarding process.
  - Tabular-Iceberg 4y ago
    >Why are you assuming that everything a software engineer creates will always be bad? Not necessarily, but it usually ends up badly. I have no doubts most of my peers could write a fine custom framework, but it's going to take a whole team of them at least a year to come up with something decently ergonomic, tested and documented. How often is the business side of the company going to be on board with spending that amount of resources on a solved problem? Instead developers decide to fly under the radar and do it anyway, but then run out of steam while the framework is still an untested, undocumented prototype and the pressure to shift focus to features becomes too great to resist. And by that they have doomed the whole company to a bottomless swamp of technical debt, with seniors getting fed up and leaving, and being replaced with juniors with no clue of what's going on, making the onboarding problem magnitudes greater than it was in the first place. And if someone has the genius idea of a big rewrite, we all know where that's going, especially since the only people they have been able to retain the whole time are either inexperienced juniors and mediocre seniors, so the cycle repeats again.

by jseban 4y ago

codedokode 4y ago

Because if you move from one project to another you want to see a familiar implementation of Request class or ORM from a framework rather than reverse engineer custom-built undocumented untested replacement for this. It may make sense if custom framework is a magintude order better, but if it is the same as a standard framework or worse then it is not worth to spend time on it.

codedokode 4y ago

> What they call "building your own framework" is simply what I think of as programming. If you want an analogy, this is like a builder claiming that he is going to make all bricks and nails himself. You don't usually write your own standard library, why would you write your own framework?

jseban 4y ago
Except it's not like that, software is not standardised, it's custom made. And software engineers already have their toolset. The real analogy would be telling all the builders that they now have to use those shitty multi tools that are 10 screwdrivers and a hammer all in one.
- delusional 4y ago
  The analogy is now officially making the argument less clear
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
- jprd 4y ago
  you are limiting yourself to typing out code, rather than what is amazing about a human brain, the ability to see coherence in random shit and improve it. If you feel your job is to find neat ways of writing Java or C# or wtfever, you are limiting yourself. You should be looking to offload any repetitive/tedious task to automation, and from there figuring out how to leverage ML to make it efficient. The "work" you speak of is going to be obsoleted in the next decade, if it isn't cutting edge CS theory it should be done by the machine.
- cornel_io 4y ago
  For 90% of SWEs (and closer to 99% of anyone doing front-end web stuff) it really isn't that custom. You're not solving problems that are difficult except those which your team creates for themselves by making bad choices as they service the fairly routine and unexciting feature requests that come in from product. And that's not to say that is a bad thing, all teams make bad choices and have to improve them over time, even when they are using highly opinionated frameworks. It's an unavoidable part of software development, even incredible teams and devs need to refactor. The point of using frameworks is that you can be sure that many of the bad choices the people who wrote it made early on have by now been tidied up. You don't have to worry that Dougie the intern's custom HTTP router is actually all sorts of ballsed when you go to set up your first DELETE endpoint, because Dougie didn't get to touch anything that fundamental to the stack. I do get off the boat when it comes to leftpad and stuff like that, don't ever pull external dependencies for trivial things. But an ORM or a UI framework? Those problems have been solved hundreds of times, absolutely no need for anyone to solve them again unless you're that good that thousands will move to using your solution instead of the existing ones.
  - deleted 4y ago
    [deleted]
CuriousCosmic 4y ago
I think there's a very prevalent and very real difference between "building your own framework" and "building your own bricks and nails". Programming isn't exactly equivalent to a construction worker. Rather your team are the construction worker, the structural engineer, and the architect all at once. The framework isn't bricks and nails. It's a prefab house plan. You follow the instructions and you get a house out on the other end. If you need to go outside what the prefab covers, you have to fight the framework because now you are drawing over top of an already printed out structural plan to try and do something different. The equivalent of bricks and nails in SWE is using libraries. Use a library to do a thing. You still need to design the program (drawing the floor plan), formalize how the parts interact (drawing the structural plans), and actually put the pieces together (building the actual house) but you don't need to worry about the small details like how to perform X algorithm (make the bricks), write a messaging standard (make the nails), or handle the intricacies of concurrency, distributed data structures, or drawing to a user interface (making the concrete and mortar). Your libraries do that for you. All you need to do as a developer is focus on writing neat functional kernels that do "the hard stuff", wrapping all your "hard stuff" and libraries together in some OO class to implement a certain functionality, and then stringing the bits together with some imperative glue to tell all the pieces to work together. Past that is orchestration & administration and that's Ops' responsibility. Unless all you need is cookie cutter, don't use a cookie cutter. Fighting the cookie cutter will be far harder than using the tools for the job(cleanly separated, well documented, and interoperable libraries) to solve specific problems.

mattgreenrocks 4y ago

Because many (not all) devs use frameworks to cover for their own weaknesses in software design. There’s something deeply comforting in the faith that a few Very Smart Framework Authors have laid a gold-plated path of success for them to follow. What they overlook is the time and energy wasted in the framework cottage industry: making dependencies talk to one another, aligning version numbers, major version upgrades being forced on them (or risk being insecure) and the time spent searching Google, SO, and GitHub issues for support.

ryanbrunner 4y ago
This really doesn't ring true to me. The biggest value of frameworks in my mind is that I don't have to waste time doing software design for things where my solution has no reason to be unique. Directory structure, how I interface with the database, how I write to logs, how I route HTTP requests to endpoints in my code are all certainly things I could solve, but I'd rather spend time on things that are unique to the problem I'm solving, and accepting a perfectly suitable standard for everything else. As a bonus, I know that every dev I hire with experience with that framework is also going to know how these things are set up, and they can focus their onboarding time on what actually needs to be unique to the problem we're solving. Regarding the downsides: - a framework doesn't necessitate additional libraries any more than rolling your own does (arguably this is worse without a framework, because unless you don't use libraries altogether you have a hodgepodge of libraries to solve common problems that don't have a lot of incentive to be cross-compatible, and a framework really can't be incompatible with itself) - Any half-way popular framework is going to ship security updates for past major versions (and again, if you're using libraries this is more of a headache than updating a single framework)
- nh23423fefe 4y ago
  Agree. I've never seen a poor dev reach for a framework to solve a problem. Poor devs do nothing for days and then ask a bad question at a stand up.
scarface74 4y ago
I would much rather waste my time on a well documented industry framework that I can use when I leave than learning a framework written by the architect astronaut because he thought his problem was a special snowflake.

hadlock 4y ago

Because someone else is going to come along behind you and need to maintain what you wrote. If you're using a standard, just about anybody can sit down and pick up where you left off within an hour or two

Handytinge 4y ago
This may have been true at one point, however new frameworks are the "standard" every few years, and the pool for anything > a junior dev depletes quickly. Documentation or (preferably and) built in language convention are the winners here as frameworks come and go.
jseban 4y ago
> If you're using a standard, just about anybody can sit down and pick up where you left off within an hour or two Yeah it just doesn't work that way, you need to understand the domain and understand the system, and it takes a while to learn in a new job. This is just a fact, for every job, also software engineering. Stop this weird fantasy of replaceable cogs on the assembly line, you are not henry ford.

scarface74 4y ago

Because your framework eventually becomes a badly written, not as widely tested version of a known framework. When you leave, it will be a lot easier to hire someone who knows React than someone who knows jseban.js. I’ve had to come in before and deal with someone’s custom ORM or logging framework. I’ve made the mistake myself of writing something that was a cross cutting concern and then later found out that there was a popular third party package. I replaced my implementation as soon as feasible.

jseban 4y ago
> Because your framework eventually becomes a badly written, not as widely tested version of a known framework. When you leave, it will be a lot easier to hire someone who knows React than someone who knows jseban.js. Why are you assuming that everything a software engineer creates will always be bad? That's an unbelievably deprecating attitude. Do you ever see any other professions do this? UX? Product? Writers? "everything we always try to do will always be bad" and we have to try to safe us from ourselves? What? And this "framework" would be custom made to solve exactly the use cases at hand, and nothing else by definition would be better at those specific use cases. And why would you optimise so much for onboarding and hiring anyway, at the expense of so much continuous wasted time and less output? When my product owner quit, the new guy was working in parallel for three months, because "of course, they have to learn the ropes". That's normal for every single job basically, except software engineering. Why not just spend a couple of days, or a week, to give an introduction to your new hires, so that they understand and learn how you have structured your program? The only "problem" with that, is that you have to stop acting out this farce of the computer genius with the superior intelligence, in your hiring and onboarding process.
- Tabular-Iceberg 4y ago
  >Why are you assuming that everything a software engineer creates will always be bad? Not necessarily, but it usually ends up badly. I have no doubts most of my peers could write a fine custom framework, but it's going to take a whole team of them at least a year to come up with something decently ergonomic, tested and documented. How often is the business side of the company going to be on board with spending that amount of resources on a solved problem? Instead developers decide to fly under the radar and do it anyway, but then run out of steam while the framework is still an untested, undocumented prototype and the pressure to shift focus to features becomes too great to resist. And by that they have doomed the whole company to a bottomless swamp of technical debt, with seniors getting fed up and leaving, and being replaced with juniors with no clue of what's going on, making the onboarding problem magnitudes greater than it was in the first place. And if someone has the genius idea of a big rewrite, we all know where that's going, especially since the only people they have been able to retain the whole time are either inexperienced juniors and mediocre seniors, so the cycle repeats again.