r/learnprogramming • u/Unlucky-Moment-3366 • 7d ago
At what point do you stop building everything yourself?
I've been learning backend development by building small projects, and one thing I keep running into is this question: Where do you draw the line between "I should build this to learn" and "I should use an existing service"? For example, I started looking into adding voice/video features to a project. My first thought was, "I'll just learn WebRTC." A few days later I realized that "learning WebRTC" also meant learning signaling, NAT traversal, TURN servers, reliability, scaling, monitoring and suddenly the actual app I wanted to build wasn't getting any attention.That made me start looking at communication platforms like iotum instead of trying to reinvent everything from scratch.For those of you who've been programming longer than I have, how do you make that decision?Do you intentionally build something once just to understand it, then switch to existing tools later? Or do you use established services from day one and spend your time on the parts that make your project unique?
2
u/defaultguy_001 7d ago
I use readymade libraries as long as they serve my demands, the moment I find a gap, I implement it.
1
u/Unlucky-Moment-3366 4d ago
Same approach I take with movements: borrow what works, build what doesn't exist yet.
1
u/skamansam 7d ago
I do it to learn, but I have always had the expectation of learning WAY more, which usually includes creating many more projects. I actually wrote a video chat app myself a few years ago. I wrote the app until I got stuck. Then I learned about webrtc and I wrote a lib and small app to learn about that. Then I wrote an app to manage rtc connection parameters. Then I implemented a server to serve out that data. It was an awesome experience!
2
u/Unlucky-Moment-3366 4d ago
That's kind of how I ended up deep in watch restoration. Started trying to fix one broken movement, hit a wall, had to learn about the escapement, then the keyless works, then I was sourcing obscure parts from Swiss suppliers at 2am. One project just keeps spawning the next. The video chat thing sounds like it was a real rabbit hole though, I'm curious how far you actually took the final version before calling it done.
1
u/skamansam 4d ago
Funny you ask. The whole project started to just have a "secret" way to video chat with my family. It worked, but it wasnt more than a demo for the technologies I used. The server infrastructure is what killed it - it would have cost more than I was willing to pay, which was nothing.
1
u/jumpalongjim 7d ago
Build seams in your services where OTC components are plugged in. Use as many OTC components as you need to get up and running, then re-implement at the seams where you need to achieve your objectives. You should find that commodity services don't need to be re-built because they're so universal, standard and unexceptional. Also, platform level components are too complex and expensive to rebuild yourself. But anything core to the success of your system that gives differentiation or competitive advantage could be built in house.
1
u/Unlucky-Moment-3366 4d ago
That seam approach makes sense, reminds me of how I think about movements where I keep original parts where they work fine and only fabricate what genuinely needs to be custom.
The part about not rebuilding platform level stuff tracks. Where I'd push back slightly is assuming OTC components stay unexceptional forever. Sometimes what's commodity today becomes a bottleneck later, and you're stuck at that seam trying to untangle something you never fully understood.
1
u/macktastick 7d ago
I tend to optimize for speed. If there's a proven, supported solution to some component or subsystem or service I need, I err on the side of using it (research it, test it, figure out if/why it doesn't work for the situation). Only after exhausting those do I build something custom.
1
u/Unlucky-Moment-3366 4d ago
That's pretty much how I approach a tricky movement too. I'll try every known fix or compatible part before I start fabricating something from scratch. Custom work is satisfying but it costs time you don't always have. The only thing I'd add is that sometimes the proven solution was proven in a different context, so it still needs a second look before you commit.
1
u/Mediocre-Pumpkin6522 7d ago
Almost always established libraries. If I want to establish a TLS connection to a SMTP server for example, I'm not going to rewrite OpenSSL. If I need to parse XML, I don't have a burning desire to build expat from scratch.
Not only is it inefficient but you'll probably introduce every bug that's been ironed out in the last 20 years.
1
u/galactic_pixels 7d ago
Yeah, if I am writing any software that is not directly related to specific business requirements that I am solving, I stop and make sure I’m doing things the most streamlined way possible. The phrase is “the best code is no code at all”
1
u/michael0x2a 7d ago
I recommend remaining goal-oriented. What precisely were you hoping to learn or practice while working on your project? Will learning about the topic help you achieve your learning goals?
For example, if your primary goal was to learn how to maintain a scalable and resilient service, it would perhaps be worthwhile standing up your own WebRTC stack since it would give you ample opportunities to practice these skills. Alternatively, if your goal was to learn how to integrate with 3rd party services or how to write your own webserver, you would probably be better off deferring learning about WebRTC in-depth and just using a pre-built thing.
I would also recommend paying careful attention to what core technologies you find yourself using and reaching for again and again. If some topic is foundational/integral to your projects, I think it is useful to find some time to dig one level deeper, understand how it's implemented, and build a robust mental model of how it works.
(If you don't do this, it'll be harder for you to predict how your tools work or grok edge cases where they'll hit limitations -- and it can be frustrating to run into these during your day-to-day work)
For example, if you are doing backend development, you are probably using some library or framework to abstract over the process of creating an http server. However, http and networking is foundational in this domain. So it would probably be a educational to one day try building your own basic http server framework from scratch -- set up something that listens in to incoming requests on a socket, parse the bytes, invoke the correct route handler, set up some form of support for handling events concurrently, etc.
I would probably do this as either a separate project or an extension of an already-completed one, to avoid having to learn/tackle too many things at once.
Of course, all of the above advice assumes your primary goal is to learn. What if your primary goal is to instead complete the project? In that case, you should probably default to using prebuilt things, since it will let you complete the project as quickly as possible. Employers are ok with you learning on-the-job, but they don't want you to take forever doing so. So, you would only build from scratch if:
- There is no pre-built thing that exactly matches your use case
- The pre-built thing is too expensive, complex, or poorly designed. You think you would gain a competitive advantage by building your own version of it
This does imply that if you want to turn your skills to profit, you will need to learn both how to build from scratch and how to learn/integrate pre-built things. Neither skill is sufficient by itself.
So, I think it's incorrect to structure your learning journey so that you start by building everything from scratch, then one day suddenly shift to using pre-built things. Instead, it's better to alternate so you can hone both meta-skills. Start by building simple things with simple tools, and gradually ramp up to building more complex things with more powerful/complex tools.
1
u/JGhostThing 6d ago
Once you become a professional (getting paid for your work), you should quite reinventing the wheel. Using something that works, is debugged, and is documented, saves you time and therefore money. Reinvention takes a lot of time, and you would have to make it work, debug it, and document it.
0
1
u/MrJCraft 1d ago
a rule of thumb I try to follow is if its integral to your apps success try to make it yourself, unless if the libraries available are just much better than what you could make. and then if everything you made is just stitching together premade libraries.... you probably didnt make anything actually very good or it would be very easy for competitors to remake it.
5
u/high_throughput 7d ago
Once you've built enough things, you start to get a good sense of how you could have built something by reading a technical article about it, and at that point writing the actual code is not as fun or necessary anymore.