What are you trying to accomplish? Say it's a start-up or a profitable business, you need to test your hypotheses, validate/invalidate the idea, etc. The risk is not technical, it's a business risk, so you ought to get to the truth as fast as possible, and you get there using what you're most productive in. The goal is to discover if it's "desirable, feasible, viable", not to optimize prematurely.
>Say, i want to build tcp client for check connection and can deploy anywhere without install any dependency
Why? What are you trying to accomplish? Where do these constraints come from? Where does the no dependency constraint come from? Where does deploying anywhere come from? Where does checking the connection come from? What is the real problem you are trying to solve?
These questions are to avoid the XY problem, to avoid the trap of solutionism, and to get to the "Job to Be Done".
Someone once asked me how to solder a thick copper wire to a thin steel plate. When I asked him why, I listened in disbelief as he answered that the fuse blew out and that he was going to get a thicker wire and solder it so it doesn't blow out. His solution comes from an incorrect diagnosis of the problem at hand, and he asked me about the solution framed as problem, not the true, root, problem.
>Is it still possible for someone like me to turn things around?
Yes.
Your very first full-time job now is to get a job in the field. Take a look at MIT's "Missing Semester". It'll expose you to a panoply of tools that will get you "semi-operational". This will not make you "stand out", but it is much better when new hires are already familiar with common tools of the trade.
Be humble, courteous, curious, helpful, reliable, diligent, patient, grateful, industrious and you'll progress fast.
When you get the job, here are a few pointers that will help you ramp up fast:
On taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable:
Remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align:
This supposes good faith from the people at hand. There are scenarios where one of the founders has decided from the start to screw over the other person, and the fallout is bound to happen when the person figures it out or tries to mediate the situation: it's not like the one who set up to screw you over will change their mind.
This is a modus operandi of some people built on finding "idealistic", "optimistic", "naïve", "gullible" people, especially technical people, of which there is no shortage in founders, to consume. These characteristics being almost a requirement for the job doesn't help.
An unbalanced equity distribution, waxing poetic about ethics, honesty, and morals... something more urgent always coming up when the equity issue is raised, etc...
Contract theory upstream.
Your work is useful when the people genuinely want to make it work but are just having trouble communicating.
I don't think the obvious choice at a terrible swimming pool would be to give up on swimming; there may be other beautiful beaches out there.
You're experienced and you seem to already have identified what you don't like. Software is practically everywhere, and it doesn't engineer itself. The aspects you talk about relate to noise that has become intolerable and there are many sectors, especially when the stakes are real, that eschew this "nonsense".
Have you considered working at places that don't "identify" as "tech companies/software companies" but where software is very present? Industry/Manufacturing, construction, automotive, aerospace, energy, logistics/supply chain, etc... In other words, places where software is a leverage to something. This may help "root" what you do in the "real world".
All these need software and they need actual, tangible, results.
Thanks for taking the time to reply. I think moving into companies where IT as cost function would be detrimental. Or do these have strong engineering culture? Reason I say that is because I used to have experience with online retail within - that was a pain! Always someone in a hurry to deliver the next feature.
reply