Senior Software Engineer with over 15 years experience writing quality software looking for challenging problems to solve. I’ve led teams, written architecture documents, built critical business software used by 1,000,000+ humans, and love solidifying vague ideas into products people love.
Actually the Slack I remember from when it first came out is more or less the same product they have now. I'm not really sure what all of those people were doing for all of those years.
Most people don't get to choose, in my case, it's our corporate IM system, so I have to use it whether I want to or not.
It's got a lot of enterprise features that companies like, like SSO integration, message retention policies, security certifications like HIPAA and FedRAMP, and more.
There are also a lot of pre-made apps for integrating with corporate apps like Jira, Gmail, Salesforce, etc.
It's fine, I haven't looked at a lot of other options, but it seems more usable than Google Hangouts (or messenger or whatever they call it now) or Microsoft Teams.
The big sells for Hangouts and Teams is that they have video. Slack doesn't so you have to find a video conference provider as well like Zoom. Also Teams integrates more easily with the existing Microsoft stack (office, outlook, etc.) that a ton of non-tech companies are on.
I think a lot of tech companies struggle to break into the non-tech world. Slack might be ubiquitous for SWEs but my SO who works in traffic engineering will probably never use it (they use Teams).
There was some technical evaluation done, but some features like retention policies and SSO were deemed requirements. Not sure what all of the criteria were or what all of the candidates were, it was a while ago.
You realize that there is a lot of stuff that goes on behind the scenes, right?
They need to scale their systems, maintain reliability, scale their processes, build internal tools, run experiments, work with 'legacy' code and within the existing architecture, etc.
It's not surprising product development has slowed down. In almost all cases it seems like the speed of product development is asymptotic.
Hiring too many people is still the number one thing that can kill your growing business. The communication costs alone eat a bunch of headcount so if you don't desperately need the people then you shouldn't hire them.
The problem generally starts when you hire a bunch of people without fixing broken processes first, these people then push back against fixing said processes, and the rot sets in.
> Also the interview was on a Tuesday or something and they said that they were out of money on Friday but were confident they would get more money on Monday.
> They wanted me to start immediately and when I turned them down because of the funding, they asked if I would start on Monday.
Is is straight out of a comedy sketch, I feel like you could take that to an open mic night and kill with it.
All planes are required to have the original POH onboard. However those don't really tell you how to fly the plane it's more focused on things like Vspeeds minimum flap extension speeds etc..
That varies based on the certification rules. My older 182 only had to have the operating limitations and weight and balance info (“O+W” in ARROW), but they did not have to be original.
My later year A36, I believe needs the original AFM/POH. (In any case, I do carry it.)
If you didn’t know how to fly, you couldn’t read enough of the book to figure it out before the aircraft departed controlled flight (if not on at least a wing-leveler autopilot).
As noted, on an airplane without an AFM (Approved Flight Manual) the POH does not need no be on-board, only a placard with the operating limitations. The cutoff for the AFM requirement are individual aircraft that had their first flight after 1 March 1979.
As the owner/operator of an early 1979 build aircraft that does not have an AFM, I’ve had this discussion with maintenance/airworthiness inspectors so frequently that I keep a printout of 14 cfr 21.5 in my POH.
I'm also an owner of an older 182 (1966 - 182K) I agree with you the POH won't really teach someone enough about the aircraft to fly it let alone operate the radios.
Pilot here: It could help with some familiarity but generally in MSFS you can get away with ignoring the gauges and just mess around. The tutorial might gloss over some of it.
Having an unbelievable number of hours in MSFS when I was a kid ... landing a real plane is considerably harder and a ton of instruction time is just focused on getting you to land reliably. I finished my PPL in just over 40hrs which is close to the minimum. Most people will fall into the 60-100hr pool.
I'm dubious that this passenger really had zero experience it takes a good 6-10hrs to get decent at landing (as in not bending metal).
MSFS does however offer a reasonable feeling for the cruise portion of a flight.
Also pilot here (C172 G1000): I personally find landing a plane IRL easier than in MSFS. Much easier when I am able to feel resistance on the yoke, feel shifts in wind and gravity etc. All the MSFS controls are so extremely touchy. Though I agree you need 6-10 hours to get decent at landings :)
I agree. I’ve been flying MSFT since the Sublogic days, using only the keyboard. It was very rare to get a good landing. I have about eight hours in a Cessna, and that was a piece of cake, by comparison.
I play MSFS in VR and have rudders, throttle and yoke... but without any forces on the rudder it's just incredibly hard. I certainly can't fly it very well with the Saitek / Logitech Yoke.
I tried MSFS in VR and it was also much easier because you are somehow much more aware of the surroundings (maybe because you move "camera" around the cockpit so much more). In VR I don't get lost so easily and always have an idea where the landing strip is.
As a teenage air cadet in the 1970's in northern Scotland, I learned to fly in open cockpit gliders and effectively went from scratch to first solo flights in a long weekend (January!) - within a few hours...
This seems familiar - I remember flying with mitten gloves (due to cold!), controls were joystick, rudder, flaps, and an altimeter: https://en.wikipedia.org/wiki/Slingsby_T.21
I figure it might be an outlier, it takes 6-10hrs to get decent at landing (that is to say reliably) but doing it one time without killing everyone on board can also be attributed to dumb luck - this is with the other assumptions of having maybe been a passenger close to pilot, MSFS etc.
It is my guess (though I have no proof) that most places with particularly large repositories have lots of binary files in them. It's hard to get a 15GB repository if you just have text.
This sort of thing suggests a centralized check-in/check-out model, because binary files are difficult to merge sensibly, and nobody wants to spend terabytes of hard drive space storing the repository locally. And your centralized check-in/check-out needs, whatever scale they might be, are probably tolerably well served by one of the existing solutions.
Yes, but why is that a show stopper? It's a small market filled only with people who typically have large fist-fulls of cash and are dependent on version control. It's a small market, but companies in it have the resources for a good solution.
Because those companies generally already pay the $$$ for Perforce (which has any number of deeply terrifying, shiny red candylike self destruct buttons and makes git's user interface look kind) which for all its other faults handles this specific user case extremely well.
And also paying Perforce fistfuls of cash in licensing fees. I hear that Perforce is a quite a small company, and the founder wrote the lion's share of the code a couple decades ago.
I think they are probably on par with craigslist in profits per employee (i.e. much higher than Google or Facebook. Interestingly I think Facebook has about 1/10 the employees of Google with 1/10 the profits -- off the top of my head feel free to correct -- so I don't think they blew it out of the park with their IPO filing).
Perforce is quite expensive, yes. I don't understand the rest of your comments though. I'm not sure why company size, code author, or profit margins are relevant. Perforce is used by every major gaming studio, Pixar, Nvidia, and many more.
If I were to make a snarky comment it would be that Git is for poor people and Perforce is what you use when you grow up. That's not an even remotely reasonable statement, but it does have a teeny, tiny hint of truth to it. :)
I'm just pointing out the Perforce is making crazy profit, and somewhat ironically it's doing so more efficiently (I conjecture) than Facebook, which you are hearing a lot more about.
Perforce is a great system, but it's showing it's age by now. I think there is probably room for someone to make another product in the high end space and make boatloads of cash from big companies, but it's not easy.
Yes partly. Doing lots of commits locally before pushing to others is definitely something I like.
Another part of it is working disconnected -- with so many people coding on their laptops that's actually a pretty common use case.
Also the lack of need to do sysadmin work on git/hg is really nice. I used to run the free Perforce server a long time ago for myself, but it was annoying to do the backups. With git or hg you get whole-repository backups for free.
The "big repository with all dependencies model" has its drawbacks but it's interesting that facebook finds a lot of use for it, and that git is unsuitable for it. Perforce is probably still their best choice in that case.
The most recent version of Perforce added streams which is their primary answer to git and hg. Easy creation, management, and switching between branches. I've only used this at home and not in a large scale environment yet, but it's promising.
Later this year they are adding p4 Sandbox which allows for disconnected work. When that is complete and working I'm honestly not sure what advantage git will have left other than being free.
Perforce just raised their limit on the free version to 20 users and 20 workspaces, it used to be 2 users. We use it at Tinkercad and have been very happy, I used it at Google previously. The price (free) is acceptable for almost any small development organization.
If you have used ClearCase, you will know that while it's a great solution to a "what shall we do with our buckets of cash" problem, it's not something that anyone encountering performance problems would reach for.
Remote: Yes
Willing to relocate: No
Technologies:iOS (Swift, ObjC) Android (Java, Kotlin), React Native / React, Python
Résumé/CV: https://docs.google.com/document/d/15sUWu85QbGjoWhU1euk6tHYh...
LinkedIn: https://www.linkedin.com/in/kenrik-march-09211b40
Email: kenrikmarch@icloud.com
Senior Software Engineer with over 15 years experience writing quality software looking for challenging problems to solve. I’ve led teams, written architecture documents, built critical business software used by 1,000,000+ humans, and love solidifying vague ideas into products people love.