Why I'm Glad I Lack Passion to Be a Programmer
blog.miris.designA lot of this resonates with me. Programming takes on a more enjoyable form when you can remove ego a bit, and worry less about padding your resume and learning your 1000th tool.
That said, it can be fundamentally hard to strike a balance on that with a client.
>Should a client need [...], I'll go with it. But I'll do so only when it's the simplest and most maintainable solution to the problem, and not because I want to be the greatest of programmers in my or other people's eyes.
"Simple" and "maintainable" depends on who is maintaining the project after you, and what they know, and what programmers at-large are likely to know. I also tend to make frontends that heavily rely on server-side and jQuery. I know that an SPA might be better sometimes, but since it will take me 10 days to learn a new framework (say 30-90 to learn it well), it's never the simplest solution _from my perspective_. But, it might be fine to stick to my old ways if the client just wants speed, or if I know I'll be around for a while, or if I'm confident any newbie can come in and quickly understand/overhaul my work.
I think it's also just ok to admit to ourselves that, even if it's not ideal for a client, eventually we want to work in a way that's mentally comfortable and familiar. You want some adventures to spice things up now and then, but too much too fast is overwhelming. Wanting to work with a familiar stack seems comparable to wanting your usual snacks, noise level, view, temperature, etc. As we become less desperate for salary, or as priorities change, it ideally becomes easier to say no to jobs/clients that can't accept a certain stack.
You're absolutely right -- it can definitely become difficult to achieve that ideal with certain clients, and as you've also said, "simple" and "maintainable" can be a very subjective thing. I admit that it's tacit knowledge in my case, and also a gamble that the next developer will preserve their sanity. There's no formal yet practical way of gauging simplicity and maintainability.
Your point on mental comfort is also spot on -- ideally, there should be a satisfaction between developer comfort and fulfilled clients. Sadly, that could also come with its own compromises. Heh, development is fundamentally a game of figuring out the sacrifices with the least impact for all parties involed.
This also served as a way of mitigating the impostor syndrome, which I'm sure many of us have dealt (or are currently dealing) with. Do you have any other approaches? I'm interested to read your thoughts!