@West
You forgot the part where you spend 6 months working on a project and then at the end of it the business decides they don’t want/need it any longer. You’ve still been paid, but then again they could have paid you for sitting on a beach getting a suntan and drinking piña coladas, which would have been more fun with the same outcome.
It sounds like you’re using Expo (a React Native framework, for cross-platform mobile development), and I do agree on the mobile development side that there’s way more environment issues than there are in web development. That’s why I prefer to stick with web development haha… 
But I would say there’s two main approaches here:
- You can start with a very simple tech stack. This way, there are far fewer moving parts and things to set up and configure, so you will be able to focus more on the programming side of things, that you say you enjoy. Then, every now and then, you can introduce a new layer to your tech stack, and because you will have been doing everything manually, you will hopefully be better able to appreciate whatever this new tool can do for you, and you can gradually gain familiarity with more and more tools.
- You can go depth-first. Keep on with the fancy tech stacks, but when you run into an issue, appreciate the value and exploration that comes from resolving that issue. Each time you solve an issue, you’re tucking away a nugget of knowledge that — who knows — might come in handy down the road. You’ll gradually improve your problem-solving skills, and bit by bit, you’ll get better at resolving these weird issues as you become more familiar with how all the pieces of your tech stack fit together.
@Payton
Hmm, that sounds like a good idea. Usually, I just keep throwing stuff at an issue until it’s fixed, and then quickly move back onto whatever I was trying to do. I should probably document every error as it comes and take notes on my understanding of why the issue came up and how I resolved it. Thanks!
@Toby
Absolutely! That’s so important. By digging a bit deeper to understand the issue, you’ll better understand why it happened, and you’ll start to understand — and appreciate — the complexity that your library abstracts away from you.
I feel you. Vanilla JS is your friend.
Rayne said:
I feel you. Vanilla JS is your friend.
Try SvelteKit. You will love it then. I don’t know of any framework that is closer to pure HTML, CSS, and JS (or TS if you prefer that).
Kai said:
@Whitney
Astro is definitely closer to raw JavaScript. But I love Svelte too.
From the documentation, I can’t see where Astro is closer to JS than Svelte. Could you give a real-life example please?
Also, isn’t Astro for generating static sites while Svelte is for dynamic rendering?
Rayne said:
I feel you. Vanilla JS is your friend.
Yup. You can accomplish so much with just HTML, CSS, JS and/or PHP. And it all just works on the server and can mostly be debugged in a browser (not PHP obvs). What a world!
I find that instead of trying to just make the errors “go away”, spending some time to fix them by understanding and deconstructing the config/dependency process as if that was the main project I am working on turns it from frustrating into something that is fun. Make that a part of the coding, not just the preparation for coding.
@Sage
Well said. It took me a while to make this mindset shift, but it’s absolutely the way to go. Once I took the time to study Webpack, NPM, interoperability between the different module systems, and whatnot, I am no longer frustrated by issues in the infrastructure. Rather, they make me curious, because I gathered enough knowledge to tackle them. I’ve debugged a couple of things at work that made colleagues look at me like I’ve just discovered fire.
As others have answered technically, I’ll go with the theoretical. Yeah, in a professional environment there is a good chance you’ll spend only 20% of your time actually coding; the other 80% becomes less about the environment as that’ll be largely automated or even managed by a dedicated person, and instead gets spent on planning, paperwork, and meetings along with the expected debugging and problem solving.
Those ratios can vary wildly. However, depending on the team composition, the project, the stack, and the DevOps process employed, what you find more or less enjoyable will change over time too. When I started out, I never even imagined how I’d become to enjoy technical writing.
If it makes you feel any better, Expo (while useful) has been an incredibly frustrating experience for myself.
I have a lengthy note in Obsidian that just lists things like “if this cryptic error, perform this step” specifically for React Native.
In comparison, most other modern tooling is really solid (Vite for example). But this is because web tooling has had a much longer journey and more time to mature. I started with RequireJS and have been through a mix of tooling like Grunt, Gulp, Browserify, and Webpack 3, 4, and 5. Each tool borrowing and learning from the previous.
I’m sure Expo will get there eventually or native in general, but it needs time.
Personally, I’ve swapped to Capacitor because the web tooling is vastly superior to native tooling (imo). It’s not without warts of course.
Coding for software developers is like cooking for a chef. You definitely do it, but there are many other activities that need to happen. Either you are doing them or someone else is doing them for you.
There’s a lot of solving error after error and that’s fine.
As other people here have mentioned, you can reduce the tooling headache by going vanilla or something like Svelte kit.
Where I find the real difficulty is when you are working with older enterprise software whose initial maintainers have retired. Then you first gotta figure out what you don’t know about the system you are interacting with.
Yes, this is common in web development — setup issues can be overwhelming, but they get easier as you gain experience and better understand the ecosystem.
Frameworks come, go, and change all the time. You will always have setup and environment issues - as things evolve, new issues will keep popping up, it never actually ends.
If you aim to work in teams and big companies, your choices can be limited and you may just have to live with the ecosystem you are given.
But if learning and/or working on your own, you definitely can find a happier place by keeping your stack simple and under your own control.
This means sticking to libraries that are less invasive and don’t dictate the environment you code in. Third-party code you depend on should ideally be constrained to a simple module that you control. If you can’t imagine switching the underlying library to a different one with relative ease, consider that library (or framework) too invasive. Frameworks bad, libraries good.
(unfortunately, pure unopinionated libraries are getting rare; more and more libraries are bound to frameworks and other convoluted systems)
Deno is a pretty good alternative to Node if you are into simpler stacks where you do and control the groundwork yourself. Less setup and hassle in general, and you still can use most of the stuff available in npm through the Node compatibility layer. (Node compatibility is not 100% but pretty good, and the problems tend to be with frameworky npm packages, which kind of reinforces the earlier point about avoiding invasive libraries haha)
You might be surprised how much you can do with plain Deno and SQLite (preferably without ORM). And how much traffic you can handle with such a basic stack on an entry-level VPS (yeah, keep also your hosting simple for maximum fun and profit - Docker, serverless platforms tend to bring more problems that they solve, just like ORMs and frameworks).
Is this what web development is like?
Yes.
Well, I code in Vanilla PHP. All joy here.