4 ms·

Meh. The company I'm at is in the exact same situation as the 'self serve' company described, taking the low end of the market while a larger company fails to d

Meh. The company I'm at is in the exact same situation as the 'self serve' company described, taking the low end of the market while a larger company fails to do so. The way we approach enterprise is uncannily similar to the way they described the other company doing so: use our API which does the hard domain specific stuff. Except we're the opposite of self serve. Virtually every customer pays us for technical support, and our developer (I'm effectively the only one), talks to customers practically every day about what they need in the product and to our services staff about their challenges. The insight this provides is invaluable. Companies in the market with dozens/hundreds of developers are worse at deploying new features than we are with a single developer (yes, I write tests and use industry best practices for my stack, extra work up front, but development is waaaay faster years later). Think ViaWeb's Lisp advantage, except our real secret weapon is just that 1 developer who talks to all their customers and their services department is as good as 20 who don't (I'm using C#/Vue for web [with an erlang like actor framework I built] and C++/Lisp for embedded). There are certainly challenges scaling, and dear lord am I underpaid (I'm more interested in autonomy than the 3x-10x money I'd get from moving to a competitor), but self serve is orthogonal to our customer appeal. (Others in the market might actually think we're self serve though, just because our software is user friendly and self serve is actually possible).

balfirevic 7y ago
Wow, while reading this I was thinking to myself: "this person better be a co-founder!". You obviously don't need any advice since you know what you want and you know what you're doing. But I couldn't help thinking - 10x-ing your pay gets you 9 years of complete autonomy for every year spent working. Also, are there any quick insights you can share about using actor model with .Net? Did it shine, did it make some things harder then you thought they would be? Thanks!
- caseymarquis 7y ago
  I'll answer the last bit first (I have no other developers to talk to at work, so excuse me for the wall of text): It's not exactly a traditional actor framework, so you might be a bit underwhelmed. It's single process (working on extending that, as we use P/Invoke, and a mistake there can completely crash the process; that said, hiding the details of distributed calls seems like a bad decision, so I'm still thinking about how to best approach this). Message passing is done through individual typed queues. Actors don't run when a message is received, but instead decide how often they should be run, and then poll for available messages from their queues (or just perform some timed action). Actors don't fail-fast so much as ensure proper logging and try again later (though parents may manually monitor and dispose their children). The biggest flaw I see is that message passing involves locking, and while I've tried to abstract this away with 'MessageQueue' and 'Atom' primitives, a user could easily circumvent this or pass mutable data. While I could easily catch and correct this if we bring a new developer on board, if someone were to start using the framework with no guidance, I worry they would not 'fall into the pit of success'. Designing a language around the actor model allows you to solve these issues: https://www.ponylang.io/discover/#what-is-pony https://www.ponylang.io/discover/#what-is-pony I've actually made the framework available as an open source library: https://github.com/caseymarquis/KC.Actin https://github.com/caseymarquis/KC.Actin I wouldn't say I'm proud of the framework's code. It could be better organized and more understandable (unfortunately, you can't use dependency injection when making the framework which does your dependency injection). What I am proud of is how simple and organized our main codebase is because of our use of the framework. A new developer can simply create a file containing a class, mark it with an attribute, specify its dependencies as private fields (also marked with attributes), and then create new functionality independent of what everyone else is doing. Effectively, fences are drawn between independent portions of the codebase in the style of 'micro-services', except there's no need for separating into separate services until a bottleneck is introduced (so there are no pointless debugging nightmares). I still have a lot of plans for building tooling around the framework: profiling, visualizations, monitoring, reporting to a centralized parent, inspection of running systems using reflection (remote inspection?), etc. I probably wouldn't recommend using it unless you're a brave soul. Maybe check in after a year or two and there will be something a bit more fleshed out. Having said all that, the actor model is a natural fit in our problem space. Our software talks to dozens of types of mission critical systems and physical equipment, each of which has the potential to fail outside of our control. I think the actor model would have been a perfect match for our software regardless of language. That said, .NET's excellent reflection and the ability to dynamically compile lambdas made it possible for the actor paradigm to feel native. I think that there's a lot of untapped potential in .NET surrounding this (making frameworks for one's domain). Regarding switching jobs: You're not wrong. There are other factors I didn't mention though. 10xing my pay would put me at the pay level of a mid-range FAANG employee. The main issue is that I would either have to move to get this kind of pay, or do a large amount of traveling (depending on the role I took). I do not live in a software hub (I live in an aerospace manufacturing hub), and so there aren't a lot of options in the area. Additionally, I feel loyalty to our team, and my leaving would have a major negative impact on them (they'd need 3 people they couldn't afford to replace me). I'm happy to have a good job in the area that I (mostly) enjoy, and to be innovating in a B2B space which allows me to make a lot of people happy. Five years from now I may feel differently (or we'll have substantially increased my pay). I get a lot of job offers, and they'll probably still be there in 5 years. At least one of the current owners wants to give me an ownership percentage, but I've told them to just keep increasing my pay as revenue increases instead. Most companies fail, typically from structural/organizational issues. I think ownership may be overrated. I could be wrong though. I think owning a piece of the company would feel more like the company owned me, and that I was stuck with it. Right now I feel like I'm choosing the company, and have the ability to easily leave if needed. Not 100% rational, but feeling good is important. I'd be much more likely to start a contracting business than found a company.
