On your side-project it's also ok to ignore best engineering practice, reinvent the wheel because you feel like it or make decisions based on what seems most interesting even if it's not a 'good' decision.
The critical thing is what the author says:
> always make sure that you're doing them for yourself, and for the right reasons
For me my side projects are generally something to have fun with and something to learn new things with. When you're finding it a slog or you feel like you've learnt what what you need to it's fine to just dump it.
Actually finishing something is of course nice and for beginners in particular there's a lot of value in going from that it's mostly there just some loose ends to tie off stage to the actually done stage but you don't have to always do this (or indeed just do it in some select cases).
> On your side-project it's also ok to ignore best engineering practice, reinvent the wheel because you feel like it or make decisions based on what seems most interesting even if it's not a 'good' decision.
Pro tip for enjoying your life at work: this also applies to you work projects. Once you realize this, you can have a lot more fun at work and even coerce work projects to be more like your for-fun/side projects. Of course this is detrimental to the company as a whole, but your company almost definitely does not care about you and you might as well extract as much enjoyment as possible.
If your coworkers are actually passionate about programming (i.e. not drones or PM brains running flowchart to increase quarterly profit), you can even make work more enjoyable for them.
Things like unconventional language choices, over-engineering of systems, unusual coding styles, obscure protocol/library use, and of course a ton of NIH can really spice up a mundane codebase.
Even stretching an "easy" module into a masterfully crafted program and going 4x over estimation can be fun sometimes (without any of the bad design choices suggested above).
Yes I stand by this bad advice, and it's allowed me to play with so much technology I would never otherwise touch at day job.
On the contrary, my side projects tend to have the most strictest linter, test and CI suites. Why? You may ask.
I'll tell you. I forget stuff.
So when I pick up that Openweather tool after three years of not touching it to quickly change the output a bit, I can be pretty sure the overly robust scaffolding around the project won't let me break anything.
That's the beauty of side projects, you get to decide and you don't have to care about working with others.
Really yearning for crafted code that meets every one of your perfect coding style guide and preference with green checks across a huge set of static analysis tools and a large test suite, go for it!
Tired of conforming to your ultra strict style guide at work and code reviews that go in endless circles nit picking about use of spacing or whatever? Let loose and stop having to care/worry so much about the details.
That's an editorialized headline. What they actually wrote was that it could be used to "generate misleading news articles, impersonate others online, automate the production of abusive or faked content to post on social media, [or] automate the production of spam/phishing content" and that they are aware other researchers have the ability to reproduce and open source their results, but this would give the community some time to decide how to proceed.
A nice game, though the truth table lighting round is pretty punishing! Big contrast to the circuit building part where you can take your time. Personally I'd drop the time requirements from that quiz section.
Having spent several years working on OT I can tell you that most of the gaps are things that should be waived anyway. Getting waiver files reliably integrated into that flow has been problematic as those files are fragile, alter the RTL and they typically break as they refer to things by line number or expect a particular expression to be identical to when you did a waiver for it.
This has all been examined and the holes have been deemed unconcerning, yes ideally there'd be full waivers documenting this but as with any real life engineering project you can't do everything perfectly! There is internal documentation explaining the rationale for why the holes aren't a problem but it's not public.
> Getting waiver files reliably integrated into that flow has been problematic as those files are fragile, alter the RTL and they typically break as they refer to things by line number or expect a particular expression to be identical to when you did a waiver for it.
Yeah last time I did this we used regexes but I really don't like that solution. I think the waiver should go in the RTL itself. I don't know why nobody does that - it's standard practice in software. SV even supports attributes exactly for this sort of thing. The tools don't support it but you could make a tool to parse the files and convert it to TCL. I've done something like that using the Rust sv-parser crate before. Tedious but not impossible.
Also we found the formal waiver analysis tools to be very effective for waiving unreachable code, in case you aren't using those.
> Also we found the formal waiver analysis tools to be very effective for waiving unreachable code, in case you aren't using those.
Yes we had used them just never got it slickly integrated into the verification dashboard. We had used this kind of analysis for internal sign off. You could generate the waivers manually and check them in but that suffers from the problem discussed above. Plus as OpenTitan was a cross company project you run into EDA licensing issues where not everyone has access to the same set of tools and a UNR flow could be running fine on one partner's infrastructure but isn't workable everywhere for multitude of reasons.
The ideal would be the nightly regression would do the UNR flow to generate the waivers and apply them when generating coverage but as ever there's only so much engineering time to go around and always other priorities.
I worked on OpenTitan for around 5 years at lowRISC. It certainly has its ups and downs but it's generated some great stuff and I'm very glad to see hit proper volume production like this. Whilst there's definitely open source chips out there and lots more using bits of open source that don't actually advertise this fact I believe this is the first chip with completely open RTL that's in a major production volume use case.
One of highlights working on OpenTitan was the amount of interest we got from the academic community. Work they did could actually get factored into the first generation silicon making it stronger. Ordinarily chips like that are kept deeply under wraps and the first time the wider security community can take a look at them development has long completed so anything they might find could only effect generation 2 or 3 of the device.
Academic collaboration also helped get ahead in post quantum crypto. This first generation chip has limited capabilities there but thanks to multiple academics using the design as a base for their own PQC work there was lots to draw on for future designs.
I'm no longer at lowRISC so I don't know where OpenTitan is going next but I look forward to finding out.
This is an interesting piece of hardware though when they go multi-chip for larger models the speed will no doubt suffer.
They'll also be severely limited on context length as it needs to sit in SRAM. Looks like the current one tops out at 6144 tokens which I presume is a whole chips worth. You'd also have to dedicate a chip to a whole user as there's likely only enough SRAM for one user's worth of context. I wonder how much time it takes them to swap users in/out? I wouldn't be surprised if this chip is severely underutilized (can't use it all when running decode as you have to run token by token with one users and then idle time as you swap users in/out).
Maybe a more realistic deployment would have chips for linear layers and chips for attention? You could batch users through the shared weight chips and then provision more or less attention chips as you want which would be per user (or shared amongst a small group 2-4 users).
> If copying user tokens was the bottle neck, batching would not achieve any speed up.
Reality is more complex. As context length grows your KV cache becomes large and will begin to dominate your total FLOPs (and hence bytes loaded). The issue with KV cache is you cannot batch it because only one user can use it, unlike static layer weights where you can reuse them across multiple users.
Emerging sparse attention techniques can greatly relieve this issue though the extent to which frontier labs deploy them is uncertain. Deepseek v3.2 uses sparse attention though I don't know off hand how much this reduces KV cache FLOPs and associated memory bandwidth.
> The issue with KV cache is you cannot batch it because only one user can use it
This is not really correct given how input token caching works and the reality of subagent workloads. You could launch many parallel subagents sharing some portion of their input tokens and use batching for that task.
1. Parallel investigation : the payoff form that is relatively small - starting K subagents assumes you have K independent avenues of investigation - and quite often that is not true. Somewhat similar to next-turn prediction using a speculative model - works well enough for 1 or 2 turns, but fails after.
2. Input caching is pretty much fixes prefill - not decode. And if you look at frontier models - for example open-weight models that can do reasoning - you are looking at longer and longer reasoning chains for heavy tool-using models. And reasoning chains will diverge very vey quickly even from the same input assuming a non-0 temp.
Anyone else find reading things like this slightly exhausting?
I'm very much pro AI for coding there are clearly significant capabilities there but I'm still getting my head around how to best utilise it.
Posts like these make it sound like ruthlessly optimizing your workflow letting no possible efficiency go every single day is the only way to work now. This has always been possible and generally not a good idea to focus on exclusively. There's always been processes to optimise and automate and always a balance as to which to pursue.
Personally I am incorporating AI into my daily work but not getting too bogged down by it. I read about some of the latest ideas and techniques and choose carefully which I employ. Sometimes I'll try and AI workflow and then abandon it. I recently connected Claude up to draw.io with an MCP, it had some good capabilities but for the specific task I wanted it wasn't really getting it so doing it manually was the better choice to achieve what I wanted in good time.
The models themselves and coding harnesses are also evolving quickly complex workflows people may put together can quickly become pointless.
I know people like this, theres a form of procrastination where they are busy hyperoptimising their todo lists and workflows but getting only a tiny amount of actual work done. It's a form of the disconnected intellect - they can tell you the problem, they can even tell you the solution, but they can't turn that knowledge into action. Convincing themselves that utterly trivial inconveniences are so productivity and or psychologically harmful they can they can then rationalize all this "meta-work" while simultaneously claiming to be virtuous, when in reality it's usually insecurity in their abilities or cowardice to face the unknown, preventing them doing real work
I almost agree with you, but with regard to this specific blog I'm not sure I can.
From my perspective, all this energy spent on AI prompting is actually just planning meetings and whiteboarding in disguise, but since all that has the bad reputation of luring devs into power struggles and yak shaving this is the new way.
It's likely where most of their improved productivity is coming from. The people doing the meta-work just need be mature about it to avoid procrastinating.
Yeah, AI generated diagrams can be pretty hit or miss. The lack of good quality examples in training data and minimal documentation for these tools can make it difficult for models to even get basic syntax correct for more complex diagrams.
I’ve had a lot of success dogfooding my own product, the Mermaid Studio plugin for JetBrains IDEs (https://mermaidstudio.dev).
It combines the deep semantic code intelligence of an IDE with a suite of integrated MCP tools that your preferred agent can plug into for static analysis, up to date syntax, etc.
I basically tell Claude Code to run the generated diagram through the analysis tool, fix issues it detects and repeat until fixed. Then generate a png or svg for a visual inspection before finalizing the diagram.
Now all of my planning and architecture docs are filled with illustrative flowcharts, sequence diagrams, and occasionally block diagrams for workshopping proposed UI layouts
Only taken a quick skim but this looks like solid material!
RISC-V Vector is definitely tricky to get a handle on, especially if you just read the architecture documentation (which is to be expected really, good specification for an architecture isn't compatible with a useful beginners guide). I found I needed to look at some presentations given by various members of the vector working group to get a good grasp of the principles.
There's been precious little material beyond the specification and some now slightly old slide decks so this is a great contribution.
The specification for an architecture is meant to be useful to anyone writing assembly, not just to people implementing the spec. Case in point x86 manuals aren't meant for Intel, they're meant for Intel's customers.
There is a lot of cope re the fact RISC-V's spec is particularly hard to use for writing assembly or understanding the software model.
If the spec isn't a 'manual' then where's the manual? If there's just no manual then that's a deficiency. If we only have 'tutorial's that's bad as well, a manual is a good reference for an experienced user, and approachable to a slightly aware beginner (or a fresh beginner with experience in other arch's); a tutorial is too verbose to be useful as a regular reference.
Either the spec should have read (and still could read) more like a useful manual, or a useful manual needs to be provided.
The critical thing is what the author says:
> always make sure that you're doing them for yourself, and for the right reasons
For me my side projects are generally something to have fun with and something to learn new things with. When you're finding it a slog or you feel like you've learnt what what you need to it's fine to just dump it.
Actually finishing something is of course nice and for beginners in particular there's a lot of value in going from that it's mostly there just some loose ends to tie off stage to the actually done stage but you don't have to always do this (or indeed just do it in some select cases).
reply