While I can get behind most of the advice here, I don’t actually like the conditions array. The reason being that each condition function now needs additional conditions to make sure it doesn’t overlap with the other condition functions. This was much more elegantly handled by the else clauses, since adding another condition to the array has now become a puzzle to verify the conditions remain non-overlapping.

I find Linear to be reasonably pleasant.

Issue resolved

Yeah, I mix them too, although I apply quite a bit of functional techniques especially at the architectural level as well. OO I use mostly for dealing with I/O and other areas where statefulness cannot be avoided.

If you’re interested, I also wrote an in-depth blog where I touch on these topics: https://arendjr.nl/blog/2024/07/post-architecture-premature-abstraction-is-the-root-of-all-evil/

Just keep in mind that inheritance is nowadays a very contested feature. Even most people still invested in object oriented programming recognise that in hindsight inheritance was mostly a mistake. The industry as a whole is also making a shift to move more towards functional programming, in which object orientation as a whole is taking more of a backseat and inheritance specifically is not even supported anymore. So yeah, take the chance to learn, but be cautious before going into any one direction too deeply.

and that burden is as far as I’ve seen being forced on those long term contributors.

This is not what is happening. The current long term contributors were asked to clarify semantics about C APIs, so the Rust maintainers could take it from there. At no point were the C maintainers asked to help maintain the Rust bindings.

First example that came to mind was actually Mac users who struggle with external monitors/projectors and things like screen sharing too. I agree they’re things that are so basic they should just work. Reality is often different even on other OSes.

Of course if you have a Windows home and everything works and then you try Linux and it struggles with a piece of equipment, it’s easy to blame Linux. You wouldn’t even be wrong. But you are oblivious to someone else’s experience who uses Linux exclusively and everything works for them, how many of those things wouldn’t work or work well with Windows.

Personally I’m a developer, so I care a lot about integrating parts of my development stack. A lot of those things don’t “just work” on Windows, or even Mac, so I’m happy to stick with Linux instead.

I agree with your examples and it’s certainly true there are plenty of rough edges on Linux. Then again, how many examples are there for things that should “just work” and do on Linux but don’t on Windows? There’s enough that make me not use Windows at all, because it has a subpar user experience. I even used a Macbook for a few years, mainly for work, and there were too many small things that annoyed me about it, so it too had a subpar user experience.

Seems it’s mostly a matter of perspective which issues are more important to you.

You make a good point in that Docker promised to make dev environments reproducible so that everyone on the team would have the same environment. They even succeeded in that, but either intentionally or accidentally omitted reproducibility over time due to the introduction of non-locked dependencies.

As a junior with no clue how to write production code, is Clean Code going to provide with a decent framework I can quickly learn to start learning my craft, should I throw it out completely because parts are bad, or should I read both Clean Code and all its criticism before I write a single line?

I see what you’re getting at it, and I agree we shouldn’t increase the load for juniors upfront. But I think the point is mainly there are better resources for juniors to start with than Clean Code. So yeah, the best option is to throw it out completely and let juniors start elsewhere instead, otherwise they are starting with many bad parts they don’t yet realize are bad. That too would increase cognitive load because they would need to unlearn those lessons again.

Also in Europe, but I’ve worked at 3 different startups before becoming a contractor earlier this year.

• First one I worked for 5,5 years, joined at ~30 people and saw things grow to 180 people at which point the company was sold and I left about a year after that.
• Second one I worked for 7 years, was one of the first employees and responsible for building their frontend stack as well as various microservices from the ground up. Company grew to about 80 people, but I left after Covid layoffs. I wasn’t one of the layoffs, but culture went to shit quickly after that.
• Third I was also one of the first people and helped build a pretty exciting architecture from scratch. Stayed for 3,5 years, but unfortunately the company never found market fit during that time and the team never grew beyond ~20 people.

Overall I can say:

• If you value autonomy and you have a getting-things-done mentality this is the right gig for you.
• Culture differs very much per workplace, you may need to be lucky. (I don’t think that’s unique to startups though.)
• You need to be assertive and pro-active.
• Don’t do it for the money. Startups usually pay less, but in theory make up for it by offering equity. But most startups fail, so in most cases this will never be more than theory. Even if you do get an exit, chances are the payout is less than you would’ve earned working those years for a bigger corporation.
• The experience can be extremely rewarding because you can easily reach a position of influence.
• You will learn a lot.
• The experience can be frustrating because there is always pressure and a lot to do and you rarely have the means to do it all.
• You will need to improvise a lot.
• If you pull it off and your startup becomes successful the thrill is exhilarating.

This is the real reason we have linters.

I absolutely agree with you. If I can avoid NPM I will indeed do so. Sometimes that means using Deno, but sometimes it can be a valid reason to avoid using the language altogether. And sometimes we have to suck it up 🤷‍♂️

As much as people like to make fun of JS/TS, I think you’re right, especially compared to the languages you mentioned. It’s my second-favorite language after Rust.

I think I would put Swift above it as well, except I don’t really use it since it’s too domain-specific in practice.

If you just have one or two required fields, with the rest being optional, it can also be a good middle ground to just pass the required fields to new() and use methods like in your example for the optionals.

PS.: A common convention for these methods is to prefix them with with_, like with_max_depth(max_depth: usize) -> Self.

Sorry, I don’t understand. Do you mean there have to be 6 digits of Pi in there, or the sixth character must be π? I’m down either way.

Sure! The other day someone called it emergent architecture. I guess it goes by multiple names :)

Can’t it be both? :)

Ah, fair :) then yeah, I’d say it’s pretty aligned with emerging architecture, just that I’m trying to define the values (and in the next post, technical guidelines based on those values) to (hopefully!) help you make the right decisions as you’re working on an emerging architecture.

I assume you’re referring to this blog series: https://medium.com/prospa-technology/emerging-vs-intentional-architecture-385071ae5d75 ? I wasn’t aware of it, and it seems to have some insightful observations! There’s definitely some overlap, but by the looks of it, I think I will diverge quite a bit with my next post. I think I’m pretty aligned on the “One-Way Decisions” vs “Two-Way Decisions” part. A One-Way decision in my mind would be, which programming language or framework do we use? Do we use REST or GraphQL?

But it doesn’t really go into how to deal with Two-Way decisions, apart from saying to trust your developers. And I think it kinda glosses over the part that things that may appear to be Two-Way decisions initially may actually be closer to One-Way decisions if you continue to build on them. So where that blog still focuses quite a bit on the process, I think I want to shift the focus a bit more to the technical side (so far I’ve mostly laid down the values that inform the technical direction), especially when it comes to Two-Way decisions. I wasn’t thinking about covering One-Way decisions much, but rather on how to shape everyday coding to be more in alignment with Post/Emerging architecture so that you can avoid the Two-Way decisions that in retrospect aren’t as much of a Two-Way decision as you’d hope.

Hope that makes sense :D