tcamp

Same thing happened to me. I got denied because as a founder/owner holding more than 25% of a company they consider the P&L of the company as your personal income(loss).

Credit score impacts interest rate but debt to income ratio that is above 50% can completely disqualify you from a mortgage. Thats where the founder ownership can skew your personal DTI.

You can go to asset based lenders who evaluate and secure the loan against your existing assets (cash, etc) rather than based on your W2 income and DTI.

My good friend google told me that 12PM UTC on Wednesday is the best time to post.

Its and old article though... https://wiredcraft.com/blog/how-to-post-on-hacker-news/

To be clear, I'm not affiliated with Starry or Guifi. Just interested in the disruption of current ISP models.

You are correct about business model, access and governance. Yet the similarities go beyond just being in the same industry.

Similarities include:

1. Both compete with & fill an ISP last mile void. a. Guifi - Access to the internet b. Starry - Access to the Gigabit internet

2. Both are the acting as ISPs for their users.

3. While not the same, there are architectural similarities. Wireless, communication nodes, etc.

Experience from the other side...

I've acquired and had to integrate several companies. I can remember writing the operational playbook that was used to handle the types of questions you are asking. After acquiring the companies I also had to manage them for several years and hopefully this sheds some light on what you're asking.

2 top level things. The acquired entity can stay together as a whole or it can be broken up into its functional pieces.

While there are exceptions, the back office functions and people (accounting, finance, admin, etc) will usually get folded into the back office functions of the acquiring entity. If you are an employee in this function, most likely you will get absorbed or let go.

Depending on what the terms and goals around the acquisition the other functions and roles will be absorbed. For example, if the goal is to find "synergies" then redundant or non critical resources might be reassigned or let go.

In one acquisition I kept the product, engineering and business development team completely whole and located in their own building and tried to not mess with the success they had but just give them what they needed. We planned what we wanted to accomplish and then I just let them run and help get the bureaucracy out of the way.

Cultural fit is hard and important. When I acquired another company we tried to fold them in and it was hard on everyone. Within 2 years only 1 engineer remained and he was the one that was hired right before the acquisition so it wasn't as big if a cultural impact to him. If the culture of the entities don't jibe, it can create an unhealthy tension.

Best advice I can give you is to understand the goals of the acquisition, how your role maps or fits into the combined entity, the level of specialization your role has and what your personal goals are.

It will be a process. I've been wildly successful and a terrible failure. My take away is that the goals and people matter.

Hope this helps give you some perspective.

This seems similar to starry (https://starry.com/internet). They are rolling out their wifi routers now and looking forward to their internet service that uses millimeter waves.

This is by the same guy who did the Aero startup. The large broadcasting companies were completely threatened by it.

Interested to see what happens with Guifi.net and Starry.

How does this work with or replace other NLP solutions in the market. Is it only for training models or for actual interpretation as well.

Completely agree. Its easier for kids to learn through stories and examples that accompany the story.

One fundamental aspect of functional programing is that it specifies the use of functions as arguments.

I like the chapter suggestion. Maybe each chapter builds upon a function that the kids can relate to. The subsequent chapters can use the previous functions as "arguments" or objects so that they understand this concept.

From my experience it really depends. I've worked as a programmer and product manager as well as a Manager of hundreds of engineers and product managers.

Reading a lot of text is only one way of getting information to perform your job. For instance, some of the best programmers and engineers I managed knew how to have good discussions and the right questions to ask.

Often times user stories are the foundation of that interaction and they are extremely short and organized. As someone else mentioned here, technical learning is very structured and most engineers I know read a little, try it out and then read more if they need more help.

As long as reading a lot of text is not the main form of how you get information and learn then you can probably be OK as a programmer. If you are looking ahead and wanted to engage in other roles then you should invest time to become confident with that form of information.

Happy to see this go. When using online tools this "feature" ruined more hours than I want to count. Love shortcuts but this one was a problem.