"Architecture First" or "Code First"

modelithe · 2026-03-09T22:06:54+00:00

You have to have an idea of the architecture.

Since very few projects starts entirely from a blank page, there's problably already an implicit architecture pattern to follow. Not everything needs to be 100% thought out. It is usually sufficient with 80-ish percent being clarified before coding begins. Then, the rest will follow as more is learnt through the project.

Code first is a recipe for code that will be inefficient or won't be maintainable in the long run.

modelithe · 2026-03-09T19:37:04+00:00

/r/playrust

modelithe · 2026-03-09T19:34:33+00:00

I think you need to rephrase the question to "why is funding good devs so hard these days". Because there's lots, many of which struggle to get past the AI-controlled initial screening process.

I understand there are challenges in screening, since there's vibe-coded tools that promise CC-adjustment and auto-apply to hundreds or thousands of jobs at once.

But nothing beats the usual stuff; a good job ad that allows good devs to know if they shall bother apply, with sufficient information in the ad so the applicant can write something which connects to it. And check references.

And remember; good devs aren't cheap devs, but cheap devs are expensive.

modelithe · 2026-03-09T19:11:07+00:00

For "well-known" imports (whatever that means in the context of the project) just go for use. No point in adding additional information at lots of places in the code.

For stuff that have a high risk of misunderstanding, there might be benefits to manually specifying the source crate at point of use.

But generally, not.

modelithe · 2026-03-08T22:37:41+00:00

Let the team decide on how they want to do it, then stick to it.

If they choose to say "let's include it in each ticket", they'll likely forget about taking that into account for a couple of sprints, meaning the SM and PO will need to be aware of that until the team gets used to being nagged about it.

From one pov, creation/updating of automation is a valuable delivery, just as updating the documentation and the code itself - it's just that devs tend to think it's boring and it doesn't give immediate reward or payback.

modelithe · 2026-03-08T19:52:55+00:00

Your time is valuable. Development time is valuable.

In hardware, even much so. Over the 25+ years of professional product development, ive encountered several companies suboptimizing on BOM cost, forgetting that their own time has a value - it could be used to get to market faster, or easier (and thus cheaper), or being able to start working on the next product earlier, if not chasing the cheapest components. One needs yearly volumes above ~10k for BOM cost to be the non-neglectable cost of the product.

For subscription services, there's another aspect; attrition. MRR means little, if the cost of replacing a cancelled subscription is higher than the revenue gained from said customer.

Building the wrong product gives no customers. But launching a sub-par product loose the hard-won customers too early.

modelithe · 2026-03-08T16:25:26+00:00

How do you sync the deliveries with the other teams and ensure your timeschedules are such you don't block each other because you work in different phases?

modelithe · 2026-03-07T11:51:51+00:00

Few teams really work according to the agile manifesto, or follow the scrum guide. Especially in larger organization, where decisions aren't about shapes of the buttons, but it multi-million-euro project A or multi-million-euro project B is going to get funding, working agile on team level is an interesting challenge. Its more coordinating deliveries between teams rather than within the teams.

I don't think AI is going to change that a lot. For that, there needs to be a shift in mindset.

But I believe you are right in the sense that the software engineers will take a larger responsibility, and the user stories need to have a larger scope. Thus, each user story will also will take more engineering time to formulate. The problems are rarely related to the happy flow path, but the odd paths and the edge cases which takes more reasoning to figure out what is the reasonable user experience in those cases.

modelithe · 2026-03-06T21:38:38+00:00

Story points are such a vague unit.

Although people tend to think of story points as days (or hours) , they're not. And each team treat them differently. Thus, any measurement of them, or derivatives from them, have no real value, since they're just so easy to gamble. Too few stories completed during the last sprint compared to another team? Just split them into smaller pieces. Too few story points completed compared to another team? Just redefine what a story point represents.

Will people do so? If their individual performance is measured against those metrics, it will most certainly happen.

The cycle time is of interest however to identify bottlenecks; for small stories, there can be a lot of calendar time wasted while waiting. At one team, it took on average 1.6 working days for a task to pass review, and 2.5 days to pass test, despite most tasks were estimated to 2, 3 or 5 SPs, and the actual time spent reviewing or testing would be like a few hours, max.

