23 ms·

TL,Dr : knowledgeable, skilled programmers writing semi-confidential software in C for mostly a single OS, by themselves, with total control of the feature set

TL,Dr : knowledgeable, skilled programmers writing semi-confidential software in C for mostly a single OS, by themselves, with total control of the feature set and release schedule, can produce pretty fast binaries. Which is great ! I just don't know how to transfer that to building software as a team with multiple skillsets, unknown feature set (because market feet is still searched for) aggressive schedule, (We don't know what we want to build , but we need it in six months), large target audience ("what do you mean they have to install stuff ? Where is the link I can paste in an email so they open it in IE6 ?") , and,let's be honest, less knowledgable and more lazy developers. (To be clear : I'm not criticizing the network or project. I just find it interesting that they had a goal - making fast software - and that, to the ebest of my knowledge and without a rigorous analysis - it seems that most projects converged on a very particular kind of software. Which just happens not to be the kind most of us will ever be working on, but it does not matter. Go them !)

arcin 6y ago
For me, it's just about learning from others or getting in touch with the part of myself that was excited about programming. I worked in web development for a few years (2010-2015) and then left to start a company with a friend (mid 2015). We decided to build audio reactive visualization software written in C/C++/glsl, way different from where web development was and is (still do web stuff but primarily backend services for our app and React for the sites). The industry we're in focuses primarily on international music festivals (burning man, boom) and specialized art installations/exhibits. We were successful and now we have employees, a vibrant community, ambitions plans for new products, and aggressive deadlines. I say that only to point out that work is work. Whether you're working for someone or working for yourself, you can always find things to stress about and reasons to push yourself to the brink of burnout. As corny as it sounds, Handmade hero has been a reminder of the reason I quit my job 5 years ago to do something technologically and emotionally challenging. It keeps me in touch with the younger me that that just wanted to learn everything I could about programming, web/native/embedded whatever. To your point, though, it definitely is not for everyone. If you see software as simply a means to an end, then there is nothing wrong with focusing on components that make products viable. I enjoy the craft but I also understand you can't have success by being precious about every little technical detail. Just wanted to share my experience. I wish I would have come across something like handmade sooner in my dev journey.
burntoutfire 6y ago
It's not only about being fast, it's also about being bug free. You inherit all the bugs of all of your software dependencies... That may be the reason why flagship software products such as Twitter or YouTube constantly have pretty glaring bugs.
- AlotOfReading 6y ago
  Nobody writing in C has "bug free" as their highest priority. Reducing dependencies is good though.
  - nikki93 6y ago
    SQLite is written in C.
    - AlotOfReading 6y ago
      And SQLite has a page on why [1] that explicitly lists the benefits of C for the project. Not on that list: bug reduction. Moreover, it has an almost superhuman level of effort put into testing and verification. SQLite is just one piece of a broader argument that C's inherent risks aren't completely unmanageable. All it takes is an incredible amount of diligence, tooling, expertise, and money. [1] https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html
      - nikki93 6y ago
        Your comment said "no one writing in C has bug reduction as a priority." Bug reduction is a priority for the SQLite authors, and it's written in C. This feels to me like an indication that it is a priority: https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html
phendrenad2 6y ago
Speed is a very real selling point for software though. If your competitor takes 6 months to get to market, and then is locked-in to a bloated, sluggish, badly-architected codebase made from 50 abstraction layers, you have plenty of time to come in later and steal their userbase, when your project is done and can do things in 1/10th the time.
- phtrivier 6y ago
  My prior in such a situation would be to assume that "stealing userbase" is very hard. It depends on the kind of application, of course, but once you have paying / committed user, I'd assume the friction to change (and natural risk/change aversion )would be in favor of the incumbent. That being said, arriving afterwards with a message of "we're like X,but faster" could be a good marketing catch, but probably not for any kind of enterprise app. (The only good marketing catch in this case would be "we're like X, but cheaper.") No idea how such an hypothesis could be tested. We would need records of user switching from an app to another.

arcin 6y ago

For me, it's just about learning from others or getting in touch with the part of myself that was excited about programming. I worked in web development for a few years (2010-2015) and then left to start a company with a friend (mid 2015). We decided to build audio reactive visualization software written in C/C++/glsl, way different from where web development was and is (still do web stuff but primarily backend services for our app and React for the sites). The industry we're in focuses primarily on international music festivals (burning man, boom) and specialized art installations/exhibits. We were successful and now we have employees, a vibrant community, ambitions plans for new products, and aggressive deadlines. I say that only to point out that work is work. Whether you're working for someone or working for yourself, you can always find things to stress about and reasons to push yourself to the brink of burnout. As corny as it sounds, Handmade hero has been a reminder of the reason I quit my job 5 years ago to do something technologically and emotionally challenging. It keeps me in touch with the younger me that that just wanted to learn everything I could about programming, web/native/embedded whatever. To your point, though, it definitely is not for everyone. If you see software as simply a means to an end, then there is nothing wrong with focusing on components that make products viable. I enjoy the craft but I also understand you can't have success by being precious about every little technical detail. Just wanted to share my experience. I wish I would have come across something like handmade sooner in my dev journey.

burntoutfire 6y ago

It's not only about being fast, it's also about being bug free. You inherit all the bugs of all of your software dependencies... That may be the reason why flagship software products such as Twitter or YouTube constantly have pretty glaring bugs.

AlotOfReading 6y ago
Nobody writing in C has "bug free" as their highest priority. Reducing dependencies is good though.
- nikki93 6y ago
  SQLite is written in C.
  - AlotOfReading 6y ago
    And SQLite has a page on why [1] that explicitly lists the benefits of C for the project. Not on that list: bug reduction. Moreover, it has an almost superhuman level of effort put into testing and verification. SQLite is just one piece of a broader argument that C's inherent risks aren't completely unmanageable. All it takes is an incredible amount of diligence, tooling, expertise, and money. [1] https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html
    - nikki93 6y ago
      Your comment said "no one writing in C has bug reduction as a priority." Bug reduction is a priority for the SQLite authors, and it's written in C. This feels to me like an indication that it is a priority: https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html

phendrenad2 6y ago

Speed is a very real selling point for software though. If your competitor takes 6 months to get to market, and then is locked-in to a bloated, sluggish, badly-architected codebase made from 50 abstraction layers, you have plenty of time to come in later and steal their userbase, when your project is done and can do things in 1/10th the time.

phtrivier 6y ago
My prior in such a situation would be to assume that "stealing userbase" is very hard. It depends on the kind of application, of course, but once you have paying / committed user, I'd assume the friction to change (and natural risk/change aversion )would be in favor of the incumbent. That being said, arriving afterwards with a message of "we're like X,but faster" could be a good marketing catch, but probably not for any kind of enterprise app. (The only good marketing catch in this case would be "we're like X, but cheaper.") No idea how such an hypothesis could be tested. We would need records of user switching from an app to another.