chrisan 7y ago
We are(were) the exact same way, and I hate(d) it. Every customer is a whale and has demands, both on features and deadlines. Failing to meet these can result in losing the customer and the more customers we get the harder it is to balance/scale it all. Scale is personnel scale to handle each new challenges new clients bring. Somehow no matter what the is always a new client with some new demand we have never seen before. I don't see how your development is way faster, how do you handle multiple requests from multiple companies all different? Last year we started our self serve initiative and have slowly been growing there. Before we might have clung on anyway possible to keep the whale where now if they are too much of a hassle we can comfortably say "no" to something and not sweat their loss. With self serve, we are much more scalable. We don't need to hire more devs just because we have more companies. This is our product this is how you can integrate it and these are the customizations. We still take client requests, but we weigh them with other requests and if we deem them mutually beneficial to a majority it will get prioritized. We talk with our clients weekly and they have access to basecamp/jira/email to communicate individually, you can still get plenty of insights
- caseymarquis 7y ago
  I hate it sometimes too, and lose a lot of time to frequent interuptions. It still seems to work for us though. I think there may be some differences in our situation based on what you've said. We don't hunt whales. We actually avoid them (whales take a long time to pay you, and are very demanding). If one customer wants something from us which we don't think will benefit our customer base as a whole, we point them to our various APIs, or just tell them no. That said, usually they want things which benefit our whole customer base, and so we're happy to work with them to provide this. Customers almost always buy the software 'as-is'. While customers expect to be able to communicate their future needs to us, and expect our software to improve over time, very rarely does a sale hinge on developing a new feature. If it does, I am always consulted and will advise on whether we should agree to the sale (I'm consulted on unusual sales anyway). The reason we're not 'self-serve' is because we have a services department devoted to providing a complete solution for our customers. Either remotely, or while visiting their facility. Customers pay for this separately. We'll definitely need to hire more developers as we continue to grow, and I'm sure we'll face challenges scaling how we operate now, but I think the benefits are worth it. Regarding getting features out the door faster with a single person. This is because I know the problem domain inside and out, even though it's a moving target. I know the domain because I constantly communicate with our end users and services staff (I used to be our whole services staff; very happy to have gotten past that!). Oddly enough, the frustration of being interrupted is usually rewarded. I've had a lot of phone calls that started with me thinking 'I don't want to deal with this right now...', and ended with me thinking 'What a great idea for adding value to our product! I'm so glad I spoke with them directly!'. Typically the customer asks for something, and then we talk about why they want it, and we eventually (together) figure out an even better way to solve their real problem. Anyway, YMMV. It sounds like the bigger challenge you're seeing is clients demanding new features, and deciding there's not acceptable ROI without them. That's definitely a problem, but I don't think it's necessarily solved by not having a team that does implementations?

balfirevic 7y ago

Wow, while reading this I was thinking to myself: "this person better be a co-founder!". You obviously don't need any advice since you know what you want and you know what you're doing. But I couldn't help thinking - 10x-ing your pay gets you 9 years of complete autonomy for every year spent working. Also, are there any quick insights you can share about using actor model with .Net? Did it shine, did it make some things harder then you thought they would be? Thanks!

caseymarquis 7y ago
I'll answer the last bit first (I have no other developers to talk to at work, so excuse me for the wall of text): It's not exactly a traditional actor framework, so you might be a bit underwhelmed. It's single process (working on extending that, as we use P/Invoke, and a mistake there can completely crash the process; that said, hiding the details of distributed calls seems like a bad decision, so I'm still thinking about how to best approach this). Message passing is done through individual typed queues. Actors don't run when a message is received, but instead decide how often they should be run, and then poll for available messages from their queues (or just perform some timed action). Actors don't fail-fast so much as ensure proper logging and try again later (though parents may manually monitor and dispose their children). The biggest flaw I see is that message passing involves locking, and while I've tried to abstract this away with 'MessageQueue' and 'Atom' primitives, a user could easily circumvent this or pass mutable data. While I could easily catch and correct this if we bring a new developer on board, if someone were to start using the framework with no guidance, I worry they would not 'fall into the pit of success'. Designing a language around the actor model allows you to solve these issues: https://www.ponylang.io/discover/#what-is-pony https://www.ponylang.io/discover/#what-is-pony I've actually made the framework available as an open source library: https://github.com/caseymarquis/KC.Actin https://github.com/caseymarquis/KC.Actin I wouldn't say I'm proud of the framework's code. It could be better organized and more understandable (unfortunately, you can't use dependency injection when making the framework which does your dependency injection). What I am proud of is how simple and organized our main codebase is because of our use of the framework. A new developer can simply create a file containing a class, mark it with an attribute, specify its dependencies as private fields (also marked with attributes), and then create new functionality independent of what everyone else is doing. Effectively, fences are drawn between independent portions of the codebase in the style of 'micro-services', except there's no need for separating into separate services until a bottleneck is introduced (so there are no pointless debugging nightmares). I still have a lot of plans for building tooling around the framework: profiling, visualizations, monitoring, reporting to a centralized parent, inspection of running systems using reflection (remote inspection?), etc. I probably wouldn't recommend using it unless you're a brave soul. Maybe check in after a year or two and there will be something a bit more fleshed out. Having said all that, the actor model is a natural fit in our problem space. Our software talks to dozens of types of mission critical systems and physical equipment, each of which has the potential to fail outside of our control. I think the actor model would have been a perfect match for our software regardless of language. That said, .NET's excellent reflection and the ability to dynamically compile lambdas made it possible for the actor paradigm to feel native. I think that there's a lot of untapped potential in .NET surrounding this (making frameworks for one's domain). Regarding switching jobs: You're not wrong. There are other factors I didn't mention though. 10xing my pay would put me at the pay level of a mid-range FAANG employee. The main issue is that I would either have to move to get this kind of pay, or do a large amount of traveling (depending on the role I took). I do not live in a software hub (I live in an aerospace manufacturing hub), and so there aren't a lot of options in the area. Additionally, I feel loyalty to our team, and my leaving would have a major negative impact on them (they'd need 3 people they couldn't afford to replace me). I'm happy to have a good job in the area that I (mostly) enjoy, and to be innovating in a B2B space which allows me to make a lot of people happy. Five years from now I may feel differently (or we'll have substantially increased my pay). I get a lot of job offers, and they'll probably still be there in 5 years. At least one of the current owners wants to give me an ownership percentage, but I've told them to just keep increasing my pay as revenue increases instead. Most companies fail, typically from structural/organizational issues. I think ownership may be overrated. I could be wrong though. I think owning a piece of the company would feel more like the company owned me, and that I was stuck with it. Right now I feel like I'm choosing the company, and have the ability to easily leave if needed. Not 100% rational, but feeling good is important. I'd be much more likely to start a contracting business than found a company.

