It was random that I started my developer career. I didn't have any conventional background in computer science or working experience back then. Long story short, I found some things at work inefficient and showed some solutions using a bit of technology I knew of. The boss liked my ideas, and I somehow became the sole developer for that company.
Still, I find this experience invaluable for being a developer. I recently had an interview and talked about my early days, which made me think of this story.
Wait, I can build that for you
I was young. I was working for a local flyer paper company—just a casual job. Every night, I delivered ad papers to mailboxes. I found it tedious, so I used Google Maps API and built a specific map to see dense areas in neighbours to make the work faster. I sent it to the business owner. "Hey, can we just use this map? It makes things much easier." He was amazed, even though I just did it casually.
He started consulting me on anything technology-related. He couldn't even use Excel. I helped him, and he paid me extras. That's when he told me he wanted an app to manage employers' working hours. Wait, I can build that. I was learning Python and Django. I told him that I would do it.
I built a simple Django app and deployed it onto PythonAnywhere. It was nothing pretty, but he appreciated it. It worked. From then on, I developed several apps for them on demand. Some worked, some didn't. The boss was a typical, hasty business owner with heaps of ideas. I turned them into real.
Anyway, I had become the sole developer for a random local small company when I realised.
What do you want? Here's the solution
Even after leaving that company, my work went on in the same manner. Whoever the stakeholder was, I asked questions. What do you want? What's the best future you can imagine? What kind of outcome are you after? What's the problem now?
And I say: Here's how to solve that problem. It's going to take X weeks. Do you want it?
This is how you become a full-stack developer. You just get problems. You get ideas you want to turn into reality. You think about it. You realise you need A and B and C. You do it all. You get the result anyway. Now you're a full-stack. Indeed, I'd never decided to be a full-stack. I just wanted to solve problems to help the people involved. My point is to follow your mind—the mind of problem solvers. Technology will follow it.
Just know what you're trying to achieve. Ask questions. What's their issue? What's preventing them from achieving their goals? How can I make it possible? As Sun Tzu once said, you won't get defeated if you know the enemy well enough.
Or maybe you don't necessarily need technology at all. Technology just makes things easier. A developer's job is not about writing a bunch of code. It's about removing pain, after all. If the code is not producing any value, it's nothing.
Solving problems is not enough
I'm not saying developers should disregard technology. No, it's the opposite. Because you want to solve problems, technology matters. It is your duty to ensure the project you're working on can try as many ideas and solutions as possible.
Your application must be flexible enough to add new features at any time. Software should always be "soft". Technical issues should never be in their way, so you should be responsible for your code. Is the structure scalable? Does it have granular components you can swap at any time necessary? Do you confidently and quickly change the code? They're not for the "good practice" sake but for business's sake.
If you're aware of that, you can make the right technological decisions even when you face trade-offs. It's impossible to make every piece of code pretty. Then, how do you pick the one that should be well-organised? The one that matters for the project. The one that is likely to change.
In the past, I was on this team and built a new application request by biz owners. We shipped the first version within two or three months. The team worked quickly but in a dirty way. The first release received favourable responses, and the business owners got excited and requested heaps of new features. I didn't nod. I knew it would eventually pollute the app's maintainability. I negotiated to narrow down the feature scope so that we could work on refactoring.
"Yes, the app does work, but unfortunately, it's currently not easy to change because we built it quickly to see if it would work and how users would respond. The features do not seem urgent, so can you give us a few days? It will save us weeks in the future." We reorganised the code for the next business stage. As a result, the domain logic became clear to the developers, who could then work on new features much faster.
Stakeholders usually have little to no idea about how technology works. If they see the app working, they assume they can add more features simultaneously. As we know, this is not always the case. The well-written app and the unmaintainable one would just work the same way, and they don't know it. So, we sometimes need to restrain the business side to achieve long-term success. And it is your mind that tells you to do so. If you're just a mindless developer, you won't.
I have seen many people who genuinely believe technology can be their work. No, they don't pay you just because you know JavaScript or whatever. It's because you can solve their problems. To help them achieve their goals. That is your work as a developer. You shouldn't write a single line of code before knowing the issues. It's your mind that solves problems, not technology.