This is seriously impressive. I asked it to create 3 different databases:
- a customer orders database with products with a timeseries of prices, and multiple fulfilments per order.
- an issue tracking system with a reflexive user/manager database
- a family relationship model
In each case I got it to put in sample model and then asked postgres.new to answer some questions about the data it had inserted. I thought the family model would trip it up, especially when I told it to put in cousins and uncles. But no, it was pretty bang on.
The only thing it didn't quite manage is that some of the relationships are reciprocal (i.e. my sibling also has me as a sibling).
I asked postgres.new to review the data and it fixed some, and i asked it to check again and it fixed the rest. This is a very useful tool that I can see myself using!
I'm genuinely baffled by this, why are the tax filing options in the US so fragmented? Here in the UK there are probably some situations in which you can't use the online, government provided, free service. But I'm going to stick my neck out and say they're fairly niche.
Having lived in the US I know things get complex when you start mixing in state taxes, but this is federal taxes right? Or wrong?
The answer is a bit complicated, but there are two major parts to it:
1) The tax filing prep companies spend ridiculous amounts lobbying to ensure both that the tax system remains complex, and that they are the only way to deal with that complexity. Fortunately, the effectiveness of this has been gradually waning, leading to things like the new service the article describes.
2) Taxes in the US are genuinely quite complicated, for some good reasons, many bad ones (including the aforementioned lobbying), and even more neutral-but-complicated ones. Both major political parties have a tendency to add extra complexity to the tax code for their own ideological (and often purely political) reasons.
(But despite what many people like to propose in response to this, a flat tax wouldn't actually make things better, because progressive taxation is very important for mitigating the staggering inequality in our current system, and is not even the primary cause of the complexity. The primary cause is the difficulty of agreeing on exactly what constitutes "income", combined with many often-conflicting attempts to incentivize or disincentivize various things through the tax code.)
Taxes are genuinely quite complicated in many countries (Germany's patchwork of feudal church obligations, diffuse taxing authority spread over multiple layers of government, and "temporary" taxes lasting over a century has some fun surprises, e.g.), and almost nobody ever voluntarily reduces the tax code's complexity.
What really sets the US apart is 1, very few other countries manage to witness so much criminal energy getting put into legislation without simply collapsing.
Federal taxes tend to be even harder than state taxes. There's usually more that goes into whether or not you qualify for exemptions and what sort of deductible you should take.
But the reason it's a mess is really really simple, lobbying. Tax prep companies have lobbied against a government solution for a long time now. Requiring everyone to spend $100, $200, or more per year is their subscription model and they like it that way.
Federal Taxes tend to be easier than state taxes. First of all, there is no nonsense of partial residencies to consider, which gets even more messy when you and your spouse have spent time in two different states.
Additionally some states (I am looking at you CA and NY) are absolutely rabid when it comes to coming after you for what they deem is their share. They will keep hounding you for years after you have moved away from the state. NY in particular enforces a withholding on additional income that's more than the maximum state tax rate, which effectively means that they get millions of dollars of interest-free loans from their taxpayers.
Plus community property laws make calculations even more messy.
I think it's a result of legacy stuff (i.e. "it's worked like this forever, why change?") and a historical and cultural distrust of the government which is far more pronounced and has had a much larger impact on how people interact with the government than in other countries. People in America tend to distrust the government by default in a way that can be baffling to people from other countries. They want to do a lot of stuff themselves.
Also, for-profit tax filers have aggressively lobbied to combat simplifying the process for decades.
Germany is a federation and US tax filing is still a mess in comparison.
As often with US oddities, the explanation boils down to "the US is big enough to make corruption really attractive and wealthy enough to be able to just ignore it".
You'll be pleased to learn that most (if not all) Cantons (= states) in Switzerland, a federalist state, have a free online tax filing solution, that computes both communal, cantonal, and federal taxes.
The US is very diffuse in taxing power. The federal government only has the power to implement procedures related to federal taxes.
But the state/county/city and even other amalgamations of governments such as “metropolitan”, “transit”, or other special case governments have the ability to tax and their own jurisdiction for implementing how to collect it.
In my opinion, the complexity is at a point that it is a drag on national productivity. And on top of that, it enables lots of corruption where anyone can simply claim plausible deniability and pay a small fine well worth the low probability of being punished.
There are slightly different issues here: fragmentation and cost. You could have a mix of non-free and unified, or free and fragmented etc.
It's fragmented because states here in US have their own laws, taxes, etc. So do local municipalities. Some cities collect some types of taxes, some others and so on. When it comes to stuff like taxes it may be easier to think of US as the EU.
Non-free is because of lobbying by various tax prep companies. It's a large business and here in US there is thing about not wanting the US government to compete with companies. So all these parasites popped up and now are saying "you can't compete with us, it will destroy us!". They always say something how anyone can get paper forms and mail stuff in, so all the electronic stuff is not needed and is just a convenience.
You can take a step back to explain this in the "bigger picture" sense.
The US is a for profit country. Virtually everything is done with the intent of making profit, rather than to benefit citizens. This is different than other developed countries, and the reason the US is so rich.
Prisons exist to make money, not to rehab (or punish) inmates.
Higher education exists to make money, not to educate.
"Healthcare" exists to make money, not to heal people.
(The list goes on and on).
Companies spend hundreds of millions of dollars lobbying the government (money is speech, after all) to keep it this way.
So when it comes to filing taxes, the goal is to make money, not to provide a service to citizens that is convenient, easy, free, etc.
Anytime you see something weirdly punitive or backwards US citizens are dealing with, its because the incentives are structured to favor this outcome. In this case we have a multi billion dollar tax filing industry that is fighting tooth and nail to keep its cash cow around through lobbying (read: legalized bribery).
>> And then there's the competition - I early discovered that I could never outperform my competition.
100% this. I'm a bit competitive, but only a bit :). After 20 years of being a dev I realised I didn't want to compete anymore and shortly after that I quit as a dev.
I've now switched more into an analyst role and because I've been a dev i think I know what makes a good analyst because I know what I would have to know to write the code - if it were me. But here's the best part, the mark of a good developer is their attention to detail. And attention to detail is also the mark of a good analyst, but as an analyst you don't have to sacrifice yourself to the detail of tool-chains, stacks and frameworks.
Working on large scale problems as a dev, and doing it right, is slow (with a small number of devs) and chaotic with a large number. But as an analyst I can work at the speed of thought, work on many projects simultaneously, and see the fruits of my ideas take shape as the devs start to deliver them and I shepherd them into existence.
So for now I'm pretty happy, I write code in my spare time for fun and like the OP - I'm back where I need to be.
Typically interface with customers/users/stakeholders, identify and document requirements, and...well, beyond that it varies a lot in different orgs, if its not actually coding, and its involved with the process of developing/maintaining software, there's some organization where someone titled as an "analyst" (usually with a prefix like "business", "system", or something) does it,
In most industries, software analysts are a thing of the past. Scrum has largely replaced them, and project managers, with product owners - the people who have to do both of these jobs for a price of one.
I have a sort of off-topic question. The marketing for this claims not using STL containers as a selling point. Does anyone know what makes STL containers unsuitable for this use case? Clearly they're not a one size fits all but I'm intrigued to know why you market an unknown container based API over a tried and tested one?
The biggest reason for me was to reduce compile times, which got cut into approximately half when I replaced STL containers with simpler custom ones. This starts adding up in large projects, where lots of files end up including the ECS.
This is a good point. If the users know the difference the costs and benefits between using GPT and not using it then it certainly has value if those users are also willing to accept that not every answer needs to be 100% accurate.
In my experience business people often have a 'nose' for the right number and will bluff it out if the numbers are wrong and they're challenged.
Blue sky things or stuff you're putting in the annual report should be left to hoomans IMHO.
This was my take too. The break-down in communication might not be WHAT is being said but HOW it's being said. This is certainly my experience of being a dev and a manager, sometimes people just seem a bit rude and it's hard to get past.
Is the rudeness excusable? I guess. Especially if I understand where it's coming from. Otherwise it's just rudeness.
And I guess that the point of the article, but you need to get to know people before you can make the judgement of why someone is how they are. That takes time.
This reminds me of a time, many years ago now, another engineer and myself ended up in a debate with one of the executives. We seemed to be in a very strong disagreement with them. After well over an hour of getting nowhere we ended up going back and essentially starting over breaking everything down into little pieces and ensuring our definitions of everything lined up. Turns out we agreed the whole time, but how each side was saying it made us think we did not. I believe it provided me a valuable lesson in this but it was so frustrating at the time and that certainly didn't help the cause. Sometimes I have to remember back to it and to take that step back take a breath and reframe things. How things are being said can really affect the conversation.
Yes, it’s a hard skill to learn, and … it’s why I ask so many questions / make sure we have the same context.
Very often in software engineering, people use abstract words that have been overloaded with meanings in many different ways, and it can be easy to think the other person is suggesting something completely different. I love using diagrams because they remove a lot of the “words”.
Interesting. For two reasons. In the many years that I developed software this was known as the producer/consumer problem [1]. A name that is somewhat (to me) more expressive than back-pressure. But that's just my opinion!
What's different now, as the article points out, is the growth of micro-service architectures. Effectively creating a lot of tiny producer/consumer problems across the solution space.
Sometimes, I'm glad I don't write code anymore, but only sometimes :-)
Yeah, when I was in school it was called "producer/consumer problem" too, back pressure was considered one of the solutions to the problem(what he calls control). I guess someone somewhere confused the two, and it kinda stuck.
Yeah right. This seems like fancy talk for the same scaling problems we've had forever. And it was 100X worse before cloud computing. System-to-system scale problems are generally a lot easier to deal with because you always have the option of resetting expectations with users. Serving web requests has to be real-time, but if a data pipeline has to be overnight due to cost constraints, you can just make the argument to management and do it.
This is a great question! When I was a developer I used to develop software the way you were told not to. I did it that way because the requirements were always very vague and a lot of gaps needed to be filled. But when I was a project manager I thought that way of development is wasteful and would rather developers didn't do what I did.
So I suppose the real answer depends on the environment you're in. If the project is meant to be agile then you probably need a bit of interaction with the user to get the job done. If the project is not agile and all the requirements could be known up-front then you're probably wasting effort having programmers determine what those requirements are. IMHO.
Absolutely. Picasso's journey was to transition from stunning realism to a child-like surrealism in later years. In some respects he was trying to unlearn form but keep the aesthetic.
And to be honest some of these MOBA pictures do that too, they're actually not bad at all. It's just perhaps not intentional, but does that matter?
My first experience of Tcl/Tk was circa 2000. The finance house I worked at had used it to implement a real-time order management system.
Even better was the ability to attach to the running ui or server (yes we had both), replace some of the code on-the-fly, and disconnect. Perhaps not so amazing these days, but it was way ahead of anything else I'd seen upto that point and pretty mind-bending for a C/C++ coder.
- a customer orders database with products with a timeseries of prices, and multiple fulfilments per order. - an issue tracking system with a reflexive user/manager database - a family relationship model
In each case I got it to put in sample model and then asked postgres.new to answer some questions about the data it had inserted. I thought the family model would trip it up, especially when I told it to put in cousins and uncles. But no, it was pretty bang on.
The only thing it didn't quite manage is that some of the relationships are reciprocal (i.e. my sibling also has me as a sibling).
I asked postgres.new to review the data and it fixed some, and i asked it to check again and it fixed the rest. This is a very useful tool that I can see myself using!