Saying “ChatGPT told me …” is a fast track to getting your input dismissed on our team. That phrasing shifts accountability from you to the AI. If we really wanted advice straight from the model, we wouldn’t need a human in the loop - we’d ask it ourselves.
First of all: great that you’re working on bringing innovation to general aviation! During training I also wondered about some technical aspects, as a lot of the tech in an airplane is from almost 60-70 years ago.
However, as a PPL holder myself I think that understanding weight and balance, aerodynamics, flight planning, ATC, airlaw, principles of flight etc. is paramount to keep yourself and others safe.
In the air you cannot simply drive to the side of the road and have a look at what’s going on. As a pilot you must be able to make decisions on the spot. To be able to make those properly, you have to understand what’s going on from first principles. In aviation safety is the primary goal. Statistically more than 80% of aviation accidents can be traced back to human error. Anything that facilitates bringing people in the pilot seat suggesting they need less training is something i strictly oppose.
Despite, anything that helps to simplify aircraft operations may decrease cognitive load and is therefore welcome.
I guess you're aware of the ICAO/FAA hoops you have to jump through to get anything of what you're developing beyond experimental certificate but having seen how long it took e.g. Volocopter to gain their (still incomplete) type certificate it is a long road.
If you'd be able to simplify avionics and create an affordable standardized fly-by-wire kit that alone would be a great innovation for GA especially in the ultralight and light sport aircraft category.
A - Just as with customer reviews on amazon unhappy customers are often times the majority to leave a review whereas fewer happy customers voice their opinion in the form of a review. I suspect the same goes for VC interactions.
B - Due to the way the VC business is structured the variance in "quality" of VCs is heavily skewed and not normally distributed, tricking our perception of what to expect. In other words i suspect that you have a much higher likelihood in to interact with a very "low quality" VC or absolute "top VC" than with an "average" VC. If you amplify this with A you may get an even worse public opinion.
Nevertheless I think on an individual basis you're always better off if you don't need VC for your business - if you have that option.
Just an anecdote (no judgement here; VC has its place): An acquaintance of mine who works for a VC firm once said "Ultimately, VC money is a loan for people who are not bankable".
That really resonated with me as with that perspective I understood why behavior & practices are closer to what you'd experience if you personally need to take out a loan outside of the regulated banking system
Cost/price is another key aspect that is not prominently present in the article but is a key decision driver. The assumption on the employer side is that younger folks will work for lower salaries AND can be developed to the companies needs whereas someone with 10-20 years of experience is automatically “more expensive” and has to adapt.
Now there is a catch: even IF an experienced candidate would work for a lower salary, e.g. if they don’t have exactly the matching skillset and need time to learn, the employer may see this as an indication/admission of a lack of competency and decide against that candidate.
It’s a tough challenge and often a lot of irrationality seems to be involved.
Can confirm that you may run into trouble e.g. when requiring screenshot capabilities (via scrot in our case) hence we had to set the WaylandEnable to false as well.
I leave the house for a walk or a bike ride for at least 15-20 minutes which is basically a "fake commute". When i come back it is like coming back home from work and i can easily switch off.
Whenever i don't, I have troubles to switch off from work.
I like that this article is very clear, visual and to the point. From my experience those exact same approaches/models are very useful throughout many situations in business, not only for designers. Consider e.g. sales where you also need to
- show (the customer) how to solve the problem (he/or she has)
- create a clear decision framework (and get the customer on board)
- craft a narrative around our solution
to succeed. There you also need your problem solving skills, a model for decision making and a way to communicate in a way that reaches and convinces your audience.
we've been doing this for the past 4 years, but as i really started to enjoy sales, things are going quite well, so i'm just adding my 2 cents:
From my experience the sales process is the only thing that matters. No client cares about the software (at least initially).
Although this is/was tough to hear as a softwareenigneer (i didn't believe it either), if you're in B2B and trying to solve a serious enterprise problem, most of the readily available info on "how to start up" on the web is not applicable.
All the talk about "build a fancy landing page", "build an MVP", "test your market first" did not help us. This is because we found that our target audience is not really active on the internet and the amount of potential DECISION MAKERS/BUYERS (not users!) is in the thousands to tenthousands not in the millions. Therefore we needed direct sales, whether we liked it or not. And initially that's a founders job.
See this as a hint for my claim: B2B companies that are turning over many millions of dollars per year often have "a website" (which looks like it's 1999) but that's basically it.
Why? The clients are in B2B as well, so the level of doing business is mostly person to person, establishing a relationship. You don't need a fancy website for that.
The reason is actually pretty simple: If you are solving a relevant business problem in B2B the duration of the anticipated business relationship is 5-10++ years. Depending on WHAT problem you solve the dependency on the clients new supplier (=you) is very high. Therefore a client cares much more about WHO that supplier is. Building that trust takes time and interactions, and that is why B2B is so fundamentally different from B2C where you have everything from one-off interactions to product-lifecycles of 1-3 years (max).
It was therefore always clear to us that building a viable B2B business takes 10 years.
So what did we do? Initially none of our clients cared about the software but about the business problem we solve and the people/the company who they are doing business with. We funded our product development by doing a mixture of pre-financed dev work & "contract software dev/consulting" with the IP remaining with us. This allowed us to build a product and use the references to get to work with the next clients. Over time this lead us to our (now SaaS) product.
B2B is tough, but as soon as you're in, you're in.
Next up in the news from 2000: "Data warehouses on the rise due to increase in data required for machine learning". /sarcasm off
Seriously: APIs were always a thing and always will be as long as different programs have to talk to each other. I just recall the good old "SOA" days with loads of XML in SOAP and WSDL/UDDI [0], when everyone told the tale of solving the interoperability problems once and for all nicely captured by [1]. I agree, how business was handled was different (you had a contract, and wouldn't order with one click and your credit card), however this doesn't mean it is fundamentally new. We will see an increasing shift towards "pay as you go" services you can consume but i wonder where the limits of this trend are as you get highly dependent on thrid party providers to not shut down or raise prices over night, e.g. [2]
We made the exact same experience (our company is also roughly 3.5 years old). In the beginning it was US who suggested to open a slack because we thought it would help us to resolve questions quickly. However we observed that this only incentivises to have chat discussions over topics that are better discussed and resolved in person/over Skype or via an thoroughly thought through e-mail that cuts straight to the problem.
In addition it added another communication channel we HAD to monitor from that point onwards because our clients had learned from US that we’d respond quickly, so not responding was not an option. This was especially problematic for our developers who would get disrupted way more often. In addition communication was scattered among channels which made it difficult for the PM to stay ahead.
Our lives are easier and our communication with our clients is way more productive ever since we abolished slack.
We're not doing .NET, however i suppose besides the fact that it uses TypeScript it is popular with MS developers, because it gives you a structure that allow to develop enterprise applications in larger teams.
If you know your application will have to be enterprise grade, will be large, will be developed by enterprise devs and has to be supported for years to come, Angular is still the definitive choice (IMHO). Mainly because it gives your team a clear structure to operate in combined with known concepts.
Saying “ChatGPT told me …” is a fast track to getting your input dismissed on our team. That phrasing shifts accountability from you to the AI. If we really wanted advice straight from the model, we wouldn’t need a human in the loop - we’d ask it ourselves.