HN user

ukoki

1,198 karma

Software developer currently working in London.

Posts7
Comments339
View on HN

This reminds me of my experience as a senior contractor joining teams that seem to enjoy endless discussion. For example, when implementing a new feature using an open-source library or framework they will want to make a prototype of all possible libraries, make a report about each of them, have some big discussions about which to choose, and only _then_ start the real implementation. My advice is always to just pick the one your gut tells you is the right one -- if the prototype works, then that _is_ the implementation and we can stop considering alternatives unless we have a good reason to reconsider them.

If a decision is hard to make, its often because the differences are small, and therefore it doesn't matter much and you might as well decide by dice-roll.

lack of automated testing and TDD

Rust has testing in the standard library -- IMHO Bevy is far easier to test than most game engines because it's "just rust". You can test game logic by starting headless apps, proding the ECS, and making assertions on the results.

For acceptance tests I've dusted off cucumber (after ten years of not thinking about BDD), as I it works great with Bevy

If you get paid by the government to do research you should make all your raw data, code, results etc, accessible to the public.

If it then turns out any of it is fabricated, you should be personally liable for paying it back

Not OP but I'm currently make a city-builder computer game with a large procedurally-generated world. The terrain height at any point in the world is defined by function that takes a small number of constant parameters, and the horizontal position in the world, to give the height of the terrain at that position.

I need the heights on the GPU so I can modify the terrain meshes to fit the terrain. I need the heights on the CPU so I can know when the player is clicking the terrain and where to place things.

Rather than generating a heightmap on the CPU and passing a large heightmap texture to the GPU I have implemented the identical height generating functions in rust (CPU) and webgl (GPU). As you might imagine, its very easy for these to diverge and so I have to maintain a large set of tests that verify that generated heights are identical between implementations.

Being able to write this implementation once and run it on the CPU and GPU would give me much better guarantees that the results will be the same. (although necause of architecture differences and floating point handling they the results will never be perfect, but I just need them to be within an acceptable tolerance)

A $1k AWS mistake 8 months ago

I don't think its about profits, its about incentivising using as many AWS products as possible. Consider it an 'anti-lock-in fee'

If anything they're a hindrance.

Absolutely. As a brit used to waiters and waitresses in the UK and Europe generally leaving me alone until I ask for something, I find the constant fawning interruptions from American service staff cringe-inducing.

A refreshing aspect of US culture is the lack of a historical class system and associated cultural baggage that we have in the UK. So I find it so strange that once you step into a restaurant you are forced into this weird servant/master cosplay where you dictate the server's livelihood based on how you happen to be feeling that day and the resulting whim of your pen writing on the tip line.

was clocked to be offset after 5.3 months of running the turbine

.. if the power would have otherwise been generated using non-renewable sources.

But even when (if?) electricity generation is switched to 100% renewable, we will _still_ need to reduce carbon emissions to reduce climate change, so reducing carbon emissions invovled in the creation and maintanence of renewable electricity seems like a good idea to me.

Your contract is legal and enforceable. The parent commenter is just saying that there's no _automatic_ right to work you do in your free time (ie it has to be specifically mentioned in the contract). You could try and negotiate that clause out of your contract though.

The Barbican 1 year ago

Michael Fassbender's character has an apartment there in The Agency as well

Two additions:

* Teams wanting to be a viewer for all kinds of filetypes. Why the hell would I want to view a Powerpoint presentation in Teams? What if I want to chat about the presentation, while viewing the presentation?

* Clipboard injection attacks. Who in the history of the humanity ever thought prefixing "[2:10 PM] Kimble, Richard:" into the URL/API key/thing-you-want-to-copy a colleague just sent you was a good idea? Yes I know you can manually highlight the text and copy, but you're forcing me to do intricate mouse movements that take time, dozens of times a day. I just want to triple-click, cmd+c, alt+tab, cmd+p

It doesn't matter if it rots, burns etc -- all that matters is that it rots slower than the time it took to grow the wood it was made of

Eg:

You have a forest of trees that take 20 years to mature

You cut the trees and regrow the forest every 20 years

You use the timber to build houses (or furniture or whatever) that are _on average_ replaced after 60 years.

This will pull 3x the carbon from the atmosphere than just the forest by itself

Pretty sure that I’m really the only person that cares about it.

Even if you don't get any useful organic traffic, I find having a technical blog is useful so that when you do go to interviews or submit resumes, hirers can read your blog and quickly establish that you know what you are talking about.

Senior platform engineer contractor with 10+ years experience working for large enterprises building and operating container-based internal platforms-as-a-service.

Location: London, UK

Remote: Yes or on-site in London

Willing to relocate: no

Technologies: Kubernetes, Go, Ruby, Python, Rust, Bash, most platform engineering / devops / SRE / IaC tools and best practices, most public clouds.

Resume / CV: https://www.linkedin.com/in/peterellisjones

Email: pete@peterellisjones.com

Don't Be Frupid 1 year ago

Why do enterprises give developers shitty laptops? Why does it take a month to onbaord a new dev? Why does it take weeks to get a new dev tool installed that requires admin access? To get a firewall request reviewed? To get your team access to a fresh public cloud account for a new project?

The answer to all these questions is that things that are measurable will always be prioritised over things that are not easily measured. And the more mature the enterprise, the more the measurable has been squeezed to the detriment of the immeasurable.

IT hardware spend it very easily measured, but the time wasted and morale hit you get working on a shitty laptop is very hard to measure.

Anything that is measurable, you just turn a knob and announce 10% savings: well done you! enjoy your promotion -- the intangible negative externalities of your recklessness will rarely be considered or even known by the person whose job it is to review your performance.

I’ve heard multiple times from execs in my company that “software” will have less value and that, in a few years, there won’t be as many developer jobs.

If LLMs make average devs 10x more productive, Jevon's Paradox[1] suggests we'll just make 10x more software rather than have 10x fewer devs. You can now implement that feature only one customer cares about, or test 10x more prototypes before building your product. And if you instead decide to decimate your engineering team, watch out because your competitors might not.

https://en.wikipedia.org/wiki/Jevons_paradox

When building a spaced repetition toy, the most satisfying algorithm I found was:

* Model the forgetting curve as p = 2 ^ (−∆/h) (p = probability of recall, ∆ = time since last review, h = forgetting half-life for a particular card and user) (see https://research.duolingo.com/papers/settles.acl16.pdf)

* Numerically fit this curve to the last ~10 recent reviews of the card by the user to give an estimate for h (the half-life but effectively the intrinsic "difficulty" of the card for that user)

* Schedule the next review of the card at the time when a particular recall probability is reached. This probability should be configurable by the user: >90% for an "easy" session, <70% for a "hard" session.

* Use the "due date" to queue up cards for review. If a user reviews a card _before_ the due date, ensure that the half-life is never reduced after a succesful review. Provide some feedback to the user to suggest they stop the session when there are no pending cards left ("10 more cards due today, 100 cards due tomorrow, 1000 cards due next week")

* Don't schedule the same card twice in a row as this is annoying for the user. If it has just been reviewed and is due next, move it back to second place in the queue.

I found this works well once there are 2 or more reviews of a particular card for a particular user. For scheduling the _second_ review of the card I had to invent a heuristic like: if first review failed, schedule again in 1 minute, if first review passed schedule again tomorrow. However in apps where many users are reviewing the same cards, you could probably build a good model of the difficulty of a card for a user before 2 reviews by considering the performance of other users on that card.