A platform for digital asset management, review and workflow. Current features focus primarily on review of images aimed at automotive configurators.
The problem is generic, however, our USP is we have a couple of enterprise customers that upload packs of 60k+ assets for a round, and thus we aim to help discover what demonstrably changed.
A bit like Github, only working with images, videos, and other digital assets rather than text files.
Honestly, I think that's people reacting to the market more than it's the market reacting to people.
If your average zoomer had the ability to get a job for life that paid comparably well by a company that would look after them, I don't think loyalty would be an issue.
The problem is today, sticking with a company typically means below market reward, which is particularly acute given the ongoing cost of living crises affecting the west.
I suspect they were more referring to curmudgeons not patching.
I was engaged after one of the worlds biggest data leaks. The Security org was hyper worried about the cloud environment, which was in its infancy, despite the fact their data leak was from on-prem mainframe style system and they hadn't really improved their posture in any significant way despite spending £40m.
As an aside, I use NATs for some workloads where I've obviously spent low effort validating whether it's a great idea, and I'm pretty horrified with the report. (=
The thing about your bigco, the OPs and the post he's talking about, is it's all so abstract from money.
You have two poles here.
1. The VC route, strikes gold, and never really needs to live with the reality of asking what an ROI is, it's all talk about spotlight, impact and value, without any articulation about cash money.
2. The MBA route where you effectively can't brush your teeth without a cost/benefit analysis that itself often cost multiple times your initiative, resulting in nothing getting done until you're in some tech debt armageddon.
The reality is if you're still making bank on the abstract without being able to articulate revenue or costs, you're probably still in the good times.
Writing TypeScript is better than JavaScript, but the lack of runtime protection is fairly problematic.
However, there are libraries such as https://zod.dev, and you can adopt patterns for your interfaces and there's already a large community that does this.
Zod is quite unpleasant to use, IME, an has some edge cases where you lose code comments.
From experience, we end up with a mix of both Zod and types and sometimes types that need to be converted to Zod. It's all quite verbose and janky.
I quite like the approach of Typia (uses build-time inline of JavaScript), but it's not compatible with all build chains and questions abound on its viability post Go refactor.
Sure. You tend to think about the edges of your application.
1. Router
Tanstack Router: Supports runtime validation libraries such as z0d. So I have routes such as example.com/viewer/$uuid/$number, it should 400 if those aren't actually validate uuid and numbers.
React Router: Supports Types, but every type is a string because, well, they technically are, but this isn't useful in practice in my opinion. There are 3rd party libs such as: https://github.com/fenok/react-router-typesafe-routes
2. API
Lets say you're making your API public to clients you can't trust to send the correct data ( which probably also includes your own client ).
It's one of the few CI tools where you can test your pipeline without committing it. You also have controls such as only pulling the pipeline from trunk, again, something that wasn't always available elsewhere.
However, it can also be a complete footgun if you're not fairly savvy. Pipeline security isn't something every developer groks.
If you choose wisely, things should suck less overall as you move forward. That's kind of the overall goal, otherwise we'd all still be toggling raw machine code into machines using switches.
This is it right here. My foil is the Elasticsearch replacement because PG has inverted indices. The ergonomics and tunability of these in PG are terrible compared to ES. Yes, it will search, but I wouldn’t want to be involved in constructing or maintaining that search.
The consequence of running ingress and DNS poorly is downtime.
The consequence of running a database poorly is lost data.
At the end of the day they're all just processes on a machine somewhere, none of it is particularly difficult, but storing, protecting, and traversing state is pretty much _the_ job and I can't really see how you'd think ingress and DNS would be more work than the datastores done right.
Now with AWS, I have a SaaS that makes 6 figures and the AWS bill is <$1000 a month. I'm entirely capable of doing this on-prem, but the vast majority of the bill is s3 state, so what we're actually talking about is me being on-call for an object store and a database, and the potential consequences of doing so.
With all that said, there's definitely a price point and staffing point where I will consider doing that, and I'm pretty down for the whole on-prem movement generally.
I'm generally strongly in favour of bare metal (not so much actually on prem) but your case is one of the rare cases wher AWS makes sense. Even for cheap setups like that, bare metal could likely be cheaper even factoring in someone on call to handle issues for you, but the amounts are so small it's a perfectly reasonable choice to just pick whatever you're comfortable with.
That's the sweet spot for AWS customers. Not so much for AWS.
The key thing for AWS is trying to get you locked in by "helping you" depend on services that are hard to replicate elsewhere, so that if your costs grow to a point where moving elsewhere is worth it, it's hard for you to do so.
Tech has built literal industries of people trying to stress you out, and they mostly don't have actual tech skills or the empathy that comes with them so back it up.
For me, I usually try to avoid anything where the working practices are strongly defined. Agile has long been a bad word.
Unfortunately while the intentions around agile were noble it's pretty much a direct way to burnout or worse. The human mind is not designed to "sprint" run a marathon, metaphorically speaking, forever.
I see older devs being active in the trade well into their 60s but even as I much younger person I don't see how agile development is sustainable for a ~50-year career.
The thing is, the core agile points from the manifesto are pretty much universally fine and can pretty much be boiled down to, "make changes fast, get feedback, gain more understanding faster".
Pretty much everything that's been layered on top though has either nothing to do with the manifesto, or actively breaks it. i.e. there's a burning issue, I'll get to that after my sprint commitment, which was sold to let me finish work, but now only exists to stress me out to squeeze more widgets per unit of time, where the widgets pretty much never actually map back to anything actually tangible.
Scrum is like Spaghetti Carbonara in America. The ingredients are simple and there's a tiny bit of technique involved that anybody can figure out after a few tries. For some reason though almost everybody that makes it decides that they know better than the people that invented it and so adulterates it with peas and onions and garlic and cream and cream cheese and Italian seasoning and parsley and chives until it ends up being Olive Garden Alfredo. If they wanted Carbonara then they would have cooked the Carbonara, not the waterfall with a bunch of JIRA workflows and four-hour meetings layered on top. They just did what they would have done anyway while attempting to sound fancy via obfuscation.
It's not just Agile but the same applies to DevOps.
DevOps is a culture. It can also be the specific subset of highly skilled individuals who were part of or an outcome of said cultures cross pollination. Today DevOps most often means fairly unskilled person hitting pipelines with hammer.
In the end, the same old people with the same old commercial interests adopted the term in a way that benefited them but changed the meaning of the term because change was not actually something anyone wanted.
That's not actually true. To give a silly example: does anyone (seriously) claim that 'true fascism' has never been tried?
Or: liberal democracy (I'm sure you can find a synonym that ends in *-ism) has been tried. It's been doing ok-ish. Obviously it has warts and all. But more importantly: approximately no one ever seriously claims that 'real liberal democracy' hasn't been tried.
Similar for constitutional monarchy, or 'social market economy', or dictatorships, etc. People can mostly agree that the real deal has been tried.
Any principle or practice falls apart when tied to an economy. See also: religion, politics, society at large. I don't foresee that changing in our lifetimes, so make money doing it the wrong way, and do it the right way in your free time.
I don’t agree with that though, plenty of places practice agile well. Maybe big corporations don’t practice it well, but startups often do agile correctly and understand the philosophy.
Inasmuch as Agile was adopted at companies, it's because it was sold to them as a way to provide greater transparency, accountability, and control into a chaotic software development process. The vice president behind the company's "Agile Transformation" probably can't even name point one of the manifesto; "we're doing Scrum with JIRA, therefore we're agile" is the extent of his concern.
You say that, but it was way more stressful pre agile with the fixed date, fuck around for a few months planning, then dev, run out of time then death march to finish, etc.
A lot of young guys like that D-Day style work, then goof off for a while, but not me. Continuous sustainable work is much preferred.
There's a difference between "bad PMs using the tool wrong" and "ordinary, human PMs using the tool in the way that common business incentives would lead you to predict they'll use it".
If the tool is used wrong most of the time, it's at least partially to blame.
"If the tool is used wrong most of the time, it's at least partially to blame."
Only if there were other tools that didn't fall victim to the same business incentives, but they all do.
I've had PMs that find a balance with the business incentives and make it work. If you’re human and make the wrong choices, then most people, including me, will likely call you bad in that context. If they can't stand up to find balance with the business incentives, then they're a bad PM. That doesn't make them a bad person.
I have seen Scaled Agile Framework (SAFe) work in multiple real program teams. Doing it successfully requires total commitment at multiple levels and many organizations are culturally incapable of making the transitions.
To be clear I am not claiming that SAFe is necessarily the best possible methodology. There is certainly room for improvement. But empirically it can work in real life.
The organizations I've seen do SAFe at the top level "coincidentally" have so much in the way of resources that if they do software at the group level at all, they do it like a gentleman farms.
"I mean if something doesn't ever work in real life then its not good."
Are you talking about Agile, Waterfall, or project management in general?
I've seen Agile work just fine. I've also seen it fail miserably. I've seen both of these at the same company with the main difference being how aggressive/delusional the leadership is. The easy test is if your leadership is legitimately ok with your team going home early if you complete your sprint commitment early, and it actually happens on occasion.
It feels like over the past decade or two, every company that builds software has gradually adopted the same terrible practices as is commonly found in game development studios.
That is why more advanced agile methodologies such as SAFe use the neutral term "iteration" rather than "sprint". It doesn't imply anything about team velocity or individual workload.
The term "iteration" was in common use by many of the big 90s proto-agile methodologies (think RUP et al). And XP - which I guess is what most people would regard as the first "true" form of agile - used it too.
SAFe is just an attempt to mush something that like looks like agile to delivery teams together with something that fits into more traditional program management, governance, and strategic direction lifecycle models.
There's no particular magic to it, and it's probably better to think of it in terms of being an "enterprise variant of agile" rather than a "humane variant of agile".
Yes, that's accurate. In the real world sometimes software programs have to make compromises in order to align with actual business needs. Like if you're going to be manufacturing hardware to go with the software or scheduling training for users then you have to apply strict program management discipline to ensure everything comes together at the correct time.
Sure, that's fair. In the real world there are a lot of developers who want to be told what to do, or need to be told what to do because they lack business domain knowledge. A defined methodology like SAFe allows large enterprises to move forward at a steady pace and get some productive work out of those people.
The reality is that in some domains there just aren't many developers who are highly motivated, self directed, and thoroughly understand customer needs. Those people just aren't widely available in the labor market regardless of wages or working conditions. So if management doesn't impose a fairly strict methodology then then the program will collapse.
I'd make a separate case that learned helplessness is a reversible thing, and more highly motivated and self directed devs can be grown.
But leadership has to incentivize not just being a ticket monkey, and needs to mindfully empower people. You can't just flip a switch in a feature factory and say "fly my pretties, be free!"
Sure, that's also fair. But it takes a long time to turn culture around. And in the meantime the company has to continue shipping releases to customers or else they run out of cash and everyone gets laid off.
In my experience of it though (only two workplaces, but not one) it's used for higher level planning, rather than being a 'more advanced agile'. I.e. a SAFe iteration spans some number of sprints greater than one. What are we going to deliver this quarter versus how are we going to break down and monitor progress of the quarter's deliverables week by week. (Don't read that like I like it.)
I think you're confused about the terminology. SAFe doesn't have sprints. Depending on the program planning horizon, several iterations can be grouped together into a larger program increment which typically lasts about a quarter.
Why is anything supposed to be sustainable for a ~50-year career? That’s a long time! Things change and people change.
It’s not like my great grandparents had a passion for farming in South Dakota and that’s why they did it until they dropped dead. It’s all they knew and what they did to survive.
If you gave them the option to tap on a keyboard in an air-conditioned room for 10 or 20 of those years they would’ve taken it.
Agile (or rather modern management) converts human capital into capital as fast as possible. Considering the endless supply of developers and lack of accountability there is no downsides to doing that, you are an externality.
Reminds me of this Indian boss I had whose only agenda used to be calling me up and telling me that others had complaints about my work. After 2 years of listening to his stories, I had to tell him off one morning. I quit about 4 months later. The guy was a completely talentless aggregator. I don't get how some Indian firms promote people and this wasn't a small firm either. He ended up being promoted upwards.
> For me, I usually try to avoid anything where the working practices are strongly defined.
I'm grateful I've managed to avoid this so far. My favorite place to work has been more akin to "we need X done in Y system before Z date, but how and when it's done is up to you".
The worst part is how these people almost always work on the most boring, rote crap. They could be selling mens hair loss medication on the internet (cough) and key individuals in the organization are convinced what they do is life-and-death, future of humanity, work nights and weekends, we're the next Google. It's so deeply cringe-worthy. Meanwhile, I know a ton of people in the traditional pharma industry (e.g. not Novo, but Novo-adjacent); those companies broadly treat their employees pretty well, very minor amounts of overwork, they're well-staffed, some still have pensions, people spend their whole working lives there.
Tech sucks. It's filled with talentless hacks who think "because we use computers" means you've got a blank check to make every individual do the work of three individuals. And then your company gets gutted by private equity anyway, because it turns out hiring talentless hacks and overworking has consequences.
This is a weird take, but I genuinely and deeply believe the world would be a far better place if everyone experienced a life-threatening but recoverable major medical event and/or had children, while young. Perspective-shifting events that are core to the human condition and help ground your reality in work not being everything. By the way: The businesses our society would build would also be stronger.
Ordering System is a good example because you typically want both. Your base logic will probably exist in OLTP with joins and normalised data, and you'll generally have local on-device OLTP databases.
Reporting on your Ordering System is an OLAP problem though. Generally an OLAP database stores data on disk in a way that it only needs to read the selected columns and the performance is better with wider columns, i.e. lots of duplicated data ( JOINs are slow ).
So like, you select * from Customer, Order, Items, Device, Staff, stick it in your OLAP database that's where customers should generate reports. This both makes reporting more performant, but it also removes the problem from the critical path of your POS device syncing and working.
This has the added benefit that updating your product name won't update the historical log of what was done at the time, because what was done at the time was done at the time ( but you can still map on like productId if you think the data is relevant. )
At scale you want to pop the writes on a queue and design those devices to be as async as possible.
This is what happens when you just build it pure OLTP.
This was an ~£19m ARR POS company dying because of architecture, now doing £150m+ ARR. ( the GTV of the workloads are multiple times that, but I can't remember them ).
> Reporting on your Ordering System is an OLAP problem though. Generally an OLAP database stores data on disk in a way that it only needs to read the selected columns and the performance is better with wider columns, i.e. lots of duplicated data ( JOINs are slow ).
This sounds like the one big table approach. Which in my experience is very difficult to do right and only makes sense in the data mart sense.
Google’s Adsense data model I’m BigQuery is like this and works well but gets so wide it’s difficult. Then again when you imbed things like arrays and structs and can unnest as needed avoiding joins can be nice.
I’ve found star schemas to work out just fine in data marts. Just do them properly. Join as needed. And a good engine will handle the rest. We’ve has no issues with a similar model in Snowflake for example. Of course YMMV.
Right, you want both, which is why databases like Oracle can store data in both forms. You can enable columnar formats on tables for both on disk and in-memory modes, where those columns can then be processed at high speed with lots of SIMD operations, but the data is kept consistent between them.
FWIW SQLserver can do the same with its column store tables. Idk though. I stopped using such when I moved to data Eng and we just use open things (clickhouse, DuckDB, etc) except for snowflake.
A platform for digital asset management, review and workflow. Current features focus primarily on review of images aimed at automotive configurators.
The problem is generic, however, our USP is we have a couple of enterprise customers that upload packs of 60k+ assets for a round, and thus we aim to help discover what demonstrably changed.
A bit like Github, only working with images, videos, and other digital assets rather than text files.