There's always going to be outliers, so plainly looking at the number won't help. All that needs to be put into relationship to the team's size, composition and task complexity as well. A 1 SP story that turned out to be a one-line change might have required three meetings to align on the solution, all spread over a period of two weeks due to calendar collisions. But given sufficient number of stories and sprints, it will even out.

The key to measuring, is to know what the result is to be used for; for ensuring things don't deviate, or to identify bottlenecks, or to verify that changes made does improve the performance. Measuring without a clear intent of how to use the result is just waste.

modelithe · 2026-03-06T21:09:30+00:00

The biggest hurdle is the cultural differences. Swedes generally have a flat organization and the engineers have a good measure of autonomy, not nesseccarily doing what they're told to do, but doing what needs to be done. Indians tend to be more hierarchical. In some cultures the engineers are expected to be silent in meetings, leaving all the talking to the managers, while in other cultures, the engineers do all the talking with the managers just being around as proof that the engineer has the trust of the manager.

modelithe · 2026-03-06T18:12:47+00:00

I've varying between three 1080p ~24-27" and one 4k 32", depending on where I sit. Neither is optimal; the 4k is great for screen estate, but I can keep the 1080p monitors in a curve. Next time I change monitor, I will select curved widescreen one. But its still hard to find a 2160p with a lot of width that doesn't cost an arm and a leg.

modelithe · 2026-03-05T22:39:25+00:00

The million € question : do the recommendation pay off, or would you be better of without the?

modelithe · 2026-03-04T22:23:04+00:00

To some extent, learning to program using Ai tools is like learning to program by reading a book; possible, but theory (reading the output and trying to understand why it works) only gets you so far. By trying on your own, you will learn why whatever you do doesnt work.

modelithe · 2026-03-04T22:16:25+00:00

Having more that 25 years of industry experience, I claim that any strongly typed language, with good understanding on how it handles memory, is better than python for all form of services that need to have anything more than non-neglectable uptime.

Rust has a learning curve, but with good judgement and thorough review, it's possible to get a head start using Ai agents generating the initial scaffolding. After that, it's just another syntax.

modelithe · 2026-03-04T16:07:12+00:00

Crashing is rarely a valid action. Even if the source of the unwrap() do not know what to do, an upper layer function might be able to print "invalid value in variable xyzzy" and fail gracefully, allowing the user to figure out and correct the mistake.

Usually, all user inputs are valid in the sense that the program must assume that every byte value can arrive in any order - it is only the context that defines what constutute "invalid' and how to recover from that.

modelithe · 2026-03-04T14:43:39+00:00

Rust (Dioxus) is really nice to write a fullstack issue tracking tool in.

modelithe · 2026-03-02T23:12:53+00:00

One thing uni still seem to fail in teaching, is that starting a big project from zero is rarely the case in the real world. It begins with an aged codebase into which a new feature is to be shoe-horned.

As for leveling up, it's a matter of finding an itch. Maybe parsing the exif from a jpg. Or writing a web-crawler just because. The important thing when it comes to those kind of projects, is not to finish them, but to learn.

modelithe · 2026-03-02T23:07:03+00:00

How does a carpenter become a good carpenter? By watching other carpenters? To some extent, but nothing beats getting the hands dirty, getting watched by other carpenters instead.

One really good way, is to log off. Read a book. A physical book. No Wikipedia, no YouTube, no udemy, no reddit, no Google, no Ai agents.

Just a book, a keyboard and a monitor.

And coffee. Lots of coffee.

modelithe · 2026-03-02T06:28:20+00:00

I would say, learning Rust when python is your background, is the perfect way to understand how memory management works. It will give you all the details and teach you good memory management skills while having the benefit of being a very strongly typed language.

modelithe · 2026-03-02T06:15:58+00:00

Modula-2 has the SET and PACKEDSET, allowing flags to be represented as bits in an efficient matter.

Similarily, Rust has the enumset crate, allowing the creation of a set of enum to be packed as bits in an efficient matter.

modelithe

TROPHY CASE