It depends on what you mean by Software Architecture. I normally see 3 interpretations of it.
For some people, S/W arch is writing readable, maintainable code. Things like Design patterns, FP, TDD, microservices etc. There is a lot of literature on this out there.
For others, it means having the ability to design the next Kafka/Spark/React. You can get basic theory for this by reading books on Domain Modelling, Distributed computing and Algorithms. So books like The Algorithm design manual, Designing Data intensive Applications, The Parallel and Concurrent Programming in Haskell, Functional and reactive domain modelling etc. The http://aosabook.org has good case studies to read as well. However, to actually build these systems require facing the problem in the 1st place and being unable to use existing systems to solve it. Or doing phd in them. It happens rarely.
Finally, the last one is my day job. Which is to convert ramblings and fantasies of leadership into a production systems, minimizing the number of curse words people use when working on it. I haven't really found any good guides to do this though. Things which help me are:
- Always thinking what could go wrong. And if it does, who should be notified if the system can't recover. A lot of times when I don't have the answer, I ask around. Things like slack channels, mailing lists, or even having coffee with people in industry who have tackled stuff like this.
- Communication skills. This doesn't mean small talk, but being able to have conversations and meetings which help define requirements and ensure everyone is on the same page. Also making sure there are hard numbers. ie. instead of "fast","responsive" etc, get latency, throughput, uptime numbers.
- Understanding business/technical capabilities and limitations. Things like business impact(LTR etc), capabilities of current infrastructure, skill levels of various people/contractors involved etc
That's right, in the H-1B context, there needs to be an employer-employee relationship between the petitioning company and the sponsored worker and this (in the eyes of USCIS) ultimately means the ability of the petitioning company to fire the sponsored worker and otherwise control his or her employment.
A CEO, CTO, CFO, CXO etc. are all "employees", technically an employee is someone who works for the company (unpaid work also counts) the company.
E.g. You can have 100% equity, be sole shareholder, pay money to a manager/employee to conduct work/business. You can even derive a dividend from the said business. however you cannot "engage in business" which means that you cannot write code whose IP gets assigned to the company. You also cannot have day-to-day management responsibilities. If I remember correctly planning a business and/or attending meetings of board of directors is allowed.
At end of the day shareholding pattern trumps everything else.
The problem here is if you are A, then no one will give 49% stake to you because of your idea. This only works on paper but in reality you will get screwed.
Can anyone help me understand what kind of employment are available in the market which requires deep knowledge of compilers?
I love this subject, but I don't know to which domains it is applied on outside of compiling languages like Javascript/JAVA/D/C/Rust and so on on into Machine code.
