1
point
ra0x3
Joined 248 karma
https://rashad.wiki
- ra0x3 parentWorking the same, the nature of the work has changed. Less time spent on the minutia of syntax and project scaffolding. More time spent on how the minutia compose into a larger system.
- True, but I think the point I'm trying to make is that when it comes to deploying (what are more often than not) web services, getting to the point with systemd where it "just works" requires more pain than I'd like - especially with regard to production deployments (reading logs, checking service status, wondering why my env vars aren't being read, etc).
If at the time when I was cutting my teeth on systemd, I had access to something more lightweight and "do one thing well", I think I would've gotten a lot more sleep :)
- systemg - "Systemd, for busy people".
https://github.com/ra0x3/systemg
I'm personally tired of getting stuck in config/deployment hell every time I want to deploy a long-lived web service. Sure I eventually learned how to use systemd, but systemd has SO many things baked into that I simply don't need. systemg is a lightweight process supervisor that features everything you'd typically want when running/managing production web services in the wild.
Would love feedback.
- I have rarely in my 11+ years of professionally writing software, met someone who could _really_ "write code", but couldn't build software. Anecdotal obviously. But I'd say the opposite tends to be the case IMO - those who tend to really know "the code", also tend to know how to effectively build software (relatively speaking).
It kinda makes sense - "knowing how to code" in modern tech largely means "knowing how to build software" - not write single modules in some language - because those single modules on their own are largely useless outside the context of "software".
- 2 points
- Brandon. He was a traditionally trained SWE (CS) but didn't have crazy FAANG names on his resume. Very humble, soft spoken guy. Could write code twice as fast as you, that was 2x easier to understand/grok, and would run 5x more effecciently than yours. Knew the stack all the way from the web layer to the CPU cache level. To this day I think about how he was thee definition of a "10x engineer".
- 5 points
- This is a really good point.
At a certain point, huge prompts (which you can readily find available on Github, used by large LLM-based corps) are just....files of code? Why wouldn't I just write the code myself at that point?
Almost makes me think this "AI coding takeover" is strictly pushed by non-technical people.
- 1 point
- > but I feel less emotionally invested in the craft of coding.
I don't think caring about the craft of coding and using AI tools are mutually exclusive options. I think you can totally do both! In a way, some of these tools actually allow you more space and time to "care about the craft" because they can take care of all of the mundane boilerplate for you.
A man once said "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."[1]. Well IMO these tools allow programmers the time/space to care about data structures and their relationships -vs syntax and such.
- > What we are doing in practice when delegating coding to LLMs is climbing up the abstraction level ladder.
100%. I like to say that we went from building a Millennium Falcon out of individual LEGO pieces, to instead building an entire LEGO planet made of Falcon-like objects. We’re still building, the pieces are just larger :)
- As fzwang mentions, your co-founder relationship IS the business at this point. I'd talk to your co-founder 1:1 and really have some uncomfortable conversations. If you both feel like the relationship is not salvageable, amicably walk away without burning the professional bridge (someone might ask her how you are to work with). If your heart is not 100% in it (for whatever reason) I'd suggest walking away. The opportunity cost of dragging the dead weight of a business that you're not bought into (and that you aren't seeing success with) is simply too high - and can have real life consequences (finances, stresses, etc). There's nothing wrong with walking away - there's a reason the overwhelming majority of startups fail. And most tiny startups fail due to co-founder relationships - doesn't have anything to do with PMF or anything. Think about it over a weekend - have the tough conversation(s) - don't burn the bridge. Live to fight another day. The sun is still shining outside and the NBA is still rigged to always make sure the Lakers are relevant ;)
- The end result tends to be similar across a lot of apps: some CI (e.g., Github Actions) step that does some combination of: uploading docker images to a registry, ssh'ing into boxes and running some restart/kick script(s), uploading some release binary. What action depends on the app obviously - but I've seen a common theme of that "action" being the last step of some CI pipeline.
- 1 point
- 25 points
- 3 points
- 3 points
- 2 points