chrisan 7y ago

We are(were) the exact same way, and I hate(d) it. Every customer is a whale and has demands, both on features and deadlines. Failing to meet these can result in losing the customer and the more customers we get the harder it is to balance/scale it all. Scale is personnel scale to handle each new challenges new clients bring. Somehow no matter what the is always a new client with some new demand we have never seen before. I don't see how your development is way faster, how do you handle multiple requests from multiple companies all different? Last year we started our self serve initiative and have slowly been growing there. Before we might have clung on anyway possible to keep the whale where now if they are too much of a hassle we can comfortably say "no" to something and not sweat their loss. With self serve, we are much more scalable. We don't need to hire more devs just because we have more companies. This is our product this is how you can integrate it and these are the customizations. We still take client requests, but we weigh them with other requests and if we deem them mutually beneficial to a majority it will get prioritized. We talk with our clients weekly and they have access to basecamp/jira/email to communicate individually, you can still get plenty of insights

caseymarquis 7y ago
I hate it sometimes too, and lose a lot of time to frequent interuptions. It still seems to work for us though. I think there may be some differences in our situation based on what you've said. We don't hunt whales. We actually avoid them (whales take a long time to pay you, and are very demanding). If one customer wants something from us which we don't think will benefit our customer base as a whole, we point them to our various APIs, or just tell them no. That said, usually they want things which benefit our whole customer base, and so we're happy to work with them to provide this. Customers almost always buy the software 'as-is'. While customers expect to be able to communicate their future needs to us, and expect our software to improve over time, very rarely does a sale hinge on developing a new feature. If it does, I am always consulted and will advise on whether we should agree to the sale (I'm consulted on unusual sales anyway). The reason we're not 'self-serve' is because we have a services department devoted to providing a complete solution for our customers. Either remotely, or while visiting their facility. Customers pay for this separately. We'll definitely need to hire more developers as we continue to grow, and I'm sure we'll face challenges scaling how we operate now, but I think the benefits are worth it. Regarding getting features out the door faster with a single person. This is because I know the problem domain inside and out, even though it's a moving target. I know the domain because I constantly communicate with our end users and services staff (I used to be our whole services staff; very happy to have gotten past that!). Oddly enough, the frustration of being interrupted is usually rewarded. I've had a lot of phone calls that started with me thinking 'I don't want to deal with this right now...', and ended with me thinking 'What a great idea for adding value to our product! I'm so glad I spoke with them directly!'. Typically the customer asks for something, and then we talk about why they want it, and we eventually (together) figure out an even better way to solve their real problem. Anyway, YMMV. It sounds like the bigger challenge you're seeing is clients demanding new features, and deciding there's not acceptable ROI without them. That's definitely a problem, but I don't think it's necessarily solved by not having a team that does implementations?