I would say yes. Having been a big fan of Dell and having used it's laptops for both professional and personal uses over many years, I have moved off it to Acer. Couple of reasons - the first is that there is a price premium which I cannot seem to justify and second is the teething / niggling issues which I have had to face in pretty much every Dell I have owned. Sometime, it will be too long a time to wake up from sleep or a random crash which requires me to fetch bitlocker key from my account so that I can boot it up again to driver update issues to the fan continuously running for no reason etc. I had, by chance, a good experience with Acer in the past and since then have purchased a couple fo them more and the experience has been seamless and pleasant. I do hope Dell ups its game as it was an iconic and innovative brand but there is less now to differentiate it from competition and so no reason for the premium to be charged.
I’ve found my biggest differentiator over the last decade was soft skills - writing, dealing with stakeholders, knowing how to talk to normies, being comfortable in the room with decision makers, being able to do effective presentations and project management skills.
And knowing how to “deal with ambiguity” and focus on how to add business value. If you look at the leveling guidelines of any tech company, anything above mid level is focused on “scope”, “impact” and “dealing with ambiguity”.
Knowing AWS really well is just a tool and it doesn’t hurt that I have a stint at AWS ProServe on my resume
Notice “codez real gud” is not a differentiator.
There is no hard skill you can learn that thousands of of others don’t know that will set you apart.
Well except for some vertical market stuff that will leave you pigeonholed.
* 40 inch 21:9 aspect ratio. 34 is too small and 43 and above are too big
* QHD i.e. 3440 X 1440 resolution - why? Because it renders the programming fonts perfectly - many will complain about pixelation but for me it just seems perfect. This translates to a PPI of approx. 93 which is the same as for a 24 inch FHD monitor. Scaling spoils it for me
* Curve - not too less nor too aggressive - LG OLED is 800R which is way too much - on the other hand 2300R is too less - I think 1800 is ideal
* 60 Hz or more refresh rate
* Accurate color reproduction
* Matte finish / antiglare
Sadly, a curved monitor with the above specs does not exist. The only one as I mentioned is the LG OLED which has a far too aggressive a curve. There are some lesser known brands which come as flat which I currently use but I wish there was one that met all of the above.
I see that you gave the person 5 warnings - I feel 3 times is less and this is exactly what I would do. Its so much better to give people more chances rather than less and then letting them go instead of letting an ego or something similar come in detween earlier.
Please do not take number 5 so literally. It's the process that matters. You do 2, 3, 4, 5, 6, 7, 8, 9 or 10 chances whatever suits your needs. The actual point is you don't fire people on the first mistake unless you're an asshole.
If you are using Java, you may want to check out the library I created for American Express and open sourced, unify-jdocs - it provides for working with JSON documents outside of POJOLand. For validations, it also has the concept of "typed" document using which you can create a document structure against which all read / writes will be validated. Far simpler and in my opinion as powerful as JSONSchema. https://github.com/americanexpress/unify-jdocs.
There is a diff functionality which I have provided in unify-jdocs that I think does exactly what you are looking for. You can get the details here -> https://github.com/americanexpress/unify-jdocs. At present it is only for Java. And if you do take a look, please feel free to give feedback - thanks.
JSONPath is good when it comes to querying large JSON documents. But in my opinion, more than this is the need to simplify reading and writing from JSON documents. We use POJOs / model classes which can become a chore for large JSON documents. While it is possible to read paths, I had not seen any tool using which we could read and write JSON paths in a document without using POJOs. And so I wrote unify-jdocs - read and write any JSON path with a single line of code without ever using POJOs. And also use model documents to replace JSONSchema. You can find this library here -> https://github.com/americanexpress/unify-jdocs.
I have been using Google search for many years now and for the past few years have been wondering if the search has really gone bad or is it just me. I remember the days when searching for something used to bring up a few sponsored links separately and I could go page after page with different results on each page allowing me to access a wealth of information and extending my reach deep into the internet. Now, it is all sponsored links and the same ones page after page. It is so sad to see and the worse part is that I am not seeing any alternative. Bing is equally bad, DDG only marginally better. I hope there comes an alternative soon but I also realize coming into this space is certainly not easy.
Until Kagi becomes popular. Then the same "SEO" bullshit that plagues Google will bite Kagi too. Right now Kagi is too small to make it worthwhile to spend resources "optimizing" for it.
Perhaps, but isn't the value of Kagi that it's user-tunable? If you open a page and it's distasteful to you, you can remove it from future searches, and you can uprank the sites you find useful. Related, no idea if they actually do it, but presumably, Kagi is getting signal from that about what people find useful, and integrating that into their rankings.
If I run into SEO crap on Google, I'm not sure they ever know I hated it and went elsewhere. They see that I searched and I clicked, and they got their money and don't care.
The alternative is using tool enabled LLMs. GPT4 can drive Bing and filter results better than I can, and it hallucinates less than I do when pile driving through spam.
If you haven't read up on modern prompting strategies and still feel LLMs are stochastic parrots, you should read the foundational prompting papers (chain of thought, react, reflexion, toolformer, etc) and update your views about llms. They're very close to being the kind of autonomous search agents that the characters in classic cyberpunk novels would unleash on the real world to compile results.
It's actually made me excited about information retrieval again, for the first time in a decade. And the cool part is that autonomous search agents might become free and open source before the corporations manage to enshittify the experience.
I went the other way - because I so much disliked working with DTOs to work with JSON, I wrote a library that allows you to get rid of DTOs in the first place. No more POJO / DTO in order to work with JSON data and much more. You could take a look at https://github.com/americanexpress/unify-jdocs. I think you will find it interesting!
Nice. It is great to see native lightweight opensource (I hope it is considering that someone said that there is no license file yet) solutions hit this space. For what it's worth, I have built something similar to this but for Java programming language. You can find it here -> https://github.com/americanexpress/unify-flowret. My reason for building something like this was that the product market is just too unwieldy to work with and has multiple layers of complexity which most of the time can be done away with. Just my opinion.
On a side note, you will at some point in time have to deal with multi version workflows. I know that this is one feature that limits wide adoption of an orchestrator.
Thanks for sharing your work Deepak, you have some pretty extensive documentation!
Funnily enough, the Golang framework is almost a clone of https://github.com/flipkart-incubator/databuilderframework (another orchestration engine in Java).
As for multi version workflows, I suppose that will have to be a tradeoff between maintaining somewhat redundant code or adding workflows as WorkflowV1 and WorkflowV2 and stitching together relevant steps in respective versions (reduces redundancy to some extent but won't eliminate)
