Ask HN: Interested on writing a book on software design/architecture together?

I may. I wrote a book once. Hard work. I think you may need an editor, rather than a co-author. Someone who'd proofread and rearrange every sentence of every paragraph of every page of every chapter. And do it 10 or more times for each of those sentences, paragraphs, pages and chapters - before it can be published even as beta. Furthermore, as we all know, senior engineers disagree vastly on so many tiny little things: preferences, practices, routines, while simultaneously agreeing on some deeper inherent truths. But keeping that in mind, co-authoring may work out kinda like Rustin Cohle and Marty Hart worked out in True Detective - in the end. Question is, what kind of journey are you up for. And where am I.

Drop me a line, the email is on my website orion3.space

Congratulations on the work! I’ve been doing startups for +10 years but also worked in big companies. This is pretty interesting, how do we contact you?

One thing I really wish I had learned from a book is how to adapt the architecture to the current stage the company is in (something like this likely exists but IDK).

For instance, the “brittleness” of your systems must follow the “certainty” the company has on product-market fit. In other words, if the % of changing code is high then it should be cheap to change it. I could explain this in much more detail, and I have seen countless under-engineering and over-engineering issues in practice because people lack this mental model.

Something that I would find useful along these lines is: how does a team with a legacy codebase which may not be nice for human in many places pay down the tech debt?

Most companies have tightly couple code, only partial test coverage and slow build times (builds bloat until the pain is too painful and it is reigned in but that is too far)

There is a technical and a social aspect to this. Telling the boss we will ship fewer features etc. as we are doing stuff for future maintainers and better on boarding.

This is a perspective I've been following and cultivating for a long time, and even led to my current endeavor [0]. Code should really be structured to be easy for us humans to understand and change, and we humans are sometimes not as logical as we'd like to believe.

It can sometimes feel like a lot of folks are chasing other priorities and forget to even consider the human aspect of architecture. I also often see people make mistakes on what "simplicity" is, and what kind of simplicity should be optimized for. For a recent example, Rust's borrow checker is based on a simple rule (roughly, a reference can have one mutable reference xor multiple readonly reference) but it can often lead to more complexity than the corresponding program written in a GC'd language. Knowing when and how this happens is an art!

I'm not sure if I have anything you haven't thought of already, but I'd love to contribute a chapter or two on whatever topic, or edit anything that needs editing. If you'd like a sample of my work, I'm particularly proud of [1]!

[0] https://vale.dev/

[1] https://verdagon.dev/blog/yak-shave-language-engine-game

Hi! I am considering myself as a generalist, that means jack of all trades but master of none. I do not work as a programmer and never did but I love to study computer sciences.

I think your book with best practices also must contain something about TDD, Lisp macroses vs C++ ones, some bits of knowledge on system programming, and how software makes our world worse because of abandoning engineer culture in craft of software development. I do not think I can be a co-author, but I might help you if you have some interdisciplinary questions or if you need somebody to read your drafts.

English is not my mother language so do not expect great writing skills from me but if you have some unanswered questions from fields of general knowledge I will do my best to let your project be as good as you have claimed.

> abandoning engineer culture in craft of software development

I think it's just a function of the rapid growth our field has seen over the past few years. With 'everyone' becoming software developers, and new frameworks being launched every day, it's just hard to promote long term planning and the following of sound engineering principles. With the current rate of change, software is seen as 'disposable', promoting more of a hacker culture, and less of an engineering culture.

I would strongly suggest you read this classic paper “programming as theory building” https://pages.cs.wisc.edu/~remzi/Naur.pdf

Hi, how can I contant you? Or maybe you can reach me out on Twitter - https://twitter.com/konradkokosa ?

Friendly suggestion: Consider listing your contact details in your HN profile.

Please note that it’s not enough to fill in the email field on your profile. Only the HN admins can see that field.

Could you post updates on HN or to my email? Would love to read "a different perspective than existing books out there"..

Hello. I would be happy to collaborate - been architecting applications for Adobe for many years now. My email is available in HN profile, or my Github profile https://github.com/sangupta

Hey! This sounds really interesting and I think I can help with something. Do you have any contacts?

That's like walking into a kindergarten class, and yelling "Who wants ice cream?"

You will not suffer for volunteers.

I'm probably not one of them. I've done that kind of thing, before, and I sincerely wish you luck, but my own dance card is fairly full.

My only ally in this life has always been serendipity. That's why I replied to this post. It's a simple post. Ice cream is simple. Kindergartens are simple. On their surface, of course. You ever watched "Kindergarten Cop"? Try and watch it and remember that scene where Arnold reads a poem. Find that poem. Read it whole.

Sometimes things that appear shallow bring about the deepest truths: if you take effort not to ignore what you're looking at, what you're hearing at the moment, if try not to ignore all your other senses. Suspension of disbelief is crucial, ESPECIALLY if you want to write something - even non-fiction. Or else, how do you expect your readers to do the same and believe your words or least consider them, if even you yourself cannot do that little trick?

amanfrommars? Is that you?

> Kindergarten Cop - "Spring Morning"

> John Kimble reads the final two stanzas of the children's poem "Spring Morning," by AA Milne, to his kindergarten class

https://www.youtube.com/watch?v=UnPsFFk0sBg

It's beautiful poem for any age. It's a gem, which I discovered only recently when I re-watched the film. A gem hidden right there, in plain sight.

I've sold a book with a large publishing house a long while back and wanted to give you a bit of perspective on that front, in case you or anyone else may be curious:

Tech books used to pay a much higher royalty than "regular books", like novels. I'd get 14% per book vs. 7% or less on a novel. That can make quite a bit difference. Of course, people will tell you to self-publish and keep next to 100% of your profit, but the gatekeeping function of publishing houses can be beneficial as well. I've had a few instances where I thought I had a fantastic idea, only to go through "the process" and see how it wouldn't have sold much.

That said, and I may get some heat for that, self-publishing only makes sense (if you're not just in it for the fun of typing and researching) — if you have a large-enough platform. I'd even argue that 95% of your success will be having a fantastic platform to launch this from, and 5% will be about the contents of the book (if you're self-publishing).

Pieter Levels could launch a photo book of his favourite cat photos, and still make a 100k off of it. Most people can't do that, because they don't have the platform.

This differs quite a bit with publishing houses. If you can get in, and it tends to be easier in tech writing as those books can be priced much higher, then they'll bring the platform, and you just bring the content. Once launched, you can build from this "borrowed" platform and try to work on your own audience. My unsolicited advice here would be to make as much as you possibly can (executing as quickly as possible) from that initial launch power and build a crowd around it that you can use as a firestarter for future projects.

Depending on which publishing house may offer a deal, this could mean being placed in most universities, being placed in large-chain book stores all around the world, or airports (for novels). Something that can rarely be done by self-publishing.

Again, not hating on the self-publishing route, especially when you look at the per-book numbers, where it's 14% or less before taxes vs. close to a 100%, but if you don't have a platform, then you'd probably need to be super ready for spending at least a full year on this to get it up to quality, and then also building a platform to launch it from. Just the title and name doesn't cut it anymore, unless you do get really lucky.

Hope this doesn't offend those who self-publish, if you're doing this successfully, you are the true masters. Finding a publishing house is, in my opinion, actually the easier route.