Dusting off some old replies. The TL;DR is: reduce information asymmetry, expose thought processes and align (everyone knows what to do, what not to do, why, and how we got there). People should send in pull requests to your thought processes. They should be able to take decisions based on their model of your thought processes, which you can help them build. Increase leverage and fire yourself every day.
The posts that are more relevant to you:
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:
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:
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.
If I disappear, what will happen:
- https://news.ycombinator.com/item?id=25008223
Communication, alignment:
- https://news.ycombinator.com/item?id=24177646
Useful things for the team and product that add leverage:
- https://news.ycombinator.com/item?id=21808439
Communication with the team (link, and subsequent clarification):
- https://news.ycombinator.com/item?id=21598632
- https://news.ycombinator.com/item?id=21614372
Fractal Communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets:
- https://news.ycombinator.com/item?id=26123017
Product development:
- https://news.ycombinator.com/item?id=22827841
Management involvement as a spectrum:
- https://news.ycombinator.com/item?id=22715971
Giving a damn:
- https://news.ycombinator.com/item?id=20356222
Researching topics:
- https://news.ycombinator.com/item?id=25922120
Keeping up with a firehose of information:
- https://news.ycombinator.com/item?id=26147502
Tips to learn from videos:
- https://news.ycombinator.com/item?id=22710623
- https://news.ycombinator.com/item?id=22723586
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:
- https://news.ycombinator.com/item?id=26179539
Less relevant to you, included nonetheless...
Understanding codebases:
- https://news.ycombinator.com/item?id=19924100
Testing pipelines, scaffolding, issue templates:
- https://news.ycombinator.com/item?id=26591067
Making the most out of meetings and leveraging your presence:
- https://news.ycombinator.com/item?id=22873103
Consulting, understanding the problem your "client", who can be your manager, has:
- https://news.ycombinator.com/item?id=24972611
Product, architecture, and impact on the team:
- https://news.ycombinator.com/item?id=24503365
Onboarding new hires to a codebase, what if it were you, improve code:
- https://news.ycombinator.com/item?id=22860716
Reduce information asymmetry, template for taking minutes of meetings to dispatch to the team:
- https://news.ycombinator.com/item?id=21427886
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:
- https://news.ycombinator.com/item?id=24209518
More meeting notes. Reply to a person who had trouble talking in corporate meetings:
- https://news.ycombinator.com/item?id=20323660
reply