I also founded, grew, but have not yet sold a boutique software services co.
I see on your profile you sold to a client. We have had that option before but the multiple on our earnings was too low to actually consider it. Curious what your revenue/earnings multiple was on the acquisition. Also curious about the handcuff terms. Giving up autonomy over my daily life is hard to swallow without 8 figures.
I can't get into exact details. It was a fairly typical multiple, a bit higher than normal after some negotiation. That's smaller than a startup, obviously, as there was no IP, just a team. However, since we were bootstrapped, all of the money went to us, none to investors.
It ended up being fairly profitable to sell, though we were by no means dependent on this - we could have just as easily continued and possibly gotten more money in the long run by not selling (with a greater risk, of course).
What's trippy is whatever workflow you have is probably molded around tools and biases that you take for granted. In modern times, there is no workflow that exists independent of technology. I can't imagine a way to isolate a "workflow" from a toolchain. And at that rate, you might as well just sample different tools until you find harmony.
Glad you can defend the totally opposing view well. Respect on the 'knowledgable about the domain' point.
I would argue that there is no more abundant resource than whitespace on computers. Useless comments (usually written after the syntax is written) definitely suck. But in a file with well written comments, you can actually just read the comments alone and understand the code as fast as you could read news headlines.
Another point, the only purpose of code as we know it is to serve as a human-readable translation of machine instruction. To me, the best achievement of that is a document that reads like natural language. After all, wouldn't it be better if we could just describe intentions in common speak and have the computer figure out the details? To me, well thought verbosity in code is a step towards that.
First, in the context of this argument, I'm talking about work in high level languages like Python, JS, fairly expressive C++, etc. If we were coding in assembler -- LEA, LDR, JNZ.. -- I'd definitely want a ton of low level comments!
When I say wasting space, it's not about disk space, or shrinking your screen size, or even formatting. It's more about what you can see all at once.
Think back to a recent time when you had a tough to fix bug. Like something really not trivial that you beat yourself up about for a while.
I bet it involved you working through various levels of libraries, opening them side by side or paging back and forth, trying to figure out what went wrong in the logic.
It probably wasn't cuz you misunderstood what a variable did. We have great ways to document that, like the function header.
Now imagine that process if it's all on the same screen. If everything feels "tangible" to you, because each level of logic (to some reasonable point) is visible, accessible.
When I encounter a code base with hundreds of source files in various folders and some flimsy abstraction tying it all together, such that I can't see a clear delineation between parts, I go nuts!
Here's a very practical example. Imagine you have some library that wraps a remote API. Something important, like Payments. The hard part there is understanding failures (does it retry?), edge cases (whats diff when i run a test CC#?), stored state (can I resume this from a different part of the code?).. those things are mighty hard to glean even from good statement-level comments, even if I could take the time to read all 3,000 lines of code.
We need higher level great docs.
I'd love to code in English or something like it, but looking at the code on my screen right now, those would be some really complex sentence structures. :)
Definitely agree on too-many-files. Documenting architecture is a whole 'nother art that's overlooked.
We diverge on locating errant code though, big time.
You'd trip at my code in the payments example because whatever is 3000 for you would easily be 5000 for me. Not only do I write comments before each line of verbose syntax, but I also add blank lines after braces and between logical "blocks" of operations.
However, that structure also gives me a mostly searchable index of every logical block of my code. That gives me a very straightforward way to bisect down to the problem, no matter how far away that code is linearly. It feels like lots of little sandwiches instead of a giant sandwich, and I'm looking for one bad slice of meat. I at least can quickly scan and jump to sandwiches containing meat when they are so explicitly separated and annotated.
I'd also argue that since good comments (written before syntax) can be read as their own document, I also have full coverage documentation by default. If I wanted to produce a crazy deep documentation page, I could actually just pull every line starting with // or /* (but really I just use Docstrings/JSDoc/etc on top of my inline comments).
I believe I've arrived on this out of practicality. I maintain 10+ codebases of differing platforms at any one time, and my most frequent problem in life is arriving at a codebase and thinking "Okay, what was going on here?". My approach now is just "read the green" (I color my comments slightly green gray) and within minutes, I can understand the entire functionality of that code and search for patterns I know will exist. I don't believe that's possible in equivalent time by executing the program line by line in your head.
Excess whitespace is extremely harmful, because it reduces, in exact proportion, the amount that can be seen, at once, of the code that actually does things. Same applies to prolix commenting. The code that does things is what people working on it need to see. A comment that explains why a thing is done might be consulted when purpose is unclear or not obvious. That is why a good coding editor grays out comment text.
Whitespace deployed very judiciously directs attention where it is needed without need for distracting verbiage.
Far more scarce than any other resource is attention. Anything that steals attention away from where it is needed most is actively harmful, creating bugs and misdesign, and knocking people out of productive flow.
The attention point is strong. However, I believe that it becomes a non issue if the concerns are well separated into the black boxes that they would be if drawn on a whiteboard. Fully disagree that whitespace is dangerous. It is only useless when misused.
IMHO, comments should never describe what the code does. We're engineers, we can all read code and see what it does (or refer to the Javadoc). Comments should be used to describe WHY the author is doing something non-obvious in the code.
Definitely agree with commenting deviations. Although I also advocate comments for each "operation". No problem if 5 lines of the same operation go uncommented, but if you have 5 lines of map().reduce().filter(), save your friends time and just pop in a
// Find the top 3 posts by comment count
Suffering comments you already understand > running a VM in your head when you forgot
They also have a poor reputation, and for what seems like a good reason. It's a risky proposal that generally attracts a get-rich-quick kind of community. Examine the Nikola company and tell me how comfortable you'd be investing a sizeable chunk of your net worth in that.
I can't predict the future, but I can bet $10k I will die before SPACs get to even half of VC funding. Side pot of $1k that 50% of them fail their investors, and another side pot that one in the next decade will be a historically spectacular failure.
I’m aware that it’s not new but Virgin Galactic’s SPAC ushered in a new era of blank check companies being spun up, which is why I’m bringing it up.
Look at the recent S-1 filings...there are already 64 “acquisiton” firms that have filed in August alone https://sec.report/Form/S-1
Is this a short term SPAC bubble? Very possible. But SPAC investors and founders are much wiser now, and if done right it’s entirely possible to completely side step traditional VC if the “good ones” prove to be successful.
I see that it could displace VC somewhat in dollar amount, but there are some serious bottlenecks around filing with the SEC and getting listed to where it'd be prohibitive for a large number of companies to start that way. It's definitely a lot harder, more all-or-nothing, and more time consuming than getting a million-dollar SAFE and building a prototype. And SPACs are also dependent on consuming those "traditional" companies to fulfill their empty promise. What feels most intuitive though is the propagation/decline of SPACs will simply be based on the successes/failures of the SPACs we're watching now. Tech and finance seem to have few mechanisms outside of pattern matching what got their predecessors rich.
yeah I’m not suggesting that SPACs are appropriate for pre-product startups. I see them replacing VCs in what would otherwise be a growth stage round eg post Series A/B.
So we will still have angel and seed/early stage investors, but I see SPACs easily competing with what would otherwise be large late stage or growth rounds that the big VC firms are most active in.
I see on your profile you sold to a client. We have had that option before but the multiple on our earnings was too low to actually consider it. Curious what your revenue/earnings multiple was on the acquisition. Also curious about the handcuff terms. Giving up autonomy over my daily life is hard to swallow without 8 figures.