I was a developer at Shell a couple years back and led a project where we were using nascent GPT-1/2 to process and search over mountains of documents. It was a fun project where I wrote a complex/fancy UI for a stratigraphic filter and indexing system...
AI in general at the time was led by a VP and a particular group (that was AI tech specialized) under him. The initial idea came about from them. We were trying to find new ways of using AI to research new sources of crude at the time.
Another AI project I worked on there was a chemical tank use estimation and refuel application which used tank sensors, previous use history and some other metrics to pre-purchase and deliver product to keep tank reserves above a certain threshold.
I had an app on the frontpage for a whole day last year (Show HN) and the server behaved like a champ... a simple 6US/month, cloud compute instance on Vultr. It was a Rails app as well.
I generally dont understand how some sites go down so quick.
The 'light-based' network thing kinda threw me for a second...wifi IS technically light, its just a frequency (RF) at which we can't see it and that can (somewhat) penetrate walls.
Literally none...this is just the argument of contrarians or people who've only ever worked on personal projects who take offense to real applications used by actual audiences.
It is! Although what I missed out from above is that whilst the API and it's documentation is the deliverable - we would, to the best of ability, try and minimise risk whist developing it. Eg: by doing small performance experiments, drawing on prior experience, thinking about the evolution of resources within the API whilst writing samples, and looking at how other APIs handle similar things (but be careful - they may have had to perform heroics to achieve their behaviour).
Whilst the official progress is top down, the duck's feet are working hard feeling along the bottom to check for obstacles.
I feel like sprints should be more relaxed: "Oh you might bleed over into the next week? Don't stress, that's fine. Can we help you get unblocked and how?"
Just because you say you want it in 2 weeks does not make it so. Don't over promise, you will be severely disappointed. Software breaks, it does not care for deadlines.
This how my team functions. It's such a refreshing work experience. Estimating work is hard, we shouldn't be punished or feel bad when we're off a bit.
That's kind of the way I write APIs, albeit at a smaller scale. First write the code of how I want to use the API, then write the the actual API. I remember a talk from the developers of the Python requests library mentioning this same process.
Yes, I do this too...its a different thing when you are talking about your own insular project or something at a smaller scale.
The thing I was talking about was larger scale projects like the ones mentioned by the author (of the sort I work on at my day job) where you have teams of stakeholders and outside influence combined with a desire to release rapidly in an iterative form.
Software these days is just done differently in those contexts...we can't slow down enough to do what was detailed above...I just wish the world was sorted in a way or slowed down enough to do REAL engineering.
I kinda work this way on my personal projects: first I come up with a rough idea of the UX, and only then do I start implementing it. The desired UX ends up driving the decisions about the implementation details and technicalities — not the other way around as it often happens in much of modern software. And I, of course, disregard the time component.
