Here is the response:

"Your primary weakness is a complete technical dependency, which forces you to rely on an external guide for every action. You cannot build, modify, or fix the code yourself, meaning any progress is entirely gated by the availability of that guide. This is compounded by an inability to perform basic diagnostics, turning every minor bug into a hard stop that you cannot investigate independently. Critically, these issues are magnified by fundamental errors in the basic mechanics of saving and managing your work, which has proven to be the most costly weakness, causing us to waste significant time on misdiagnosed problems that stemmed from simple process mistakes."

Ooof!

I can't wait until Gemini does my next performance review...

Comments URL: https://news.ycombinator.com/item?id=44871928

Points: 17

# Comments: 3

'I have a database table Foo, here is the DDL: , create CRUD end points at /v0/foo; and use the same coding conventions used for Bar.'

I find it copies existing code style pretty well.

Complex queries I write myself anyway, so Claude fills the 'ORM' gap for me, leaving an easily understood project.

I have aphantasia - I can't visualise/picture things in my mind, so I use pen and paper or whiteboards A LOT!

I create various ERDs, mind maps, sequence diagrams etc. I use a ReMarkable which makes it a bit easier to move stuff around and makes it more effective.

I get that some people might think it is 'pure romanticism', but pen and paper has been crucial for my success.

I've read that the 'surprise' factor is much reduced when you actually see just how much data these things are trained on - far more than a human mind can possibly hold and (almost) endlessly varied. I.e. there is 'probably' something in the training set close to what 'surprised' you.

Comments URL: https://news.ycombinator.com/item?id=43286658

Points: 11

# Comments: 1

Github copilot is so good at writing CRUD db queries that it feels as easy as an ORM, but without the baggage, complexity, and the n+1 performance issues.

The degree turned out to have a lot of transferable skills - especially in researching and solving problems.

Just 25 years later I am a Principal Engineer in the Oz Telco industry writing Rust!

I don't regret the degree for a moment - although when I went through the degree was free, even at a top tier Australian university.

I don't write 'clever' code, just sticking stuff into Postgres/PostGIS/Neo4J/Clickhouse, some basic business logic and math, returning JSON etc.

I have found Rust to be super-productive and a joy to use compared with Go. I don't use the complex parts of Rust; no messing with lifetimes, a little cloning and using Arc<> to share things across threads/tasks.

GitHub Copilot in Jetbrains RustRover is very effective at generating accurate Rust CRUD code, handler methods etc. I don't bother with an ORM because it is so fast to write the SQL queries. Having said that, Copilot sucks at anything even slightly complicated and you take a risk asking it to generate code you can't validate quickly.

The whole of Rust might be a beast, but I have had a very productive couple of years just using the 'boring' bits and it took a week or two for me to be more productive than in Go writing bog-standard web backend code.

For marketing purposes I generate viewsheds around each of our ~500 towers, so we can get an idea which suburbs to market to.

At the time of sale, my system will calculate the line of site from the access point on the tower to the customer rooftop to determine the height of the pole (is any) needed to get service.

Like the OP, we re-sampled (gdalwarp, raster2pgsql) some of the 15cm lidar data to ~1m to get it down to a manageable size (7TB) and run it on a single bare-metal PostgGIS instance (500GB ram, 64 cores)

Radio waves at 5GHz are quite 'fat' so we need to allow for that on LOS calculations as per [0].

The GIS magic mostly sits in PostGIS and we use a number of data sets to solve problems: * Shuttle Radar Topography Mission - Digital Elevation Model and Digital Surface Model, 30m grid [1] * Building footprints for all of Australia [2] * National Roads [3] * property boundaries (cadastre) [4] * All Australian addresses [5] * Australian suburbs [6]

For the front end we use a VueJS app (quasar.dev) using DeckGL on Google Maps to visualise the LOS path. Back end is Rust (axum/sqlx).

GIS is a very interesting are to work in - if I had more fun they might start charging me admission to come to work!

[0] https://s.campbellsci.com/documents/au/technical-papers/line... [1] https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/me... [2] https://github.com/microsoft/AustraliaBuildingFootprints [3] https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/me... [4] https://www.data.qld.gov.au/dataset/cadastral-data-queenslan... [5] https://www.industry.gov.au/publications/geocoded-national-a... [6] https://www.abs.gov.au/statistics/standards/australian-stati...

Apart from the mention of some no-code frameworks it is pretty much content-free.

In my opinion Rust is generally superior to Go for basic JSON web services communicating with the usual suspects; Postgres, RabbitMQ, etc. I'd say it is far superior to the JVM approach for a our problem space.

I found the JetBrains tooling for Rust to be equivalent to what is available for Go. Compile times are on the order of 10 seconds for a 'medium sized web' service but of course YMMV. This is slightly annoying, but comparable with large Java/Spring projects I've worked on.

I presented an example web service (Axum) that was very similar in architecture to the Go approach we had been using; router, handlers, middleware etc. Migrating from Go to Rust is not that bad at all. Rust has a great error handling story and better type system, so the code is much cleaner and easier to understand.

Using SQLX means that you get compile-time database schema checking, including understanding if a return field could be null and requiring that to be Option<>.

The compiler is picky, but I quickly came to appreciate that 'once it compiles, it will very likely just work'. It is like having a pair programmer helping out.

It took me about 2 months learning what were the appropriate crates to put together, but now I have paid that price, I am more productive in Rust than Go.

Rust uses less memory and is faster/safer than Go, so we can deploy more services on the same hardware, with less downtime, which saves $.

You won't find an army of Rust developers to hire, but you will find an army of people who want to learn/use Rust at $dayjob, and these people will tend to be motivated self-learners that you want to have on your team. Advertising a Rust role will make your business more attractive to better candidates in my experience.

I have been a developer for 20 years; mostly Java/Scala/Kotin, then Go. Now I have learned to use Rust there is no way I am going back to those languages!

[1]https://www.preposterousuniverse.com/podcast/2022/05/23/198-...