Learning programming technologies, platforms, libraries, approaches is somehow similar to personal development - unlimited, illusionary beneficial (most of the things are better for concrete use cases), boundless, subjective.
What is better or good is subjective, even area like computers, technologies and totally measured and should have been black and white stuff, in terms of speed and math. (Un)fortunately, tech can and should be looked at from a lot of view points.
User eXperience - There is some science, what should be the colors, where the stuff should be on the web pages to get into the mind of the users. Besides that - exposing the tech stuff to a non technology is somehow winning. There are tons of WordPress sites even that - PHP is interpreted language and before OOP was a little bit strange to work with (at least in my personal experience).
Finances - what makes any software valuable in terms of money is the users, the psychological package that comes to it, not the complexity behind it. Many personal development individuals have an e-commerce site selling digital stuff (audio, books, videos), or a membership - which is the content accessible with just a user management platform. No cryptography, hashing, P2P sharing, and other ideas that are mixed together in the block-chain stacks that are hard to explain to your grandma.
Speed of development - As a developer you are paid to create something that in the end is given to non-technical people. Obviously, the fastest you create it, the better. I've seen in my experience - the number of design patterns does not relate to the speed. I've seen in colleagues - fast and slow speed - in both simple apps and in complex. In the end it is the monkey in front of the computer that is giving the horse power to the development process.
Adaptable to change - the software should be easy to change for any upcoming changes. That is not always the case when you develop fast. This could be changed with practice and having a tool set, reusable components that you know (coded by you or by others, but such that you understand them deeply enough).
Quality - Quality does not go along very good with speed of development. There are two levels of quality that I thing are important. The higher level - when the software does the job with some small bugs here and there, some areas to improve, like speed, color change, rearrange some items visually. and low level - the blue screen of death, stack-traces, blocking bugs - stopping the software even with correct input data.
Too much complexity in the beginning. If you've worked in the corporate world, with design patterns, complex frameworks, technologies of scale, don't shit them all on a new toy that hasn't reached any user yet. Yes, the Minimal Viable Product should be implemented in such a way that it could be transformed from bicycle to a car to a air plane without dumping all in the migration. But, before you know the world needs your creation, it is waste of time to dive deep into technical junk like - the best programming language, framework, stack, library, server/cloud etc. That comes with practice. When you already know that you will have users, then it is OK to go deep.
My idea is - to enter the feedback loop as soon as possible. Some development methodologies try to embed it - Scrum, agile, dev-ops, fast release on different environments with automated tools. Having circles of closed friendly to your heart group for testing could help. In the corporate world, sometimes, there are too much nodes in the process. If you ever tried to be entrepreneurial, you know that it is better to have the big picture, so you could better understand what the end user could use even if he is now aware that he needs it. I realized that in the past weeks, talking to non-devs even about stuff that is totally unrelated to what I do.
Top comments (0)