You think it is the first half. You’ll realize later on that really you need a totally different structure to write the book. You’ll try to refactor the whole thing, but some obstinate subset of the original readers will insist on using the original index. In the interest of backwards compatibility, you’ll jam the new structure into the margins (so they can keep their precious index).
Top tier comment, lol. This is the reality though, be it text, code, or design; you work hard on it, you're happy with the results, show it to others, and think it's almost done. But the 20/80 rule applies in multiple ways. You think you're at 80%, but in reality you're only at 20%. Or the last 20% will take 80% of your time.
Real life example, we were presented with a redesign of a website with an undertone of "this is it, I have worked hard on it, I am happy with how it turned out". But then we, the pesky software developers, get in and start asking questions. "Where's the mobile design? 60% of visitors visit the site through mobile but you started with a desktop design?", "What if the user increases their font size, as per the legally mandated WCAG 1.4.4 rule?", "Did you consider dark mode?" "How does this work with a touch device?" "How does this work with a screen reader?", "What about this and this and this use case?". It goes on.
I think a big difference between being a professional and a beginner is, a beginner will work very hard on the most obvious part of the problem. And might get something reasonable after a while. But the professional knows that the obvious part isn't where most of the difficulties lie, they'll probably use some tool to handle the obvious part near automatically, and they'll factor in all these invisible requirements into their original estimate.
I started writing the book in Obsidian, but realized I needed something a little better. So, I took it to Scrivener, which is where the first draft was completely developed (it can maintain references and a TOC somewhat).
But once I needed editors, it had to be in Word and all of the references needed to be rebuilt when that was completed. It's now in a contractor's hands, using some book making software (not even sure which, I think an Adobe product).
As someone who is also writing a book (for the first time), I hate how accurate this is.
I wrote my first draft in 3 months, about 200 pages... Six months later, I haven't delivered a quarter of the book. And I will probably revisit those delivered chapters later.
If you are interested, my writing group is doing a free, 6-week (1-hour on Thursday) accountability group sprint. We spend most of the time writing (quick chat at the beginning and end)
This is why I never make any drafts that I might have to change later. I always think of the entire book ahead of time without and type it out exactly without errors. /s
Congratulations on writing a book and getting it out in the world.
1. It took me two tries to realize there is more than the table of contents and find the Unlabeled links on the left. Just make the text in the TOC clickable.
2. Maybe text navigation didn't work the first time because I did not select the correct option on the popup about interaction. This is a distraction from reading irrespective of what I picked.
3. Advice: make the reading experience work like readers expect. There are conventions. Trying to be clever doesn't benefit your readers...and will annoy at least one of them.
The author chose the format to present their work and posted the link. They own the problems associated with their book, are in a position to choose other options, and can benefit from the feedback.
The website designers probably aren't looking at this page and even if they were, the problem is not as important to them as it is to the author.
The swimming analogy is not a strong start. You disavow an obvious and strong analogy to monetary debt right away while dumping us into this strange metaphor that depends on us having an intuition for how you think and feel about swimming, and specifically swimming laps? Instead of setting the stakes high right off the bat you've lowered them and lost my attention with this wandering train of thought that has no clear relationship to the topic you wish to discuss...
I'm reading a bit more now and you're realizing that your debts are real and cost something all the time so that you will have to pay them. Nothing about swimming explains why this might be, though monetary debt sure does.
The analogy I am going for is the water resistance. The debt payment is the burst of momentum you get from pushing off the wall.
I think of tech debt as something you are dealing with all of the time and something inevitable.
I don't like the financial analogy because it implies that you "took out a loan" by taking a short-cut, and that you are obligated to pay it. There is definitely some of that, but mostly, I see it as good decisions that didn't age well. And also, that you may be ok with living with it.
The fungible nature of money helps explain why that is the case. One dollar bill is as good as another, something people know from handling cash. Paying down a debt is one kind of investment. Maybe it costs you $100/day to service that debt. If someone offers you a chance to invest that same money that you could have used to pay off the first debt and by investing earn divdends of $200/day, then the fact that one dollar is as good as another is what means that you should do it.
But even then you're also not (yet) getting to the heart of it: what is the value of tech debt? You still make it sounds like a damp rag dragging on you rather than an integral part of an energetic strategy. Money also gives people a clear analogy for why sometimes you want debt -- why and how it can be used as a tool.
In the swimming analogy I would say incurring a debt is like creating a wall that you can burst off of, at the cost of increasing the resistance of the water. Yeah it's a weird analogy. To be more literal, debt buys you the time you need to figure out the optimal direction and especially the critical priorities that will reward work -- will reward investment. It buys time to learn the requirements from experience, and for people to come to some community consensus as to which needs are most imminent. But only if the person managing the debt thinks of it as a tool to be used in this manner.
You go right back to the monetary analogy when you need to explain that focusing on debt created value.
The thing that I think the swimming analogy doesn't capture well is that the resistance of water is fixed. The walls of the pool will be there to push off of no matter what you do. These are the intuitions you're asking people to draw on and they don't map.
I struggled with this. I didn't have the guts to not use "tech debt" in the title and throughout the book. I wanted to coin a new term, but didn't find anything that worked.
There are parts of the debt analogy that (I think) really hurt getting it dealt with. I think that explaining it like that to non-engineering decision makers will make them think they understand it and then quash projects based on some kind of ROI analysis of debt payments. They'll be happy to have the debt.
Debt is the right metaphor.
Some amount of tech debt is virtually unavoidable; just like w/ $, a low-interest student loan or mortgage might be a great investment, while using a high-interest-rate credit card, or usurious payday loans, represent catastrophe.
Cutting a few corners for the sake of GTM is often the former. Forgoing proper tests, or letting PoCs shape architecture, is more like the latter.
I don't see "swimming" replacing it anytime soon -- and the energy you'd expend trying to shift the metaphor might be better spent elsewhere.
That said, "swimming in debt" still works, as a fairly common and intuitive metaphor. Break-even is treading water, profitability is flying above the waves, and accruing debt can put you in Davy Jones' locker.
Isn't that same resistance the thing that enables you to float in the first place though? I don't really swim so don't understand the analogy I'm afraid.
The debt analogy works because you're taking a shortcut that allows you to eg get to market sooner (Vs perhaps not at all).
For some debt, yes, it starts with a shortcut. I want to talk about other kinds of debt-like problems that have nothing to do with that. Where you did everything right, but the world just changed.
I think most engineers know that doing everything right is reserved for toy problems. In engineering you're always making choices about what problems to deal with today and which to leave for tomorrow. Code is always some kind of simplification of reality: reality is just too damn complicated. The rules of the game of tech debt are the same as the rules of thermodynamics and the game of being alive: you can't win, you can't break even, and you can't even stop playing the game.
Monetary debt is often a useful tool. Technical debt in many cases is just shortsightedness in throwing delayed time bombs around. It is built on the hope that you won't need to return on this minefield again (the product dies sooner).
This is a good insight. The real gambles behind tech debt are not taken on the same way a company would take on real debt. If there is analysis of it, and it's not just a sneaky shortcut by a dev (either being lazy or working to a deadline), then it's not considered in terms of future cash flow or any other kind of meaningful metrics that matter over time. It only comes due if you want it to; you only pay interest on it when you interact with it. Sometimes it really is Good Enough for the slapdash thing you're working on. Sometimes more crap on top of more crap is just how the thing you're working on goes, and trying to fix it is tilting at windmills... especially if it's just to make your employer rich by mildly improving efficiency on their ad delivery platform.
Thanks for the feedback. The reason that I put up half the book and offered it for $1 to start was to make sure that people that didn't like it wouldn't buy it.
I struggled with this opening and it definitely could have been better.
No worries at all. I really do appreciate constructive feedback. I put every draft of the book out there that I could, and this is my best version of making the book I wanted to make that resonated with at least some people.
I think people are being extreme pedants at best, disingenuous at worst. I think your analogy is clear, and the people that can't connect because they don't understand swimming is in the minority.
The chapter titles are too long, and the contents of each are too anecdotal.
That means I can't find an interesting chapter, and just blindly picking one leaves me with a stream of consciousness to sort through.
I don't get the sense that this is coherent enough to be the book or guide people expect. It really does feel like a collection of loose blog posts. That's not necessarily a bad thing if you change how this is presented.
If you want to tell stories that's fine, but don't then organize this as if each chapter is a lesson. That's misleading because there's not enough conceptual meat on the bones there. Organize the chapters by the stories you want to tell, not by the concepts you hope the reader sees in them.
Distilling and organizing the knowledge you think you have in your blog posts would mean an entire rewrite of this book and more careful analysis than just labeling each as its own chapter and adding a few sentences to fill gaps. The book people want would probably be 10% narrative and 90% instructional. This is 100% narrative in its current form.
Honest question expecting your honest response. How much of it's written by AI? Recently, I noticed I am liking thoughts of real people over the super structured, emdash-y, zero grammar mistake AI texts.
I want to support authors who share their experiences, rather than guiding AI to write thoughts
I did not use AI to write this. I paid professional editors to help me get it polished. There were 4 rounds with 5 different people. I also got lots of grammar/typo comments using helpthisbook (hundreds of readers pointing out errors).
I did (very rarely) take single sentences to ChatGPT and ask it for the correct way to punctuate it.
I personally have always used em-dashes, perhaps incorrectly. I actually tried to learn the correct usage and stick to using it when appropriate. One of my goals in writing this book was to become a better writer, which I could only do (IMO) by writing and getting editors to help me.
I don’t have time to write a more detailed review just yet, but given all the highly critical comments, I just wanted to put out there that I read quite a bit of this last night and thoroughly enjoyed it!
Thanks! I put up half the book so that only people that liked it would buy it. I am ok with it not being for everyone. I got about 70 sales overnight, so I am totally fine with some negative comments as well. Most are constructive.
I am a little miffed that someone called it AI slop. I wrote every word (with professional editors helping). So, that hurts a little :)
I'd recommend resubmitting as Show HN since this is your product and those submissions actually have their own dedicated URL. Plus, the way the title reads now is as if the submission was a blog you found
I haven't read the book but I've known Lou for probably 20 years and he is a very smart, very pragmatic software engineer who also happens to be a great guy. I look forward to when this is launched so I can buy a copy.
I read the first part and I enjoyed it. I agree that us developers aren't great at communicating tech debt effectively. Managers are also not great at prioritizing it. I think the "debt" analogy has been a net negative as management often thinks "we'll just pay it later" but don't often see how much pain it's causing. So having a resource to help both sides on this topic is very valuable.
Thanks. That’s my belief as well. I would have loved to come up with a better term.
In the next two parts of the book I try to convince managers to give some autonomous time to engineers to do whatever tech debt projects they think is best. With some constraints and accountability.
Any chance you’re selling the ePub format directly, or via the Kobo store? I switched from Kindle to Kobo a few months back, when Amazon decided to remove everyone’s ability to download the books they’ve purchased. But I’d love to read this!
My priority is Kindle, then print. Then I will look into other formats. At that point I will have a PDF (that was used for Print) and an epub, so it will primarily be driven by interest.
The best way to be notified by it is to be on my list at loufranco.com or reaching out to me.
A total tangent but it's amazing how more palatable "tech enhancement" is in planning, management chats, etc., than anything involving the term "tech debt"
Can you say more on your experience here? I've not heard people use that term before, and I'd be interested in how it received/what you think the difference is.
Sure, just that stories about "paying down tech debt" are an implicit admission of flaws and shortcuts and "doing it again because it wasn't done right initially".
Which is all true but the concept of making deliberate trade offs for speed and expedience invariably gets lost.
Stories about ongoing improvement - tech enhancement - just get seen as more positive. Plus that term covers both remediating original shortcut choices as well as new engineering improvements arising.
I wish you luck, and you’ve picked a good subject.
I once wrote a book (about 400 pages, after editing). No one read it, and rightly so. It covered a topic in a preachy, dictatorial manner. It’s long buried in a deep, unmarked grave, in the desert.
It was accurate, well-written, well-structured, relevant, and useful, but assumed a tone that was pure poison. It was aimed at an audience that did not respond well to the tone.
It was extremely valuable education for me, though. My mother was a scientific editor, and edited the book. It was brutal, and quite humbling, but her work ensured that the book was absolutely perfect. I don’t think I’ve ever shipped anything as close to [unpopular] perfection as that book.
Even though I have never been particularly interested in writing book-length stuff, since then, I continue writing to this day[0]. Here’s the latest thing I did (released a few days ago)[1]. I don’t really write for others; I write for myself.
[EDITED TO ADD] I typically get some downvotes, when I link to my postings. Long ago, I favorited a comment that I made, explaining this[2]. I don’t expect anyone to actually read it before hitting the down arrow, but I figured that I’d add it here, for elucidation.
I do wish HN had a culture of being ok with linking to supporting material on our own sites. I have been blogging for 20+ years -- some of those posts are relevant (and I think useful).
I also mostly write for myself, but I want to get more of it out there because I think it's useful.
It's a good topic and I am currently trying to manage lots of tech debt. So it caught my attention and I started to read, but it seems that you liked your swimming upstream allegory a little bit too much. Basically reading the same sentence several times in every chapter bored me and I quit...
Thanks for the link. Its always helpful to have new ways to describe tech dept. The term is too overloaded and most people roll their eyes when hearing it since it can be used to describe anything from real issues to things that are fine but you just do not like for whatever reason. Look forward to reading the section on what issues are worth paying down and those that are fine to live with. Its not any easy decision to make, but having concrete examples is always a bonus. For .99 cents pre-ordered a copy and if there is going to be a real book would love to have it sitting on my desk. It could sit next to Software Estimation by Steve McConnell ;) Cheers!
There will be a print book about a month after the Kindle version launches. It takes time to get the formatted properly (using a contractor). It will be offered for the Amazon minimum price to start -- if you want a notification, sign up on my site: https://loufranco.com/tech-debt-book.
You seem to be writing about other concepts and just redefining them as tech debt.
I left more detail in comments, but if I had purchased this book I would be seeking a refund, because I would be expecting a detailed exploration of technical debt, not just a focus on bad coding practice.
This is why I shared half the book. I will probably continue to do so for at least a few months (even after the book is launched). I am sharing a lot of the content of the next six chapters on my email list and will probably always have that archived for them.
I really don't want people to buy it if they won't like it.
Its not really an issue of getting to read before I buy.
Its very much that its advertised as something its not.
You could do research into technical debt and bring other peoples anecdotes and experiences into the book and bring the content in line with the title and readers expectations.
Or you could update the title and therefore manage expectations to ensure there are no misunderstandings.
It was not AI written. I took 18 months to write it. I documented a lot of that on my blog in real time and in LinkedIn. I have posted several drafts of (hopefully) increasing quality publicly.
I get that you might not like my writing, but it is mine.
You think it is the first half. You’ll realize later on that really you need a totally different structure to write the book. You’ll try to refactor the whole thing, but some obstinate subset of the original readers will insist on using the original index. In the interest of backwards compatibility, you’ll jam the new structure into the margins (so they can keep their precious index).
It’s text-debt.
Top tier comment, lol. This is the reality though, be it text, code, or design; you work hard on it, you're happy with the results, show it to others, and think it's almost done. But the 20/80 rule applies in multiple ways. You think you're at 80%, but in reality you're only at 20%. Or the last 20% will take 80% of your time.
Real life example, we were presented with a redesign of a website with an undertone of "this is it, I have worked hard on it, I am happy with how it turned out". But then we, the pesky software developers, get in and start asking questions. "Where's the mobile design? 60% of visitors visit the site through mobile but you started with a desktop design?", "What if the user increases their font size, as per the legally mandated WCAG 1.4.4 rule?", "Did you consider dark mode?" "How does this work with a touch device?" "How does this work with a screen reader?", "What about this and this and this use case?". It goes on.
I think a big difference between being a professional and a beginner is, a beginner will work very hard on the most obvious part of the problem. And might get something reasonable after a while. But the professional knows that the obvious part isn't where most of the difficulties lie, they'll probably use some tool to handle the obvious part near automatically, and they'll factor in all these invisible requirements into their original estimate.
I started writing the book in Obsidian, but realized I needed something a little better. So, I took it to Scrivener, which is where the first draft was completely developed (it can maintain references and a TOC somewhat).
But once I needed editors, it had to be in Word and all of the references needed to be rebuilt when that was completed. It's now in a contractor's hands, using some book making software (not even sure which, I think an Adobe product).
So, yeah.
As someone who is also writing a book (for the first time), I hate how accurate this is.
I wrote my first draft in 3 months, about 200 pages... Six months later, I haven't delivered a quarter of the book. And I will probably revisit those delivered chapters later.
If you are interested, my writing group is doing a free, 6-week (1-hour on Thursday) accountability group sprint. We spend most of the time writing (quick chat at the beginning and end)
https://pages.usefulbooks.com/writing-sprint-2025
Try writing other people’s books. As in typing them into the word processor. It really helps speed things up.
> You’ll try to refactor the whole thing, but some obstinate subset of the original readers will insist on using the original index
and as always the answer is simple: "use the old version of the book or bite the bullet"
>In the interest of backwards compatibility, you’ll jam the new structure into the margins (so they can keep their precious index).
Its fine, they just need to tweak the workflow and wire up some kanban.
This is why I never make any drafts that I might have to change later. I always think of the entire book ahead of time without and type it out exactly without errors. /s
Congratulations on writing a book and getting it out in the world.
1. It took me two tries to realize there is more than the table of contents and find the Unlabeled links on the left. Just make the text in the TOC clickable.
2. Maybe text navigation didn't work the first time because I did not select the correct option on the popup about interaction. This is a distraction from reading irrespective of what I picked.
3. Advice: make the reading experience work like readers expect. There are conventions. Trying to be clever doesn't benefit your readers...and will annoy at least one of them.
4. Nobody likes popups. Nobody. Nobody.
Good luck.
This is a website to get feedback about their book, your ux complaints are with "helpthisbook."
The author is looking at this page.
The author chose the format to present their work and posted the link. They own the problems associated with their book, are in a position to choose other options, and can benefit from the feedback.
The website designers probably aren't looking at this page and even if they were, the problem is not as important to them as it is to the author.
Agreed. I am pretty sure that they are going to look at it though. I am in close contact with them.
I will give this feedback to the helpthisbook people. I am sure they will appreciate it.
I'm reading this in the same tone as when someone says "bless your heart"
The swimming analogy is not a strong start. You disavow an obvious and strong analogy to monetary debt right away while dumping us into this strange metaphor that depends on us having an intuition for how you think and feel about swimming, and specifically swimming laps? Instead of setting the stakes high right off the bat you've lowered them and lost my attention with this wandering train of thought that has no clear relationship to the topic you wish to discuss...
I'm reading a bit more now and you're realizing that your debts are real and cost something all the time so that you will have to pay them. Nothing about swimming explains why this might be, though monetary debt sure does.
The analogy I am going for is the water resistance. The debt payment is the burst of momentum you get from pushing off the wall.
I think of tech debt as something you are dealing with all of the time and something inevitable.
I don't like the financial analogy because it implies that you "took out a loan" by taking a short-cut, and that you are obligated to pay it. There is definitely some of that, but mostly, I see it as good decisions that didn't age well. And also, that you may be ok with living with it.
The fungible nature of money helps explain why that is the case. One dollar bill is as good as another, something people know from handling cash. Paying down a debt is one kind of investment. Maybe it costs you $100/day to service that debt. If someone offers you a chance to invest that same money that you could have used to pay off the first debt and by investing earn divdends of $200/day, then the fact that one dollar is as good as another is what means that you should do it.
But even then you're also not (yet) getting to the heart of it: what is the value of tech debt? You still make it sounds like a damp rag dragging on you rather than an integral part of an energetic strategy. Money also gives people a clear analogy for why sometimes you want debt -- why and how it can be used as a tool.
In the swimming analogy I would say incurring a debt is like creating a wall that you can burst off of, at the cost of increasing the resistance of the water. Yeah it's a weird analogy. To be more literal, debt buys you the time you need to figure out the optimal direction and especially the critical priorities that will reward work -- will reward investment. It buys time to learn the requirements from experience, and for people to come to some community consensus as to which needs are most imminent. But only if the person managing the debt thinks of it as a tool to be used in this manner.
You go right back to the monetary analogy when you need to explain that focusing on debt created value.
The thing that I think the swimming analogy doesn't capture well is that the resistance of water is fixed. The walls of the pool will be there to push off of no matter what you do. These are the intuitions you're asking people to draw on and they don't map.
I struggled with this. I didn't have the guts to not use "tech debt" in the title and throughout the book. I wanted to coin a new term, but didn't find anything that worked.
There are parts of the debt analogy that (I think) really hurt getting it dealt with. I think that explaining it like that to non-engineering decision makers will make them think they understand it and then quash projects based on some kind of ROI analysis of debt payments. They'll be happy to have the debt.
Debt is the right metaphor. Some amount of tech debt is virtually unavoidable; just like w/ $, a low-interest student loan or mortgage might be a great investment, while using a high-interest-rate credit card, or usurious payday loans, represent catastrophe. Cutting a few corners for the sake of GTM is often the former. Forgoing proper tests, or letting PoCs shape architecture, is more like the latter.
I don't see "swimming" replacing it anytime soon -- and the energy you'd expend trying to shift the metaphor might be better spent elsewhere.
That said, "swimming in debt" still works, as a fairly common and intuitive metaphor. Break-even is treading water, profitability is flying above the waves, and accruing debt can put you in Davy Jones' locker.
Isn't that same resistance the thing that enables you to float in the first place though? I don't really swim so don't understand the analogy I'm afraid.
The debt analogy works because you're taking a shortcut that allows you to eg get to market sooner (Vs perhaps not at all).
For some debt, yes, it starts with a shortcut. I want to talk about other kinds of debt-like problems that have nothing to do with that. Where you did everything right, but the world just changed.
I think most engineers know that doing everything right is reserved for toy problems. In engineering you're always making choices about what problems to deal with today and which to leave for tomorrow. Code is always some kind of simplification of reality: reality is just too damn complicated. The rules of the game of tech debt are the same as the rules of thermodynamics and the game of being alive: you can't win, you can't break even, and you can't even stop playing the game.
Monetary debt is often a useful tool. Technical debt in many cases is just shortsightedness in throwing delayed time bombs around. It is built on the hope that you won't need to return on this minefield again (the product dies sooner).
This is a good insight. The real gambles behind tech debt are not taken on the same way a company would take on real debt. If there is analysis of it, and it's not just a sneaky shortcut by a dev (either being lazy or working to a deadline), then it's not considered in terms of future cash flow or any other kind of meaningful metrics that matter over time. It only comes due if you want it to; you only pay interest on it when you interact with it. Sometimes it really is Good Enough for the slapdash thing you're working on. Sometimes more crap on top of more crap is just how the thing you're working on goes, and trying to fix it is tilting at windmills... especially if it's just to make your employer rich by mildly improving efficiency on their ad delivery platform.
Thanks for the feedback. The reason that I put up half the book and offered it for $1 to start was to make sure that people that didn't like it wouldn't buy it.
I struggled with this opening and it definitely could have been better.
Sorry, I'm a notoriously harsh critic. That probably comes from being homeschooled by two English major parents (a poet-professor and a journalist).
No worries at all. I really do appreciate constructive feedback. I put every draft of the book out there that I could, and this is my best version of making the book I wanted to make that resonated with at least some people.
I totally get that it's not for everyone.
I think people are being extreme pedants at best, disingenuous at worst. I think your analogy is clear, and the people that can't connect because they don't understand swimming is in the minority.
The chapter titles are too long, and the contents of each are too anecdotal.
That means I can't find an interesting chapter, and just blindly picking one leaves me with a stream of consciousness to sort through.
I don't get the sense that this is coherent enough to be the book or guide people expect. It really does feel like a collection of loose blog posts. That's not necessarily a bad thing if you change how this is presented.
If you want to tell stories that's fine, but don't then organize this as if each chapter is a lesson. That's misleading because there's not enough conceptual meat on the bones there. Organize the chapters by the stories you want to tell, not by the concepts you hope the reader sees in them.
Distilling and organizing the knowledge you think you have in your blog posts would mean an entire rewrite of this book and more careful analysis than just labeling each as its own chapter and adding a few sentences to fill gaps. The book people want would probably be 10% narrative and 90% instructional. This is 100% narrative in its current form.
Someone has to mention Working Effectively With Legacy Code, by Michael Feathers, still a fantastic book.
https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...
Love that book. Also, "A Philosophy of Software Design" by John Ousterhout
First of all, congratulations
Honest question expecting your honest response. How much of it's written by AI? Recently, I noticed I am liking thoughts of real people over the super structured, emdash-y, zero grammar mistake AI texts.
I want to support authors who share their experiences, rather than guiding AI to write thoughts
I did not use AI to write this. I paid professional editors to help me get it polished. There were 4 rounds with 5 different people. I also got lots of grammar/typo comments using helpthisbook (hundreds of readers pointing out errors).
I did (very rarely) take single sentences to ChatGPT and ask it for the correct way to punctuate it.
I personally have always used em-dashes, perhaps incorrectly. I actually tried to learn the correct usage and stick to using it when appropriate. One of my goals in writing this book was to become a better writer, which I could only do (IMO) by writing and getting editors to help me.
I don’t have time to write a more detailed review just yet, but given all the highly critical comments, I just wanted to put out there that I read quite a bit of this last night and thoroughly enjoyed it!
Thanks! I put up half the book so that only people that liked it would buy it. I am ok with it not being for everyone. I got about 70 sales overnight, so I am totally fine with some negative comments as well. Most are constructive.
I am a little miffed that someone called it AI slop. I wrote every word (with professional editors helping). So, that hurts a little :)
I'd recommend resubmitting as Show HN since this is your product and those submissions actually have their own dedicated URL. Plus, the way the title reads now is as if the submission was a blog you found
I did submit as ShowHN. I don’t know how and when this got edited.
I haven't read the book but I've known Lou for probably 20 years and he is a very smart, very pragmatic software engineer who also happens to be a great guy. I look forward to when this is launched so I can buy a copy.
Thanks! You can buy it now for a buck. But, if you are waiting for print, that will be about a month later.
Thank you for writing down and sharing your experiences and insights, and making it accessible for just a mere buck.
No problem. I hope you find some useful tips in it.
I read the first part and I enjoyed it. I agree that us developers aren't great at communicating tech debt effectively. Managers are also not great at prioritizing it. I think the "debt" analogy has been a net negative as management often thinks "we'll just pay it later" but don't often see how much pain it's causing. So having a resource to help both sides on this topic is very valuable.
Thanks. That’s my belief as well. I would have loved to come up with a better term.
In the next two parts of the book I try to convince managers to give some autonomous time to engineers to do whatever tech debt projects they think is best. With some constraints and accountability.
I'm having this exact conversation with senior leadership in my team. I'm looking forward to it and I might do a book club reading when it comes out!
Any chance you’re selling the ePub format directly, or via the Kobo store? I switched from Kindle to Kobo a few months back, when Amazon decided to remove everyone’s ability to download the books they’ve purchased. But I’d love to read this!
My priority is Kindle, then print. Then I will look into other formats. At that point I will have a PDF (that was used for Print) and an epub, so it will primarily be driven by interest.
The best way to be notified by it is to be on my list at loufranco.com or reaching out to me.
A total tangent but it's amazing how more palatable "tech enhancement" is in planning, management chats, etc., than anything involving the term "tech debt"
Can you say more on your experience here? I've not heard people use that term before, and I'd be interested in how it received/what you think the difference is.
Sure, just that stories about "paying down tech debt" are an implicit admission of flaws and shortcuts and "doing it again because it wasn't done right initially".
Which is all true but the concept of making deliberate trade offs for speed and expedience invariably gets lost.
Stories about ongoing improvement - tech enhancement - just get seen as more positive. Plus that term covers both remediating original shortcut choices as well as new engineering improvements arising.
Thanks!
I wish you luck, and you’ve picked a good subject.
I once wrote a book (about 400 pages, after editing). No one read it, and rightly so. It covered a topic in a preachy, dictatorial manner. It’s long buried in a deep, unmarked grave, in the desert.
It was accurate, well-written, well-structured, relevant, and useful, but assumed a tone that was pure poison. It was aimed at an audience that did not respond well to the tone.
It was extremely valuable education for me, though. My mother was a scientific editor, and edited the book. It was brutal, and quite humbling, but her work ensured that the book was absolutely perfect. I don’t think I’ve ever shipped anything as close to [unpopular] perfection as that book.
Even though I have never been particularly interested in writing book-length stuff, since then, I continue writing to this day[0]. Here’s the latest thing I did (released a few days ago)[1]. I don’t really write for others; I write for myself.
Good luck.
[0] https://littlegreenviper.com/miscellany/
[1] https://littlegreenviper.com/series/passkeys/
[EDITED TO ADD] I typically get some downvotes, when I link to my postings. Long ago, I favorited a comment that I made, explaining this[2]. I don’t expect anyone to actually read it before hitting the down arrow, but I figured that I’d add it here, for elucidation.
[2] https://news.ycombinator.com/item?id=31860143
I do wish HN had a culture of being ok with linking to supporting material on our own sites. I have been blogging for 20+ years -- some of those posts are relevant (and I think useful).
I also mostly write for myself, but I want to get more of it out there because I think it's useful.
I sincerely wish you luck. As I said, I think it's a timely topic.
I didn't know helpthisbook existed. Interesting service.
As you may have noticed, people are conflating the HTB stuff with your material, and HTB should keep that in mind.
I have found that talking about improving software Quality is a deeply unpopular topic, on HN, and that kinda breaks my heart.
Refreshing to see a potential conflict[2] get solved in a civilized manner, rare these days. Thanks for including it.
It's a good topic and I am currently trying to manage lots of tech debt. So it caught my attention and I started to read, but it seems that you liked your swimming upstream allegory a little bit too much. Basically reading the same sentence several times in every chapter bored me and I quit...
Sorry to hear that. Fair.
Thanks for the link. Its always helpful to have new ways to describe tech dept. The term is too overloaded and most people roll their eyes when hearing it since it can be used to describe anything from real issues to things that are fine but you just do not like for whatever reason. Look forward to reading the section on what issues are worth paying down and those that are fine to live with. Its not any easy decision to make, but having concrete examples is always a bonus. For .99 cents pre-ordered a copy and if there is going to be a real book would love to have it sitting on my desk. It could sit next to Software Estimation by Steve McConnell ;) Cheers!
There will be a print book about a month after the Kindle version launches. It takes time to get the formatted properly (using a contractor). It will be offered for the Amazon minimum price to start -- if you want a notification, sign up on my site: https://loufranco.com/tech-debt-book.
will check out your blog ! cheers and good luck
Thanks. I hope it’s useful to you
DNR'ed pretty quickly.
You seem to be writing about other concepts and just redefining them as tech debt.
I left more detail in comments, but if I had purchased this book I would be seeking a refund, because I would be expecting a detailed exploration of technical debt, not just a focus on bad coding practice.
This is why I shared half the book. I will probably continue to do so for at least a few months (even after the book is launched). I am sharing a lot of the content of the next six chapters on my email list and will probably always have that archived for them.
I really don't want people to buy it if they won't like it.
Its not really an issue of getting to read before I buy.
Its very much that its advertised as something its not.
You could do research into technical debt and bring other peoples anecdotes and experiences into the book and bring the content in line with the title and readers expectations.
Or you could update the title and therefore manage expectations to ensure there are no misunderstandings.
Yes, I too noped out after a few minutes read.
Very distinct babblezone liturgy.
This whole thing reads as AI written and doesn't really talk about "tech debt" in any brass tacks way.
It was not AI written. I took 18 months to write it. I documented a lot of that on my blog in real time and in LinkedIn. I have posted several drafts of (hopefully) increasing quality publicly.
I get that you might not like my writing, but it is mine.
Anymore, if the first thing I get when I visit a site is some kind of modal popup, I just close the tab. This shit has got to stop.
I find helpthisbook.com to be helpful in getting comments on the book and sharing it. I'll send this feedback to them.