> It's simple stuff like putting together a base Modal display component for re-use instead of copy/pasting that div with the inline-styled zIndex of 99,999 for the umpteenth time.
Is this on the critical path to solving more ambitious goals or just the Sisyphean task you've appointed yourself? It's fine to take pleasure in the small details, and if you want to set up a company to feed that obsession more power to you. However I will go out on a limb and predict two things: 1) unless you are independently wealthy, you are going to stop worrying about this level of detail pretty quickly once you are focused on how to make enough money to afford to hire talented engineers and 2) if you micro-manage style and details to this degree, you may find it hard to retain the level of talent you aspire to.
I took a look at your github profile and looked through your csv_builder repo project in particular. It's good, clean code. Well done! Given that you apparently understand what clean code looks like, I can't help but feel I may be misrepresenting the nature of the 'bad code' I provided an example for. Let me expand on my modal example and perhaps you'll better understand things.
Here's a snippet from the code I had in mind when I wrote my comment:
This was copy/pasted from some other modal in the application. Have you ever heard of the DRY principle? Don't Repeat Yourself. Now, I could wax poetic about just how far one ought to go to embody this principle when considering the time pressures and business demands in a startup environment, but I don't think it should be controversial to say that repeating those 11 lines throughout the codebase for every modal is a Bad Idea, especially considering they could have used the much simpler one-liner, <Modal>.
I won't go deeper into that because that seems like a pretty air tight assumption, but feel free to let me know if it's an invalid assumption on your part nonetheless.
Now, one might say, maybe he didn't know about the other component? And, in fact, I think this was probably the case. And so I can, to some extent, forgive him for copy and pasting due to ignorance of the other component. It's a big codebase and it's impossible to stay up to date on all changes all the time. Nevertheless, this isn't an isolated case, this kind of sloppiness is the rule in the codebase rather than the exception.
> 2) if you micro-manage style and details to this degree, you may find it hard to retain the level of talent you aspire to.
Good engineers make these kinds of mistakes occasionally, it isn't their default mode of programming. I wouldn't have to worry about micro-management because the need for it, at least of the variety concerning this particular example, would never arise. Surely you understand that bad programming can and does exist?
> 1) unless you are independently wealthy, you are going to stop worrying about this level of detail pretty quickly once you are focused on how to make enough money to afford to hire talented engineers
As long as I am responsible for the construction of any kind of software, I will never stop worrying about these kinds of errors because over time they are immensely costly. Team velocity slows drastically due to the unreadable, verbose and repetitive nature of this kind of code. That is unless, of course, the product I'm building manages to embody the vision I have in mind for it and appropriately and sufficiently addresses these kinds of issues such that they are impossible to make anymore. If and when that happens, I will stop worrying because I will rest easy that an automatic process catches these errors and I will be ready to dedicate my brain power to other more interesting problems.
I have no way of knowing exactly how much, but my suspicion is that, in aggregate, sloppy coding such as this likely costs many, many companies building software around the globe millions or even billions of dollars worth of development time every year. I want to alleviate that waste with Pidgin.
And, yeah, devtools aren't exactly the cash cows of software, but they do exist and are occasionally successful. I've got a whole list of SaaS companies in the space, but for brevity I'll simply drop a reference to one I found on HN just this evening. It's called Replay (https://www.replay.io/), and it's a standalone time traveling debugger for web code. They're backed by Andreesen Horowitz, so I think it's likely they have managed to strike on something true.
My aim is for Pidgin to target the process of construction rather than debugging or design as I've seen some other tools do, while still retaining the power of plain text that is invariably lost when using other so-called "low-code" tools.
If you think you might be interested, I would be happy to note your contact details down for when the alpha version is released!
Is this on the critical path to solving more ambitious goals or just the Sisyphean task you've appointed yourself? It's fine to take pleasure in the small details, and if you want to set up a company to feed that obsession more power to you. However I will go out on a limb and predict two things: 1) unless you are independently wealthy, you are going to stop worrying about this level of detail pretty quickly once you are focused on how to make enough money to afford to hire talented engineers and 2) if you micro-manage style and details to this degree, you may find it hard to retain the level of talent you aspire to.