35 karma · joined July 31, 2016
> Do you keep improving them over time?
In my global AGENTS.md I have a note to agents to explain any frustrations they had doing a task, and to suggest any skill/tool/AGENTS.md improvements. I am trying to keep AGENTS.md files small but still finding the balance.
{
"servers": {
"context7": {
"command": "npx",
"args": [
"-y",
"@upstash/context7-mcp"
],
"type": "stdio"
},
"fetch": {
"command": "uvx",
"args": [
"mcp-server-fetch"
],
"type": "stdio"
},
"git": {
"command": "uvx",
"args": [
"mcp-server-git"
],
"type": "stdio"
},
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
],
"type": "stdio"
},
"brave-search": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-brave-search"
],
"env": {
"BRAVE_API_KEY": "${input:brave-api-key}"
},
"type": "stdio"
}
},
"inputs": [
{
"type": "promptString",
"id": "brave-api-key",
"description": "Brave Data for AI API Key",
"password": true
}
]
}
I found o1-pro unbelievably good for coding, but when o3-pro was released, I saw the response length in ChatGPT was gimped severely compared to o1-pro, so didn't find it all that useful - it couldn't output long enough responses. I actually cancelled my ChatGPT subscription as it seemed like such a downgrade, though I'll probably try using again via OpenAI's API at some point, so long as the response length isn't capped. I'm tempted to try out Grok 4 Heavy.
Refactoring duplicate code into a helper function should be achievable with current agents. To replace existing code with an external crate , you could try giving the agent access to a browser (e.g. playwright-mcp), and instructing it to browse the crate docs. For anything that involves using APIs that may be past the knowledge cutoff for the agent's model, it's definitely worthwhile to have some MCP tools on hand that'll let it browse for up-to-date info - the brave-search and context7 MCPs are good.
It's good to consider the financial impact seriously in balance with everything else - not only the income you won't earn, but also how that would have compounded across your lifetime.
To address your point about recruiter emails, I still get them. So long as you can provide value to a business at the end of your break it's not necessarily an issue, though you might have to work harder to demonstrate that - I think especially for the soft skills you'd otherwise be using day-to-day in a workplace as opposed to when you're just doing your own thing.
Remote: yes (can work hybrid or full time on-site if there is an office in London)
Willing to relocate: no
Technologies: Rust, Go, Kubernetes, AWS, Terraform, Python, React, Java
Résumé/CV: https://www.linkedin.com/in/jameshiew/
Email: james@hiew.net
GitHub: https://github.com/jameshiew
Website: https://james.hiew.net
---
5+ years software development experience, mostly working on backend systems at fintechs. Seeking an IC role using the Rust programming language (and other tech as well!)
My previous experience ranges from working in cross-functional teams at larger corps, to being the sole fullstack developer for a startup. Some of the more interesting things I've worked on: an event-driven scheduling service (think dkron), core protocol logic for a blockchain validator in Rust, and complex SQL models for financial pipelines.
Let's talk if I sound like a fit for your engineering team or project: james@hiew.net
Another one is using Heroku (~$7pcm) over Vercel (~$20pcm) for deploying a simple website/CMS for a business (and therefore not eligible for Vercel's free hobby tier). I initially wanted to use Vercel but Heroku is actually fantastic if you're developing solo and don't need all the bells and whistles Vercel provides.
Of course, there are exceptions to this. I'm also explicitly excluding here employers who outsource the technical challenge to a third party like leetcode.
[1]: https://www.parc.com/blog/half-human-half-computer-meet-the-...
The first runtime I tried was Corretto 17 which crashed on me, and I had to delete some `idea.jdk` file somewhere or other to get IntelliJ to start up again. That file seems to contain which JVM to use when starting IntelliJ, I use Toolbox as well (on Ubuntu).
[1]: https://www.jetbrains.com/help/idea/switching-boot-jdk.html
# Writing a good docstring
This is an example of writing a really good docstring that follows a best practice for the given language. Attention is paid to detailing things like
* parameter and return types (if applicable)
* any errors that might be raised or returned, depending on the language
I received the following code:
```{{{language}}}
{{{snippet}}}
```
The code with a really good docstring added is below:
```{{{language}}}
It's also decent at doing tasks that would be easy for a beginner programmer but perhaps tedious. Like you can give it a function for generating random colors and a task like "expand the variable names in this function to be better", and it will change variable names like `r`, `g` and `b` to `red`, `green` and `blue`. Hardly amazing, and the latency of the API means it's not actually that useful in practice (yet), but with the right prompt it can do some impressive things, and I expect it to get much better in the near future. Pulling magic strings out of functions into constants and adding typehints to Python functions are other simple tasks I've found it OK for.
Currently it only works with OpenAI so you'd need an API key to use it, but the plugin is (over)engineered so that adding a backend for something more open like GPT-Neo should be doable. OpenAI Codex is used by default but other OpenAI engines can be used as well.
It's also worth getting familiar with terminology early on, because common terms in the context of graphics programming have different meanings to their common usage. e.g. I've found it helpful to think of a "vertex" first and foremost as an element of an array, which is processed SIMD-style by the "vertex shader". In most cases it is the co-ordinates of a polygon vertex, but usually with other data bundled in the element as well such as texture co-ordinates. The term "shader" seems to be used for any program that runs on the GPU, regardless of whether it does shading of any kind.
The biggest thing I am missing right now from Go is the fast compile times, something I rarely had to think about before. In some of the small Rust projects I’ve tried out, compilation takes minutes on a clean run or after having updated dependencies. When you’re checking out a lot of different Github projects, or experimenting with different crates, it really adds up.
I’ve tried out Rust’s equivalent of channels (the `std::sync::mpsc` module - https://doc.rust-lang.org/std/sync/mpsc/) and it feels clunky by comparison to Go. Spawning threads in Rust via a `thread::spawn()` call feels archaic compared to `go func` (putting aside that threads aren’t exactly equivalent to goroutines, you might generally use them in the same way). I’d actually hope Rust could introduce first class language constructs for concurrency like Go has, at some point.
There are some other Go things like implicit interfaces I am learning to get used to without, but I am really liking Rust’s concept of ownership and having proper enum types/pattern matching is a breath of fresh air. I probably appreciate Go more now for what it is - a straightforward, performant language with very good devex.
I've only done the Python one myself but it did seem to ask questions on some fairly esoteric stuff, from what I vaguely remember.
On the topic of speeding up terminal startup, I can recommend https://github.com/benvan/sandboxd for managing various shell initialization scripts to only be run or sourced at the point where they are needed.