91–100 of 112 posts
I'm very disappointed if I move from a company that uses macs, slack, Confluence to PCs, MS Teams (horrible) and SharePoint (worse).
At one of the places I worked, a relatively large university-hospital, there was an entire Java-UI framework build based on C#s XAML. But it could also experimentally be compiled to html/css/js. Writing any type of UI in Swing is just painful - but this system made it so much nicer. It also had a WYSIWYG editor that you could interop with actually writing the code. Plus you could write either the 'markup language' or…
I am very curious what the university-hospital was, if you can share it.
I honestly miss the internal tooling at AWS. The build system and CI/CD pipelines used internally are truely amazing.
This topic is one of the primary reasons I enjoy working at MS these days. The tech stack is full of OSS or industry standard tools, not a bunch of internal NIH things. My current stack is: React, Node, Kubernetes, Linux (for dev and deploy), Git for sc, GitHub, vs code. I can’t even think of some internal tool that I depend on at the moment.
That depends entirely on what part of MS you are in right? There is cosmos (internal, not exactly the same as external cosmos), autopilot for infra, mdm for metrics, mds for logs, icm for alerts, etc.
This topic is one of the primary reasons I enjoy working at MS these days. The tech stack is full of OSS or industry standard tools, not a bunch of internal NIH things. My current stack is: React, Node, Kubernetes, Linux (for dev and deploy), Git for sc, GitHub, vs code. I can’t even think of some internal tool that I depend on at the moment.
Github is open source?
Earlier quoted context omitted.
Do the math - maybe it works in your case. I'd say a key question to ask is "Do I have a technical problem that's legitimately unusual and faced by very few other businesses?" If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper. When doing the math: A common mistake is to calculate the cost of "build" as SU…
What if the product doesn't work without the tech, because it's several orders of magnitude too slow with commodity public tech? (I'd end up writing an essay if I was to fill this out to full detail.)
The point is to only build things that are necessary for your product, not to avoid building anything.
Earlier quoted context omitted.
What if it's a tool which halves your operating costs and eliminates a new technology stack you'd need to teach your whole dev team? What if the only tech that solves the problem is Oracle, and your business model can't cope with the costs that would incur? (I have a specific example in mind but it's private. Poor evidence for an argument; but I'll stand by the fact that some business problems require too much glue w…
Do the math - maybe it works in your case. I'd say a key question to ask is "Do I have a technical problem that's legitimately unusual and faced by very few other businesses?" If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper. When doing the math: A common mistake is to calculate the cost of "build" as SU…
If it's not a particularly complex problem, but not one that other businesses broadcast how they are solving it, it's quite possible you can solve it less expensively than finding out how other businesses are solving it.
(And, no, finding out how solution vendors tell you other businesses are handling it isn't the same as finding out how other businesses are handling it, since such a presentation, while readily available, will always distort the facts to serve the sales interests of the vendor.)
Not everyone finds BigCorp problems to be the interesting problems. Not everyone wants to live in the Bay Area. There's a lot of jobs in the world that aren't at FAANG, and it's okay if the right job for someone is at a place whose entire dev shop is smaller than the team at Google that maintains Blaze. If you find yourself in a job like that, it is absolutely the right call to invest in the best commodity tools you…
I've found there to be a pretty huge difference in those offices, particularly the European offices. The staff is far more diverse (e.g. I'm on a 40 person team and the largest number of people from one country is 4) and the culture and attitude to work is completely different. Much less koolaid-drinking and much better work/life balance. People actually use their (much more generous) vacation time!